打包失败分四种：回编、对齐、签名、校验各会怎么报

大部分人对"打包失败"的想象是一种样子：弹个红框，说"打包失败"。——实际不是。这个工具里，打包是一条四步的链，而失败可能发生在链上的任何一个位置——每一种位置失败，报出来的话、你该做的事、甚至"这件事有多严重"，都完全不同。

四步是这么走的：先回编——把改过的工程重新编成 unsigned.apk；再对齐——用 zipalign 做四字节对齐，产出 aligned.apk；然后签名——用你项目里配置的那份签名签出 signed.apk；最后校验——用 apksigner verify 验一遍，并打印证书指纹。——四个文件依次落地，而只有最后那个 signed 是能装到手机上的。

「安卓修改大师智改工坊」把这条链的每一步都写了日志——统一进 pack.log。——而失败的时候，它会把日志的尾部直接附在那句错误提示后面。——这个设计非常关键：它意味着你不需要"去某个地方找日志"，错误提示本身就带着现场。

为什么"哪一步失败"这么重要？——因为四步的性质不同：回编是"翻译"，它把工程翻译成包，失败通常意味着工程里有东西不自洽；对齐和签名是"加工"，它们不改内容只改外形，失败通常是工具或参数的问题；校验是"验收"，它失败意味着前三步里有一处做了但没做对。——三类问题，三类解法——而你只要认出是哪一类，排查范围就缩小了一大半。

只需说话，就能让应用变成你想要的样子。而这句承诺的另一半是：当它做不到的时候，得能告诉你卡在哪。想自己走一遍这四步，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」——随便导入一个自己的应用，点一次「去打包」，然后打开项目目录下的 pack.log，你会看到这四步各自留下了什么。

一、四步的时间预算：为什么"慢"和"卡住"是两件事

在讲失败之前，先说清时间。因为"等太久"和"失败"经常被混为一谈，而它们的处理方式完全不同。

回编这一步，给的时间是十分钟。——为什么给这么久？因为这一步的工作量跟工程大小直接相关：一个几百个 smali 文件的小工具应用，可能十几秒就完了；而一个资源多、类多、还带一堆 so 的应用，走三五分钟是常事。——给十分钟不是"预计要十分钟"，是"允许它慢到这个程度"。

对齐、签名、校验这三步，各自给三分钟。——听起来也很多，但这三步的性质是"处理一个已经存在的文件"，它们的耗时基本只跟包大小有关，跟工程复杂度无关。——一个几十兆的包，签名几秒就完了；三分钟是一个很宽松的上限——宽到"如果它超时了，那基本不是慢，是卡住了"。

"卡住"和"慢"的区别，在日志里看得出来。——慢，是日志还在往前走：一行一行有新输出，只是间隔长。——卡住，是日志停在某一行不动了——而那一行通常是一个具体的文件或一个具体的类。——所以遇到"等很久"，第一件事不是重新点一次，是先看日志的最后一行停在哪。

还有一个更容易被误判的情况：超时被杀掉，报出来的话看起来像"失败"。——"启动某某失败"或者"某某超时"——这种提示容易让人以为工具坏了，而实际上它是"我按规则停手了"。——区别在于：真正的失败，工具会给你退出码和输出；超时，只有一句"没等到"。——而这两种情况的下一步动作完全不同——失败要改工程，超时要先弄清"为什么这么慢"。

二、第零步：还没开始就结束的六道闸门

在真正调用任何一个工具之前，程序会先过六道检查。它们几乎不花时间，但能挡掉绝大部分"本来就不该开始"的打包请求——而每道闸门对应的那句提示，都非常直白。

第一道：工具链是不是可用。——不可用时那句提示只有五个字："工具链不可用"。——这句话通常出现在"反编译环境没装好"或者"更新到一半被打断"的情况下。——它对应的动作不是反复重试，而是去把工具链重新体检一遍。

第二道：项目的工作目录还在不在。——提示会直接带上路径："项目工作目录不可用：某某路径"。——这一句最常见的成因是：你从列表里点开了一个项目，但那个目录已经被手动删掉、或者被挪到了别的盘。——而这个程序的所有项目信息都存在项目目录里——目录没了，项目就只剩一条空记录。

