简介：面向安卓开发和逆向调试场景的安装包修改工具整合包，适合需要分析安装包结构、定制应用行为或学习编译打包流程的开发者。压缩包内共有186个文件，整体约8.76兆字节，主要包括94个smali字节码文件、45个png图片资源和13个xml配置资源，并提供apktool批处理、aapt编译工具、ArscEditor资源编辑器、签名脚本及对应密钥文件，能够串联起反编译、资源修改、重新编译、签名打包的完整操作链路。当前已有617人学习下载，这套工具虽然以命令行脚本为主，也带有可视化编辑器，方便不同水平的用户上手。借助这些组件，可以实践修改QQ尾巴或应用标识、删除内置模块、清理冗余资源等二次开发工作；对逆向初学者来说，也可通过阅读smali代码定位关键逻辑，理解安卓安装包结构及签名验证原理，是一份适合日常调试和逆向练习的实用资源。

1. 拿到一个 APK 却没有源码：android apk 修改工具到底在改什么

外包项目交付时只给了个 release.apk，渠道方要求换启动图、改应用名，源码又找不回来——这种「只有安装包没有源码」的处境下，要做的不是重写一遍，而是用 android apk 修改工具把现有安装包解开、调整、再封回去。它解决的是一类很具体的需求：在不重新编译源码的前提下，替换资源、改动代码逻辑、修正包名版本，并让改完的产物能正常安装运行。这套流程适合移动开发、测试、安全审计和渠道运营的人，也是所有渠道包定制工作的地基。下面不会绕弯子，直接从 APK 的物理结构讲到解包、修改、重打包、签名一条龙，再列出最容易让人翻车的那几个坑。

2. 先看懂 APK 的壳再动手：DEX、资源表与签名校验的修改边界

任何修改工具都作用在 APK 的特定文件上，不先搞清楚这些文件的职责，后续命令报错时你连该怀疑谁都找不到。APK 本质是一个 Zip 压缩包，但 Android 系统只关心其中一小部分关键文件，改错一个重打包就装不上。这一章把壳拆开，顺便把工具选型与环境一次定下来。

2.1 APK 不只是 Zip 包：修改前必须认识的四个关键文件

先说 AndroidManifest.xml。它在包里是二进制 XML，直接文本编辑器打开全是乱码，需要 apktool 解码成可读格式。这里声明了 App 的入口 Activity、权限、ContentProvider 等，改错一个字段轻则闪退，重则直接判定为非法包。

再说 classes.dex。App 的 Java/Kotlin 逻辑编译后都在这里，多 dex 工程会有 classes2.dex、classes3.dex。大部分「改逻辑」的需求最后都落到改 dex 上，而 apktool 把 dex 反编译成 smali，改完再编译回去。resources.arsc 则是资源索引表，它把 R.java 里的整型 ID 映射到 res/ 下具体文件，这个文件在重编译时最容易出问题，很多闪退都跟它有关。

最后是 res/ 和 assets/。res/ 里的资源会被 aapt 编译并且受 resources.arsc 索引，assets/ 里则是原样打包，适合放一些不想被索引的原始文件。META-INF/ 更直接：只要你动了包里任何一个字节，这里的签名摘要就失效，系统安装时校验失败，所以「重打包必重签名」是铁律。

补充一点容易混的：系统组件格式 .apex 和普通 APK 是两套打包与修改路径，看到包体里嵌着 apex 的，用 apktool 硬解意义不大，先确认目标类型再动手。

2.2 工具选型：apktool、jadx、Android Studio APK 分析器怎么分工

选工具的核心原则是「修改动作只用一个主工具，分析动作用多个辅助工具」。主工具我一般选 apktool，它负责资源解码/重编译和 dex/smali 互转，是把修改落盘的执行者。jadx 负责分析，它能把 dex 还原成接近 Java 源码的形式，定位「改哪里」比直接看 smali 快得多。

Android Studio 自带一个 APK 分析器（Build > Analyze APK），适合只做体检不动刀：看每个 dex 的方法数、资源分布、原始 Manifest、图标和签名摘要。官方工具的好处是零配置，装上 Android Studio 就能用。dex2jar + JD-GUI 是老牌组合，现在多数场景被 jadx 替代，但遇到 jadx 解析不了的畸形 dex 时它偶尔能救急。

