反编译失败伤的是那一步，不是你建好的项目

"新建项目失败：apktool 返回 1，反编译失败。"——很多人第一次看到这句话，第一反应是"这个包废了"，第二反应是"那我删了重建一个吧"。——而这两个反应都不太对：第一个不准，第二个多余。

真实的情况是：反编译失败，只是"新建项目"这个流程里的最后一个动作没成功——而它前面的四个动作都已经做完了，东西都在磁盘上。——包括你的原始包、应用的图标、以及那份记录了应用名、包名、版本号、minSdk、targetSdk、启动 Activity 的配置文件。——换句话说，这个项目并不空——它只是缺一个"可回编的工程"。

这个区别为什么重要？——因为它决定了你接下来的五分钟花在哪儿。——如果你以为项目废了，你会删掉重来、重新导入、重新填名字——而重新导入的时候，很可能撞上同一个错误。——如果你知道只是"反编译这一步没成"，你会去看 apktool.log，把真正的原因找出来。

「安卓修改大师智改工坊」把反编译的输出完整写在项目目录下的 apktool.log 里——成功也写，失败也写。——而失败的提示里，除了日志路径，还会直接附上日志的尾部。——这个设计等于告诉你：不必去别处找原因，原因就在这句提示和那个文件里。

只需说话，就能让应用变成你想要的样子。而在这句话能生效之前，得先有一个能被改的工程——反编译就是那一步。想看看这一步在你的机器上是怎么走的，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，随便导入一个自己的应用，然后打开项目目录——你会看到 config.ini、图标、源包，以及（如果成功的话）apktool 目录，它们各自是什么时候落地的，一眼就清楚。

一、一个项目是分五步建出来的，反编译是最后一步

理解这件事，只要知道创建项目时那五步的顺序。

第一步：在项目目录下建一个工作目录。——名字是八位随机字符，用循环试出来一个不重名的。——为什么用随机名？因为两个同名项目撞在一起，比十个不同名项目更难查。

第二步：把原始包拷进来。——拷成 source 加原扩展名，apk 就是 source.apk，jar 就是 source.jar。——这一步的意义是"留底"：你后面所有的改动都发生在工程目录里，而这一份永远是最初的样子。——顺便说一句，文件名跟着扩展名走这件事是有讲究的——jar 存成 source.apk，你和 AI 看着都会认错。

第三步：把图标存下来。——从原包里取出来，存进项目目录，作为这个项目在列表里显示的封面。——于是你在项目列表里能一眼认出哪个是哪个，不用靠名字猜。

第四步：写 config.ini。——应用名、包名、版本名、版本号、原始文件名、创建时间、minSdk、targetSdk、启动 Activity——全写进去。——这个文件是这个项目的"身份证"：详情页上显示的那些信息，都是从它读出来的。

第五步才是反编译。——把 source.apk 解成 apktool 目录：AndroidManifest.xml、res、smali，可读可改的那一份。——而这一步失败，前面四步的成果一个都不会消失。

为什么顺序要这么排？为什么不先反编译、成功了再写配置？——因为这个顺序让"失败"这件事的成本最低。——如果先反编译，那反编译失败之后你手上就什么都没有——连"这个包叫什么、包名是什么"都记不下来，只能靠文件名。——而现在的顺序是：先把能确定的都确定下来，再去干那件可能失败的事。

还有一个细节值得注意：拷源文件这一步，程序是"拷成功了才写进配置"的。——拷不过去（比如源文件被占用、磁盘满），配置里的源文件名就留空————而不是写一个其实不存在的名字。——这条处理很朴素，但它避免了一种很难查的状态：配置说有这么个文件，磁盘上没有。

二、"成功"是怎么判定的：退出码不够，还得看一个文件

这一步的判定，比大多数人想的严。程序不是"命令跑完了就算成功"，而是要满足两个条件。

第一个条件：apktool 的退出码是 0。——不是 0 就报"apktool 返回 N，反编译失败"，同时给出日志路径和尾部。——这条很直接。

第二个条件：输出目录里必须真的有 apktool.yml 这个文件。——如果没有，报的是另一句话："apktool 跑完了但没有生成 apktool.yml，反编译可能不完整。"——注意这句话的措辞——"跑完了但没有生成"，这说明它承认了退出码是 0，但仍然判定失败。

