上一篇?Apktool 使用教程 - 簡書?簡單說明了以下 apktool 的基本使用。能夠反編譯和重新打包一個apk了。

如果你學會了使用 -d ，-b 進行apk的反編譯和重新打包。

那么恭喜你！apktool你已經學會了90%的使用了，你也能夠反編譯絕大多數的apk了。

但事情總有小小的例外，有那么一些apk它就是不讓你如愿。比如加固過的，或者一些廠商的系統應用，它們依賴了一些系統特有的resource，你不得不進行特殊處理，才能成功的反編譯，甚至有時候需要你去修改apktool的源碼。

所以，這一篇文章就是告訴你那些你平時可能不注意的小細節，不常用的參數到底有什么用。

注意：本文所用apktool版本為，2.4.1。

官網介紹：Apktool - Documentation

1、-d 反編譯

apktool d bar.apk -o baz

apktool decode bar.apk -o baz

你可以使用-o來指定反編譯的輸出目錄，如上命令為 反編譯 bar.apk 到 baz 目錄，也可以使用絕對路徑，輸出到任意目錄。

decode 和 d 以及 -d 等效。

2、-b 打包apk

apktool b bar -o new_bar.apk

apktool build bar -o new_bar.apk

你可以使用-o來指定重新打包的輸出目錄，如上命令為 重新編譯bar目錄下的結構到 new_bar.apk，也可以使用絕對路徑，輸出到任意目錄。

build 和 b 以及 -b 等效。

3、if?or?install-framework 安裝 framework

（1）apktool if framework-res.apk

安裝?framework-res.apk 到默認目錄，默認目錄如下：

????????unix -?$HOME/.local/share/apktool

????????windows -?%UserProfile%\AppData\Local\apktool

????????mac -?$HOME/Library/apktool

（2）apktool if com.htc.resources.apk -t htc

安裝?framework-res.apk 到默認目錄，并添加tag標記，最終可能生成 2-htc.apk，前序的數字，由所安裝的framework的pkgId決定。個人理解pkgId是所安裝的 framework 的apk中的Manifest中的package字段值。

（3）apktool if framework-res.apk -t baz -p foo/bar

安裝?framework-res.apk 到 -p 指定的目錄，并添加tag標記，最終可能在 foo/bar 目錄下生成 2-htc.apk

安裝framework的作用，是讓apktool能夠識別一些廠商自定義的屬性或resource，否則將反編譯失敗。

每一個版本的apktool都會自帶有最新AOSP的framework，能支持絕大多數的apk反編譯。當需要特殊的framework時，如何尋找相應的framework，請參閱apktool文檔中的內容，此處不再詳述。

如何找到framework

（4）注意：你需要自己確保默認的framework是最新的

apktool會將自帶的framework拷貝到默認路徑下，各平臺默認路徑，請參考上文。

但是，當你升級apktool之后，最好是去掉默認路徑下的framework，讓apktool自動安裝最新的（自帶的）framework。

同時，當默認路徑不可用（通常是無權限）時，apktool會使用 /tmp 目錄，但是此目錄通常都不穩當，你可以使用?--frame-path（也就是上文提到的 -p ） 指定一個其他的穩定的目錄。

從2.2.1版本開始，apktool加入了相應的命令，可以完成此操作。?

apktool empty-framework-dir?

命令會清除framework目錄下的所有已安裝的framework

（5）apktool不會判斷framework是否重復安裝了，你可以任意安裝

4、使用指定的framework進行反編譯

當你安裝了不同的framework，并且其中一些framework可能是互不兼容的，那么你在反編譯的時候需要指定使用相應的framework。

安裝不同的framework，并指定tag

使用指定的framework進行反編譯，注意查看log中的區別。

使用不同的framework進行反編譯

同時需要說明的是，當你使用了指定的framework進行反編譯后，想要重新打包apk時，不需要再進行framework的指定了，apktool會自動使用反編譯時使用的framework進行重新打包。

5、關于.9圖的問題

谷歌官方文檔上有.9圖的說明，但是說漏了一些東西。

.9圖有兩種存在形式，一種是"源碼"形式，一種是經過編譯處理的形式。

"源碼"形式很容易得到，我們平時寫apk所用的到就是這種形式，網上也能方便的找到。而apk中的.9圖，是經過編譯處理后的圖。

