反编译失败别急着重装：经典版排错、资源 ID 与多渠道

先把结论放在前面：反编译失败时，卸载重装几乎是最后一招，而且大多数时候无效。重装能修的是“工具文件损坏、组件缺失、路径被写坏”这一类问题；可现实里绝大多数失败，发生在工具之外——APK 本身的资源表、你改过的某个 XML、工程里那张同名不同路径的图、上一次签名留下的缓存。工具每次都在忠实地执行，它没有坏，坏的是输入或工程状态。

更麻烦的是，重装会把现场一起清掉。经典版的工程目录、apktool.log、build 里的中间产物、签名配置，重装后要么被覆盖，要么路径变了。你以为是“问题还在”，其实是“证据没了”。更常见的情况是：重装后 JDK 或工具链路径变了，引入了新变量，原来的问题还没解决，又叠了一层环境问题。

这篇文章按一条真实排错链路的顺序写：先判断失败发生在哪一层，再教你怎么读日志，然后依次拆开框架与资源表、资源 ID 与 public.xml、伪九点图、签名冲突、多渠道打包，最后落到 Android Studio 工程导出和三个自家应用的实例。你可以从头读，也可以在遇到具体报错时直接跳到对应章节。

一、先别急着重装：把“失败”拆成五层

改包不是一次点击，而是一条流水线。输入层决定“这个包能不能被读”，解析层决定“资源表与清单能不能被理解”，资源层决定“res 能不能编译成新的资源表”，代码层决定“smali 能不能重新组装成 dex”，产物层决定“对齐、签名、安装能不能通过”。五层里任何一层出错，表面现象都可能只有一句“反编译失败”，但日志出现的位置、异常类名、被点名的文件完全不同。

排错的第一件事不是动手，而是归层。归层靠两个线索：失败发生在什么时间点，以及日志最后停在哪一个阶段标记上。反编译刚开始两秒内就失败，通常是输入包或框架资源表读不了；日志已经走到解码 values 之后才失败，多半是某个 XML 或资源值有问题；回编卡在 I: Building resources 是资源层；过了 I: Building apk file 才失败，是打包收尾；安装阶段才失败，问题已经不在 apktool 里了。

归层之后，再决定“重跑哪一段”。反编译失败，就从反编译重来；回编失败，保留已经反编译好的工程，只重跑资源编译；安装失败，连回编都不用重跑，直接查签名和旧包。经典版的手动路线在这里反而有优势：它不把整条链路包成一个看不见的黑盒，工程目录、日志、构建产物、签名结果都留在磁盘上，你可以只重跑失败的那一段，也可以把工程复制一份做对照实验。

手动意味着慢一点，但也意味着每一步都可解释、可复现、可交付给同事复查。改一个图标，正常路径可能只是十秒；可一旦失败，你需要的是“知道哪一个文件、哪一行、哪一个 ID 出的问题”，而不是“再点一次试试”。这就是经典版保留下来的价值：它把控制权交给你，也把排错的责任交给你。

动手之前，先把现场收好。至少保留这些：原始 APK（source.apk 或你自己备份的那份）、apktool.log、反编译后的工程目录（含 public.xml、res、smali、AndroidManifest.xml）、build 目录里的中间产物、签名用的 keystore 与别名、以及设备信息（Android 版本、ABI、targetSdk）。旧日志不要覆盖，改个名字留档；下一次失败时，两份日志一对比，多出来的那条往往就是答案。

• 不要先删工程。工程目录里的 public.xml 和原始资源，是判断“改坏了什么”的唯一参照。
• 不要先换工具版本。换版本等于同时改了两个变量，出了问题更难判断。
• 不要清空 build 目录。里面的 unsigned.apk、对齐后的包、签名日志，能证明失败发生在哪一步。

还有一个容易被忽略的细节：重装会重置工具链路径。经典版依赖 JDK 1.8+，如果机器上装了多个 JDK，重装后选中的可能不是原来那个；apktool 与 aapt 的位置也会跟着变。于是你以为是“原来的问题没解决”，其实是引入了新的环境变量。排错最怕变量太多，保留现场、一次只改一个因素，才是稳定的做法。

把“重装”换成“复现”。能稳定复现的失败，才有稳定的修法；不能复现的失败，先怀疑环境和缓存，而不是怀疑工具坏了。

二、读懂 apktool.log：从最后一行倒着找“第一现场”

apktool.log 是 apktool 自己输出的运行记录。经典版把它落在工程目录里，反编译的每一个阶段、每个被处理的目录、每条警告和异常都会写进去。它不是为“读着舒服”设计的，但对排错足够：有阶段锚点、有文件路径、有异常类名，三样东西凑在一起，基本能定位到具体文件。