为什么要多这一个条件？——因为"退出码 0 但没产出"是一种真实存在的情况：工具可能因为参数、权限、磁盘之类的原因提前退出，而退出码仍然是 0。——而 apktool.yml 是 apktool 每次成功解包都会写的清单文件——它就是这个工程"能回编"的凭证。——用产物当成功标志，比用退出码当成功标志可靠得多。

这件事和后面的打包是呼应的：打包那一步的第一道检查，就是看 apktool 目录里有没有 apktool.yml。——没有就报"项目里没有反编译出来的 apktool 目录，没法回编"。——所以同一个文件，在这里是"成功标志"，在那里是"入场券"——两个地方认的是同一个东西，逻辑非常一致。

还有一处设计，是给"重跑"准备的：动 apktool 之前，如果输出目录已经存在，先整个删掉。——为什么？因为反编译是"解一整个包"，如果目录里还留着上一次的残骸，新旧文件会混在一起——而混出来的工程，回编时会报一些完全看不出原因的错误。——所以宁可先删干净——反正源包还在，随时能重解。

而那一步也有它自己的失败提示："旧的 apktool 目录删不掉：某某原因"。——这句看起来是个小问题，其实指向一个很常见的情况：你上次反编译之后，拿编辑器或看图工具打开了那个目录里的某个文件，没关。——文件被占用，目录就删不掉——而这时候你看到的提示并不是"反编译失败"，而是"删不掉"。——分清这两句，能省一轮瞎猜。

时间上，这一步给了十分钟。——为什么比打包那四步里的回编一样多？因为它们的性质相似——都是"处理整个工程"，耗时跟工程规模走。——而反编译通常比回编快一些：解包是"读一个包、写成很多文件"，回编是"读很多文件、编成一个包"，后者要编译资源、要处理 smali。

顺便说清一件事：反编译的日志和打包的日志是两个文件。——反编译写 apktool.log，打包写 pack.log，都在项目目录下。——为什么分开？因为它们的读者不同：apktool.log 是你排查"为什么解不开"时看的；pack.log 是你排查"为什么打不出"时看的。——而把两种输出混在一个文件里，会让每一次排查都先翻过一堆不相干的内容。

三、六种失败理由，分成两堆看

反编译失败的提示不止一种。而它们可以先分成两堆：一堆是"压根没开始"，一堆是"开始了但没成"。——分堆的标准很简单：看提示里有没有提到 apktool 的退出码。

第一堆：压根没开始（五种）。

一是"找不到要反编译的文件"，后面跟路径。——这个通常发生在"你导入的是个快捷方式"或者"文件在你导入之后被挪走了"。——注意程序在拷源文件那一步已经把包拷进项目目录了——所以只要拷贝成功，后面解的其实是项目里那一份，源文件被挪走也不影响。——那这句话什么时候出现？在拷贝失败、且源文件又不在的时候。

二是"项目工作目录不可用"，也带路径。——这句代表项目目录被删了或被挪了。而现在项目刚建、目录刚建出来——所以它出现，多半是环境层面的事（比如那个盘突然不可写）。

三是"工具链不可用"。——四个字，没有更多信息。这句对应的动作只有一个：去把反编译环境重新弄好。

四是缺 java、或者缺 apktool 的 jar。——提示分别是"没找到 java 环境，请先更新反编译环境"和"工具目录里没找到 apktool（apktool*.jar），请先更新反编译环境"。——它们和打包那一步的检查是同一套话——因为这确实是同一套工具。

五是"旧的 apktool 目录删不掉"。——这句只在"重跑"时出现——第一次建项目时没有旧目录。——而它的解法通常不是技术问题：关掉那个开着这个目录的窗口，再试一次。

第二堆：开始了但没成（三种）。

一是退出码不是 0。——这是最常见的一种，提示是"apktool 返回 N，反编译失败"，带日志路径和尾部。——而它的原因可能五花八门：包的结构不标准、资源里有解析不了的东西、某个文件损坏、甚至是包本身做了保护让人解不开。

二是退出码是 0，但没有 apktool.yml。——这一种最容易被误认为"成功了"——因为如果程序不检查这个文件，你会看到一个空空的 apktool 目录，然后在打包的时候才发现没东西可编。

三是超时。——十分钟没跑完，程序停手，报的是"启动 apktool 失败"或者一句关于时间的提示。——这种提示里没有退出码——因为工具还没结束就被终止了。——而"没有退出码"正是区分"超时"和"真失败"的关键。