"源碼"形式的.9圖，帶有透明的邊框，而編譯后的.9圖，不再存在這種透明邊框，編譯后的圖存在一種叫做?npTc 數據塊的結構中。你不能方便的查看和修改它，但是Android系統可以更快的讀取和使用它。

以上的情況就會導致，apktool不能直接去修改.9圖，而需要依賴谷歌官方的工具 -- aapt進行處理。

6、Options

? ? 常用的配置

（1）-version, --version

? ? 輸出當前工具版本

（2）-v, --verbose

? ? 輸出所有log，此參數必須放在第一位

（3）-q, --quiet

? ? 靜默模式，與?-v, --verbose 相反，此參數必須放在第一位

（4）-advance, --advanced

? ? 進行每一步操作前，打印相應log。默認開啟。

????清空framework的配置

（1）-f, --force

? ? 強制清除目標目錄

（2）-p, --frame-path <DIR>

? ? 指定加載framework的目錄

? ? 反編譯的配置

（1）-api, --api-level <API>

? ? 指定生成smali文件所用的api等級，默認使用targetSdkVersion版本

（2）-b, --no-debug-info

? ??防止baksmali寫出調試信息（.local，.param，.line等）。如果您要比較來自不同版本的同一APK的smali，則首選使用。

（3）-f, --force

? ? 如果反編譯的目標目錄存在，將會被強制清空

（4）--force-manifest?

? ? 強制反編譯 AndroidManifest.xml文件，優先級高于?-s, --no-src 配置。

（5）--keep-broken-res

? ? 如果出現?"Invalid Config Flags Detected. Dropping Resources..." 錯誤，這表示apk中有apktool不能識別的結構?？赡苁莂pktool不支持的更新的api版本，亦或者是該apk為不規則的apk。你可以添加此配置，以跳過錯誤，但后續你需要手動修復這些錯誤。

（6）-m, --match-original

? ? 將各文件處理為最接近原生的形式，將會導致不能備重新打包。

? ? Ps：我試了下，格式確實更接近原生，但是我重新打包也是成功了（打包成功，但并未簽名安裝）。

（7）--no-assets

? ? 不處理和拷貝屬于?unknown 的資源文件。

（8）-o, --output <DIR>

? ? 指定輸出目錄

（9）--only-main-classes

? ? 只反編譯apk根目錄下的dex文件，如：classes[0-9].dex

? ? 通過閱讀源碼發現，此配置的作用為：反編譯根目錄下的以?classes 開頭，并以 .dex 結尾的dex文件，不僅限于0-9

（10）-p, --frame-path <DIR>

? ? 指定存儲和加載framework的目錄

（11）-r, --no-res

? ? 不反編譯資源，保留?resources.arsc 為原來的樣子，如果你只是需要修改代碼，此配置會加快反編譯和重新打包的速度。

（12）-s, --no-src

? ? 不反編譯代碼，即不處理 dex文件。如果你只是需要修改資源，此配置會加快反編譯和重新打包的速度。

（13）-t, --frame-tag <TAG>

? ? 使用指定的framework進行反編譯，前文有述。

????重新打包配置

（1）-a, --aapt <FILE>

? ? 指定使用的aapt，當指定目錄未找到aapt時，會使用apktool自帶的aapt進行處理。

（2）-api, --api-level <API>

? ? 指定處理smali文件的api版本，默認使用minSdkVersion版本

（3）-c, --copy-original

? ? ?拷貝原始 AndroidManifest.xml?and?META-INF 到apk包體中。將會在2.5.0版本移除此功能。

（4）-d, --debug

? ? ?在 AndroidManifest 加入?debuggable="true" 配置

? ? ? ? 此配置，不會覆蓋已經存在的debuggable配置。

（5）-f, --force-all

? ? 當生成的文件存在時，進行強制覆蓋

（6）-nc,--no-crunch

? ? 此配置會傳遞給aapt，參閱：

? ??Expose the aapt --no-crunch option by Novex · Pull Request #1849 · iBotPeaches/Apktool · GitHub

? ??aapt build in apktool is not support new options · Issue #1232 · iBotPeaches/Apktool · GitHub

? ? 禁止對資源文件的處理

（7）-o, --output <FILE>

? ? 指定apk的輸出目錄

（8）-p, --frame-path <DIR>

? ? 指定加載framework的路徑

（9）--use-aapt2

? ? 使用aapt2進行打包

以上就是apktool目前支持的所有配置，下一篇文章，將會進一步深入源碼，去看看apktool到底都做了些什么。