读日志的顺序和读小说相反：从后往前。先看进程是怎么结束的——是正常走到 I: Built apk...，还是抛了 Exception in thread "main"；再看最后三十行有没有 brut.androlib.AndrolibException；然后往上找第一条以 E: 开头的行，或者第一条 Exception。

为什么是第一条 E，而不是最后一条？因为后面的错误往往是级联的。资源表读不出来，后面每一个资源都会“找不到”；一个 layout 引用了不存在的 drawable，aapt2 会把整棵引用树都点一遍。最后一行通常只是“最后一根稻草”，第一条 E 才是第一现场。很多“看起来几十个错误”的日志，真正需要修的只有一个文件或一个 ID。

I: Using Apktool 2.12.1 on app-release.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: ...\framework-res.apk
I: Regular manifest package...
I: Decoding file-resources...
W: Could not find 9patch chunk in file: "res/drawable-xxhdpi/btn_bg.9.png". Renaming it to *.png.
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...

上面这段日志信息量很大。第一行告诉你用的是哪个版本；Loading resource table 说明开始读 APK 自己的资源表；Loading resource table from file 说明它去读框架资源表了，路径就在后面；那条 9patch 警告是“兜底成功”，不是失败；最后一行 Copying original files 说明反编译整体完成。

回编阶段的日志长得不一样，但锚点同样清楚。下面这段是一个典型的“资源引用缺失”场景：aapt2 在链接阶段报某个 drawable 找不到，紧接着 manifest 处理失败，最后抛出 AndrolibException，并带上 aapt2 的退出码。真正的原因在中间那行 error: resource drawable/bg_main not found，后面的异常只是它的回声。

I: Using Apktool 2.12.1
I: Checking whether resources has changed...
I: Building resources...
res/layout/activity_main.xml:8: error: resource drawable/bg_main (aka com.example.demo:drawable/bg_main) not found.
AndroidManifest.xml:18: error: failed processing manifest.
Exception in thread "main" brut.androlib.AndrolibException:
  brut.common.BrutException: could not exec (exit code = 1):
  [aapt2, link, -o, ...]
I: Building apk file...

注意最后那行 I: Building apk file...。它出现不代表成功，只是 apktool 在异常之后仍然尝试走完了流程；判断成败要看进程退出码，以及有没有 Built apk 这样的收尾行。这也是“读日志不能只看最后一行”的原因：收尾行可能只是流程惯性，不是结果。

把阶段锚点记住，排查会快很多。反编译侧：Loading resource table 对应资源表，Decoding AndroidManifest.xml 对应清单，Decoding file-resources 对应图片与原始文件，Decoding values 对应 values 下的 XML，Baksmaling 对应 dex，Copying assets and libs 对应资产与 so。回编侧：Building resources 对应 aapt，Building apk file 对应打包，Copying unknown files 对应收尾。日志停在哪一行的下一段，问题就在那一段。

再说 W 与 E 的区别。W 是“我处理了，但结果可能和你预期不一样”，E 是“我处理不了”。伪九点图、属性按原始值保留、未知文件被原样拷贝，这些都是 W；资源表读不出、smali 语法错、aapt 链接失败，才是 E。把 W 当失败原因，容易南辕北辙；看到 E 却盯着 W 找，也是浪费时间。判断方法很朴素：W 之后流程继续，E 之后流程中断，只有 E 才需要你改输入。

实操时，建议把日志按阶段切成三段，分别搜索 E:、Exception、error:、W: Could not。搜索的目的不是列出所有错误，而是确认第一现场落在哪一段。再保留一份成功日志，把失败日志和它做对比，往往一眼就能看到多出来的那一条——这可能比逐行通读快十倍。

修复后的验证也要用日志。同一位置不再出现那条 E，后续阶段能继续推进，最后出现正常的收尾；如果只是“这次没报错”，但阶段日志比之前少了一截，说明有东西被静默跳过了，不能算修好。日志是证据，不是安慰剂：它应该能证明“这个失败点已经跨过去了”，而不是只证明“这次没看见它”。

三、框架与资源表：apktool 读不懂系统资源的三种症状

要理解框架问题，先要接受一个事实：一个 APK 里并没有“所有资源”。它自己的 res 目录、自己的资源表当然在包里，但像 android:textColor、android:windowSoftInputMode 这些系统属性，定义在设备的 framework-res.apk 里。apktool 反编译时要把属性 ID 还原成名字，就必须读一份对应版本的框架资源表；回编时又要把名字编译回 ID，用的还必须是同一份。

这就解释了为什么“昨天还好好的包，今天读不了”。变的不一定是包，可能是 Android 版本：新系统给 framework 加了新属性、新类型、新的资源表结构，旧框架文件里没有这些条目，apktool 就会在解码阶段卡住。也可能是你换了一台机器，机器上缓存的框架是另一个 API 的。工具没坏，参照物不对。

