简介：这份资源面向需要在 macOS 环境下进行 APK 逆向与资源提取的开发者与安全学习者，核心是 apktool 工具及其配套使用说明，帮助解决在 Mac 上获取、反编译 APK 资源时工具零散、配置繁琐的问题。压缩包共 3 个文件，包含 1 个 jar 主程序、1 个 sh 启动脚本和 1 个 md 说明文档，整体约 10.25MB，体积轻量，解压即可按说明快速调用。其中 jar 文件承载反编译与打包的核心逻辑，sh 脚本用于简化命令行调用流程，md 文档则给出具体使用方式与注意事项，三者配合可覆盖从环境准备到实际执行的完整链路。目前已有 2829 人学习下载，说明该工具组合在 APK 逆向入门与日常资源提取场景中具备一定参考价值。对于希望快速上手 apktool、减少环境踩坑的读者，这份资源能提供可直接复用的工具与操作指引，遇到问题也可通过留言交流。
1. 从一次资源提取翻车说起：为什么我最后还是留了 apktool
有次帮朋友看一个安卓应用的资源文件，想从里面把图标和布局扒出来复用。我第一反应是直接改后缀解压，结果打开一看，resources.arsc是二进制乱码，图片倒是能捞出来几张，但九宫格图全废了，AndroidManifest.xml也是一坨看不懂的字节流。折腾半小时，最后老老实实回到 apktool，两条命令搞定。
这件事让我意识到，apktool 这类工具的价值不在于它多“高级”，而在于它把安卓逆向里最脏最累的活——资源解码和重打包——做成了标准流程。这篇内容面向三类人：刚接触 apk 逆向、想搞清楚怎么获取 apk 资源的新手；做过一些逆向但总在资源混淆上翻车的熟手；以及需要批量处理 apk 资源、想找一套稳定方案的人。我会把 apktool 的安装、解码、重打包、常见报错排查讲透，中间穿插我踩过的坑和判断依据，让你少走弯路。
2. apktool 到底解决什么问题：和直接解压、和 jadx 的边界在哪
2.1 直接解压 vs apktool 解码：差在资源可读性
很多人第一次拿 apk 都会直接改后缀为.zip解压，这招对纯 Java 代码和部分图片有效，但遇到资源就废了。核心原因是 apk 里的资源在打包时经过了 aapt 编译，resources.arsc是二进制格式，AndroidManifest.xml也被编译成了二进制 XML。直接解压得到的是“原料”，不是“成品”。
apktool 做的事情是调用内置的 aapt 解析逻辑，把二进制 XML 还原成可读的文本 XML，把resources.arsc里的资源表反编译成res/values/下的strings.xml、public.xml等文件。这样你才能看到每个字符串对应的 key、每个 drawable 的引用关系。
我一般会这么比：如果你只需要拿几张图片，直接解压够用；如果你要看布局结构、改字符串、替换资源再打包回去，apktool 是绕不开的。判断依据很简单——打开res/layout/目录，如果里面是.xml文件且内容可读，说明解码成功；如果只有resources.arsc和一堆.9.png，那就是没解码。
2.2 apktool vs jadx：一个管资源，一个管代码
这两个工具经常被放在一起说，但定位完全不同。jadx 强在把 dex 反编译成 Java 代码，适合看逻辑；apktool 强在资源解码和重打包，适合改资源、改清单文件、做二次打包。
我自己的习惯是：先用 apktool 解码拿到完整的资源目录和 smali 代码，再用 jadx 单独打开 apk 看 Java 层逻辑。两者不冲突，反而是互补的。如果你只想看某个 Activity 的实现，jadx 更快；如果你想改应用名称、替换图标、修改AndroidManifest.xml里的权限声明，apktool 是唯一选择。
这里有个常见误区：有人以为 apktool 能直接反编译出 Java 代码。实际上 apktool 默认输出的是 smali 汇编，想看 Java 还得靠 jadx 或 dex2jar + JD-GUI。所以别指望一个工具通吃，搞清楚边界能省很多时间。
2.3 资源获取的三种典型场景
第一种是纯提取资源，比如拿图标、拿字符串、拿布局参考。这种场景下 apktool 解码后直接去res/目录里翻就行，不需要重打包。
第二种是修改资源后重新打包，比如换图标、改应用名、去掉某些权限。这种需要 apktool 的b命令配合签名，流程稍长但可控。
第三种是批量处理多个 apk，比如做资源对比分析。这种场景下我一般会写个脚本循环调用 apktool，把解码结果按包名分目录存放，方便后续 diff。
三种场景对 apktool 的依赖程度不同，但共同点是：解码质量决定了后续所有操作的效率。如果解码报错，后面全白搭。
3. 环境搭建与基础命令：从安装到第一次成功解码
3.1 安装方式与版本选择
apktool 的安装方式主要有两种：直接下载 jar 包，或者通过包管理器安装。我推荐直接下载官方 jar，因为版本可控，不会因为系统包管理器的版本滞后导致解码失败。
下载后你会得到一个apktool.jar文件，同时需要一个包装脚本（Windows 下是apktool.bat，Linux/macOS 下是apktool脚本）。把这两个文件放在同一个目录，并加入 PATH，就可以在任意位置调用。
版本选择上，我一般会选最近半年内发布的稳定版。太老的版本对新版 aapt 编译的资源支持不好，容易在解码resources.arsc时报错。但也不要盲目追最新，有些新版本会引入回归问题，稳妥做法是保留两个版本，遇到解码失败时切换试试。
提示：如果你在 Windows 上遇到
java命令找不到，先确认 JDK 是否安装并配置了JAVA_HOME。apktool 依赖 Java 运行环境，版本建议 8 以上。
3.2 解码命令与参数详解
最基本的解码命令是：
apktool d target.apk -o output_dir这条命令会把target.apk解码到output_dir目录。如果不指定-o，默认会在当前目录下创建一个以 apk 文件名命名的文件夹。
几个我常用的参数：
-f：强制覆盖已存在的输出目录。第二次解码同一个 apk 时很有用，省得手动删目录。-r：跳过资源解码，只反编译 dex 到 smali。当你只关心代码逻辑、不关心资源时，这个参数能大幅缩短解码时间。-s：跳过 smali 反编译，只解码资源。当你只想要资源文件时用这个，速度更快。--only-main-classes：只反编译主 dex，忽略多 dex 中的次要 dex。适合快速查看主逻辑。
我一般会这么组合：第一次解码用默认参数，拿到完整结果；如果只是快速看资源，用-s；如果只关心代码，用-r。参数用对了，效率差好几倍。
3.3 解码后的目录结构说明
解码成功后，输出目录里会有几个关键文件夹和文件：
res/：资源目录，包含布局、图片、字符串等。其中res/values/下的strings.xml、public.xml、ids.xml是资源表反编译的结果。smali/：smali 代码目录，按包名分层存放。如果你用了-r参数，这个目录不会生成。AndroidManifest.xml：解码后的清单文件，可读的 XML 格式。apktool.yml：apktool 的元数据文件，记录了 apk 的版本、编译信息等。重打包时依赖这个文件。assets/、lib/、original/等：分别对应原始资源、native 库和未解码的原始文件。
判断解码是否成功，我一般看三点：AndroidManifest.xml是否能正常打开且内容可读；res/values/strings.xml是否存在且包含字符串条目；smali/目录下是否有.smali文件。三点都满足，说明解码完整。
4. 重打包与签名：改完资源怎么装回去
4.1 重打包命令与常见报错
修改完资源后，重打包命令是：
apktool b output_dir -o new.apk这条命令会把output_dir重新打包成new.apk。如果不指定-o，默认输出到output_dir/dist/目录下。
重打包阶段最容易遇到的报错是资源引用找不到。比如你删了某个图片，但布局文件里还在引用它，打包时就会报resource not found。解决办法是全局搜索被删资源的文件名，把所有引用一并清理。
另一个常见报错是AndroidManifest.xml格式错误。手动改清单文件时，少个闭合标签或者属性名拼错都会导致打包失败。我一般改完清单后会先用 xmllint 校验一遍格式，再执行打包。
注意：重打包前建议先备份原始解码目录。打包失败时，apktool 可能会修改部分中间文件，导致二次打包结果不一致。
4.2 签名流程与工具选择
apktool 打包出来的 apk 是没有签名的，直接安装会报INSTALL_PARSE_FAILED_NO_CERTIFICATES。所以重打包后必须签名。
签名工具我常用apksigner（Android SDK 自带）或jarsigner（JDK 自带）。apksigner更推荐，因为它支持 v2/v3 签名方案，兼容性更好。
签名步骤分两步：先生成密钥库，再用密钥库签名。
# 生成密钥库 keytool -genkeypair -v -keystore mykey.jks -keyalg RSA -keysize 2048 -validity 10000 -alias myalias # 用 apksigner 签名 apksigner sign --ks mykey.jks --ks-key-alias myalias --out signed.apk new.apkkeytool命令会交互式询问密码和证书信息，按提示填写即可。apksigner签名时需要输入密钥库密码和别名密码。
签名完成后，可以用apksigner verify signed.apk验证签名是否生效。如果输出Verified using v2 scheme: true，说明签名成功。
4.3 重打包后的验证清单
签名完成后别急着安装，先做几项检查：
第一，用aapt dump badging signed.apk查看包名和版本号是否与预期一致。如果包名变了，说明apktool.yml里的信息被改动了。
第二，用apktool d signed.apk重新解码一次，对比修改点是否生效。比如你换了图标，重新解码后去res/mipmap-xxx/下看图标是否已替换。
第三，在模拟器或测试机上安装，确认应用能正常启动。有些资源修改会导致运行时崩溃，比如替换了尺寸不匹配的九宫格图。
这三步走完，基本能确认重打包结果可用。如果安装后闪退，优先检查AndroidManifest.xml里的application节点和MainActivity声明是否完整。
5. 避坑与排查：那些年我踩过的资源解码坑
5.1 解码报错 “Could not decode arsc file”
现象：执行apktool d时，终端输出Could not decode arsc file，解码中断。
原因：apktool 内置的 aapt 版本与 apk 编译时使用的 aapt 版本不匹配。新版 Android 构建工具会对resources.arsc做格式调整，老版本 apktool 解析不了。
解决：升级 apktool 到最新稳定版。如果升级后仍报错，尝试用-r参数跳过资源解码，先拿到 smali 代码，资源部分用其他工具（如aapt2）单独处理。
5.2 重打包报错 “resource not found”
现象：执行apktool b时，报错提示某个资源 ID 找不到，打包失败。
原因：通常是你删除了某个资源文件，但public.xml或布局文件中仍有引用。apktool 在打包时会校验资源引用完整性，找不到就报错。
解决：全局搜索报错中提到的资源名，找到所有引用点并清理。如果资源是在public.xml中声明的，还需要同步删除对应的<public>条目。改完后重新打包。
5.3 签名后安装报错 “INSTALL_FAILED_INVALID_APK”
现象：签名后的 apk 安装时提示INSTALL_FAILED_INVALID_APK，无法安装。
原因：签名不完整或签名方案不兼容。有些设备要求 v2 签名，如果只用 v1 签名，安装会被拒绝。
解决：用apksigner重新签名，确保同时启用 v1 和 v2 签名方案。命令中加上--v1-signing-enabled true --v2-signing-enabled true。如果设备是 Android 11 以上，还需要考虑 v3 签名。
5.4 解码后 smali 目录为空
现象：解码完成后，smali/目录存在但没有.smali文件，或者目录根本不存在。
原因：apk 使用了多 dex 或者 dex 被加固。apktool 默认只反编译主 dex，如果代码都在次要 dex 中，主 dex 可能为空。另外，加固后的 apk 的 dex 是加密的，apktool 无法直接反编译。
解决：如果是多 dex，检查smali_classes2/、smali_classes3/等目录是否存在。如果是加固，需要先脱壳再反编译，apktool 本身不处理加固。
5.5 修改资源后应用闪退
现象：重打包安装后，应用启动即闪退，日志中报Resources$NotFoundException。
原因：资源 ID 在重打包过程中发生了变化。apktool 重新编译资源时会重新分配资源 ID，如果代码中硬编码了资源 ID，就会找不到对应资源。
解决：尽量避免硬编码资源 ID。如果必须修改资源，优先改res/values/strings.xml中的字符串，这类修改通常不会影响资源 ID 分配。如果闪退发生在修改布局后，检查布局中引用的资源是否都存在。
6. 从手动到批量：一套可复用的资源提取流程
6.1 批量解码脚本与目录规范
当你需要处理多个 apk 时，手动一个个执行命令效率太低。我一般会写一个简单的 bash 脚本：
#!/bin/bash # 批量解码 apk 并输出到指定目录 INPUT_DIR="./apks" OUTPUT_DIR="./decoded" mkdir -p "$OUTPUT_DIR" for apk in "$INPUT_DIR"/*.apk; do name=$(basename "$apk" .apk) echo "Decoding $name ..." apktool d "$apk" -o "$OUTPUT_DIR/$name" -f if [ $? -eq 0 ]; then echo "$name decoded successfully" else echo "$name decode failed" >> "$OUTPUT_DIR/errors.log" fi done这个脚本会遍历apks/目录下所有.apk文件，逐个解码到decoded/目录，并按文件名建立子目录。解码失败的记录到errors.log，方便后续排查。
目录规范上，我习惯按包名_版本号命名输出目录，这样后续做版本对比时一目了然。如果 apk 文件名本身不含包名，可以用aapt dump badging先提取包名再重命名。
6.2 资源提取后的整理与去重
解码完成后，res/目录下会有大量文件。如果只是找特定资源，可以用find命令按类型筛选：
# 提取所有 png 图片到统一目录 find decoded/ -name "*.png" -exec cp {} ./extracted_images/ \; # 提取所有 strings.xml 并合并 find decoded/ -path "*/res/values/strings.xml" -exec cat {} \; > all_strings.xml去重方面，我一般用文件的 md5 值做比对。相同 md5 的图片只保留一份，能大幅减少冗余。对于字符串资源，可以用脚本解析 XML 后按 key 去重，但要注意不同应用的 key 可能相同但含义不同，去重前先确认上下文。
6.3 资源对比与版本差异分析
当你拿到同一个应用的两个版本时，可以用 diff 工具对比解码后的资源目录：
diff -r decoded/v1.0/res decoded/v2.0/res这条命令会递归对比两个版本的res/目录，输出新增、删除和修改的文件列表。重点关注res/values/strings.xml和res/layout/下的变化，这些往往对应功能更新。
如果只想看图片变化，可以用md5sum生成文件指纹再对比：
# 生成 v1 版本图片指纹 find decoded/v1.0/res -name "*.png" -exec md5sum {} \; | sort > v1_hashes.txt # 生成 v2 版本图片指纹 find decoded/v2.0/res -name "*.png" -exec md5sum {} \; | sort > v2_hashes.txt # 对比差异 diff v1_hashes.txt v2_hashes.txt这套流程我在做竞品资源分析时经常用，能快速定位到图标替换、文案调整等变化点。apktool 的解码质量直接决定了对比结果的准确性，所以遇到解码报错的 apk，宁可多花时间排查，也不要跳过。
回过头看，apktool 这个工具本身不复杂，但要用得顺手，关键在细节：版本选对、参数用对、报错会查、流程能批量。我现在的习惯是，每次拿到新 apk，先跑一遍默认解码，确认资源目录完整后再决定下一步。如果解码失败，先看报错类型，再决定是升级版本还是换参数。这套流程帮我省了很多重复劳动，也希望帮到你。
本文还有配套的精品资源，点击获取
