dex2oat編譯兩種模式
Ⅰ dex2oat 有什麼用
dex2oat的用處：
眾所周知，Android虛擬機可以識別的是dex文件，應用使用過程中如果每次將dex文件載入進行內存，解釋性執行位元組碼，效率會很低，嚴重影響用戶體驗。
通過dex2oat優化後，可以在系統運行之前利用合適的時機將dex文件位元組碼提前轉化為虛擬機可以執行運行的機器碼。
後續直接從效率更高的機器碼中運行，則運行階段更加流暢，優化用戶體驗。
Dex2oat (dalvik excutable file to optimized art file)，是一個對 dex 文件進行編譯優化的程序，在我們的 Android 手機中的位置是/system/bin/dex2oat。
對應的源碼路徑為 android/art/dex2oat/dex2oat.cc。
通過編譯優化，可以提升用戶日常的使用體驗（包含安裝速度、啟動速度、應用使用過程中的流暢度等），是 Android Art Runtime 中的一個重要的模塊， 本文我們一起來了解下 dex2oat 的功能以及常用的場景。
Ⅱ 如何反編譯 android 中 /data/dalvik-cache/arm 下的文件
所有的 apk 內包含一個 classes.dex 文件。在 Dalvik上，apk包里的 dex文件在安裝的時候會通過 dexopt 轉化成另一個格式，叫odex（Opitimized dex），然後存在 /data/dalvik-cache裡面，如：
/data/dalvik-cache/data@[email protected]@classes.dex
雖然文件後綴還是 .dex，但是這個dex和apk內的那個已經不一樣了。這個文件是針對當前機器的硬體對 dex 文件進行了定製化，也就是說把這個放到別的設備上，不一定能運行。
PS: 在要編譯 rom 的時候，如果參數加上 "WITH_DEXPREOPT=true"，會在 /system/app/ 下同時生成 .apk 和 .odex 文件（注意，這里後綴又用的 .odex，但實際上和系統在 /data/dalvik-cache/ 下的 .dex文件是一樣的）
ART
在 ART上，apk 包里的 dex文件在安裝的時候通過 dex2oat，也會生成一個後綴為 .dex 的文件，放在 /data/dalvik-cache中，如：
/data/dalvik-cache/arm/system@app@[email protected]@classes.dex
/data/dalvik-cache/arm64/system@vendor@app@[email protected]@classes.dex
這個文件後綴叫 .dex ，但是這個文件又不一樣了，這個既不是 dex 也不是 odex，用 dex2jar 的無法進行反編譯的。文件格式也完全不同，因為這其實就是一個實打實的 elf文件，這個文件已經可以直接在機器上運行了。
為何 pm.jar 是空的？
首先來了解一下 ROM 的編譯選項，看一下編譯的時候能做什麼事情， 大致了解就行了 。
編譯選項
WITH_DEXPREOPT
使能編譯時生成 OAT，避免第一次開機時編譯耗時，但會增大 system分區的空間消耗
DONT_DEXPREOPT_PREBUILTS
使能後，將不會對 Android.mk中包含了 include $(BUILD_PREBUILT)的 Apk進行 oat，例如 Gmail，它很可能會在後期通過商店自行升級，而升級後系統中的 oat文件則沒有意義了，但又無法刪除，會造成空間的浪費（oat比dex文件要大）
WITH_DEXPREOPT_BOOT_IMG_ONLY
僅僅針對 boot.img進行oat優化（boot.img中包含 boot.art和 boot.oat）
LOCAL_DEX_PREOPT ture|false|nostripping
可用於各個 Android.mk，對每個 package進行單獨配置，當設置為 true時，dex文件將會從 apk中剔除，如果不想剔除可使用 nostripping WPRODUCT _DEX PREOPT_*
WPRODUCT__DEX_PREOPT_*
PRODUCT_DEX_PREOPT_BOOT_FLAGS
這里的參數將會傳至 dex2oat，控制 boot.img的編譯優化行為。
PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
控制除 boot.img 外，其他（如 jar, apk）的 OAT編譯行為 例如：
PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler- filter=interpret-only
$(call add-proct-dex-preopt-mole- config,services,--compiler-filter=space)
WITH_DEXPREOPT_PIC ture|false
使能 position-independent code，這樣在dex2oat編譯生成的 odex文件在運行時將不必再從 /system 下拷貝到 /data/dalvik-cache/ 目錄下， 可以節省 /data 空間
WITH_ART_SMALL_MODE true|false
設置為 true 時，將只編譯處於 boot classpath 里的類，其他的均不編譯，這樣既能加快第一次開機時間，因為大部分必要的類已經編譯過了； 同時也能節省不少空間，因為 APP 都未進行編譯。缺點是可能損失一性能，這可能要平時覺察不出，但在跑分軟體上會有所體現
編譯選項的經典配置
為了提高第一次開機速度，WITH_DEXPREOPT是必須使能的，這樣則在編譯階段會完成 dex2oat的操作，避免在開機時間去做這個轉碼，節省了開機時間（6min以上縮短2min內）。
但會引起一個缺點，那就是 apk中還是包含了 class.dex（dexopt生成的），同時在對應的apk文件夾中又生成了已經轉碼成oat的 class.odex（dex2oat生成的），相當於這部分重復，造成了大量的空間浪費。
為了把 apk包里的 class.dex去除，節省空間，可以打開 DEX PREOPT DEFAULT := ture。
然而，這樣開機速度是快了，而且節省了不少system空間，但開機後，咱們會發現即使在 system中已經存在 class.odex的 apk，第一次開機後還是會在 /data下面生成 class.odex，如data/dalvik-cache/arm64/system@app@[email protected]@classes.dex，這是何解？原來 Google為了提高安全性，在每一台機器開機時都會在之前的機器碼加一個隨機的偏移量，這個偏移量是隨機的，每台機器都不相同，而 data分區下的這些文件就是從 system下的 class.odex加上偏移而來。
Ⅲ android dex2oat 處理加固應用
好的。。。。
Ⅳ 如何在刷機包里開啟dex2oat模式
刷機准備工作：1、保證手機有充足的電量（70%以上）；2、備份手機中的個人數據（聯系人、簡訊、應用程序等）；3、下載官方包或其它刷機包（可以到官網論壇，ROM基地下載）。方法步驟：1、首先將刷機包包拷貝到手機存儲卡的根目錄下。2、關機狀態下，同時按住電源鍵與音量下鍵，約十秒鍾時間之後，屏幕上將出現黑底黃字，這說明手機已經進入Recovery模式。3、使用音量上、下按鍵將游標移動到「手動選擇安裝包」位置，點擊電源鍵進行確認。接下來使用音量上、下按鍵選擇安裝包，點擊電源鍵進行確認。 4、只需等待自行完成，機過程中手機始終保持屏幕點亮狀態，除了不斷滾動的黃色文字之外還有藍色的進度條顯示在綠色機器人的下方。最終屏幕最下方將顯示「安裝完成」字樣，機完成，5、根據提示選擇立即重啟系統，完成。
Ⅳ android在哪個版本上強制使用art為唯一的運行時環境
在安裝應用程序時會調用dex2oat將代碼轉換為機器語言以oat文件形式存儲在本地，這樣在運行程序時就不會每次都進行一次編譯了，執行效率也大大提升。
Android運行環境ART
安卓之前的版本運行機制是Dalvik，這個導致安卓卡慢，安卓4.4之後推出了ART，在5.0上完全使用了ART模式。
ART 的機制與 Dalvik 不同。在Dalvik下，應用每次運行的時候，位元組碼都需要通過即時編譯器轉換為機器碼，這會拖慢應用的運行效率，而在ART 環境中，應用在第一次安裝的時候，位元組碼就會預先編譯成機器碼，使其成為真正的本地應用。這個過程叫做預編譯（AOT,Ahead-Of-Time）。這樣的話，應用的啟動(首次)和執行都會變得更加快速。
通俗一點就是，ART增加APK安裝容量，實現了流暢度。
Ⅵ 如何利用dex2jar反編譯APK
本篇講述如何利用dex2jar反編譯APK，筆者親試可用，希望對大家有幫助
工具/原料
電腦
dex2jar
JD-GUI
方法/步驟
下載dex2jar和JD-GUI，在參考資料中添加了這兩個工具的網路網盤下載地址供讀者下載使用（筆者親測）
找到我們准備測試用的apk，並將 後綴.apk改為.zip
將test.zip解壓，並查看目錄，找到classes.dex
並將這個文件拷至dex2jar工具存放目錄下
打開控制台，使用cd指令進入到dex2jar工具存放的目錄下
進入到dex2jar目錄下後，輸入「dex2jar.bat classes.dex」指令運行
執行完畢，查看dex2jar目錄，會發現生成了classes.dex.dex2jar.jar文件
上一步中生成的classes.dex.dex2jar.jar文件，可以通過JD-GUI工具直接打開查看jar文件中的代碼
Ⅶ Android運行環境ART的主要特點
在安裝應用程序時會調用dex2oat將代碼轉換為機器語言以oat文件形式存儲在本地，這樣在運行程序時就不會每次都進行一次編譯了，執行效率也大大提升。
Ⅷ dex2oat和dexmp是什麼
非木馬，無影響，佔用空間很小，但可刪除
Ⅸ 如何進行ODEX反編譯實例
反編譯普通的APK文件：
對於普通的APK/DEX文件的反編譯，其實工具有很多, 包括：
ByteCode Viewer: 一個可視化的集成工具，說實話，不太好用，不夠穩定，生成代碼質量中等。
dex2jar + jd_gui: 這兩個工具組合還可以， 用起來比ByteCode Viewer麻煩一些，但比較穩定，生成代碼質量中等。
反編譯ODEX文件：
Android 5.0 Lollipop以後，Google用ART代替了以前的Dalvik，對於普通的app來說我們仍然可以用上面的方法來把dex文件反編譯成java源代碼。但對於系統預裝的App，特別是類似應用商店，播放器等， 你會發現這些應用的apk文件中找不到對應的classes.dex文件，而是會發現在其子目錄下有個.odex文件。 那如何反編譯這個odex文件呢？我通過google查了查，知道應該用baksmali，但從github上下載了幾個版本都不行，報各種不同錯誤。
具體方法如下：
1. 從 這里 下載工具包， 解壓縮到本地。 這里的baksmali的版本是2.0.3. 不同版本的baksmali針對的Android內核不同。有時候高版本反倒不好用。
2. 打開工具所在目錄， 按住shift鍵， 點擊滑鼠右鍵，打開Windows命令窗口
3. 把 odex文件拷貝到該目錄
4. 在命令窗口運行： oat2dex.bat *.odex . 正常情況下，應該顯示OK等信息。如果報錯的話，說明這個文件無法轉換，後面的也不用試了。
5. 運行 oat2dex.bat *.odex temp.dex . 運行後會創建一個temp.dex文件。
6. 運行 java -jar baksmali-2.0.3.jar -a 21 -x temp.dex -o source . 運行後會創建一個source的文件夾，並將temp.dex反編譯到該文件夾。-a 21 表明的是Android內核的版本21
7. 運行 java -jar small-2.0.3.jar -a 21 source -o classes.dex , 反編譯為classes.dex文件。
需要注意的是：由這種方式反編譯成的classes.dex 文件相比原生的classes.dex 還是缺少了些信息，因此反編譯這種classes.dex 文件後生成的java代碼可讀性會更差些。
8. 用在線工具JADX 來把 classes.dex 最終反編譯為java代碼。
Ⅹ 如何反編譯 android 中 /data/dalvik-cache/arm 下的文件
所有的 apk 內包含一個 classes.dex 文件。在 Dalvik上，apk包里的 dex文件在安裝的時候會通過 dexopt 轉化成另一個格式，叫odex（Opitimized dex），然後存在 /data/dalvik-cache裡面，如：
/data/dalvik-cache/data@[email protected]@classes.dex
雖然文件後綴還是 .dex，但是這個dex和apk內的那個已經不一樣了。這個文件是針對當前機器的硬體對 dex 文件進行了定製化，也就是說把這個放到別的設備上，不一定能運行。
PS: 在要編譯 rom 的時候，如果參數加上 "WITH_DEXPREOPT=true"，會在 /system/app/ 下同時生成 .apk 和 .odex 文件（注意，這里後綴又用的 .odex，但實際上和系統在 /data/dalvik-cache/ 下的 .dex文件是一樣的）
ART
在 ART上，apk 包里的 dex文件在安裝的時候通過 dex2oat，也會生成一個後綴為 .dex 的文件，放在 /data/dalvik-cache中，如：
/data/dalvik-cache/arm/system@app@[email protected]@classes.dex
/data/dalvik-cache/arm64/system@vendor@app@[email protected]@classes.dex
這個文件後綴叫 .dex ，但是這個文件又不一樣了，這個既不是 dex 也不是 odex，用 dex2jar 的無法進行反編譯的。文件格式也完全不同，因為這其實就是一個實打實的 elf文件，這個文件已經可以直接在機器上運行了。
為何 pm.jar 是空的？
首先來了解一下 ROM 的編譯選項，看一下編譯的時候能做什麼事情， 大致了解就行了 。
編譯選項
WITH_DEXPREOPT
使能編譯時生成 OAT，避免第一次開機時編譯耗時，但會增大 system分區的空間消耗
DONT_DEXPREOPT_PREBUILTS
使能後，將不會對 Android.mk中包含了 include $(BUILD_PREBUILT)的 Apk進行 oat，例如 Gmail，它很可能會在後期通過商店自行升級，而升級後系統中的 oat文件則沒有意義了，但又無法刪除，會造成空間的浪費（oat比dex文件要大）
WITH_DEXPREOPT_BOOT_IMG_ONLY
僅僅針對 boot.img進行oat優化（boot.img中包含 boot.art和 boot.oat）
LOCAL_DEX_PREOPT ture|false|nostripping
可用於各個 Android.mk，對每個 package進行單獨配置，當設置為 true時，dex文件將會從 apk中剔除，如果不想剔除可使用 nostripping WPRODUCT _DEX PREOPT_*
WPRODUCT__DEX_PREOPT_*
PRODUCT_DEX_PREOPT_BOOT_FLAGS
這里的參數將會傳至 dex2oat，控制 boot.img的編譯優化行為。
PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
控制除 boot.img 外，其他（如 jar, apk）的 OAT編譯行為 例如：
PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler- filter=interpret-only
$(call add-proct-dex-preopt-mole- config,services,--compiler-filter=space)
WITH_DEXPREOPT_PIC ture|false
使能 position-independent code，這樣在dex2oat編譯生成的 odex文件在運行時將不必再從 /system 下拷貝到 /data/dalvik-cache/ 目錄下， 可以節省 /data 空間
WITH_ART_SMALL_MODE true|false
設置為 true 時，將只編譯處於 boot classpath 里的類，其他的均不編譯，這樣既能加快第一次開機時間，因為大部分必要的類已經編譯過了； 同時也能節省不少空間，因為 APP 都未進行編譯。缺點是可能損失一性能，這可能要平時覺察不出，但在跑分軟體上會有所體現
編譯選項的經典配置
為了提高第一次開機速度，WITH_DEXPREOPT是必須使能的，這樣則在編譯階段會完成 dex2oat的操作，避免在開機時間去做這個轉碼，節省了開機時間（6min以上縮短2min內）。
但會引起一個缺點，那就是 apk中還是包含了 class.dex（dexopt生成的），同時在對應的apk文件夾中又生成了已經轉碼成oat的 class.odex（dex2oat生成的），相當於這部分重復，造成了大量的空間浪費。
為了把 apk包里的 class.dex去除，節省空間，可以打開 DEX PREOPT DEFAULT := ture。
然而，這樣開機速度是快了，而且節省了不少system空間，但開機後，咱們會發現即使在 system中已經存在 class.odex的 apk，第一次開機後還是會在 /data下面生成 class.odex，如data/dalvik-cache/arm64/system@app@[email protected]@classes.dex，這是何解？原來 Google為了提高安全性，在每一台機器開機時都會在之前的機器碼加一個隨機的偏移量，這個偏移量是隨機的，每台機器都不相同，而 data分區下的這些文件就是從 system下的 class.odex加上偏移而來。