如何用 Apktool 解包与重建 Android APK3 步跑通全流程的完整指南【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool收到一个线上 apk想确认它到底申请了哪些权限、改掉一句错误文案、或者打一个 smali 补丁后重新装回手机——用普通解压工具是打不开的AndroidManifest.xml 是二进制 XML代码全封在 dex 里。Apktool 就是干这件事的把 apk 解包成 smali 代码、res 资源和文本化清单组成的工程化目录修改后再重建回一个新的 apk。环境准备安装 Apktool 并验证版本安装预编译 jarLinux / macOS / Windows 通用Apktool 是一个自包含的 fat jar三套系统用法一致下载发布版apktool_*.jar后用java -jar运行即可。仓库自带一套包装脚本如 scripts/linux/apktoolLinux / macOS / Windows 各一份它会优先在同目录寻找apktool.jar或版本号最高的apktool_*.jar把java -jar封装成一条apktool命令。把 jar 与脚本放进同一目录、给脚本加上执行权限之后就能直接敲apktool开头的命令。验证安装是否成功apktool v # 预期输出一行版本号如 3.1.0-SNAPSHOT说明 jar 与 JDK 环境都已就绪如果不想走脚本等价写法是java -jar apktool_3.1.0.jar v能打印版本号就说明环境没问题可以往下走。从源码构建需要 JDK 17 及以上git clone https://gitcode.com/GitHub_Trending/ap/Apktool cd Apktool ./gradlew build shadowJar # 预期结果各模块编译通过在 brut.apktool/apktool-cli/build/libs/ 下生成可执行的 apktool jar构建与发布流程的细节可以对照仓库内的 INTERNAL.md。构建产物同样用java -jar jar 路径 v验证一下版本号再使用。核心链路解包、改文件、重建出新的 apk这条链路共四步上一步的产物直接作为下一步的输入全程只在命令行里完成。第 1 步用 apktool d 解包成工程化目录apktool d -f -o demo demo.apk # 预期结果生成 demo/ 目录含文本化的 AndroidManifest.xml、smali*/ 下的 .smali 文件、res/ 资源目录和 apktool.yml 元信息-o指定输出目录-f允许覆盖已存在的输出不带-o时默认生成与输入同名的demo.out目录。第 2 步修改解包产物改文案编辑res/values/strings.xml普通文本编辑器就能打开改逻辑在smali*/里定位到对应类.smali 是 dex 反编译的产物方法体是逐行可读的寄存器指令改配置AndroidManifest.xml已是 XML 文本权限、组件、minSdk 一目了然。建议一次只动一个点再重建方便定位失败原因。第 3 步用 apktool b 重建出新的 apkapktool b demo -o demo-rebuilt.apk # 预期结果smali 汇编回 dex、res 重新编译打包日志末尾出现 Built apk at: ...生成 demo-rebuilt.apk重建的输入就是前两步产出的整个demo/目录不再需要原始 apk不带-o时默认输出到解包目录下的dist/demo.apk。第 4 步签名后装机验证apksigner sign --ks demo.keystore --ks-key-alias demo demo-rebuilt.apk # 预期结果得到已签名的 apk卸载设备上的旧版本后即可安装启动确认改动生效到这里apk 进、改过的 apk 出的完整链路就跑通了。典型场景三个最常用的组合修改字符串文案并重建发布包背景线上包里一句提示语写错了等下个版本要两三周。关键操作解包后只改res/values/strings.xml里对应字符串用apktool b重建并签名。效果设备上的文案立即更新其余资源和逻辑保持原样。解包 manifest 排查权限与组件背景拿到一个第三方 apk想先搞清楚它声明了哪些权限、注册了哪些 Activity。关键操作apktool d -s -o probe demo.apk用--no-src跳过 smali 解码速度明显更快。效果直接打开probe/AndroidManifest.xml读取权限与组件声明十几秒出结论。修补 smali 逻辑并生成可调试 apk背景定位到某段逻辑有 bug改完 .smali 想在真机上反复调试。关键操作修改后执行apktool b --debuggable demo它会把清单里的android:debuggable置为 true。效果装到设备后可直接 attach 调试器观察修改后的实际行为。容易翻车的三个地方现象解包时报 Output directory ... already exists。原因-o指向的目录已存在且非空Apktool 拒绝覆盖以防误删你的修改。解法换一个输出目录或确认可以丢弃旧产物后加-f强制重建。现象重建时 aapt2 阶段报资源错误甚至出现 failed file tree check。原因改了资源文件名、删了资源或新增的 id 与代码引用对不上——smali 里的资源引用是按 id 硬编码的。解法只改资源值不动名字与引用格式确实要增删时先全局搜 smali 里对该资源的引用再动手。现象重建出的 apk 直接安装报签名错误覆盖旧版本时提示签名不一致。原因Apktool 的输出默认不带原应用签名签名不同就无法覆盖安装。解法用 apksigner 自行签名后安装先卸载旧版本日常调试固定使用同一个测试 keystore避免反复重装。周边搭配工具smali / baksmaliApktool 解包 dex 与重建时底层的汇编引擎两者调用封装见 brut.apktool/apktool-lib/src/main/java/brut/androlib/smali/aapt2重建时把 res 目录编译回 resources.arsc版本不匹配报资源错误时可用--aapt指定自带二进制apksigner给无签名的重建产物补上签名并验证zipalign对最终 apk 做 4 字节对齐满足安装与上架要求跑通以上步骤后你已经可以独立完成解包 → 修改 → 重建 → 签名装机的完整循环剩下的是按具体包的结构做有针对性的调整。【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考