简介面向安卓开发者和逆向入门者的 APK 修改工具资料包围绕安装包结构认识、界面资源替换、反编译重打包、签名校验与权限调整等常见需求展开适合希望系统了解安装包组成并动手定制应用的中初级读者。内容从清单配置文件、资源目录、字节码文件、架构库目录、附加资源与签名信息等模块讲起并介绍反编译、代码查看、图形化修改和命令行签名等工具的使用场景兼顾图标、启动画面、文字与布局替换以及代码查看、广告去除、资源复用等操作思路。压缩包为 zip 格式约 28.58MB文件总数显示为 0类型明细暂未提供因此不展开具体文件构成。已有 1320 人学习下载可帮助读者建立从解包、修改到重新签名的基础流程认知同时提示版权、安全、兼容性与隐私风险便于在合法前提下开展个性化定制与研究。1. 从一次渠道包事故说起apk修改工具到底在改什么去年帮某公司的安卓渠道包做灰度测试机上只回了一行INSTALL_PARSE_FAILED_INVALID_APK日志里什么都没多说一句。翻到打包脚本最后才发现zipalign和apksigner的顺序被上一位同事调反了v2 签名把对齐结果又覆盖了一遍。apk修改工具这个说法听着笼统落到手上其实就一组命令解包、定位、改、回编译、对齐、签名、验证七步里任何一步偷懒后面全是玄学问题。这篇按我实际排障的顺序写从 APK 的文件结构讲到 apktool 与 jadx 两条路线再落到签名顺序和五个高频翻车点适合给自有应用做渠道定制、兼容性适配、体积裁剪的 Android 开发也适合想搞明白重打包到底动了哪些字节的逆向入门者。2. 拆开一个 APK五层结构决定你该用哪把刀很多人拿到 APK 第一反应是解压然后对着一堆二进制 XML 发愣。先把容器结构看清楚后面选工具就不会乱。一个标准 APK 从上到下大致是 ZIP 容器、编译后的二进制资源、编译后的字节码、原生库和签名块这几层每层的可编辑性差别很大能不能改、改完要不要重新编译取决于你动的是哪一层。我一般会先用unzip -l把目录树打出来比任何工具都快也最不容易被工具的“智能处理”误导。2.1 ZIP 容器与三个不能碰的目录# 只看文件清单不解压 unzip -l app-release.apk | head -40 # 看某个条目是否被压缩存储关键看 Compressed size 是否等于 Uncompressed size unzip -v app-release.apk | grep -E resources.arsc|AndroidManifest|\.so$上面两条命令解决的是两个问题文件清单告诉你这个包有多大、有没有多余 dex、so 库铺了几套 ABIunzip -v的压缩率则直接决定重打包后能否安装。APK 本质是 ZIP但不是所有条目都能随便压缩AndroidManifest.xml、resources.arsc以及lib/下的 so 在多数 targetSdk 下要求存储或特定对齐方式尤其是 Android 11 之后resources.arsc必须保持未压缩且四字节对齐否则安装器直接拒绝。而META-INF/目录是签名块的家任何改动只要动了这个目录里的文件v1 签名立刻失效所以它属于“改了就得整包重签”的区域。实务上我会把 APK 内部划成三块可自由改的assets、raw 资源、编译后要重打包的res、dex、manifest、绝对不能手改只能靠工具重建的META-INF。分清楚这三块你才知道自己该走全量重打包还是只替换 dex。2.2 dex、resources.arsc、AndroidManifest 的分工文件/目录实际格式常用编辑工具改错后的典型症状classes*.dexDalvik 字节码jadx 看、baksmali/smali 改、apktool 全量类找不到、NoClassDefFoundErrorresources.arsc二进制资源索引表apktool 反编译为res/valuesResources$NotFoundException、安装失败AndroidManifest.xml二进制 XMLapktool 解为明文组件不注册、exported报错res/下 XML二进制 XMLapktool 解码布局错乱、资源 ID 对不上lib/abi/*.soELF一般不动只做裁剪UnsatisfiedLinkErrorMETA-INF/签名文件apksigner 重建签名校验失败表格里最容易被低估的是resources.arsc。它不是简单的字符串表而是资源 ID 到值的映射索引res/目录下的每个文件都和它有一一对应关系。你手改res/layout/xxx.xml却不重新编译 arsc运行时拿到的还是旧 ID轻则布局没变化重则直接崩在inflate。所以改资源必须走 apktool 回编译没有捷径。AndroidManifest.xml同理它是二进制 XML 格式用文本编辑器打开只会看到乱码。apktool 会把它还原成可读 XML但还原过程中会插入platformBuildVersionCode之类的属性某些校验严格的场景下需要手动清掉。2.3 工具选型四条路线对照路线工具组合适用场景代价全量重打包apktool d b改资源、改 manifest、改 smali慢容易踩资源编译坑仅资源apktool d -s b只改res/、strings、图标不能碰代码仅代码baksmali smali zip 替换只改一两个方法需自己处理 dex 合并二进制补丁十六进制对比 重签极小的字符串替换长度必须严格一致选型上有条血泪经验改动范围越小走的工具链就该越短。改一个开关常量用不着 apktool 全量重打包再等三分钟baksmali 打完补丁塞回 ZIP 就行反过来只要碰了res/values/strings.xml就必须老老实实走 apktool因为资源 ID 会重新分配。另外两个辅助工具值得常备jadx负责把 dex 还原成可读 Java 用于定位apkanalyzerAndroid SDK 自带能直接对比两个 APK 的体积构成和方法数裁 so、找冗余资源时比肉眼看目录快得多。3. apktool 全量路线解码、改资源、回编译apktool 是这条路线上绕不开的工具但它也是最容易用错参数的一个。很多人把它当成“解压 反编译”一步到位的黑匣子结果改完回编译出来装不上又回头怀疑工具本身有 bug。实际上 apktool 的参数决定了它到底帮你做了多少事选错参数改动就是白做。3.1 解码参数-s、-r、-f 各自的代价# 全量解码资源 dex 都反编译成 smali apktool d app-release.apk -o decoded -f # 只解资源dex 原样保留不生成 smali 目录 apktool d app-release.apk -o decoded -s -f # 只解 dex 和 manifest资源保持二进制不反编译 apktool d app-release.apk -o decoded -r -f # 指定 aapt2 处理兼容较新的资源格式 apktool d app-release.apk -o decoded -f --use-aapt2-s的含义是 skip sources即不反编译 dexdecoded/下会保留原始的classes.dex而不生成smali/目录。这个参数适合“只改资源”的场景能省掉一大半解码时间但代价是你没法在里面改任何代码回编译时 apktool 会原样把 dex 塞回去。-r是 skip resources反过来保留二进制资源只把 dex 和 manifest 解出来。这里有个坑-r模式下res/目录里躺的是原始二进制文件你即便改了也不会被重新编译很多人以为改了图标就生效实际打出来还是旧图。除非你只动 smali否则别用-r。-f是强制覆盖已有输出目录。这个参数本身无害但它会让“上次解码残留的文件”被清空如果你在decoded/里手写了补丁文件却忘了备份一条-f就全没了。我一般会先cp -r decoded decoded.bak再动手。--use-aapt2建议默认带上。老版本 apktool 用的 aapt 对某些新资源格式支持不好回编译时报Invalid resource或者资源 ID 冲突换 aapt2 基本能解决。3.2 改 resources 与 AndroidManifest 的边界资源侧能改的东西比想象中多res/values/strings.xml改文案、res/values/colors.xml改主题色、res/mipmap-*换图标、res/values/bools.xml关掉某个特性开关。改完这些不需要动 smaliapktool 回编译时会重新生成resources.arsc资源 ID 映射自动对齐。!-- decoded/res/values/strings.xml改应用名 -- string nameapp_name渠道演示包/string !-- decoded/AndroidManifest.xmltargetSdk 31 必须显式声明 exported -- activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity上面这段exported是这两年最常见的坑。targetSdk 升到 31 之后带 intent-filter 的组件不写android:exported会在安装阶段被拒报错信息还很不直观。做渠道定制时如果把启动 Activity 换掉记得同步补这个属性。版本号不在 manifest 里改而是在decoded/apktool.ymlversionCode: 10203 versionName: 1.2.3-channel minSdkVersion: 23 targetSdkVersion: 33这个文件是 apktool 回编译时的权威来源直接改 manifest 里的versionCode反而会被覆盖。改完apktool.yml再回编译adb shell dumpsys package 包名里能看到新版本号这是验证改动是否真的写进去了的最快方式。3.3 回编译与增量替换 smali# 回编译输出的是未签名、未对齐的 APK apktool b decoded -o dist/app-unsigned.apk --use-aapt2 # 如果只想替换 dex不重打包资源可以走增量路线 # 1) 用 baksmali 把原始 dex 拆开 baksmali d dist/original/classes.dex -o smali_out # 2) 改完 smali 后重新汇编回 dex smali a smali_out -o classes.dex # 3) 直接替换 ZIP 里的条目资源部分完全不动 zip -j dist/app-unsigned.apk classes.dex增量替换这条路的价值在于资源部分一个字节都没动resources.arsc不会被重新生成也就避开了所有资源编译相关的坑。代价是你得自己保证 dex 的格式正确多 dex 场景下还要注意classes2.dex的对应关系改错 dex 就是白忙。回编译失败时先看 apktool 的 stderr 第一行通常是资源编译错误会直接指出哪个 XML 的哪一行。如果报的是brut.androlib.AndrolibException: Could not smali那基本是 smali 语法问题把改过的文件单独拿出来对照原文件看寄存器数量是否匹配。4. 轻量路线jadx 定位 smali 单点补丁只改一两个方法的时候全量 apktool 显得太重。我的常规做法是 jadx 先把目标方法找出来再用 baksmali/smali 做单点替换整个过程不碰资源回编译成本几乎为零。这条路线适合加调试开关、改常量、临时屏蔽某个 SDK 的初始化。4.1 用 jadx 找到要改的那一行# 反编译成 Java 源码便于阅读输出到 out/ jadx -d out app-release.apk # 只搜字符串快速定位常量或日志 tag jadx -d out --no-res app-release.apk grep -rn isDebugEnabled out/ | head-d指定输出目录--no-res跳过资源反编译能省不少时间。jadx 的输出是“尽量还原”的 Java遇到混淆代码会有synthetic方法或者$后缀的类名但方法体逻辑基本可信。找到目标方法后记下它的完整签名类名 方法名 参数类型 返回类型smali 里就是靠这个签名定位的。一个实用技巧jadx 反编译出来的方法旁边会标注它在 dex 里的位置信息但更直接的办法是在 smali 目录里搜方法签名。混淆过的类名可能变成a.b.c方法名也可能变成a这时候只能靠字符串常量反查——先 grep 到常量所在的 smali 文件再往上看它属于哪个方法。4.2 baksmali / smali 只动一个方法# 原始方法返回一个 boolean 开关 .method public static isDebugEnabled()Z .registers 1 const/4 v0, 0x0 return v0 .end method # 补丁后常量改成 1本地调试时强制打开 .method public static isDebugEnabled()Z .registers 1 const/4 v0, 0x1 return v0 .end method这个例子里.registers 1表示方法体分配了 1 个寄存器v0就是那唯一的寄存器const/4表示四字节常量赋值。改动只涉及一个字节的立即数方法签名和寄存器数量都没变所以不会影响调用方。要动更复杂的逻辑时寄存器数量是最容易翻车的地方。比如给方法体加一行日志就需要额外的寄存器.registers的值必须同步加一否则回编译出来的 dex 校验不过运行时报VerifyError。我一般的做法是宁愿不改寄存器总数用方法里已有的空闲寄存器或者干脆把整个方法体替换成一段固定逻辑。# 拆 dex baksmali d classes.dex -o smali_src # 改完之后汇编回去注意 -a 指定 API 级别要和原包一致 smali a smali_src -o classes.dex -a 33 # 替换进 APK zip -j app-unsigned.apk classes.dex-a参数指定 API 级别影响 smali 汇编时使用的指令集版本。这个值和原 APK 的minSdkVersion对不上时可能出现低版本设备无法验证方法的问题。稳妥做法是从apktool.yml里读出原值照抄。4.3 怎么验证补丁真的生效改完不验证等于没改。我的验证顺序是三步第一步apktool d把刚打出来的包重新解一遍grep 你改的那个常量或者字符串确认写进去了。这一步排除“改错文件”和“ZIP 替换没生效”两种可能。第二步装到设备上adb shell dumpsys package 包名看版本号、adb logcat | grep 你的 tag看运行时行为。如果改的是开关方法找一个会调用它的入口触发一次看日志分支有没有变化。第三步如果改动涉及 dex 结构用dexdump -d classes.dex | head -50检查 dex 头部是否合法或者干脆用 Android SDK 里的apkanalyzer dex packages看类列表能不能正常解析。dex 损坏的症状很有迷惑性安装能过一启动就ClassNotFoundException很容易误判成混淆问题。5. 签名、对齐与常见排查安装失败的九成在这到这一步包已经改完了剩下的是让它能装上去。签名和对齐是整条链路上最没有技术含量、却又最容易出错的两步我见过的安装失败里至少九成能归到这两件事上。搞懂 v1/v2/v3 的差异和工具执行顺序能省掉大量无效排查。5.1 v1/v2/v3 的差异与选择签名方案引入版本覆盖范围特点v1 (JAR)很早META-INF/下三个文件逐文件摘要改任何文件都会失效v2Android 7.0整个 APK 的二进制块校验快但对齐必须在签名前v3Android 9.0增加密钥轮换支持与 v2 并存向下兼容v4Android 11独立.idsig文件增量安装用一般打包不需要实际打包时我的建议是三个都开--v1-signing-enabled true --v2-signing-enabled true --v3-signing-enabled true。v1 保证低版本设备能装v2/v3 保证新设备校验通过。只开 v2 在 Android 6 及以下会直接装不上这个兼容性问题在渠道包里特别常见。# 生成签名密钥一次性操作 keytool -genkeypair -v \ -keystore demo-release.jks \ -alias demo \ -keyalg RSA -keysize 2048 -validity 10000 \ -storepass 你的密码 -keypass 你的密码 \ -dname CNdemo, OUdev, Odemo, Lcity, STstate, CCN-validity 10000是天数约 27 年够用了。-dname里不要填真实信息测试密钥随便写就行。这个 jks 文件要保管好丢了就没法给已安装的包做覆盖升级只能让用户卸载重装。5.2 zipalign 与 apksigner 的顺序# 顺序不能反先对齐再签名 zipalign -p -f -v 4 dist/app-unsigned.apk dist/app-aligned.apk # 签名输出最终包 apksigner sign \ --ks demo-release.jks \ --ks-key-alias demo \ --ks-pass pass:你的密码 \ --key-pass pass:你的密码 \ --v1-signing-enabled true \ --v2-signing-enabled true \ --v3-signing-enabled true \ --out dist/app-signed.apk \ dist/app-aligned.apk # 验证签名和对齐 apksigner verify -v --print-certs dist/app-signed.apk zipalign -c -v 4 dist/app-signed.apkzipalign的-p参数是针对 so 库的页对齐API 23 以上必须带否则部分设备加载 so 会失败。4是四字节对齐这个值不要改。顺序的原理很简单v2/v3 签名是对整个 APK 文件做二进制摘要签名之后再跑zipalign会把文件内容挪位置摘要立刻失效但apksigner verify有时候还能通过因为它读的是签名块里的摘要装到设备上才报错。这种“验证通过但装不上”的情况最消耗时间我踩过一次之后就把顺序写死在脚本里了。apksigner verify -v的输出会列出 v1/v2/v3 各自的校验结果三个都是true才算干净。--print-certs打印证书指纹和已安装版本对比能快速判断是不是签名不一致导致的覆盖安装失败。5.3 五条高频翻车记录第一条resources.arsc被压缩安装报INSTALL_PARSE_FAILED_INVALID_APK。现象是签名验证全过装到 Android 11 以上设备直接被拒。原因是某些打包脚本用zip命令重新打包时默认压缩所有条目把 arsc 也压了。解决办法是用zipalign -p -f -v 4处理它会顺带把 arsc 调整为存储且对齐或者用zip -X -0 resources.arsc显式指定不压缩。第二条解码时用了-r改完res/里的图标没生效。现象是包能装、能跑就是图标和文案还是旧的。原因是-r模式下资源没有被反编译res/下是原始二进制改了也不会进编译流程。解决办法是去掉-r重新全量解码改完再回编译。这个坑我见过不止一个人踩因为-r解码速度快很容易图省事。第三条解码时用了-s改完 smali 改动全丢。现象是明明改了smali/下的文件回编译出来行为没变。原因是-s模式下 apktool 保留了原始classes.dex回编译时优先使用它smali/目录压根没参与编译。解决办法是改代码就不要带-s或者删掉decoded/下的原始 dex 文件强制走 smali 重编。第四条重签名后覆盖安装报INSTALL_FAILED_UPDATE_INCOMPATIBLE。现象是adb install -r失败提示签名不一致。原因是设备上已装的版本用的是另一套密钥。解决办法是adb uninstall 包名后重装或者从原包里把签名证书导出来复用但那需要私钥一般拿不到。做渠道包时一定要用同一套 jks别每次临时生成。第五条先签名后对齐安装成功但一启动就崩。现象很隐蔽apksigner verify说没问题装上去也能打开跑到某个功能点直接Resources$NotFoundException或者 so 加载失败。原因是zipalign在签名之后执行破坏了 v2 签名的完整性校验。解决办法是把顺序改成zipalign→apksigner并且把这条写进 CI 脚本靠人记迟早会出事。6. 自动化流水线与差分校验把改动关进笼子手工敲一遍上面所有命令十分钟能搞定一周做二十个渠道包手工敲就是灾难。我的做法是把整条链路固化成一个脚本参数全部走变量任何一步失败就退出不给“中间状态”留机会。6.1 一条命令跑到签名完成#!/usr/bin/env bash set -euo pipefail SRC_APK$1 WORKbuild/$(basename ${SRC_APK%.apk}) KSdemo-release.jks ALIASdemo rm -rf $WORK mkdir -p $WORK/dist # 1) 解码改代码就带 --use-aapt2不要带 -s apktool d $SRC_APK -o $WORK/decoded -f --use-aapt2 # 2) 这里插入你的改动脚本化替换、资源覆盖等 # cp -r patches/res/. $WORK/decoded/res/ # 3) 回编译 apktool b $WORK/decoded -o $WORK/dist/unsigned.apk --use-aapt2 # 4) 对齐必须在签名之前 zipalign -p -f 4 $WORK/dist/unsigned.apk $WORK/dist/aligned.apk # 5) 签名 apksigner sign \ --ks $KS --ks-key-alias $ALIAS \ --ks-pass pass:$KS_PASS --key-pass pass:$KEY_PASS \ --v1-signing-enabled true --v2-signing-enabled true --v3-signing-enabled true \ --out $WORK/dist/final.apk $WORK/dist/aligned.apk # 6) 双重验证任何一项不过直接退出 apksigner verify -v $WORK/dist/final.apk /dev/null zipalign -c 4 $WORK/dist/final.apk echo OK: $WORK/dist/final.apkset -euo pipefail是这段脚本最值钱的一行任何一条命令返回非零就立刻中断不会带着半成品继续往下跑。密码走环境变量KS_PASS/KEY_PASS不写死在脚本里避免提交到仓库。第六步的zipalign -c是对齐检查模式只校验不改文件放在最后当守门员。脚本化之后还有个额外好处改动可以做成 patch 目录res/下放渠道专属的资源文件脚本里一句cp -r覆盖进去比手工一个个改稳得多也方便版本管理。6.2 差分校验确认只改了该改的# 解压两个包对比文件清单和大小快速看改动范围 mkdir -p diff/orig diff/new unzip -q original.apk -d diff/orig unzip -q final.apk -d diff/new diff -rq diff/orig diff/new | grep -v META-INF | head -20 # 对比 dex 里的类清单确认没有意外引入新类 apkanalyzer dex packages diff/orig/classes.dex diff/orig-classes.txt apkanalyzer dex packages diff/new/classes.dex diff/new-classes.txt diff diff/orig-classes.txt diff/new-classes.txt | headdiff -rq会列出所有内容不同的文件grep -v META-INF是为了排除签名文件本身的差异否则每次都会刷一屏。如果改动只在预期范围内输出应该只有你动过的那几个文件。apkanalyzer那段是防“误引入”的——有时候 smali 汇编参数不对会把整个 dex 的类索引重排表面上看不出来实际方法数暴涨装到低端机上直接65535溢出。从那以后我每次出渠道包都会强制走一遍这个差分哪怕只改了一个字符串。改动范围失控是重打包里最难查的一类问题肉眼看不出来工具一对比就现原形。希望帮到你。本文还有配套的精品资源点击获取