框架问题有三种典型症状，区分清楚能省很多时间。第一种是属性名丢失：反编译出来的 XML 里出现 android:attr/0x0101… 这种原始 ID，或者属性干脆不见了；日志里常见 W: Could not decode attr value, using raw value instead。第二种是资源表直接读不了：Could not decode arsc file，后面跟着 Expected: 0x…, got: 0x… 之类的字节偏移。第三种是反编译能过、回编报属性不存在：error: attribute android:… not found，因为工程里保留了一个当前 aapt 不认识的属性名。

判断是不是框架问题，有一个很省事的实验：换一份与 APK 的 targetSdk 匹配的框架资源表，重新反编译同一个包，其他什么都不改。如果日志里的错误位置明显后移、属性名恢复、资源表能读，那就是框架；如果错误一模一样，框架基本可以排除。这个实验的关键是“只改一个变量”，不要顺手升级 apktool，也不要改工程文件。

框架版本怎么选？看 APK 的 targetSdkVersion 与它用到的系统属性。最稳的来源是目标设备本身：从设备的系统分区里取 /system/framework/framework-res.apk，这份和机器上跑的系统完全一致。设备取不到时，用与 targetSdk 同代的 AOSP 框架包也可以，但要注意它和厂商定制包可能有属性差异。不要拿一个很老的框架去解一个很新的包，也不要用一个新框架去回编一个老工程——两边的 ID 空间不一致，问题只会更隐蔽。

这里有一条硬规则：反编译和回编必须使用同一套框架。apktool 支持用参数指定框架目录，反编译时读的是它，回编时读的也应该是它。中途换框架，等于把资源 ID 的“字典”换了一本，原来能对上的名字和数字会对不上；表现可能是回编成功但运行时报资源找不到，也可能是某些属性值悄悄变成了默认值。日志不会告诉你“你换了字典”，它只会告诉你“某个 ID 不存在”。

还有一种容易误判的情况：反编译日志里出现大量 W: Could not decode attr value, using raw value instead，但最后产物能用。这类警告往往是某个厂商自定义属性、或者某个可选属性在当前框架里没有定义，apktool 选择保留原始值继续。它不一定是“框架错了”，也可能只是“这份框架没有那个扩展”。判断方法是看这些属性是否影响你要改的部分：如果只影响一个你用不到的系统控件，可以先记录、继续；如果影响清单里的启动模式、权限或主题，就必须处理。

框架问题最忌讳“删了重装”。框架文件不会因为重装而更新，工具也不会因为重装而认识新属性。正确顺序是：确认 targetSdk，确认设备 Android 版本，取一份匹配的框架，反编译与回编共用它，然后重新验证。这个顺序看起来笨，但每一步都有可检查的依据，出了问题也知道该回到哪一步。

验证框架是否真的修好，不要只看“没有报错”。反编译完成后，打开几个关键 XML，确认系统属性是名字而不是数字；打开资源表相关的输出，确认没有大面积的 UndefinedResObject；回编完成后，安装到目标设备，检查主题、状态栏、权限弹窗这些依赖系统属性的部分是否正常。日志干净只是第一层，设备上行为正常才是最终标准。

四、资源 ID 与 public.xml：图换了，引用没换

资源 ID 是一个 32 位整数，通常写成 0xPPTTEEEE。PP 是包段，应用自己的资源通常是 0x7f，系统资源是 0x01；TT 是类型段，drawable、string、layout 各占一个号；EEEE 是条目段，同一个类型里的第几个资源。理解这三段，很多“ID 对不上”的问题就能自己解释。

apktool 反编译时会把原有的 ID 记录到 res/values/public.xml 里。它的作用不是“给资源起名”，而是“把名字和数字钉在一起”：回编时，public.xml 里列出的资源会尽量沿用原来的 ID，代码里写死的 const v0, 0x7f0b0012 才能继续指向同一个东西。你新增一个资源却没在 public.xml 里登记，构建工具就会给它分配一个新号，这个新号可能刚好和别处的旧号错位。

最常见的四种“改对了却没生效”，几乎都和引用链有关。第一种，改错了目录：manifest 的图标指向 @mipmap/ic_launcher，你改的是 res/drawable/ic_launcher.png，两个名字一样但类型不同，系统用的是 mipmap 那个。第二种，改错了密度：包里同时有 drawable-hdpi、drawable-xxhdpi、drawable-xxxhdpi，你只替换了其中一套，目标设备恰好用的是另一套。第三种，同名资源跨目录并存：drawable 与 drawable-v24 各有一份，构建时按配置择一，你以为改的是“唯一的那张”。第四种，代码里写死了 ID，资源本身换了新号，界面还去读旧号。