为什么不推荐全程用手机端的管理器？因为它能改资源、能帮你重签名，但没法脚本化，改 10 个渠道包你得手动点 10 遍，还容易漏签名步骤。电脑上搭一次命令行环境，后续全部可自动化，这是正规出包和临时改包的本质差别。

2.3 环境准备：Java、Build-Tools 与 apktool 的版本匹配

环境就三样：JDK、Android SDK Build-Tools、apktool。JDK 建议直接用 17，apktool 2.9 以上的版本在 JDK 8/11/17 下都能跑，17 对后续工具链兼容性更好。apktool 本体是一个 jar，去官方 GitHub Releases 页面拿最新版，统一放在一个目录里，比如 ~/tools/apktool.jar。

SDK Build-Tools 里藏着 apksigner、zipalign、aapt 三个关键命令。确认路径的方法：

ls $ANDROID_HOME/build-tools/ export PATH=$ANDROID_HOME/build-tools/35.0.0:$PATH apktool --version apksigner --version aapt version

注意不要同时把两个 build-tools 版本都加进 PATH，aapt 版本互相覆盖是编译期怪报错的常见来源之一。如果你用 Android Studio 装过 SDK 但没有配过环境变量，Android Studio 下载的 build-tools 路径一般在 ~/Android/Sdk/build-tools/ 下，按实际情况改上面那行 export 即可。顺手写一个 env.sh 把这个 export 放进去，每次开终端 source 一下，省得命令找不到再回来翻路径。

3. 用 apktool 跑通一次完整流程：解包、替换资源、重打包与签名

现在进入正题。下面每一步都基于一个未加固的普通 APK，目标是完成「换应用名、换图标、重新签名」的最小闭环。这条闭环跑通了，后面所有更复杂的修改都只是替换其中某一环。

3.1 解包命令与产物：apktool d 之后你拿到了什么

apktool d release.apk -o release_dir -f

d 是 decode 的缩写，-o 指定输出目录，-f 表示目标目录已存在时强制覆盖。执行后 release_dir 下会出现 AndroidManifest.xml（已从二进制转成可读 XML）、smali/（dex 反编译出来的代码）、res/（原样资源）、以及 apktool.yml（记录原包版本与构建信息）。

这里有两个加速开关值得记住。只看资源不改代码，加-s跳过 dex 反编译，能省掉一大半时间；只改代码不动资源，加-r保留 resources.arsc，重打包时不重编资源，闪退概率也降低。大型项目里这两个开关可以分开用，但第一次完整练习建议什么都别加，把全流程看一遍。

解包产物其实就是后续修改的工作目录。我一般会先在 release_dir 里翻一圈 res/values/strings.xml 和 apktool.yml，确认原包的版本号、minSdk 和包名，这些东西在安装阶段决定成败。

3.2 替换启动图标与修改应用名称：第一次最小修改

# 用本地图标覆盖 mdpi 密度的启动图标 cp new_icon.png release_dir/res/mipmap-mdpi/ic_launcher.png # 修改应用显示名称 sed -i 's/测试应用/正式应用/g' release_dir/res/values/strings.xml # 直接改版本号，不改代码 sed -i 's/versionName: 1.0.0/versionName: 2.0.0/' release_dir/apktool.yml

第一行替换图标注意密度目录。mdpi、hdpi、xhdpi、xxhdpi 分别对应不同分辨率，如果只替换了 mdpi，高分辨率机型会去别的 density 目录找同名资源，找不到就用默认缩放，效果可能模糊。稳妥做法是所有密度目录都覆盖一遍同名文件。

第二行改的是应用显示名，它最终会被写回 resources.arsc。用 sed 的好处是快，坏处是如果 strings.xml 里有多处匹配会全改，严格场景可以打开文件手工改。第三行改版本号只是演示，versionName 决定系统设置里显示的版本，versionCode 才是应用升级判断的依据，渠道包场景通常只动 versionName。

3.3 重打包与签名：apksigner 的 V1/V2 参数差异

# 1. 把修改后的目录编回 APK apktool b release_dir -o modified.apk # 2. 4 字节对齐，必须在签名之前做 zipalign -f 4 modified.apk aligned.apk # 3. 用 keystore 签名 apksigner sign --ks release.keystore --ks-key-alias release \ --ks-pass pass:changeit --out final.apk aligned.apk # 4. 验证签名 apksigner verify -v final.apk