提示里有什么	说明	下一步
没有退出码、没有日志尾部	还没开始，或者被时间掐掉	先修环境／先弄清为什么慢
有退出码、有日志尾部	工具真的跑了，但没解完	读日志尾部第一处异常
提到 apktool.yml 没生成	跑完了但产出不完整	重解一次；仍不行就看是不是包的问题

这张表只有三行，但它能替你省掉一大半猜。——因为三行对应三种完全不同的处置：第一种别看工程、第二种必须看工程、第三种要判断"是偶发还是必然"。——而判断"偶发还是必然"的方法很土也很准：同一步重试一次——过了就是偶发，不过就是必然。

四、失败了之后，这个项目还能做什么

这是本文最实用的一章。下面这份清单，左边是"还能做"，右边是"暂时不能做"——而它决定你该不该删掉重来。

还能做一：它仍然是一个完整的项目条目。——列表里有它、有图标、有名字，点开能看到应用名、包名、版本名、版本号、minSdk、targetSdk、启动 Activity。——这些东西不是"猜的"，是在建项目那一步从原包里读出来、写进 config.ini 的。

还能做二：重新反编译。——这是最值钱的一条——因为它意味着"失败"不是终局。——而重跑之前，程序会先把旧的 apktool 目录整个删掉，所以不会出现"新旧混着"的状态。——换句话说：失败之后你什么都不用清理，直接重试就行。

还能做三：改项目的配置。——版本号可以改、启动 Activity 可以改、签名可以换——这些都在 config.ini 里，而反编译成不成功跟它们没关系。——这件事的实际意义比听起来大：如果你导入的是一个"版本号写错了"的包，你可以先把配置改对，再去解决反编译的问题——两个问题不必串行。

还能做四：把它删掉。——删除是允许的——而这个程序在这里做了防呆：只允许删项目目录下那些直接子目录，不会顺着你去删别的地方。——所以"删了重来"这条路是通的，只是大多数时候不需要走。

不能做一：打包。——打包的第一道检查就是"apktool 目录里有没有 apktool.yml"，没有就直接拦下来。——这不是限制，这是保护：它不让你在一个不存在的工程上白等十分钟。

不能做二：让 AI 去改。——因为"改"的对象就是那个工程——工程不存在，就没有可改的东西。——而环境说明里那句"请将工作目录切换到某某下面进行修改"，指向的正是一个还不存在的目录。

不能做三：装机。——没有新包，装的就是旧包——而"装了个旧包然后以为改动生效了"，是最难自查的一种错。

把这份清单压成一句话：反编译失败的项目，是一个"有身份、有底稿、缺工程"的项目。——而"有底稿"这一条，意味着你永远可以从头再来一次——源包就在项目目录里，它不会因为你解不开就消失。

还有一个容易被忽略的用途：这个失败的项目，本身是一份证据。——它的 apktool.log 记录了这次失败的全过程——而这份日志在你换机器、换工具版本、或者拿同一个包去别处试的时候，是唯一的对照物。——所以我们内部有个习惯：一个包解不开，先不删——留着日志，等第二次尝试有结果了再一起清。————而这份证据有个很实际的用法：下次拿到同类包，先把两份日志的尾部放在一起看——如果卡在同一个地方，基本可以断定是包这一类的问题，不必再从环境查起。

五、两个自家应用的例子：失败之后怎么走出来

理论和清单讲完，看两件我们自己做过的具体事。两个都不是"修好了工具"，而是"换了做法"。

例子一：内部报修应用的"包型不对"。

以前怎么做：——这个应用的应用商店上架包是分包形式（一个主包配几个配置包），我们从下载目录里拿到的是那个主包，直接导入。——旧流程里，这一导入就报反编译失败，然后我们的习惯是"再试一次"——而重试三次都一样，于是判定"这个包不能用"，放弃。

后来发现的问题：主包里缺东西。——分包结构下，真正的内容有一部分在配置包里，只解主包当然解不完整。——而这个工具本身支持多种包型——不只是 apk，还有分包形式的那几种。——把完整的那份包（而不是从里面挑出来的主包）导进来，反编译一次就过了。

现在一句话怎么做：——先把包型弄对——这一步没有"一句话"能代替，因为它发生在导入之前。——导入成功之后，改动的需求就回到一句话的量级："把首页底部那个报修入口的文字改成『我要报修』，图标不要动。"