第三道：反编译出来的工程在不在。——判断方式很具体：项目里的 apktool 目录下面有没有 apktool.yml 这个文件。——没有，就报"项目里没有反编译出来的 apktool 目录，没法回编"，后面跟路径。——这一句意味着：不能再打包了——因为没有可回编的源。——而一个项目什么时候会变成这样？新建项目时反编译失败、或者你手动清过目录、或者项目是"只导入没反编译"的半成品状态。

第四道：四个关键工具各自在不在。——按顺序查 java、apktool 的 jar、zipalign、apksigner——缺哪个就报哪个，而且提示都带一句"请先更新反编译环境"。——比如"没找到 java 环境，请先更新反编译环境"、"工具目录里没找到 apktool（apktool*.jar），请先更新反编译环境"。

这道闸门有个很值得说的细节：它只报第一个缺的，不会一次把四个都列出来。——为什么？因为四个缺两个的情况，处理动作是同一个：去更新环境。——一次只报一个，反而让你不会被一串错误吓到——而更新的动作会一起把它们补齐。

第五道：签名方式能不能确定下来。——这一步比看起来复杂，因为它要先问一句"apksigner 是哪个版本"。——原因很实在：v3 / v4 这些签名方案开关是 0.9 以后才有的，老版本传了会直接报"未知参数"——与其等它报错，不如先探一次版本，按支持的能力来拼参数。

签名方式一共四种：项目里配好的 jks、pem 加私钥、随机签名、以及默认的内置测试签名。——选默认签名时，程序会去工作目录根目录找那一对默认的签名文件和证书——找不到就停下来，提示你可以在项目详情页点「设置签名」，换成自己的签名文件再打包。——这句提示很重要：它没有让你"去修环境"，而是给了你一条产品内的解决路径。

第六道：打包目录建不建得出来。——提示是"建不出打包目录：某某路径"。——这一句通常指向权限问题：目录在、但写不进去；或者路径太长、或者盘满了。——而它出现的位置很靠后——在签名方式都确定之后——说明这一步是"最后确认一下要往哪儿放东西"。

这六道闸门放在一起看，有一个共同点：它们全都在"四步开始之前"。——而这意味着——如果你的打包在几秒内就失败了，那大概率不是这四步的问题，是这六道闸门里的一道没过。——判断方法很简单：看提示里有没有出现"退出码"。有退出码，说明工具真的跑起来了；没有，说明还没轮到它跑。

三、回编失败：话最多的一步，也最容易被误判

四步里，回编是唯一一步"输出量可能大到吓人"的环节。它的报错形式是这样的：一句"apktool 回编失败（退出码 N）"，后面跟一句"详细日志：某某路径"，再跟一段日志尾部。

为什么它的话这么多？因为 apktool 回编时会逐项处理资源、逐类处理 smali——中间任何一处出问题，它都会打印一行。——而它通常会"继续往下走"，把能编的都编一遍，最后才汇总失败。——所以你看到的日志是：前面几百行都很正常，突然某一段开始报错，然后结束。

这就带来一个很实际的阅读技巧：不要从日志开头读，从"第一次出现错误"的地方读。——日志尾部那一段是程序替你截的，但如果它太长，你可以打开完整日志，从后往前找第一个不是普通输出的行。——而那一行往往就是一个文件路径加一句话——那个文件就是问题的入口。

回编失败常见的样子有三类。——第一类跟资源有关：某个布局引用了找不到的图片或颜色，某个资源名不合规范，某张图放错了目录。——第二类跟 smali 有关：某个方法少声明了寄存器数、某条指令不合法、某个标签跳不到。——第三类跟这两者都无关但同样致命：文件被占用、磁盘写不进去、路径里有异常字符。

为什么要分成这三类？因为它们的"责任人"不同。——资源问题，多半是这一轮改动引进来的——上一轮还能打包，这一轮不行，那问题就在这一轮动过的地方；smali 问题，可能是这一轮改的，也可能是上次留下的隐患；而第三类，跟你的改动完全无关，它是环境问题。——分清这一点，你就知道该回头看需求、还是该看环境。

有一个具体的坑值得单独讲：九图。——Android 里有一类图片叫九图，文件名以 .9.png 结尾，它带一圈一像素的边框用来定义拉伸区域。——如果你拿一张普通 png 去覆盖一个 .9.png——哪怕尺寸、内容看着都对——回编时就会报错，因为那张图缺少九图必需的边框信息。——而肉眼完全看不出区别：两张图在资源管理器里都是 png，缩略图也一样。