apktool b 是 build 的缩写，它把 release_dir 重新编译成 APK。zipalign 是 Android 系统的内存对齐优化，-f覆盖旧文件，4表示 4 字节对齐，这一步必须在签名前，因为签名是对整个包内容做摘要，签名后再对齐会导致摘要失效。

提示：zipalign 与 apksigner 的顺序不能颠倒，先签名再对齐会让签名摘要失效。

apksigner 是 SDK Build-Tools 里官方的 apk 签名工具。--ks指定 keystore 文件，--ks-key-alias指定别名，--ks-pass后跟密码。签名方案上 apksigner 默认 V1 和 V2 都开，这个默认值很关键：V1 兼容 Android 7.0 以下，V2 从 Android 7.0 开始强制校验，两套都开覆盖才完整。老项目如果只有 V1 签名，Android 11 以上安装会直接提示签名方案错误。验证命令最后一步会列出 v1、v2 的启用状态，看到都是 true 才算完。

keystore 如果还不存在，先用 keytool 生成一个，这是 JDK 自带的命令，与 apksigner 配合用：

keytool -genkeypair -v -keystore release.keystore -alias release \ -keyalg RSA -keysize 2048 -validity 10000

这里注意密钥有效期单位是天，10000 天约 27 年，够一个长期维护的渠道包用了。密码在--ks-pass pass:changeit里是明文，脚本里可以接受，落到团队共享环境建议改成从环境变量读。

3.4 最小流水线：把命令串成可复用脚本

手动一步步敲没效率，把上面的步骤串成脚本，输入一个原始包，输出签名后的最终包：

#!/bin/bash set -e SRC="$1" OUT="final-$(date +%Y%m%d-%H%M).apk" R_DIR="work_dir" apktool d "$SRC" -o "$R_DIR" -f # 这里插入资源替换或 smali 修改逻辑， # 例如 3.2 节的 cp/sed 命令。 apktool b "$R_DIR" -o modified.apk zipalign -f 4 modified.apk aligned.apk apksigner sign --ks release.keystore --ks-key-alias release \ --ks-pass pass:changeit --out "$OUT" aligned.apk apksigner verify -v "$OUT" echo "output: $OUT"

set -e 让任何一步返回非零就直接退出，防止签名步骤对一个坏包继续执行。SRC 从命令行第一个参数读入，输出文件名带时间戳，方便连续出包时追溯到具体版本。这就是一条最简的修改流水线，后续加渠道号、批量签名都从这段脚本扩展。

4. smali 级修改与加固检测：从改返回值到识别伪 APK

资源替换解决名字和图标，逻辑层面的修改要进入 smali 的世界。apktool 把 dex 反编译成 smali，这种格式刚看会觉得啰嗦，但套路其实很固定。这一章只讲两件事：怎么改一个判断逻辑，怎么识别哪些包根本改不动。

4.1 看懂一段 smali：寄存器、指令与返回值的修改套路

拿一个最简单的方法举例，假设 Java 代码是public boolean isVip() { return false; }，反编译后的 smali 长这样：

.method public isVip()Z .registers 2 const/4 v0, 0x0 return v0 .end method

.method 声明方法名，()Z表示无参数返回 boolean。.registers 2 表示这个方法一共占用 2 个寄存器，这里实际只用到了 v0。const/4 v0, 0x0 是把 0 写入 v0，相当于 Java 里的 false；return v0 返回它。想把返回值改成 true，只需要把 0x0 改成 0x1。

定位方法比改重要。在 jadx-gui 里打开 APK，找到目标方法，复制类名和方法签名，再到 smali 目录用 grep 搜位置，搜出来的文件就是你要改的那个类。加了一个新判断想记录变量，要记得同步调整 .registers。

4.2 实例修改：把固定的 boolean 返回值改掉

场景是调试版本的开关写死了，现在要通过修改 smali 让开关打开：

grep -rn "isVip" work_dir/smali/com/example/ # 找到 MainActivity.smali 后修改 sed -i 's/const\/4 v0, 0x0/const\/4 v0, 0x1/' \ work_dir/smali/com/example/MainActivity.smali

sed 只能用于唯一匹配的简单场景，方法里如果多处出现const/4 v0, 0x0，直接 sed 会把不相关的地方也改掉，这种时候建议用文本编辑器打开文件看上下文再改。另外 Linux 下-i直接生效，macOS 上要写成sed -i ''。改完回到第 3 章的完整命令串，重打包、签名、安装验证，一个闭环就完成了。