排查这类问题，建议按“现象、引用、定义、ID”的顺序走，不要跳步。先在界面上定位是哪个控件、哪个页面；再在 layout、menu、manifest 或 smali 里搜资源名，确认它到底引用了谁；然后找这个资源名在所有目录下的定义，看是不是有多个同名文件；最后才看 public.xml 里的 ID，以及回编后的资源表里这个 ID 指向什么。这个顺序的好处是：每一步都能留下证据，不会靠猜。

修改原则可以归纳成四句话：只改值，不改 key；能复用，不新增；要新增，先登记；写死 ID 的代码，优先改成按名字查。第一句是为了不动引用链，第二句是为了减少 ID 变化，第三句是为了让新资源有稳定身份，第四句是为了让代码不再依赖某个具体数字。前三条在 apktool 工程里就能做，第四条要看代码的可改程度。

“按名字查”在 smali 里通常是通过 getIdentifier 把字符串转成 ID，再拿去用。它比写死数字灵活，但有两个代价：一是运行时查找有开销，频繁调用要缓存结果；二是资源名在混淆或裁剪后可能不存在，必须在构建配置里保留。对于只改一次、不长期维护的包，直接把旧 ID 替换成新 ID 往往更省事，前提是你有一张准确的映射表。

映射表怎么来？最可靠的办法是对比修改前后的资源表。用 aapt2 或 aapt 导出资源列表，按“类型 + 名字”排序，逐条比对 ID；把变化的条目记下来，再去代码里搜这些旧 ID。只搜 0x7f 前缀是一个粗筛，能覆盖绝大多数应用资源引用，但也可能误伤常量；最终仍要结合上下文确认这个数字是资源 ID，而不是别的魔数。

public.xml 本身也有坑。它不是“越多越好”，而是“越准越好”：重复条目、类型段冲突、条目段越界，都会让回编报错或者产生不可预期的 ID。手工编辑时，最安全的做法是只在末尾追加、使用当前类型下未被占用的条目号、保持类型名与资源目录一致。不要为了“让 ID 好看”去重排整个文件，重排等于把全工程的引用重新洗一遍。

资源 ID 是“名字与数字的契约”。public.xml 是契约文本，资源表是契约的执行结果；只改图不改契约，界面当然不会变。

验证分三层。第一层是构建层：回编通过，aapt 没有报资源缺失或重复。第二层是资源层：导出回编后的资源表，确认目标资源的 ID 与预期一致，确认没有两个名字指向同一个条目。第三层是运行层：安装到目标设备，逐屏点检，切换语言与深色模式，看 logcat 里有没有 Resources$NotFoundException。三层都过，才算“改完”。

如果准备导出 Android Studio 工程，public.xml 的角色会发生变化：它不再是构建输入，R 类由 Gradle 的 AAPT2 重新生成，ID 顺序取决于资源合并与依赖。所有用符号引用的代码会自动跟随，写死数字的代码会断。这一点在第七节会展开，这里先记住结论：手动改包时，public.xml 是你的朋友；转成 Gradle 工程后，符号引用才是朋友。

五、伪 .9.png：Could not find 9patch chunk 的正确处理姿势

九点图（nine-patch）是 Android 里用来做“可拉伸背景”的图片格式。文件名以 .9.png 结尾，图片四周有一圈一像素的黑边：上边和左边标记可拉伸区域，右边和下边标记内容区域。PNG 文件内部还会带一个名为 npTc 的数据块，用来描述这四条边的位置。真正的九点图必须同时满足“文件名”和“数据块”两个条件。

伪九点图就是“名字叫 .9.png，但里面没有 npTc 块”的文件。它可能是一张普通 PNG 被错误命名，也可能是构建管线、二次打包、加固处理留下的产物。apktool 2.x 遇到这种文件不会直接失败，而是打印一条警告，把文件重命名为普通 .png，并改写引用：W: Could not find 9patch chunk in file: "res/drawable-xxhdpi/btn_bg.9.png". Renaming it to *.png.。这是标准兜底，不是崩溃。

在一个较新的 Android 样本上，曾出现过 18 个只有 77 字节的伪 .9.png，日志里对应 18 条同样的警告，回编仍然成功，产物也能正常安装。77 字节基本可以判定不是真正的九点图——真正的九点图至少要有像素数据和 npTc 块，不可能这么小。这类文件多半是占位图或空背景，改名之后不影响显示，也不影响功能。

那要不要处理？默认不处理。先把日志里的文件名全部记下来，按用途分三类：占位或纯色背景、必须拉伸的背景、根本不再被引用的废弃文件。占位与纯色，保留 apktool 改名后的结果即可；必须拉伸的，才需要重做真正的九点图；废弃的，确认没有引用后再删。分类的依据不是文件名，而是它在 layout 或代码里被谁引用、显示在什么位置。