这个坑我们自己在内部应用上踩过一次，可以当例子讲。——那是我们内部的一个巡检记录应用，做法是把详情页顶部那条分割线换成新的视觉样式。以前的做法是：找到那张图、改、回编、装机——四步里最花时间的是"找到那张图"，因为它在 drawable 下面有好几个密度版本。

结果那一次回编直接失败，报了退出码，日志尾部指向一张 .9.png。——原因是我们把设计给的一张普通 png 直接改了名字塞进去——看着对，实际少了九图那圈边框。——我们没有去改工程，而是回过头让设计重新导出一份真正的九图（他们的工具里有一个"导出九图"的选项），再改一次。

现在的做法：一句话说清"这条分割线要换成新样式，图在附件里，是九图导出的"，改完由主程序打包。——而那句话里"是九图导出的"这五个字，就是从那次失败里学来的——它不是给程序听的，是给你自己听的：说出口，你就会顺手确认一遍。

改完怎么验证：——装上看那条线在不在、颜色对不对；然后故意把列表拉到最长，看那条线有没有被拉变形——九图的意义就在这儿，一张普通 png 拉长了会糊，九图不会。——所以"回编成功"只说明它编过了，真正的验收是"拉伸之后还正常"。

四、对齐与签名：两个"短超时"步骤，失败原因往往在参数里

回编之后的三步，性质完全不同。它们不解释你的工程，只是对一个已经存在的文件做加工——所以失败的原因几乎不在代码里，而在参数、文件、权限这些地方。

先说对齐。——zipalign 做的事很单纯：把包里那些未压缩的文件按四字节边界对齐。——为什么要对齐？因为 Android 在运行时是直接映射这些文件的——对齐了，映射效率才高；不对齐，轻则启动慢，重则在某些机型上直接装不上、起不来。——它的报错形式是"zipalign 对齐失败（退出码 N）"，后面接日志。

对齐失败少见，但一旦出现，原因通常很"物理"：输入文件不存在、输出路径写不进去、或者输入文件本身是个坏包。——注意最后一种：如果回编那一步其实没真正成功（比如产出了一个 0 字节的 apk），对齐会在这一步才炸。——所以对齐失败时，第一件该看的事是"上游那个 unsigned.apk 到底有多大"。

再说签名，这一步的复杂度主要在"有四种方式"。——第一种，jks：项目里配好的密钥库，带别名和两套口令。——第二种，pem 加私钥文件：一个证书配一个私钥，分开的两个文件。——第三种，随机签名：每次打包临时生成一个密钥，签完就删。——第四种，默认的内置测试签名：工作目录根目录下随程序放着的那一对文件。

这里有两个设计细节，平时看不见，但出了问题才知道它们值钱。

第一个：口令走环境变量，不进命令行、也不进日志。——命令行的参数是会被记录下来的——进了日志，就等于把口令写在了磁盘上。——所以这个工具把口令放在环境变量里传给 apksigner，日志里只留一份"打码版"的参数。——这就是为什么你翻 pack.log 时看到的那行签名命令，看不出密钥口令是什么——这是故意的。

第二个：随机签名用的临时密钥，用完立刻删——成功也删，失败也删。——为什么失败也要删？因为一次失败的打包之后，工程目录里多出一个没人认识的密钥文件，是最容易让人困惑的状态：你不知道它是什么、也不知道能不能删。——而这个工具的处理是：不留。——代价是"随机签名每包指纹都不同"（下一章会讲这带来什么后果），收益是目录里永远不会积累垃圾。

签名失败的提示，同样是"退出码加日志尾部"。——而它背后常见的成因有四种：签名文件路径不对（文件被挪走了）、别名或口令不对、apksigner 版本不支持你要求的签名方案、以及随机签名时 keytool 生成密钥失败。——最后这一种会单独报"keytool 生成随机签名失败（退出码 N）"——注意它是 keytool 报错，不是 apksigner，这本身就是一条线索。

我们内部那个报表应用就在这一步卡过一次。——以前的做法：一直用内置测试签名，图省事；后来因为要发给合作方试用，决定换成我们自己的 jks。——换的时候只填了密钥库路径和一个口令，忘了别名——于是签名失败，提示带着退出码和一段日志。——当时的第一反应是"文件坏了"，其实日志里那行字写得很清楚，是关于别名的。