这里必须展开一个寄存器配平的问题。smali 的方法头里有.registers N和.locals N两个数值，.registers 是方法占用的总寄存器数，.locals 只计算局部变量，带参数的方法参数也算在 .registers 里但不计入 .locals。当你把一段逻辑从 1 个变量扩展到 3 个变量时，如果没有同步把 .registers 调大，重打包后一运行就崩，报的是 VerifyError 或 RuntimeException。这是 smali 修改最常见的新手坑，我在这里翻过一次车，后来凡是引入新变量都先数一遍寄存器数再动头。

4.3 加固 APK 的识别：为什么解出来只有一个 dex

apktool d 解包本来顺利，一看 smali 目录却只有零星几个类，MainActivity 都不在；再翻 assets 目录，有 libjiagu.so、libshell*.so 这类文件名。基本可以断定这个包做了 apk 加固。加固的原理是壳先启动，运行时才把真正的 dex 释放到内存并加载，磁盘上的 dex 只是一个壳入口。

这种包直接在 smali 目录里找业务逻辑是找不到的。常见做法是让应用在测试环境跑起来，用内存 dump 类工具把运行时释放的 dex 捞出来，再交给 jadx 分析。但这一步已经踩进逆向加固的深水区，我只建议在两个前提下做：目标是你自己开发的 App，或者有书面授权的安全测试。两个前提都不满足，最稳妥的答案是回上游要源码。别为了一时改包去硬刚加固壳，很多壳带反调试，运行环境稍有异常就把真实代码销毁，耗时耗力还拿不到干净产物。

4.4 与混淆字典无效的联动坑：改了字典为什么没有效果

遇到过「Android 自定义混淆字典无效」的场景：在 proguard-rules.pro 里改了字典文件、把 keyword 换成自定义词汇，重新打包后发现方法名毫无变化。这不是工具坏了，是混淆字典的作用时机问题。R8/ProGuard 的字典只在「从源码打包」时参与混淆命名，你手上拿到的 APK 里的 dex 已经混淆完成，名字是固定的，再改字典对现有 dex 没有任何影响。

想看到可读的类名方法名，唯一可靠的是原始工程的 mapping.txt。把 mapping.txt 拖进 jadx 可以做反混淆映射，改完的代码逻辑再对回 smali 才有意义。如果拿到的渠道包和你手上的 mapping.txt 对不上，说明它不是同一份构建产物，继续往下改只会浪费时间。

5. 避坑：重打包后闪退、无法安装与检测异常的 5 个常见问题

重打包后的故障率远高于正常开发，因为每一步都可能引入不可见的问题。下面 5 条是把常见翻车按现象拆出来的排查路径，每一条都按「现象 → 原因 → 解决」来给。

5.1 闪退定位：先看 logcat 的 ActivityNotFoundException 与资源 ID

现象：安装成功，点图标闪一下就退回桌面，没有弹窗没有提示。

原因：常见两类。一类是 Manifest 里声明的 Activity 类名在 smali 目录里对不上，典型报错 ActivityNotFoundException；另一类是资源 ID 悬空，代码里引用的 R.id 在 resources.arsc 里找不到，典型报错 Resources.NotFoundException。

解决：先把崩溃堆栈抓出来再动手：

adb logcat -s AndroidRuntime:E | head -50

看到 ActivityNotFoundException，比对 manifest 里的 activity 类名和 smali 目录里的实际路径；看到 Resources.NotFoundException，优先怀疑重编译资源时 ID 映射被改动。这里有个绕坑技巧：重打包时加-r保留原始 resources.arsc，很多资源类闪退会直接消失。

5.2 签名方案不匹配：V1 缺失导致 Android 7.0 以下装不上

现象：同一个修改包，手里的 Android 13 测试机装得好好的，客户老手机一会说「解析包错误」，一会说「无法安装apk文件」。原因基本确定是签名方案覆盖不完整。apksigner 如果只开了 V2 签名，Android 7.0 以下系统不认 V2，直接拒绝安装；反过来只开 V1，Android 11 以上又会因为缺少 V2 而报错。

解决：签名时把 V1、V2 都显式打开，别依赖默认值：