最常见的错误处理，是看到警告就删文件。删掉之后，引用还在，回编就会报 resource drawable/… not found；如果恰好没报错，安装后运行到那个界面就会崩。第二个错误是“补一张真九点图，但没删掉改名后的 .png”，同名资源在同一个目录下并存，aapt2 直接报 duplicate。第三个错误是把伪九点图当成了回编失败的原因，反复重装、反复换工具，真正的问题其实在后面的另一条 E。

正确姿势是“先接受兜底，再按需升级”。接受兜底的意思是：让 apktool 把伪九点图改名，不要阻止它，也不要手工改回去；按需升级的意思是：只有确认某张图承担拉伸职责时，才用九宫格工具重做一张，替换掉改名后的普通 PNG。重做时注意四点：四周各留一像素黑边；左侧与上侧标记拉伸区；右侧与下侧标记内容区；文件名保持 .9.png。改完先回编，再安装，再在不同分辨率下看边缘有没有糊、内容有没有被拉偏。

验证伪九点图是否处理正确，有三个检查点。回编层：没有 duplicate，没有 not found。资源层：回编后的资源表里，这个资源名只对应一个文件，路径是 .png 或 .9.png 之一。运行层：在横屏、竖屏、小屏、大屏下分别看那个背景，拉伸区域应该只拉伸你标记的那一段，圆角和边框不应该变形。如果三者都过，这条警告就可以从待办里划掉。

还要提醒一句：日志里出现几十条 9patch 警告，并不代表工程有几十个问题。它们通常是同一批资源、同一种产生方式，处理逻辑完全一样。把文件名列出来、按引用分类、批量确认，比逐条“修”要快得多。真正需要你动手的，往往只有其中一两张确实承担拉伸职责的图。

六、回编成功却装不上：签名冲突、覆盖安装与多渠道包

回编成功不等于交付成功。很多人的“反编译失败”，其实 apktool 早就走完了全程，日志最后一行还是 Built apk，失败发生在安装：adb 一句 INSTALL_FAILED_UPDATE_INCOMPATIBLE，或者更绕的 INSTALL_PARSE_FAILED_NO_CERTIFICATES。这两类错误看起来都像“包坏了”，实际一个在讲证书，一个在讲字节。

先分清三种冲突。第一种是身份冲突：设备上已经装了同包名的应用，但它不是用你手上的密钥签的，系统拒绝覆盖，报 UPDATE_INCOMPATIBLE。第二种是版本冲突：包名和签名都对，但新包的 versionCode 比已安装的低，系统拒绝降级，报 VERSION_DOWNGRADE。第三种是完整性冲突：签名之后又改过 APK 的字节，v2/v3 校验对不上，系统认为“这个包没有有效签名”，报 NO_CERTIFICATES 或 verify 失败。

判断顺序建议固定成四步：先看 adb 的完整错误码，不要只看“安装失败”；再用 apksigner 的 verify 看包本身签没签上、用的是哪套方案；然后用设备侧的包信息看已安装版本的签名摘要；最后才回头检查 keystore 与构建顺序。这个顺序能避免“证书换了三次，结果是版本号低了”这类无效劳动。

签名的方案差异必须讲清楚。v1 是 JAR 签名，逐文件计算摘要，兼容最老的 Android；v2 把整个 APK 当作一个整体签名，覆盖除签名块以外的几乎所有字节，速度快、防篡改强；v3 在 v2 的基础上增加密钥轮换与更细的校验信息。三者可以同时存在，安装时系统按版本选择。关键点是：v2 与 v3 覆盖范围极大，签名之后哪怕只改一个字节，校验都会失败。

所以顺序只能是：改内容、对齐、签名、验证。zipalign 必须在签名之前，因为它会移动文件在包内的偏移；如果先签名再对齐，v2/v3 立刻失效。签名之后只允许做“不改变字节”的操作，比如复制、改名、计算哈希。很多人习惯“签完再看一眼，改个渠道号吧”，这一改，前面的签名全白做。

多渠道打包的本质，是“同一份代码与资源，只让渠道标识不同”。常见做法有三种：把渠道号写进清单的 meta-data，让应用启动时读取；把渠道号写进 assets 下的一个小文件；把渠道号写进 ZIP 的注释字段。前两种是包内内容，天然受签名保护；第三种曾经常用于“签名后追加”，因为它不动包内文件，但在 v2/v3 时代，追加注释同样会改变文件字节，校验必然失败。