现在的做法：签名这件事只在项目配置里做一次，之后每轮改包都由主程序用同一份配置打包。——而"换签名"这个动作被当成一件需要单独做的事——它不是改包的副产品，它是一件会影响"能不能覆盖安装"的大事。

改完怎么验证：——看 pack.log 里那一行"签名方式"，确认它是你想要的那一种；再翻到校验那一步，看打印出来的证书指纹——如果指纹和你上次记录的一样，这次就能覆盖安装；不一样，就得先卸载。——这个核对动作只需要十秒，但它能替你省掉一次"装不上，然后卸载，然后数据没了"。

五、校验：四步里最不该跳过的一步

前三步都是"做"，第四步是"查"。它的做法是：用 apksigner 的 verify 读一遍刚签出来的包，并把证书打印出来。——而它的失败提示，是这个工具里语气最重的一句："签名校验没通过（退出码 N），这个包不要用。"

"这个包不要用"这五个字，值得单独说。——大部分工具在失败时的措辞是中性的："操作失败，请重试"。——而这句是明确的指令：不是"再试试"，是"别用"。——因为一个签名校验不过的包，最坏的情况不是装不上——是装上了、跑起来了，然后在你以为一切正常的时候出问题。

为什么"签名命令返回 0"和"这个包能用"是两件事？——因为签名那一步只是在写：把一个签名块写进包里。——而 verify 是从"读包的人"的角度重新检查一遍：签名块在不在、用的哪种方案、包的摘要对不对、证书链完不完整。——写的人和读的人关心的事不完全一样——所以写完必须读一遍。

而 verify 顺手做的另一件事，其实价值更高：打印证书。——它会输出这个包的签名证书信息，程序把第一条证书行留下来，写进日志。——于是 pack.log 里就有了这个包的"身份证"——一行指纹。

这行指纹有什么用？它回答一个非常具体的问题：这个包能不能覆盖安装到那台机器上。——Android 的规则很硬：同包名、同签名、版本号不小于已装版本，三条都满足才能覆盖安装。——而"同签名"这件事，肉眼看不见——你不能靠"都是我们打的包"来判断。

这里就显出"随机签名"的代价了。——随机签名每次打包都临时生成一个新密钥，签完删掉——于是每一个包的指纹都不一样。——而指纹不一样意味着：上一个包装在这台机器上，这一个包永远装不上去，除非先卸载。——所以随机签名适合"我只打一次、给别人装"的场景；不适合"我要在自己机器上反复改、反复装"的场景。

我们后来养成的一个小习惯，是把这行指纹记下来。——做法非常土：一张表，四列——应用名、包名、指纹的前八位、签名方式。——第一次给某个内部应用打包时记一行；之后每次打包，翻一眼 pack.log 里的指纹，和表里那八位比一下。——一样，就安心装机；不一样，就先想清楚"是不是换了签名"，而不是等装不上的时候再回头查。

这张表为什么值得建？因为它记录了一件"代码里看不出来"的事实。——一个项目做得久了，签名可能被换过——换了内置测试签名、换了别人的 jks、某次误用了随机签名。——而这些变更不会写在任何一行代码里，只体现在那个指纹上。——等三个月后你接手一个项目、装机报"应用未安装"，那张表就是最快的答案。

第三个自家应用的例子，正好落在这件事上。——内部有一个用于库房扫码的小应用，早期图省事一直用随机签名。——以前的做法：每次改完，先在手持机上卸载旧的、再装新的——而卸载会清掉本地缓存的库位数据，每次都要重新同步一遍，赶上信号不好的时候要等好几分钟。

后来改成固定签名，一句话就能说清这次的改动，改完由主程序打包，直接覆盖安装——缓存和登录状态都还在。——而验证方式也变了：以前是"装上了就算成功"，现在是"装上了、并且打开后不用重新登录、库位数据还在"——三个都满足才算这一轮真的没破坏现场。

所以第四步的意义，可以总结成一句话：它把"我以为能装"变成了"我知道能装"。——而这两者之间的差距，往往就是一次卸载清数据的代价。

六、怎么读 pack.log：四段、三看、一张对照表

pack.log 不是一坨文本，它是有结构的：四步各占一段，每段开头有一句"现在做什么"，然后是工具的原样输出。知道这个结构之后，你可以在十秒内定位到出问题的那一段。

三看，是这个顺序：——一看最后那一步是哪一步——直接决定了问题归哪一类。——二看那一步里第一处异常——不是最后一行，是最早出现的那个不像正常输出的行。——三看它提到的文件路径——路径就是入口，把那个文件打开看看，往往一眼就明白。