apksigner sign --ks release.keystore --ks-key-alias release \ --v1-signing-enabled true --v2-signing-enabled true \ --ks-pass pass:changeit --out final.apk aligned.apk apksigner verify -v final.apk

verify 输出里 v1 和 v2 都要是 true。V3 签名只有 Android 9+ 需要，普通渠道包不需要开，开了反而缩小兼容范围。

5.3 安装时提示「应用未安装」：包名冲突与签名不一致

现象：点安装后系统直接弹「应用未安装」，没有任何细节，日志里也不一定有报错。

原因：手机上已有一个同包名的包，但签名跟你要装的这个不一致，系统为了保护数据安全拒绝覆盖安装。另一个可能性是 targetSdkVersion 高于手机系统版本，不过后者少见，多数是签名冲突。

解决：先卸载旧包再装，或者用 adb 强制覆盖：

adb uninstall com.example.app adb install final.apk

不想卸载原应用就只能改包名，这要同步改 Manifest 的 package 属性、Gradle 里的 applicationId 和代码里所有用到包名的位置。特别提醒 ContentProvider 的 authorities 也经常带包名前缀，只改 Manifest 不换 authority 一样会冲突。

5.4 编译中断：aapt 报错与 framework 文件过期

现象：apktool b 时突然报一堆资源编译失败，或者直接一个字 nil 然后退出。之前同样的流程跑过很多次都没问题。

原因：apktool 在解包时会把当前系统的 framework-res.apk 解析并缓存 ID 映射，Android SDK 升级后缓存过期，重编译时新旧 ID 对不上；第二种可能是 res/ 里有新版 Android 才支持的资源类型，老版本 apktool 不认识。

解决：先清理缓存再重新解包：

apktool empty-framework-dir apktool d release.apk -o work_dir -f

如果清理后仍报错，去把 apktool 更新到最新版。这个坑属于典型的「升级 SDK 后玄学报错」，其实和你的修改逻辑完全没关系。

5.5 服务端校验：装得上但提示「非官方版本」

现象：包装好了，功能也能打开，但进入主界面就弹「检测到非官方版本」，或者某个按钮被禁用。

原因：App 的服务端在请求里带上包名、签名哈希、渠道号等设备信息，服务端比对后发现不是官方渠道。这是完整的防篡改链路里最常用的手段，绕过的成本和风险都很高。

解决：先抓包确认校验接口。常见做法是用代理工具对 HTTPS 做解密，看哪个接口返回了校验失败字段，定位后评估修改点。这里我要把边界画清楚：绕过服务端校验明显超出合规范围，对测试团队来说，遇到这一层保护的正确结论是「该包已做完整性保护，需要回到源头确认授权」，而不是继续硬破。这条放在最后，是因为很多人发现连授权都没拿到时才意识到，自己的目标从一开始就不该选这种包。

6. 把修改固化成本地脚本：批量验证与回归测试的一个可行做法

当「改一个包」变成「改十个渠道包」，手工流程就不够用了。把第 3 章的流水线加一个验证函数，每次出包后自动检查包名、签名、可安装性：

#!/bin/bash verify_apk() { echo "verify: $1" aapt dump badging "$1" | grep -E "package:|application-label:" | head -2 apksigner verify -v "$1" | grep -E "v1|v2" pkg=$(aapt dump badging "$1" | awk -F"'" '/package:/{print $2}') adb install -r "$1" >/dev/null 2>&1 && \ adb shell monkey -p "$pkg" 1 >/dev/null 2>&1 sleep 3 adb logcat -d -s AndroidRuntime:E | grep "$pkg" || echo "no fatal: $pkg" } for apk in out/*.apk; do verify_apk "$apk" done

aapt dump badging 输出里带包名、版本、启动 Activity，是验证产物的第一道关；apksigner verify 确认签名方案；adb install 安装后用 monkey 发一条随机事件拉起主界面，3 秒后再查 logcat 有没有崩溃。这套验证能覆盖大部分安装即崩的回归问题。

我现在的习惯是，每次出包都把原始 APK、中间修改目录、签名产物三份留在带日期的目录里。调试到第三轮时还能翻出最初那份原始包做对比，确认自己中途没改歪。这个习惯帮我省掉了不少「改着改着忘了哪个步骤」的血泪时间，也建议你把它固定下来。希望帮到你。

本文还有配套的精品资源，点击获取