改完怎么验证：——装到那台值班手机上，看首页底部第一个入口的文字是不是新的、图标是不是原来的；再点进去走一遍提交，确认没把入口点坏。——顺便说一句：这个例子真正的教训不在"改"，在"导入"——包型错了，后面做什么都白搭。

例子二：内部巡检应用的"解不开的发布包"。

以前怎么做：——我们要给这个应用的某一版加一个"演示模式"入口，手上有的是从发布渠道拿回来的成品包。——导入、反编译，退出码非 0，日志尾部停在资源和入口相关的处理上。——旧习惯是"可能包坏了，再下一个"——而重新下载的包还是一样。

真正的原因是：那份成品包本身做了保护处理，不是"完整可解"的形态。——这不是工具的问题，是包的问题——而这类包的正确处理方式不是硬解，是换一份可解的包。——我们的做法是：让负责这个应用的同事从构建环境里给我们一份内部构建的包——同一份代码、同一个版本，但没有额外的保护处理。

现在一句话怎么做：——内部构建包导入、反编译一次通过；然后一句话："在设置页最下面加一个『演示模式』开关，打开后首页顶部显示一条提示条，其它功能不变。"——注意这句话里的边界——"其它功能不变"——这是这类改动必须说的，因为加开关很容易牵动别的地方。

改完怎么验证：——装上看设置页最下面有没有那个开关；打开它、退回首页，看提示条在不在；再关掉、再看提示条消失。——最后一步"关掉再看"最容易被忘——而它恰好是"这个开关真的在控制"的唯一证据。

这两个例子的共同点是：问题都不在"改"这一环，在"改之前"。——一个是包型没选对，一个是包的形态不适合被解。——而它们的解决方式都不是"更努力地重试"，是"换一份能用的输入"。——这也回答了本文的标题：反编译失败伤的是"这一步"，而你需要动的往往也不是项目，是输入。

六、解不开的包，通常长这四个样子

如果你已经排除了环境和工具，日志也读到第一处异常了，那就该怀疑输入本身。从我们自己的经验看，解不开的包通常落在这四类里。

第一类：包被做了保护处理。——有些发布包会把 dex 或资源做成"只能在设备上跑、不方便被读"的形态。——这类包的特征是：日志尾部的异常通常出现在处理代码或资源的最初阶段，报错位置很靠前，看起来"刚开始就崩了"。——遇到这一类，正确的动作不是继续试，是去要一份内部构建的包——同一份代码，没有额外的保护处理。

第二类：分包，但你只给了主包。——分包结构的包里，主包只是一部分——真正的资源和代码可能分散在几个配置包里。——这类包的特征是：解出来的东西"少得反常"——比如 res 目录里只有几个文件、smali 只有寥寥几个类。——而如果它连 apktool.yml 都没生成，就更容易被误判成"工具不行"。

第三类：资源里有不合规范的东西。——这类包在其他机器上可能解得开，在你这台解不开——因为不同版本的 apktool 对某些边缘写法的容忍度不完全一样。——特征是：报错位置在资源处理阶段，且指向具体的某个文件或某个属性。——处置方式是"换输入"或者"换版本"——而换哪一边取决于你手上有什么。

第四类：包本身不完整。——下载中断、拷贝中断、U 盘拔早了——都会得到一个"看着有大小、其实缺尾巴"的包。——特征是：报错位置很靠后、甚至像是随机位置；而同一个包在别的机器上也解不开。——这一类的验证方法最简单：重新拿一份，比一下文件大小——如果两次大小不一样，那第一次那份就是坏的。

观察到的现象	更可能是
报错位置很靠前，像刚开始就崩	包被做了保护处理
解出来内容少得反常	分包，只给了主包
报错指向具体某个资源文件	资源写法不合规范
两次下载大小不一样，或换机器也解不开	包不完整
同一份包昨天能解、今天不行	环境变了，不是包变了

这张表最后一行，是很多人漏掉的一种可能：包没变，环境变了。——比如你昨天更新了工具链，今天同一个包就解不开了。——而这种情况下，"换包"是错的方向——该做的是把环境退回去或者修好。——判断依据还是那个："昨天能、今天不能、中间没换包"——三个条件都成立，就先怀疑环境。