下面这张表，可以当成一个速查。——左列是失败发生在哪一步，中间是提示大概长什么样，右边是你该先怀疑谁。

失败位置	提示的样子	先怀疑
闸门（几秒内失败）	没有退出码，只有一句描述	环境、目录、签名配置
回编	apktool 回编失败（退出码 N）	这一轮动过的资源或 smali
对齐	zipalign 对齐失败（退出码 N）	上游那个包的体积与完整性
签名	apksigner 签名失败（退出码 N）／keytool 生成随机签名失败	签名文件、别名口令、方案支持
校验	签名校验没通过（退出码 N），这个包不要用	签名参数本身，不要拿这个包去装

这张表里最容易用错的一行，是对齐那一行。——因为对齐失败经常"替上游背锅"：真正的问题在回编，只是回编没报错、悄悄产出了一个不完整的包。——所以看到对齐失败，第一个动作不是研究 zipalign，是去 build 目录看一眼 unsigned.apk 的大小——如果它小得反常（比如几 KB），那问题就在回编。

另一个值得记住的点：失败时错误提示已经把日志尾部附上了。——这意味着很多情况下你根本不用打开日志文件——那一段尾部就够定位了。——而什么时候必须打开完整日志？两种情况：一是尾部被截断在关键行之前，二是你需要看"之前有没有警告"——有些问题在失败前几十行就已经警告过了，只是没人注意。

七、什么时候该怀疑工程，什么时候该怀疑环境

这是排查里最容易走偏的一步：把环境问题当工程问题修，或者反过来。有一个很好用的判断标准——用"上一轮"当参照。

如果上一轮同一个项目能打包成功，这一轮不行，而且这一轮改过东西——那大概率是工程问题。——因为环境没有变，变的是工程。——这时候回头看你这一轮的需求和附件：动了哪些文件、加了哪些资源、换了哪张图。

如果上一轮能打包、这一轮什么都没改、还是不行——那大概率是环境问题。——可能是工具被更新了一半、可能是工作目录被挪了、可能是磁盘满了。——这时候去检查工具链体检、看工作目录在不在、看剩余空间。

第三种情况最有意思：换了机器就不行。——同一份工程，A 机器上能打，B 机器上不行。——这几乎一定是环境差异——工具版本、java 版本、路径里的空格和中文、甚至是系统权限。——而这种情况的排查成本高，所以更值得做一件事：把"能打的那台机器"的体检结果记下来，出问题时对照。

最后说一个容易被忽略的第四种情况：打包成功，但装不上。——这不在本文的四步里——四步全过了，包是好的。——问题出在"包和机器之间"：签名和已装的不一致、版本号没升、minSdk 太高、ABI 不匹配、系统不允许安装未知来源。——而这个工具对此有单独的处理路径——它会把安装失败的原始错误交给 AI，让它只修与安装相关的问题，改完重新留标志、重新打包。——所以"装不上"和"打不出"是两件事，别在同一个方向上找原因。

八、一次完整的排查：从一句提示走到根因

前面讲的都是分类。这一章把一次真实的排查过程完整走一遍——因为我们内部那个考勤应用的那次失败，几乎把四步里的坑都用上了。

背景：那次的需求是"把打卡成功后的提示音换掉，顺便把提示语改一下"。——以前的做法：找到 res/raw 下面的音频文件、替换；再去 strings 里改那句话；回编、对齐、签名、装机。——以前最麻烦的其实不是改，是"确认改对了"——提示音要打卡一次才能听到，而打卡一天只能打一次。

第一次打包，几秒就失败了。——提示里没有退出码，只有一句"项目里没有反编译出来的 apktool 目录，没法回编"，后面跟着路径。——这就是第二章说的闸门——问题不在四步里，在四步之前。

顺着那句提示去看：路径指向的那个目录，里面只有 config.ini 和一张图标，没有 apktool 目录。——原因是这个项目当初建的时候反编译没成功（当时以为是原包的问题，就先放着），后来一直没回头处理。——于是第一步动作不是"再点一次打包"，是重新建一个项目，让反编译真的跑完。——这就是闸门提示的价值：它把"我该干什么"直接说出来了。