这就解释了一个很典型的现场：老的多渠道脚本在 Android 11 以上突然装不上，报“没有有效签名”。脚本的逻辑是“先签一个基包，再往每个渠道包的尾部写渠道号”，在只校验 v1 的年代没问题，因为 v1 只看每个文件的摘要，不看尾部注释；到了 v2/v3，整个文件都在签名覆盖范围内，尾部一改就废。解决办法不是换设备，而是换顺序：先写渠道，再对齐，再签名。

用经典版做多渠道，推荐把手动路线固定成一张清单：一份反编译工程；一份渠道列表；一套 keystore 与别名；每个渠道只改一处渠道标识；每次构建都走“回编、对齐、签名、verify”四步；产物按渠道命名并记录哈希。这样做的目的是可复现：同一个工程、同一份渠道表、同一套密钥，任何时候重跑都得到行为一致的包。渠道多了以后，清单比记忆可靠。

渠道标识写在哪里，要看应用怎么读。清单 meta-data 适合早期就初始化的场景，读取方便，但要求清单结构稳定；assets 文件适合不想动清单的场景，读写都简单，也不容易和别的改动冲突；ZIP 注释适合只做分发统计、应用不读的场景，但它与 v2/v3 冲突，不建议在新项目里使用。无论选哪种，都要保证“渠道信息在签名之前就位”，并且“应用读取逻辑与写入位置一致”。

还有一个常被忽略的冲突：同一台设备装两个渠道。包名相同，系统只认一个，后装的会覆盖先装的；如果签名相同、版本号相同，覆盖会成功，但渠道信息变成后装那个，测试时很容易误判。要并存，就得让包名不同，例如给每个渠道加后缀；要串行测试，就每次卸载干净再装。渠道包不是“复制几份改个名字”，包名、签名、版本号三者的关系必须先想清楚。

密钥管理单独说一段。覆盖升级的前提是“同一应用、同一密钥”；密钥一换，老用户就无法平滑升级，只能卸载重装，数据也可能丢。所以 keystore 要长期保存，别名与口令要分开记录，构建机上不要每次重新生成。经典版的手动路线里，签名是你必须亲自确认的一步。好处是你能明确知道这一次用的是哪份密钥、哪个别名；坏处是也没有人替你兜底，配置文件丢了就是丢了。

验证要落到三个层面。包层面：对每个渠道包执行 verify，确认 v1/v2/v3 的结果符合预期，确认证书摘要与基包一致。内容层面：解出渠道标识，确认与渠道表一致；对比两个渠道包的文件清单，确认差异只在预期的那一处与签名块。设备层面：安装后打开应用的“关于”或调试页，确认读到的渠道号正确；覆盖安装一次，确认签名与版本号都没问题。

如果 verify 通过但安装仍失败，优先怀疑设备侧：旧包没卸干净、工作资料限制、系统应用的签名校验、厂商的安装策略。这时候继续改包没有意义，换一台干净的测试设备，往往一分钟就能得出结论。排错最怕在错误的方向上反复“优化”，而签名问题的方向，应该由错误码决定，不由猜测决定。

七、导出 Android Studio 工程：资源映射与交付验收

经典版支持把反编译后的工程导出为 Android Studio 可继续维护的项目。这一步的价值不在“换个编辑器”，而在“把一次性的改包，变成可持续的工程”：资源可以进版本库，清单可以 review，构建可以进流水线，签名可以交给 Gradle 管理。但导出不是复制粘贴，资源目录、清单、库文件、代码层都有各自的映射规则，搞错了就会出现“工程能打开、编译不过”或者“编译过了、装上去不对”。

这张表里最容易被误解的是 smali。smali 是 dex 的汇编表示，不是 Java 源码，也不是 Kotlin；Android Studio 不会把它当源码编译。导出工程后，资源与清单可以正常参与构建，代码层则需要另想办法：要么用反编译工具把 smali 还原成可读的 Java 再纳入工程，要么把原来的 dex 作为预编译产物保留，只在资源层做修改。两条路各有代价，前者可维护性更好但还原质量不稳定，后者改动快但代码不可读。

第二个容易误解的是 public.xml。在 apktool 工程里，它是稳定 ID 的关键；到了 Gradle 工程里，它不参与构建，R 类由 AAPT2 按资源合并结果重新生成。所有用 R.id.xxx、R.string.xxx 写的代码会自动跟随新 ID；而任何写死数字的代码、或者从旧资源表里抄来的 ID，都会断。导出前先搜一遍硬编码 ID，是很有必要的准备工作。

清单层还有几个现代 Android 的硬性要求。Android 12 起，带 intent-filter 的组件必须显式声明 android:exported，否则安装直接失败；targetSdk 提升后，通知权限、后台启动、存储访问、剪贴板行为都有变化；旧工程里常见的宽松权限声明，可能在新版本上被忽略或拒绝。导出不是“原样搬过去”，而是“借这个机会把清单和 targetSdk 校准一遍”。