七、重试的正确姿势：两次是上限，第三次要换东西

"再试一次"是人类面对失败时最自然的反应，也是最容易浪费时间的一种。反编译这件事上，重试有它明确的适用范围。

值得重试的情况有三种：——一是超时——因为那可能是机器当时忙；二是文件被占用那类"删不掉旧目录"——因为关掉窗口就好了；三是"偶发"——比如第一次因为磁盘写满失败，你清了磁盘再试。

不值得重试的情况只有一种，但它覆盖了大多数：日志明确指向了包里的具体内容。——因为同一个包、同一个工具、同一台机器——第二次的结果必然和第一次一样。——这时候"重试"不是排查，是拖延。

为什么说两次是上限？——因为每一次反编译都要先删掉旧目录、再从头解一遍——它是"全量"操作，不像某些步骤可以断点续。——一个几十分钟的包，试三次就是半小时——而这半小时本可以用来找另一份包。

而"第三次要换东西"里的"东西"，有四个可换的：换包（要一份内部构建的）、换包型（分包给完整的那一份）、换环境（更新或回退工具链）、换机器（同一份包在另一台上试）。——四个里最省力的是换机器——因为它能一次性回答"是我的环境问题还是包的问题"。——而我们内部的实际做法是：先换机器试一次，再决定是找开发要包、还是修自己的环境。

八、apktool.log 里其实有三段信息，多数人只看最后一段

那个日志文件，不只是"报错文本"。它开头就写了两行非常关键的东西：这次解的是哪个包（完整路径），以及解到哪个目录去（完整路径）。

为什么这两行重要？因为它们把"我以为"和"实际"对齐了。——你以为解的是刚下载的那个包，日志说解的是三小时前那份；你以为解到了项目目录，日志说解到了另一个盘。——而这类偏差是真实存在的——尤其在你有好几个同名包、或者项目目录换过盘的时候。

中间那一段，是 apktool 的原始输出：解到哪一步了、处理了什么、有没有 WARNING。——而这一段的价值在于"节奏"：正常解包时，输出是持续推进的——你会看到它一个个目录往下走。——如果它停在了某一行，那一行就是卡住的位置——而卡住和失败的处置方式不一样：失败要修，卡住要先弄清它在等什么。

最后一段，是异常和退出信息。——而"最后一段"最容易骗人：因为异常信息往往是最后发生的，不是最先发生的。——所以我们读日志的口诀是：从最后往前找，找到第一处"不像正常输出"的行——那一行通常才是根因的入口。

举个具体的对照：日志尾部写着"某个资源文件无法处理"。——如果你只看这一句，会去研究那个资源文件。——而如果你往前翻二十行，可能会看到"某个目录不存在"——那才是真正的原因：资源处理失败只是因为它在处理一个本来就不该被处理的路径。

所以"读日志"这件事，动作上只有三步：找最后一段、往回找第一处异常、看它提到哪个文件。——三步之外不需要更多技巧——需要的是耐心：不要在第一句看起来像错误的行上就下结论。

九、一个被低估的动作：解之前先确认"这是哪个包"

这一章讲的不是技术，是习惯。而它挡掉的失败，比任何技术手段都多。

我们遇到过这样一个情况：一个内部应用要改文案，同事从共享盘里拿了包、导入、反编译失败。——查了一下午——环境换了、工具重装了、包又重新下了一次——还是失败。——最后发现：共享盘里那个文件名是对的，但内容是这个应用两年前的旧版本——而旧版本里有一处资源写法，正好是现在这个工具版本处理不了的。

这个失败的根因不是工具、不是环境、也不是"包坏了"——是"包不是那个包"。——而现在有一个很省事的确认方式：导入之后先看详情页——应用名、包名、版本名、版本号都在那儿。——版本号和你预期的一致吗？如果不一致，那你解的根本不是你想改的那一版。

为什么这个动作值钱？因为它把"技术排查"换成了"核对"。——核对只需要十秒，而技术排查可能要一下午——更糟的是，技术排查往往能"做出一些看起来有进展的事"（换环境、重装工具），让你误以为自己在接近答案。

顺带说一句版本号这件事本身。——版本有两个字段：一个整数（系统看），一个字符串（人看）。——而"人看"的那个，有时候会被构建脚本写成固定值——于是两个不同的包，版本名一模一样。——这种情况下，只比版本名是不够的——还得看版本号那个整数，或者干脆比文件大小和修改时间。

