Apktool 反编译后多出的 apktool.yml到底该不该改【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool当你第一次执行apktool d app.apk反编译目录里除了smali和res还会多出一个apktool.yml。别把它当生成的杂项丢掉——这个文件记录了 APK 元数据后面用apktool b重新打包能不能成功、装上去能不能跑很大程度就取决于它。如何读懂 Apktool 生成的 apktool.yml拿一份真实的输出来看典型内容长这样字段顺序和缩进与实际一致apkFileName: demo-release.apk version: 2.9.0 doNotCompress: - arsc - pngresourcesInfo: packageId: 127 packageName: com.example.demo sdkInfo: minSdkVersion: 24 targetSdkVersion: 33 versionInfo: versionCode: 88 versionName: 1.4.2逐块看它们负责什么apkFileName和version前者决定重打包后 APK 的文件名后者记录执行反编译的 Apktool 版本方便排查两份 yml 行为不一致的问题。doNotCompress反编译时 Apktool 扫描了原 APK把其中未压缩的文件按扩展名记在这里重打包时照单还原压缩策略。resourcesInfo资源包的关键身份packageId: 127就是十六进制的0x7f——你看到的所有资源 ID 都以此开头。sdkInfo应用声明的最低/目标 SDK重打包时会被当作编译参数用。versionInfo应用版本号与版本名来自原包 AndroidManifest.xml。下面这张九宫格按钮图来自项目自带的测试样本brut.apktool/apktool-lib/src/test/resources/testapp/它对应doNotCompress里的png条目——这类 9-Patch 资源必须保持未压缩才能被系统正确渲染元数据在反编译到重打包之间怎么流转 整个过程是一条闭环理解它比背字段名有用反编译时写入apktool d阶段Apktool 一边拆包一边采集信息——从 manifest 读出 SDK 版本和版本号扫描 zip 条目记录哪些文件是 Stored未压缩最后统一序列化进输出目录的apktool.yml。对应源码在 brut.apktool/apktool-lib/src/main/java/brut/androlib/meta/ApkInfo.javawriteApkInfo逻辑位于ApkDecoder.java。你修改改 smali、改资源、顺手改 yml。重打包时读取apktool b启动后第一件事就是从反编译目录读回这个 yml。minSdkVersion用来决定 smali 组装回 dex 时的最低字节码级别versionInfo、sdkInfo、resourcesInfo、usesFramework等会被透传给 aapt 参与资源重编译doNotCompress决定新 APK 里哪些文件保持未压缩。也就是说yml 不是给人看的说明书而是apktool b的执行输入。你改了它打包行为就会跟着变。重打包前必查apktool.yml 关键字段速查字段作用改它会发生什么apkFileName输出 APK 的文件名只改输出名若含/或..会直接报 SecurityException有路径校验usesFramework资源编译用的框架ids通常是[1]改成不存在的 ID资源编译阶段直接失败sdkInfo.minSdkVersionsmali→dex 的最低字节码级别也是 aapt 参数调太高老设备装不了或运行崩溃调太低代码用到高版本 API 时编译报错sdkInfo.targetSdkVersion目标 SDK传给 aapt调高可能触发新平台的行为限制装上去再排查很麻烦versionInfoversionCode / versionName重打包时这两个值会作为参数传给 aapt覆盖manifest 里你改的值resourcesInfo.packageId资源包 ID 前缀一般 127改它而不改代码里的引用运行时大面积找不到资源doNotCompress保持未压缩的扩展名/文件列表删掉arsc、png9-Patch 变黑、resources.arsc 读取异常最容易被改坏的 3 个字段minSdkVersion打包成功不代表能跑现象apktool b一路绿灯装到老版本 Android 上闪退或 smali 组装阶段报错。原因它是 smali 回编译 dex 的最低 API 级别。往高调生成的字节码老设备读不了往低调 dex 里可能引用设备上不存在的 API。怎么改回来恢复原始值。确实要抬最低支持版本时先确认代码里没有低版本 API 调用再改。resourcesInfo.packageId资源 ID 的根现象安装后图标、九宫格显示异常运行时抛资源找不到。原因所有资源 ID 都带这个前缀0x7fsmali 里的 R 字段引用也是按它编译的。只改 yml 不改代码两边就错位了。怎么改回来改回 127。为解包名冲突而改 packageId 属于连锁工程一般不值得。doNotCompress删一行变小运行就出事现象APK 体积变小了但部分设备 9-Patch 变黑或 resources.arsc 读取失败。原因arsc 和 9-Patch 类资源要求未压缩存储以便随机访问删掉记录后apktool b会把它们压成 Deflated。怎么改回来至少保留原有的arsc和png条目要精简列表先用unzip -l对照原 APK 确认目标文件确实是 Stored 再动。如何验证 apktool.yml 的改动生效了# 1. 确认新包的 SDK 与包信息与 yml 一致 aapt2 dump badging demo-release.apk | grep -E package|sdkVersion|targetSdkVersion # 2. 确认 arsc/png 仍是未压缩应为 Stored 而非 Deflated unzip -l demo-release.apk | grep -E resources.arsc|\.png第一条能核对versionInfo和sdkInfo是否真的进了最终产物——因为它们是作为 aapt 参数传入的manifest 改了、yml 没改时结果会以 yml 为准这正是很多人改了 manifest 却没生效的原因。下一步下次动apktool.yml之前先执行cp apktool.yml apktool.yml.bak每次只改一个字段再apktool b重打包验证出问题用diff定位是哪一行引入的。按这个流程操作改完字段、打包、验证十分钟内就能闭环之后批量处理 APK 时改元数据也就有了底。【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考