第二个项目建好，反编译成功，重新提交同一句需求。——这一次走到了回编，然后失败——提示是"apktool 回编失败（退出码 1）"，日志尾部指向一个布局文件。——打开日志，从后往前找第一处异常：报的是某个布局里引用了一个不存在的字符串资源。

为什么会出现这种引用？——因为我们改那句提示语的时候，把原来那条字符串资源的名字也"顺手"改了——而另一个页面还在引用旧名字。——这就是第三章说的第一类：资源问题，而且是"这一轮改动引进来的"——所以判断依据很直接：上一轮能打，这一轮不行。

修复方式也很朴素：把需求重新说一遍，明确写"只改这条字符串的内容，不要改它的名字，其它页面还在引用"。——注意这句话的结构：目标（改内容）加边界（别改名）——正是上一篇文章讲的写法。——而这一次回编通过了。

第三个坑在对齐之后。——签名失败，提示是"apksigner 签名失败（退出码 1）"。——看日志里那一行"签名方式"，发现是默认的内置测试签名——而当时我们为了给合作方试用，已经把项目签名换成了自己的 jks，但这一轮不知道在哪个环节退回默认了。——于是去项目详情页看一眼签名设置，重新指到那个 jks。

顺手说一句：这次失败其实帮了我们。——如果它"默默用了默认签名然后成功"，我们会拿到一个指纹和上次不同的包，装到测试机上装不上，然后再花半小时怀疑人生。——而签名这一步失败了，等于把这个错误提前暴露出来了。

第四次，四步走完，校验通过，pack.log 里打出了证书指纹。——改完怎么验证：装到那台测试机上，打一次卡——听提示音是不是新的、看提示语是不是新的；再看一眼"关于"页的版本号。——而那次有一个意外收获：新提示音比原来的长了两秒，结果在打卡成功的动画结束之后还在响——听起来像卡了一下。——于是又改了一轮，把音频剪短。

这次排查值得复盘的地方，是它的顺序：闸门 → 回编 → 签名 → 放行。——每一步都只回答一个问题，没有跳步、没有猜。——而如果当时我们的习惯是"失败了就重试一次"，那第一次重试会撞在闸门上、第二次会撞在回编上——看起来像是"这工具不行"，实际上是把三个不同的错误当成了同一个。

九、三件不该做的事，每件都有人做过

第一件：签名校验没过，还是拿去装了。——动机可以理解：包在那儿，文件名就叫 signed.apk，看着挺正规；而重打一次要等几分钟。——但这句话"这个包不要用"是有具体所指的：它可能装得上，然后在某个时刻出问题——而那时候你已经忘了它是校验不过的那个包。

第二件：把 build 目录整个删掉，然后重新打包。——动机也合理：清干净重来。——但 build 目录里装的是这一步的产物，删掉它不会修好工程里的问题——它只会让日志变短，让你更难看出上一次失败在哪。——更实际的做法是：先读日志，再决定删不删；而大多数时候你不需要删。

第三件：用"换个签名试试"来解决装不上的问题。——这是最危险的一件，因为它在短期内真的"有效"：换了签名，包能装上了。——而代价是你之前所有装过这个应用的机器，从此都得卸载重装——包括那些你根本没在管的机器。——签名是一件"一旦定下就该稳定"的事；它不该被当成排查手段。

这三件事背后其实是同一种心态：想让"失败"这件事赶快过去。————而失败最怕被赶快过去：它已经把线索写在了提示和日志里，你要做的只是读它。————所以面对一次失败，最划算的动作顺序是：先看那句总结、再看日志尾部、然后决定"改工程"还是"改环境"还是"什么也不改、重打一次"。————三步走完再动手，往往比"先试三遍再看提示"快得多。

十、三类"看起来像失败、其实不是"的情况

排查里最耗时间的，不是真失败，是假失败。下面三种，每一种都会让你在错误的方向上修半天。

第一种：超时被杀，报出来的话像"工具坏了"。——回编给了十分钟，其余三步各三分钟——超了，程序会停手并报一句"启动某某失败"或"某某超时"。——而这句提示里没有退出码，也没有工具的输出——因为工具还没结束就被终止了，它没来得及说什么。——所以看到"没有退出码、也没有输出"的失败，先想"是不是被时间掐掉了"，而不是"是不是程序有 bug"。

为什么回编会慢到超时？——三种可能：包特别大、机器同时在跑别的东西、或者某个环节真的卡住了（比如在等一个读不到的路径）。——而区分这三种的办法还是日志：如果日志一直在往前走，那就是慢；如果停在某一行很久，那就是卡。——慢，重试一次可能就过了；卡，重试一百次也一样。

