apktool.yml 里那 7 個字段到底管什么從反編譯到重打包的完整解讀【免費下載鏈接】ApktoolA tool for reverse engineering Android apk files項目地址: https://gitcode.com/GitHub_Trending/ap/Apktool您運行apktool d xxx.apk之后輸出目錄最顯眼的一個文件不是 smali 或 res而是一份短短的apktool.yml。很多人直接忽略它直到b命令重打包時報錯、或者資源 ID 對不上才回頭查。這個文件由 Apktool 生成并持久化它就是 Apktool 保存 APK 元數(shù)據(jù)的方式記錄了反編譯時發(fā)現(xiàn)的框架依賴、SDK 版本、資源包信息和壓縮策略重打包時工具會重新讀入它來決定怎么重建 APK。本文把這份文件從頭到尾拆開講每個字段什么含義、哪些值能動、哪些絕對別碰。apktool.yml 是怎么生成的這一節(jié)回答文件從哪來、什么時候會被再讀。反編譯階段ApkDecoder解析 APK 后把結(jié)果填進 ApkInfo.java 這個類然后調(diào)用它的save()方法寫成 YAML重打包時ApkBuilder則調(diào)用ApkInfo.load(反編譯目錄)讀回。整個過程您不需要手動參與但要知道一點這個文件是單向依賴的——刪掉它再重打包工具只能按默認值猜結(jié)果往往不符合預期。七個頂層字段逐一對照這是全文核心。下表把apktool.yml的全部頂層鍵整理出來按改動風險從高到低排序字段含義示例值能不能改version生成該文件的 Apktool 版本2.8.1不建議改版本不匹配時解析行為可能變化apkFileName原始 APK 文件名standard.apk可改純記錄性質(zhì)usesFramework框架依賴ids是框架 ID 列表tag是系統(tǒng)應用標簽ids: [1]改 ID 前必須確認本機有對應框架否則打包失敗usesLibrary第三方共享庫列表常見為空為空時不寫出按需增刪sdkInfominSdkVersion/targetSdkVersion/maxSdkVersion三項25 / 30可以改但需與 manifest 保持一致versionInfoversionCode與versionName取自 manifest-1 / null讀不到時建議同步修改 manifest 中的同名屬性resourcesInfo資源包packageId通常 127、包名、sparseEntries標志127packageId 改動極易引發(fā)資源引用失效doNotCompress打包時不壓縮的擴展名或文件列表arsc、png可安全增刪其中兩個子對象值得多看一眼。sdkInfo的字段在 SdkInfo.java 中定義除了純數(shù)字還支持M、N、Q這類代號寫法構(gòu)建時會統(tǒng)一換算成 API 等級另外當 min、max、target 三者矛盾時重打包用的是被夾在 min/max 中間的那個 target 值。usesFramework的tag非 null 時說明這是一個系統(tǒng)應用overlay 或系統(tǒng)擴展重打包需要對應的框架環(huán)境。一份真實文件長什么樣下面是倉庫測試資源里的兩個真實樣例。左邊是最簡形態(tài)——很多字段為空時干脆不出現(xiàn)在文件里這也是新手常見的困惑為什么我的 yml 里連sdkInfo都沒有因為原 APK 的 manifest 里就沒寫。右邊字段齊全可以看到列表項用 4 空格縮進的寫法同樣合法# 最簡樣例src/test/resources/meta/standard.yml apkFileName: standard.apk doNotCompress: - arsc resourcesInfo: packageId: 127 packageName: null sparseEntries: false sdkInfo: minSdkVersion: 25 targetSdkVersion: 30 usesFramework: ids: - 1 tag: null version: 2.8.1 versionInfo: versionCode: -1 versionName: null您想改字段時最容易踩的四個坑這一節(jié)只講改壞了會怎樣。packageId動了資源全亂。resourcesInfo.packageId是 smali 里0x7f...常量與資源表之間的橋梁改成非 127 且不同步修改資源表時運行期找不到資源是常規(guī)結(jié)局。doNotCompress漏了arsc。把resources.arsc壓縮進 zip部分機型讀取資源會失敗。反編譯時若原包以 stored 方式存放 arsc這里必有arsc手動刪掉等于自找問題。versionCode改成 0 或負數(shù)。升級安裝場景下 versionCode 必須大于舊版本-1是原 manifest 讀不到的占位值直接帶著它打包等于沒設(shè)置。version字段改成別的版本號。它記錄的是寫出這份文件的 Apktool 版本不是 APK 的版本。改成與本機 apktool 不一致的值不會報錯但跨版本序列化時新增字段可能被忽略。重打包前必查的三項動手執(zhí)行apktool b之前花十秒核對這三點能避免絕大多數(shù)詭異報錯usesFramework.ids與本機1框架一致apktool ifp可查看框架安裝情況sdkInfo三個值滿足 min ≤ target ≤ max且與修改后的 AndroidManifest.xml 一致doNotCompress包含arsc以及您新加入的不壓縮文件類型。核對無誤后再打包若仍失敗錯誤日志里通常會點名是哪個階段出問題回到本文的字段表對照定位即可。小結(jié)apktool.yml是 Apktool 在反編譯與重打包之間傳遞 APK 元數(shù)據(jù)的唯一載體七個頂層字段分別管版本、文件名、框架、庫、SDK、應用版本和資源包信息。它不該被刪除改動前先用本文的字段表確認風險重打包前過一遍上面三項檢查這份小小的 YAML 就不會再給您添堵。【免費下載鏈接】ApktoolA tool for reverse engineering Android apk files項目地址: https://gitcode.com/GitHub_Trending/ap/Apktool創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 apktool.yml 里那 7 個字段到底管什么：從反編譯到重打包的完整解讀
apktool.yml 里那 7 個字段到底管什么從反編譯到重打包的完整解讀【免費下載鏈接】ApktoolA tool for reverse engineering Android apk files項目地址: https://gitcode.com/GitHub_Trending/ap/Apktool您運行apktool d xxx.apk之后輸出目錄最顯眼的一個文件不是 smali 或 res而是一份短短的apktool.yml。很多人直接忽略它直到b命令重打包時報錯、或者資源 ID 對不上才回頭查。這個文件由 Apktool 生成并持久化它就是 Apktool 保存 APK 元數(shù)據(jù)的方式記錄了反編譯時發(fā)現(xiàn)的框架依賴、SDK 版本、資源包信息和壓縮策略重打包時工具會重新讀入它來決定怎么重建 APK。本文把這份文件從頭到尾拆開講每個字段什么含義、哪些值能動、哪些絕對別碰。apktool.yml 是怎么生成的這一節(jié)回答文件從哪來、什么時候會被再讀。反編譯階段ApkDecoder解析 APK 后把結(jié)果填進 ApkInfo.java 這個類然后調(diào)用它的save()方法寫成 YAML重打包時ApkBuilder則調(diào)用ApkInfo.load(反編譯目錄)讀回。整個過程您不需要手動參與但要知道一點這個文件是單向依賴的——刪掉它再重打包工具只能按默認值猜結(jié)果往往不符合預期。七個頂層字段逐一對照這是全文核心。下表把apktool.yml的全部頂層鍵整理出來按改動風險從高到低排序字段含義示例值能不能改version生成該文件的 Apktool 版本2.8.1不建議改版本不匹配時解析行為可能變化apkFileName原始 APK 文件名standard.apk可改純記錄性質(zhì)usesFramework框架依賴ids是框架 ID 列表tag是系統(tǒng)應用標簽ids: [1]改 ID 前必須確認本機有對應框架否則打包失敗usesLibrary第三方共享庫列表常見為空為空時不寫出按需增刪sdkInfominSdkVersion/targetSdkVersion/maxSdkVersion三項25 / 30可以改但需與 manifest 保持一致versionInfoversionCode與versionName取自 manifest-1 / null讀不到時建議同步修改 manifest 中的同名屬性resourcesInfo資源包packageId通常 127、包名、sparseEntries標志127packageId 改動極易引發(fā)資源引用失效doNotCompress打包時不壓縮的擴展名或文件列表arsc、png可安全增刪其中兩個子對象值得多看一眼。sdkInfo的字段在 SdkInfo.java 中定義除了純數(shù)字還支持M、N、Q這類代號寫法構(gòu)建時會統(tǒng)一換算成 API 等級另外當 min、max、target 三者矛盾時重打包用的是被夾在 min/max 中間的那個 target 值。usesFramework的tag非 null 時說明這是一個系統(tǒng)應用overlay 或系統(tǒng)擴展重打包需要對應的框架環(huán)境。一份真實文件長什么樣下面是倉庫測試資源里的兩個真實樣例。左邊是最簡形態(tài)——很多字段為空時干脆不出現(xiàn)在文件里這也是新手常見的困惑為什么我的 yml 里連sdkInfo都沒有因為原 APK 的 manifest 里就沒寫。右邊字段齊全可以看到列表項用 4 空格縮進的寫法同樣合法# 最簡樣例src/test/resources/meta/standard.yml apkFileName: standard.apk doNotCompress: - arsc resourcesInfo: packageId: 127 packageName: null sparseEntries: false sdkInfo: minSdkVersion: 25 targetSdkVersion: 30 usesFramework: ids: - 1 tag: null version: 2.8.1 versionInfo: versionCode: -1 versionName: null您想改字段時最容易踩的四個坑這一節(jié)只講改壞了會怎樣。packageId動了資源全亂。resourcesInfo.packageId是 smali 里0x7f...常量與資源表之間的橋梁改成非 127 且不同步修改資源表時運行期找不到資源是常規(guī)結(jié)局。doNotCompress漏了arsc。把resources.arsc壓縮進 zip部分機型讀取資源會失敗。反編譯時若原包以 stored 方式存放 arsc這里必有arsc手動刪掉等于自找問題。versionCode改成 0 或負數(shù)。升級安裝場景下 versionCode 必須大于舊版本-1是原 manifest 讀不到的占位值直接帶著它打包等于沒設(shè)置。version字段改成別的版本號。它記錄的是寫出這份文件的 Apktool 版本不是 APK 的版本。改成與本機 apktool 不一致的值不會報錯但跨版本序列化時新增字段可能被忽略。重打包前必查的三項動手執(zhí)行apktool b之前花十秒核對這三點能避免絕大多數(shù)詭異報錯usesFramework.ids與本機1框架一致apktool ifp可查看框架安裝情況sdkInfo三個值滿足 min ≤ target ≤ max且與修改后的 AndroidManifest.xml 一致doNotCompress包含arsc以及您新加入的不壓縮文件類型。核對無誤后再打包若仍失敗錯誤日志里通常會點名是哪個階段出問題回到本文的字段表對照定位即可。小結(jié)apktool.yml是 Apktool 在反編譯與重打包之間傳遞 APK 元數(shù)據(jù)的唯一載體七個頂層字段分別管版本、文件名、框架、庫、SDK、應用版本和資源包信息。它不該被刪除改動前先用本文的字段表確認風險重打包前過一遍上面三項檢查這份小小的 YAML 就不會再給您添堵。【免費下載鏈接】ApktoolA tool for reverse engineering Android apk files項目地址: https://gitcode.com/GitHub_Trending/ap/Apktool創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考