资源层也有覆盖顺序的坑。values、values-v21、values-v31 会按版本择一，values-night 会按深色模式择一；同一个字符串在多个目录里定义，最终用哪个取决于配置匹配，不取决于你改的顺序。导出后如果发现“文案又变回英文”，先查是不是有个 values-en 或 values-vXX 覆盖了你改的那份。图片同理：drawable 与 mipmap 是两种类型，密度目录是一组配置，改哪一份、设备用哪一份，要分开看。

签名在导出后要重新对齐。Android Studio 默认用调试密钥签 debug 包，用你配置的 release 密钥签 release 包；如果经典版手动签名用的是另一套密钥，两个包就不能互相覆盖。团队交付时，建议把 keystore 纳入受控管理，构建脚本里显式指定签名配置，产物统一走 verify。不要出现“这台机器能覆盖安装、那台机器不能”的情况，那不是 Android 的问题，是密钥不统一。

验收清单可以写得很具体：Gradle 同步无错；assembleRelease 通过；Lint 没有资源缺失与清单错误；安装覆盖旧版成功；启动无崩溃；逐屏对照修改点；切换语言、深色模式、横竖屏；检查图标与名称；检查签名摘要；检查渠道信息（如果有）。九项里任何一项不过，都不要急着宣布完成，因为“能编译”离“能交付”还有一段距离。

什么时候该导出，什么时候不该？需要长期维护、多人协作、接 CI、接崩溃监控的项目，导出是值得的；只改图标、改文案、做一次内部交付的包，留在经典版的手动路线里更快，也更容易复现。两条路线不是对立的：经典版负责“快速、可控地改”，Android Studio 负责“长期、规范地养”。把一次改包变成一项工程，才是导出的真正意义。

也正因为有这两条路线，「安卓修改大师智改工坊」把选择权留给了使用者：AI 版把门槛降下来，用一句话描述需求就能推进改包；经典版把控制权留下来，让你能盯着日志、资源和签名一步步走。两者共享同一个目标——让改动可解释、可验证、可交付，而不是把结果交给运气。

八、三个自家应用的排错实录与一张判断顺序表

前面讲的都是方法，这一节落到三个真实场景。三款应用都来自自有项目或已获授权的内部项目，改动范围限于自己的资源、文案、渠道与签名，不涉及他人的商业应用。每个实例都按“以前怎么做、现在怎么做、改完怎么验证”来写，你可以把它当成模板，套到自己手上的工程里。

实例一：自家教学 App 本地化，资源 ID 对不上

这个教学 App 原本只有英文界面，我们要把它做成中文版，同时把零散的旧品牌名统一成新名称。工程不大，资源目录却很杂：values、values-en、values-v21 各有一份字符串，drawable 下还有几套不同密度的插图。第一次改完，设置页和帮助页出现了“一半中文、一半英文”的奇怪状态，重启、清数据、换设备都一样。

以前怎么做：直接打开 res/values/strings.xml，把英文值逐条改成中文，又新增了六十多条字符串；回编、签名、安装，看起来一切顺利。问题在于新增条目没有登记到 public.xml，构建时这些条目被重新分配了 entry 号；而帮助页有一处 smali 写死了旧字符串 ID，读到的还是原来那条英文。再加上 values-en 里有同名 key，系统按语言配置选中了英文那份，覆盖了我们改的值。日志里没有 E，只有几条属性警告，所以一直被当成“缓存问题”。

现在怎么做：先把 key 盘点一遍，导出所有字符串名，按“已有、需要新增、需要废弃”三类整理。本地化优先复用已有 key，只改值，不动名字；确实要新增的，统一加 l10n_ 前缀，并在 public.xml 末尾追加条目，选当前类型下未占用的 entry 号，绝不重排整个文件。对 smali 里写死的 ID，先在工程里全量搜索 0x7f，列出“文件、行号、旧 ID、对应资源名”的映射表，再逐条替换成新 ID；能改成按名字查询的，优先改。最后处理 values-en：要么同步翻译，要么删掉覆盖项，保证默认 values 是最终生效的那份。

改完怎么验证：先用 aapt2 导出修改前后的资源列表，按“类型 + 名字”比对，确认每个目标字符串的 ID 与预期一致，确认没有两个名字指向同一个条目；再安装到中文与英文两种系统语言的设备上，逐屏点检设置页、帮助页、弹窗与空状态；然后查看 logcat，确认没有 Resources$NotFoundException；最后导出 Android Studio 工程，跑一次 Gradle 构建与 Lint，确认资源引用在符号层面也成立。四步都过，才算本地化完成。

实例二：自家内部 App 的多渠道包，签名与渠道信息打架