把这一章压成一句可执行的习惯：导入之后，先看详情页那五个字段，确认它就是你想改的那一份；然后再点反编译。——十秒的核对，换掉一下午的排查——这笔买卖很划算。——而它还有一个副作用：核对得多了，你会开始留意"这个名字和内容对不对得上"——而这个习惯本身，就能挡掉很多别的问题。

十、一份十项的自查表，从上往下走

前面八章的内容，最后压成一张表。它的顺序是有讲究的：从最省事的核对开始，到最后才怀疑包本身。——因为越靠前的检查越便宜。

检查	怎么看
是我想改的那一版吗	详情页看版本名与版本号
包型对不对	分包场景要给完整的那一份
工具链齐不齐	提示里缺什么就补什么
旧目录是不是被占用	关掉开着那个目录的窗口
日志有没有退出码	没有就是没开始或被掐掉
根因在哪一行	从尾部往回找第一处异常
它提到的文件是什么	打开那个文件，看它引用了什么
换机器能不能解	能解是环境问题，不能解是包问题
包是不是完整的	重新拿一份比大小
要不要换一份包	要内部构建的那一份

这张表里最容易被跳过的是第八行——"换机器能不能解"。——因为它需要另一台机器，听起来麻烦。——但它是唯一一个"一次就能分辨责任人"的检查：能解，说明包没问题、你的环境有问题；不能解，说明问题在包这一边，修环境是白费。——而在有第二台机器的团队里，这一步往往比前面七行加起来都省时间。

十一、三件不该做的事

第一件：失败一次就删项目重建。——这一步的代价比你想象的大：删掉的是源包、图标、配置——而这三样你都要重新弄一遍，还得重新走一次导入流程。——而如果失败原因是"包不适合被解"，重建之后还会以同样的方式失败——于是你陷入"建了删、删了建"的循环。

第二件：手动往项目目录里塞文件，试图"补齐"。——典型动作是：看日志说缺某个东西，于是从别处拷一个进去，再点重试。——而重试会先把整个 apktool 目录删掉——你塞进去的东西一起消失。——这类"手工修补"在反编译这一步是不成立的，因为它每次都是全量重来。

第三件：把一个"解不开的项目"当成"能改的项目"继续往下走。——这个不容易被识别，因为界面上看不太出来——项目在那儿、图标在那儿、详情能打开。——而真正的分界是：点反编译能不能过。——过不了，就不要往下点打包、也不要点立刻修改——那两步只会给你两句更绕的提示。

这三件事的共同点是"想跳过这一步"。——而反编译这一步恰好是不能跳过的：它是"把包变成工程"的唯一入口，没有工程，后面所有能力都没有落点。——所以它失败的时候，唯一正确的方向不是绕开，是弄清楚"为什么进不去"——而这件事，日志里其实都写着。

十二、反编译成功之后，还有三件事要立刻确认

"成功"这两个字很容易让人松手。而解包成功只是"门开了"，门后面是不是你要的那间屋子，还得看一眼。

第一件：apktool 目录里那三样东西在不在。——AndroidManifest.xml、res、smali——这是"能改"的最小集合。——清单管结构、res 管界面和资源、smali 管代码逻辑。——三样都在，说明这次解的是个完整工程；缺哪一样，后面都会以更难懂的方式出问题。

第二件：启动 Activity 对不对。——这个字段在详情页能看到，它决定了"装完之后能不能被拉起来并停在前台"。——而它有时候是空的——那说明读的时候没读到。——空着也不一定失败（后面还有别的办法查），但如果你要用"装完自动拉起"这条路，先确认它有值，会省掉一轮排查。

第三件：版本号该不该动。——版本有两个字段：一个是整数，系统拿它比大小；一个是字符串，人拿它认版本。——而覆盖安装的第三个条件就是"整数不小于已装的那个"。——所以如果你的改动要装到一台已经装着旧版的机器上，先确认这个整数——不然装到一半报"应用未安装"，你还得回头改。

这三件事加起来不到一分钟，但它们把"解包成功"变成了"可以开工"。——而它们的共同点是：都能在动手之前看出来，都不需要试错。

十三、试了三次还是不行，接下来怎么办

这是一个很实际的问题，而它需要一个明确的答案，不然人会一直在原地打转。我们内部的规则是这样的，四步，走完就停。