第二种：日志里有一堆警告，但打包其实是成功的。——工具在正常工作时也会打印警告——资源里有重复的、某个属性写法不推荐、某个库的版本对不上。——这些警告不影响结果，退出码是 0，包也签出来了。——而如果你习惯了"看到红字就以为失败"，会被这些警告带着去修一些根本不存在的问题。

判断标准很简单：看退出码，别看颜色。——退出码 0 就是过了；有警告也过了。——而真正的失败一定带退出码，且提示里会明确说"某某失败"。——养成"先看那句总结、再看日志"的顺序，能省掉很多无谓的折腾。

第三种：文件被占用，而提示看起来像"权限不足"。——典型场景：你刚装完上一版，手机上还连着、adb 还在读那个包；或者你拿看图软件打开了 build 目录里的预览图没关。——这时候重新打包，写文件那一步就会失败。——而提示可能只说"建不出打包目录"或者"某某失败"——看起来像权限或磁盘问题，实际只是"有东西没松手"。

解决办法朴素到有点好笑：把预览窗口关掉、把上一轮的装机流程走完，再打一次。——而"想到这一层"的前提，是你知道四步里每一步都在写文件——写文件这件事，最怕的就是别人正拿着那个文件。

这三种假失败有一个共同点：它们都不需要你改工程。————而它们之所以难缠，是因为它们长得太像真失败：都有"失败"两个字，都可能带一段看不懂的日志。————所以那三条判断标准值得记住：有没有退出码、退出码是不是 0、日志是停住了还是在走。————三个问题问完，你基本就知道该修工程还是该松手。

十一、一份十行的自查表，贴在手边就够用

把前面所有内容压成一张表。它的用法是：打包失败时，从第一行往下走，遇到"是"就停下——因为第一行能解释的，不需要往后查。

问自己	是的话，动作
是不是几秒内就失败，提示里没有退出码？	查环境、目录、签名配置，别动工程
项目目录里有没有 apktool 目录和 apktool.yml？	没有就重建项目，让反编译跑完
上一轮能打，这一轮不行，中间改过东西吗？	怀疑这一轮动过的资源和 smali
日志里第一处异常指向的是哪个文件？	打开那个文件，看它引用了什么
换图的时候，原来那张是不是 .9.png？	要九图导出的图，普通 png 不行
对齐失败时，上游那个 apk 有多大？	体积反常就回查回编，不要修 zipalign
日志里"签名方式"这一行是不是你想要的？	不是就去项目详情页改签名设置
校验没通过？	这个包不要用，重打
四步都过了，但装不上？	去查签名指纹、版本号、minSdk、ABI
打包成功、装上也正常，但改动没生效？	查有没有残留的完成标志文件

最后一行值得单独说，因为它最反直觉：打包成功、装上也正常，但你的改动没生效。——这时候四步全都没问题——问题在"这一轮到底有没有真的改"。——而最常见的成因，是完成标志文件在开始等待之前就已经存在了（上一轮残留），于是程序一上来就认为"改完了"，直接拿旧工程打了一个包。——所以这一行的动作不是"再打一次"，是先去项目目录看有没有那个标志文件。

这张表还有一个用法：反过来用。————在点「去打包」之前扫一眼最后三行，就相当于提前做了一次验收准备：你先想好"装不上要查什么""没生效要查什么"，真出了问题就不会慌。————预判本身就是一种省钱：它把"事后想"挪到了"事前想"，而事前想只需要十秒。

十二、用过的人怎么说

五条里，有三条讲的是"分清"。————分清第几步、分清包该不该用、分清该修哪一边。————而这三件事其实是一件事：知道失败发生在哪儿，比知道失败本身有用得多。

这几条反馈还让我注意另一件事：提示的语气会决定人的第一反应。————"操作失败，请重试"让人想再点一次；"这个包不要用"让人停下来想。————而一次打包失败的正确答案，往往恰恰是"停下来想"，不是"再点一次"。————所以那些写得具体的提示，本质上是替你把动作也说了一半。

---

只需说话，就能让应用变成你想要的样子。——而当它没能做到时，安卓修改大师智改工坊也会把"卡在哪一步"写得足够清楚——因为能说清失败，才配得上那句"你说就行"。