这是给内部团队使用的工具型应用，需要按部门出几个渠道包，用来区分使用群体和反馈来源。渠道不多，五六个，但每次发版都要出全量，手工操作很容易漏。更麻烦的是，早期脚本在 Android 11 以上的设备上开始装不上，报“没有有效签名”，而同一份基包在旧设备上正常。

以前怎么做：先打一个基包并签名，再用脚本往每个渠道包的 ZIP 注释里写渠道号，最后改名分发。这个做法在只校验 v1 的年代能用，因为 v1 逐文件校验，不改包内文件就不会失败；到了 v2/v3，整个文件都在签名覆盖范围内，尾部注释一改，校验立刻失效。另一个问题是渠道号写在注释里，应用自己读不到，只能在分发系统侧统计，内部“关于”页永远显示“未知渠道”，排查反馈时经常对不上号。

现在怎么做：把渠道号写进 assets/channel.txt，应用启动时读取并在“关于”页显示。构建顺序固定成四步：回编得到未签名包；zipalign 做四字节对齐；apksigner 用同一套 keystore 签名，开启 v1、v2、v3；最后 verify 并打印证书。渠道表单独维护，一行一个渠道号，构建脚本按表循环，产物按“应用名-版本-渠道”命名。版本号统一递增，所有渠道共用同一个 versionCode，避免覆盖安装时互相打架。

改完怎么验证：每个渠道包都跑一次 verify，确认三种签名方案的结果符合预期，证书摘要与基包一致；用 aapt 检查包名、版本号、minSdk、targetSdk 是否一致；解出 assets 里的渠道文件，与渠道表逐条比对；安装两个不同渠道的包，确认“关于”页显示的渠道号正确；对同一渠道做一次覆盖安装，确认签名与版本号都能通过；最后对比两个渠道包的文件清单与哈希，确认差异只在渠道文件与签名块，别的地方一个字节都不该变。

实例三：伪九点图引发的“回编失败”，其实只是警告

这个项目是一个内部展示类应用，界面里有大量卡片、气泡和圆角背景。某次反编译日志里出现了十几条 9patch 警告，紧接着回编报错，负责的同事第一反应是“工程被改坏了”，于是把带 .9.png 的文件全删了，结果回编直接报资源找不到；又怀疑是工具问题，卸载重装了一遍，错误照旧。

以前怎么做：把日志里的警告当成失败原因，删文件、换工具、重装，一圈下来问题更多。实际上那些警告来自一批只有几十字节的伪九点图，apktool 已经自动改名并改写引用，回编本该继续；真正的失败是后面某条资源引用错误，被满屏警告淹没了。删掉文件之后，引用还在，才出现了新的 not found。

现在怎么做：先把日志里所有被改名的文件列出来，按引用位置分成三类：占位或纯色背景、必须拉伸的背景、已经没人引用的废弃文件。占位与纯色保留改名结果，不做处理；必须拉伸的，用九宫格工具重做一张真正的 .9.png，放进去之前先删掉同名普通 .png，避免 duplicate；废弃的，确认全工程无引用后再删。整个过程只改资源，不动工具，也不重装。

改完怎么验证：回编日志里不再出现 duplicate 与 not found；导出资源表，确认每个名字只对应一个文件；安装后分别用横屏、竖屏、小屏、大屏查看那些卡片与气泡，拉伸区域应该只拉伸标记段，圆角与边框不变形；再触发一次深色模式，确认背景切换正常。验证通过后，把“伪九点图警告不等于失败”写进团队排错手册，下次看到就不会再慌。

把三件事连起来看，会发现它们共享同一种思路：先确认失败发生在哪一层，再找那一层的证据，最后只改一个变量。教学 App 的问题在资源 ID，渠道包的问题在签名顺序，伪九点图的问题在“把警告当错误”。如果一开始就去重装，三个问题一个都解决不了，反而会把日志、工程和配置一起弄丢。

回到最初那句话：反编译失败别急着重装。重装解决的是工具文件问题，而绝大多数失败，答案就写在 apktool.log 的第一条 E 里、写在 public.xml 的某个条目里、写在签名与对齐的先后顺序里。把这几条链路看明白，你就不再需要靠“再来一次”碰运气。

这也是「安卓修改大师智改工坊」想提供的两种节奏：想快，用 AI 版，把需求说清楚，让工具去跑；想稳，用经典版，把日志打开、把资源对清、把签名验完。两者不是替代关系，而是同一件事的两个入口——一个降低门槛，一个保留掌控。固定口号放在这里依然合适：只需说话，就能让应用变成你想要的样子；而当你需要知道“为什么”，经典版就在那里。

排错顺序记住一句话：先归层，再读日志，再对资源，最后才动签名与打包。工具可以重装，工程可以重来，但被清掉的现场回不来。