第一步：换一台机器试同一个包。——十分钟内能出结论：能解，问题在你的环境；不能解，问题在包。——这一步的价值是"分岔"——它把一条模糊的路分成两条清晰的路。

第二步：如果问题在包，去找这个应用的人要一份可处理的版本。——说清楚你要做什么、要哪一版、需不需要内部构建的形态。——这一步的关键是"说清用途"——因为对方给你包，本质上是在授权你处理它。

第三步：如果问题在环境，把工具链重新弄一遍，然后只试一次。——不要连着试——一次就够判断"修好没修好"。——而如果还是不行，就该考虑"这台机器上有别的东西在干扰"（杀毒、权限、路径里的特殊字符）。

第四步：停，并且记下来。——记三件事：包是哪一版、日志最后停在哪、试过什么。——然后把项目留着——别删。——因为下一次你或者别人遇到同一个包，这三行记录能省掉一整天。——而"停下来记录"这个动作，看起来是放弃，其实是把一次失败变成了一次资产。

顺带说一句：这四步也适用于"别人来问你"的场景。——同事拿着一个解不开的包来找你，你按这四步问一遍——换机器试过吗、包是哪来的、工具什么时候更新的、日志停在哪——往往问完他自己就有答案了。

十四、为什么这个失败被这样对待

写到这儿，可以退一步看设计。一个"反编译失败"的处理方式，其实暴露了整套产品对"失败"的态度。

第一个态度：失败不撤销已完成的事。——项目建了一半失败，前面四步的成果全部保留——不因为最后一步没成，就把整个项目回滚掉。——这是个选择：回滚看起来"干净"，但代价是你失去了那次失败的现场——包括日志、包括你导入的那份包。

第二个态度：失败的证据要留得比失败更久。——日志写在项目目录里，不写在临时目录、不随手清掉。——于是那个"解不开的项目"就变成了一个可回看的记录：下次遇到同类包，你可以翻出上次的日志对照。

第三个态度：宁可判严一点，也不放一个半成品过去。——退出码 0 还不够，必须看到 apktool.yml——而这条多出来的检查，会拦住那些"看起来成了、其实不完整"的情况。——这类严格在短期看起来是"多事"，在长期是"少坑"：因为一个不完整的工程，会在打包那一步以更难懂的方式失败。

而这三个态度合起来，其实在回答一个问题：失败应该被当成"事故"还是"状态"？——当成事故，就要清场、要回滚、要重新来过；当成状态，就可以停在原地、带上证据、换一条路继续。——这个工具选的是后者——而这也是为什么本文的标题是那个说法：失败的是一步，不是整个项目。

还有一点值得说：这三种态度其实都是"给下一次留信息"。——保留项目，是为了下次还能重试；保留日志，是为了下次能对照；判严一点，是为了让真正的问题在它该出现的地方出现，而不是被推到更远的一步。——而这三件事都不需要你多做操作——它们是程序默认就这么做的。——于是"失败"这件事的成本，从"重新来过"降到了"读一遍、想一下、换一条路"。

十五、用过的人怎么说

五条里，有两条讲的是同一个误会：以为"项目"和"包"是一回事。————而这正是本文想说清的那条界线：项目是你在工具里的一个工作单元，包是它的输入。————输入不对，换输入；项目没坏，别删它。

还有一条提到"不用赶在删之前把信息抄下来"——这个说法很形象。————好的工具应该让你有余地：失败了不必急着清场，可以先看、先想、先问人。————而这个余地的成本，其实只是"不要把失败当成需要立刻抹掉的东西"。

最后一条值得记住的经验，来自那句"我一直在解同一个解不开的包"。——失败的时候人容易盯着"我做了什么"，而很少回头问"我给它的东西对不对"。——而反编译这件事，恰好九成的答案是后者：包型、包版本、包的形态、包是否完整——这四个变量任意一个不对，工具再新、环境再干净也没用。——所以下一次遇到解不开，先把"输入"这一栏在纸上写一遍：哪个包、哪一版、什么形态、从哪儿来的。——写的时候你往往会自己发现问题——因为很多"我以为"经不起写下来。

---

只需说话，就能让应用变成你想要的样子。——而在你说出那句话之前，安卓修改大师智改工坊得先把包变成能改的工程——这一步做成了，后面才有那句话的空间。