Apktool 反编译 APK 后多出来的 apktool.yml 是什么ApkInfo 元数据完整指南【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/ApktoolApktool 是 Android APK 逆向工程里的常用工具它能把 APK 反编译成可读的资源文件与 smali 代码。反编译跑完后输出目录里总会多出一个apktool.yml文件它由 ApkInfo 类序列化而来记录了重建这个 APK 所需的整套元数据——框架版本、SDK 区间、资源包 ID、压缩策略等。可以说没有它重打包这一步就少了一半依据。很多人第一次接触会好奇这个 yml 到底能不能删删了会怎样要回答这个问题得先看懂它每个字段的含义以及 ApkInfo 是怎么把数据读进来、写出去的。从一份 apktool.yml 实例看起元数据到底记了什么apktool.yml你可以理解成 APK 的“构建参数清单”。反编译时Apktool 从resources.arsc、AndroidManifest.xml里读出关键信息打包成一个ApkInfo对象重打包时再从这个对象取回这些值去还原 APK。它实现的是YamlSerializable接口负责对象与 YAML 文本之间的双向转换。下面是一份典型反编译产物version记录的是写盘时用的 Apktool 版本apkFileName记录原始 APK 文件名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注意这里的写法特点值为null的字段会被写出来表示“没有该值”而整个对象为空的字段则直接不出现在文件里。这一点在代码里由write方法对每个子对象先判空、非空才写来控制。为什么这个文件删不得重打包时 Apktool 依赖它来恢复三件事用哪个框架编译、按哪个 SDK 区间处理、资源表怎么排布。少了它工具只能猜测默认值原本依赖特定框架或特定资源包 ID 的应用就可能打不出能运行的 APK。逐字段拆解apktool.yml 里每个字段在说什么这一节按文件里出现的顺序把每个键对应到ApkInfo的结构。理解到这一层你就能判断哪些值能动、哪些动不得。顶层字段version写入时使用的 Apktool 版本号便于日后判断这份产物由哪版工具生成。apkFileName原始 APK 文件名。ApkInfo读取它时会做安全校验出现.、..或路径分隔符会抛异常防止恶意输入做目录穿越。doNotCompress一个字符串列表指定打包时不按压缩处理的文件类型常见arsc、png。Android 资源表等必须可被随机访问的文件通常都列在这里。框架与库依赖usesFramework对应UsesFramework对象含ids框架 ID 列表1通常代表默认 Android 框架与tag自定义框架标签。这是重打包能否找对1.apk框架缓存的关键。usesLibrary对应mUsesLibrary列表记录应用声明使用的第三方库为空时不写出。SDK 与应用版本sdkInfo对应SdkInfo含minSdkVersion、targetSdkVersion、maxSdkVersion。这些值既可以是数字也可以是M/N/O这类代号代码里的parseSdkInt会做映射getTargetSdkVersionBounded还会把 target 收敛到 [min, max] 区间内。versionInfo对应VersionInfo含versionCode整数与versionName字符串都取自AndroidManifest.xml。当versionCode未指定时getVersionCode返回-1所以你在 yml 里看到versionCode: -1不代表异常。资源包信息resourcesInfo对应ResourcesInfo字段包括packageId资源包 ID绝大多数 APK 为127、packageName、sparseEntries、compactEntries、keepRawValues。packageId未指定时getPackageId返回-1几个布尔项未指定时默认按false处理。ApkInfo 如何加载与保存从目录读取和流读取ApkInfo的持久化只有两个入口都围绕apktool.yml这一个文件名。从反编译目录加载load(File apkDir)会在传入目录里找apktool.yml打开它的输入流再交给流版本处理。重打包场景用的就是这条路径传入的是反编译后的输出目录ApkInfo apkInfo ApkInfo.load(new File(app-decompiled)); // 读取目录下的 apktool.yml从输入流加载load(InputStream)是真正干活的版本被标记为仅测试可见VisibleForTesting用YamlReader逐行调用readRoot填充对象。单元测试正是拿它直接喂 yml 内容验证标准解析、未知字段容错、缩进错误等边界情况相关用例在 测试目录 里可以查到。保存走save(File apkDir)同样固定写向目录下的apktool.yml内部用YamlWriter调write方法。也就是说读和写共用同一个文件名且子对象为空就不落盘这让文件始终只保留有内容的键。重打包时元数据如何生效修改、框架与资源包元数据不是只读记录它在“反编译 → 修改 → 重打包”这条链路里每一步都参与决策。逆向分析阶段你直接读apktool.yml就能快速知道这个 APK 依赖哪个框架、支持到多高的 SDK、资源表怎么排布不必再翻resources.arsc。修改重打包阶段改动AndroidManifest.xml比如调debuggable或替换资源后执行重打包Apktool 用sdkInfo保持 SDK 区间一致、用usesFramework找对框架、用doNotCompress还原压缩策略最后把更新后的ApkInfo写回apktool.yml。自动化批处理阶段因为加载/保存都是稳定的目录约定脚本可以批量改字段再打包把它接进 CI 做批量校验也很自然。常见坑哪些字段改了容易出问题别乱改packageId资源引用都挂在这个 ID 上改成非127的值会让大量引用失效除非你明确知道自己在做什么。删了或写坏apktool.yml后重打包拿不到框架与资源信息要么报错要么按默认值重建出不兼容的包。这个文件要随反编译目录一起保留。调 SDK 字段要保守把targetSdkVersion提到远超应用实际支持的版本可能触发行为变化导致运行时异常maxSdkVersion与targetSdkVersion的相对关系也会影响收敛结果。框架依赖要对齐应用若依赖特定框架版本重打包时应使用相同或兼容的框架否则资源解析会出错。apktool.yml不是可有可无的附属文件它是 Apktool 记住“这个 APK 当初是怎么构成的”的那张清单由ApkInfo读取与写出字段对应框架、SDK、版本、资源包与压缩策略。看懂它你就能放心地在“分析—修改—重打包”之间来回操作。【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Apktool 反编译 APK 后多出来的 apktool.yml 是什么？ApkInfo 元数据完整指南
Apktool 反编译 APK 后多出来的 apktool.yml 是什么ApkInfo 元数据完整指南【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/ApktoolApktool 是 Android APK 逆向工程里的常用工具它能把 APK 反编译成可读的资源文件与 smali 代码。反编译跑完后输出目录里总会多出一个apktool.yml文件它由 ApkInfo 类序列化而来记录了重建这个 APK 所需的整套元数据——框架版本、SDK 区间、资源包 ID、压缩策略等。可以说没有它重打包这一步就少了一半依据。很多人第一次接触会好奇这个 yml 到底能不能删删了会怎样要回答这个问题得先看懂它每个字段的含义以及 ApkInfo 是怎么把数据读进来、写出去的。从一份 apktool.yml 实例看起元数据到底记了什么apktool.yml你可以理解成 APK 的“构建参数清单”。反编译时Apktool 从resources.arsc、AndroidManifest.xml里读出关键信息打包成一个ApkInfo对象重打包时再从这个对象取回这些值去还原 APK。它实现的是YamlSerializable接口负责对象与 YAML 文本之间的双向转换。下面是一份典型反编译产物version记录的是写盘时用的 Apktool 版本apkFileName记录原始 APK 文件名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注意这里的写法特点值为null的字段会被写出来表示“没有该值”而整个对象为空的字段则直接不出现在文件里。这一点在代码里由write方法对每个子对象先判空、非空才写来控制。为什么这个文件删不得重打包时 Apktool 依赖它来恢复三件事用哪个框架编译、按哪个 SDK 区间处理、资源表怎么排布。少了它工具只能猜测默认值原本依赖特定框架或特定资源包 ID 的应用就可能打不出能运行的 APK。逐字段拆解apktool.yml 里每个字段在说什么这一节按文件里出现的顺序把每个键对应到ApkInfo的结构。理解到这一层你就能判断哪些值能动、哪些动不得。顶层字段version写入时使用的 Apktool 版本号便于日后判断这份产物由哪版工具生成。apkFileName原始 APK 文件名。ApkInfo读取它时会做安全校验出现.、..或路径分隔符会抛异常防止恶意输入做目录穿越。doNotCompress一个字符串列表指定打包时不按压缩处理的文件类型常见arsc、png。Android 资源表等必须可被随机访问的文件通常都列在这里。框架与库依赖usesFramework对应UsesFramework对象含ids框架 ID 列表1通常代表默认 Android 框架与tag自定义框架标签。这是重打包能否找对1.apk框架缓存的关键。usesLibrary对应mUsesLibrary列表记录应用声明使用的第三方库为空时不写出。SDK 与应用版本sdkInfo对应SdkInfo含minSdkVersion、targetSdkVersion、maxSdkVersion。这些值既可以是数字也可以是M/N/O这类代号代码里的parseSdkInt会做映射getTargetSdkVersionBounded还会把 target 收敛到 [min, max] 区间内。versionInfo对应VersionInfo含versionCode整数与versionName字符串都取自AndroidManifest.xml。当versionCode未指定时getVersionCode返回-1所以你在 yml 里看到versionCode: -1不代表异常。资源包信息resourcesInfo对应ResourcesInfo字段包括packageId资源包 ID绝大多数 APK 为127、packageName、sparseEntries、compactEntries、keepRawValues。packageId未指定时getPackageId返回-1几个布尔项未指定时默认按false处理。ApkInfo 如何加载与保存从目录读取和流读取ApkInfo的持久化只有两个入口都围绕apktool.yml这一个文件名。从反编译目录加载load(File apkDir)会在传入目录里找apktool.yml打开它的输入流再交给流版本处理。重打包场景用的就是这条路径传入的是反编译后的输出目录ApkInfo apkInfo ApkInfo.load(new File(app-decompiled)); // 读取目录下的 apktool.yml从输入流加载load(InputStream)是真正干活的版本被标记为仅测试可见VisibleForTesting用YamlReader逐行调用readRoot填充对象。单元测试正是拿它直接喂 yml 内容验证标准解析、未知字段容错、缩进错误等边界情况相关用例在 测试目录 里可以查到。保存走save(File apkDir)同样固定写向目录下的apktool.yml内部用YamlWriter调write方法。也就是说读和写共用同一个文件名且子对象为空就不落盘这让文件始终只保留有内容的键。重打包时元数据如何生效修改、框架与资源包元数据不是只读记录它在“反编译 → 修改 → 重打包”这条链路里每一步都参与决策。逆向分析阶段你直接读apktool.yml就能快速知道这个 APK 依赖哪个框架、支持到多高的 SDK、资源表怎么排布不必再翻resources.arsc。修改重打包阶段改动AndroidManifest.xml比如调debuggable或替换资源后执行重打包Apktool 用sdkInfo保持 SDK 区间一致、用usesFramework找对框架、用doNotCompress还原压缩策略最后把更新后的ApkInfo写回apktool.yml。自动化批处理阶段因为加载/保存都是稳定的目录约定脚本可以批量改字段再打包把它接进 CI 做批量校验也很自然。常见坑哪些字段改了容易出问题别乱改packageId资源引用都挂在这个 ID 上改成非127的值会让大量引用失效除非你明确知道自己在做什么。删了或写坏apktool.yml后重打包拿不到框架与资源信息要么报错要么按默认值重建出不兼容的包。这个文件要随反编译目录一起保留。调 SDK 字段要保守把targetSdkVersion提到远超应用实际支持的版本可能触发行为变化导致运行时异常maxSdkVersion与targetSdkVersion的相对关系也会影响收敛结果。框架依赖要对齐应用若依赖特定框架版本重打包时应使用相同或兼容的框架否则资源解析会出错。apktool.yml不是可有可无的附属文件它是 Apktool 记住“这个 APK 当初是怎么构成的”的那张清单由ApkInfo读取与写出字段对应框架、SDK、版本、资源包与压缩策略。看懂它你就能放心地在“分析—修改—重打包”之间来回操作。【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
