build 目录里都是什么：三个 APK 谁能发出去、谁只能留在本机（附自检清单）

先把主角介绍清楚。安卓修改大师智改工坊是一款 Windows 桌面工具：把自家的安装包拖进去，用中文写一句需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

这篇文章要解决的是一个非常具体、几乎每个人都会遇到一次的问题：打包完了，打开项目的 build 目录，里面躺着三个 APK —— 哪一个才是能发给别人的？ 有人凭直觉挑名字最顺眼的，有人挑体积最大的，有人挑时间最新的（三个时间几乎一样）。挑错的结果通常很直接：对方下载完，安装被系统拒绝，然后回来问你"是不是包坏了"。而更麻烦的一种情况是：你发对了包，但自己心里并不确定为什么是它 —— 于是下一次、换一个项目，同样的疑虑再来一遍。

你也许会想：挑错了再发一次不就完了？大多数时候确实如此，但有两种情形代价并不小。一种是"包已经离开你的手"：对方把包装进了日常用的手机，装失败还留下了"这个包有问题"的印象，下一轮他就不愿意第一时间帮你验了 —— 这是内测里最贵的隐性成本。另一种是"错得不够明显"：三个文件体积相近、名字相似，如果某个环节恰好绕过了安装（包只是躺在群里，没人真去装），你会以为交付已经完成，几天后才发现对方手上根本没有可用的包。花三十秒认准交付物，规避的就是这两种情形。

我们打算把这件事一次说透：先给结论（哪个能发、为什么），再拆链路（五步各自产出什么、为什么顺序不能换），然后教核对（怎么用两条命令确认签名与对齐），最后给清单与实例。读完这篇，你再看 build 目录时会多一层"我知道每个文件是怎么来的"的踏实感。

一、先给结论：三个 APK，只有一个是交付物

在项目目录下的 build 里，一次成功的打包会留下三个文件，名字分别是 unsigned.apk、aligned.apk 和 signed.apk。它们不是"三个版本"，而是同一条流水线上先后经过的三个断面：

原因可以说得非常直白：Android 系统只接受"签过名"的安装包。 未签名的包在安装器那一关就会被拒 —— 它连"作者是谁"都说不清，系统没有理由收下它。而"对齐"是一个折中的产物：它已经修好了包内部的排列方式，但还没有签名，所以它同样装不上。于是答案就水落石出了：

• unsigned.apk —— 不能装、不能发。它是回编的直接产物，留在这里是为了"证明回编这一步完成了"，以及万一要对齐失败做排查时有原件可比。
• aligned.apk —— 不能装、不能发。它是签名的输入，留在这里是为了"签名这一步的输入可追溯"。
• signed.apk —— 能装、能发，这是唯一的交付物。你们内部测试、发给同事、提交到内部分发渠道，用的都应该是它。

也许你会问：既然是同一条链路，为什么不像很多工具那样"只留一个最终包"？把中间产物也留在磁盘上，是三种需求的交集。第一种是排查：出错时分得清问题出在哪一步。第二种是复现：想验证"是对齐让包更稳"或者"是签名这一步出的问题"，中间件都在手边，可以拿起来单独核对。第三种最朴素，也最重要 —— 可靠性：一条由多个外部工具串起来的流水线，最怕把中间状态藏起来；每一步都落地成文件，任何一步的结果就能被独立检查，而不是"整条链跑完了，中间发生过什么谁也不知道"。

这三件事背后其实是同一个标准：可追溯。当一个包出了问题，你需要能回答"问题出在回编、对齐、还是签名" —— 三个断面都在，这个问题就能被分段回答：如果 unsigned 本身就异常，问题在回编；如果 unsigned 正常、aligned 异常，问题在对齐；如果前两个都好、只有 signed 装不上，问题多半在签名。把中间产物全部清掉，你就只剩一个"结果不对"的黑盒，排查只能从头重来。

一句可以贴在显示器边上的判断法则：build 目录里的东西都可以重新生成，只有 signed.apk 值得你另存一份。 前两个丢了，重新打包就有；signed 丢了，你手里的可交付物就少了一个版本。

二、打包链路逐段拆解：五步各自的产出与理由

现在把链路一步一步走一遍。理解了每一步"为什么必须存在、为什么是这个顺序"，上面那条结论就不再需要死记 —— 它是可以被推导出来的。

第 0 步：打包标记 —— 在回编之前，先往工程里写一点东西

这一步不出现在那三个文件名里，但它决定了"这个包是谁打的"。每次出包之前，程序会在反编译工程里找到 res/values/styles.xml，写入一个名字固定的样式 —— 名字就叫 info。它的内容是一串编码后的标记，里面是打这个包的时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名。

为什么放在回编之前？因为只有先写进工程，它才会被 apktool 一起编进包里 —— 后面对齐、签名都只是搬运字节，不再有"往包里加内容"的机会了。这个样式的写入逻辑处理了三种情况：文件不存在就先造一个空壳；文件里没有这个样式，就插在 </resources> 之前；已经有这个样式，就把整块内容替换掉（所以重新打一次包，标记里的时间也是新的）。

在实际工作中，这个标记有三种常见用法：核对版本（连续几轮内测时，靠它确认对方手上装的是第几轮）、归属确认（同一个包经过几个人的手时，确认它是谁在哪台机器上打出来的）、归档说明（给一份历史包做备注时，标记里的打包时间与账号就是最可靠的来源）。你不需要记住它的格式 —— 需要用它的地方会自己去解它。

还有一个设计态度值得单独点出来：这一步失败了不会拦着打包。 写不进去（文件被占用、格式没看懂、路径不对）时，程序只在日志里记一行，然后继续跑完全部流程。理由很实在：打出一个"少了标记"的包，远比"包根本打不出来"要好；标记是追溯用的元信息，不该成为交付路径上的单点故障。这也解释了为什么你偶尔会在打包日志里看到"打包标记：跳过"之类的字样，而包依然正常产出。

第 1 步：回编 —— 从工程到 unsigned.apk

命令是 apktool b -f -o build\unsigned.apk apktool：把反编译出来的工程（清单、smali、资源）重新装配成一个 APK，输出到 build 目录，文件名固定叫 unsigned —— 名字本身就是一句自我说明：它还没有签名。 -f 表示目标文件已存在就覆盖，所以重复打包不会因为"文件已存在"失败。

这一步是整条链路里最重的一步，也是唯一一个超时给到 10 分钟的步骤（对齐、签名、校验这三步都只给 3 分钟，因为它们只是在搬字节）。"正常慢"和"真的卡住"要分得清：大包本来就要多花时间，日志里会持续有输出；如果输出停住不动直到超时被中断，那多半是真的出了问题（资源有问题、工具被拦、磁盘异常），此时日志的尾部就是第一手证据 —— 记住这个区分方式，比记住那个分钟数有用得多。判断成功的标准有两条，缺一不可：退出码为 0，而且产物文件真的出现了。只看退出码是不够的 —— 命令"跑完了"和"产物在了"是两件事，这一点在整条链路里反复出现，也是为什么最后一步非要"校验"不可。

第 2 步：对齐 —— 从 unsigned 到 aligned.apk

命令是 zipalign -f -p 4 build\unsigned.apk build\aligned.apk。它在做的事是调整包内部数据的排列方式：让包里的各个条目从规定的边界开始。为什么要这样做？因为 APK 本质是一个 Zip 压缩包，运行时要频繁从里面直接读取数据（尤其是不压缩的资源与库文件）；如果这些数据的起始位置正好落在边界上，读取就能更直接，反之就可能带来多余的搬运。

命令里两个参数值得认识一下：-p 是"额外把未压缩的库文件按内存页对齐"（这类文件运行时会被直接映射进内存，页对齐能省掉一次拷贝）；4 是常规的对齐基准（4 字节）。-f 同样是"覆盖已有输出"。产物 aligned.apk 依然没有签名，所以它和 unsigned 一样装不上。

第 3 步：签名 —— 从 aligned 到 signed.apk

命令是 apksigner sign --key testkey.pk8 --cert testkey.x509.pem --out build\signed.apk build\aligned.apk。这一步用工作目录根下的两个密钥文件给包签名：一个是私钥（.pk8，DER 编码的私钥），一个是证书（.x509.pem，X.509 格式的证书）。签名的输出是独立文件（signed.apk），而不是覆盖 aligned.apk —— 这个"每步一个产物"的习惯，正是前面说的可追溯性的来源。

这一步出来之后，包终于"能装"了。同时它也是整条链路里最容易被换掉的一环：两个密钥文件就放在工作目录根下，团队想让所有内测包统一签成同一把密钥，把它们替换掉即可 —— 之后所有新出的包都带着新密钥。要提醒的是：换了密钥，之前用旧密钥签的包就不再能覆盖安装（系统认为作者变了），换密钥这件事要在一个"大家都能接受重新安装"的时间点做。

第 4 步：校验 —— 为什么这一步不是多余的

命令是 apksigner verify --print-certs build\signed.apk。很多人的第一反应是"前三步都跑通了，还验什么"。可前面已经出现过两次同样的句式：命令跑成功，和结果真的成立，是两件事。 前三步的判断依据是退出码与文件存在性，而"这个包到底签上没有、签它的是谁"，只有校验能给出答案。

最典型的例子是密钥文件的格式问题：如果 .pk8 不是 DER 编码的私钥、或者 .x509.pem 不是标准的 X.509 证书，签名这一步可能以某种方式"跑完了"，而只有校验这一步会明确报出来。校验失败时程序的做法也很干脆：告诉你"签名校验没通过，这个包不要用"，并把日志路径一起给你 —— 这一条提醒比任何"成功"提示都重要，因为它拦下的是一个看起来完成了、实际不能用来交付的包。

校验成功时，程序会从输出里挑出签名者信息（证书摘要或签名者名称那一行）展示给你 —— 这样你交付前能亲眼确认一句：包确实签上了，签它的是这把证书。

追问一：既然 aligned.apk 已经对齐了，能不能自己给它签个名？

可以，而且在技术上完全成立：aligned.apk 本来就是签名这一步的输入，你对它执行一次参数相同的签名，就能得到一个可安装的包（前提是用的还是同一对密钥文件）。但这件事没有实际必要 —— 程序紧接着就会做这一步，而且签名之后还有一道校验替你确认结果；手工补签等于绕开了校验，把一个"你自己以为签好了"的包交到手上。真正值得记住的是它的反面：不要跳过对齐直接给 unsigned.apk 签名。那样得到的包"能装"，但少了对齐带来的那部分优化，属于能用但不够好的状态；更麻烦的是，跳过一步之后，你在 build 目录里也就失去了"对齐到底做没做"的证据。顺序存在的意义，正是让每一步的结果都留下凭证。

三、三个产物怎么区分：对照表与两条核对命令

把这些信息压成一张表，日常对照着看就够了：

产物	从哪来	能安装吗	能发给别人吗
unsigned.apk	回编的直接输出	不能（未签名，系统不收）	不能
aligned.apk	对齐的输出，签名的输入	不能（对齐过了，但还没签名）	不能
signed.apk	签名的输出，校验的对象	能	能，唯一的交付物

顺便说一句"为什么名字是这三个固定的英文词"。它们不是给最终用户看的，而是给"排查"看的：名字固定，意味着任何一份日志、任何一次口头描述里提到 unsigned 或 signed，大家都知道指的是哪一步的产物，不需要再解释"那个名字里带日期的包"。改包这件事里，命名的一致性和步骤的一致性一样重要 —— 它把"你说的到底是哪一个"这类沟通成本直接降到了零。

除了名字，还有两个不用工具就能用的"土办法"，用来快速区分：看体积 —— 三个文件是同一份内容的不同阶段，体积通常非常接近（对齐只调整排列、签名只追加一小段签名数据，都不会让包明显变大或变小）；看时间戳 —— 三个文件的时间戳几乎一致，因为它们是一次链路里连续产出的，前后差不了几秒。所以"靠大小或时间挑"通常挑不出对错，只能靠名字与这一步里的知识。这也是为什么我们建议永远优先用"保存"功能去另存交付包：另存的名字里带着应用名与版本号，比在 build 目录里现场挑选可靠得多。

如果你想亲手核对一次（而不是只相信流程），可以用命令行确认两件事 —— 这两条命令用的正是工具目录里那套工具，也就是说，程序的打包流程本来就已经替你跑过它们：

核对签名还有一个非常实用的"进阶用法"：当覆盖安装提示签名冲突时，把新旧两个包的证书摘要各验一次、对着看。 如果两行的摘要不同，那就确认了"这两个包的作者不同"，覆盖安装被拒是必然的，正确的处理是卸载旧包再装（并接受数据会被清掉）—— 而不是反复重试安装。改包场景里这个判断会经常用到，因为内测包（调试密钥）与正式包（正式密钥）天然不同源。

追问二：签名到底往包里"加"了什么？

很多人以为签名是"往包里放一个证书文件"，所以会自然地想"那我把别的包里的证书拷过来不就行了"。这条路从根上走不通，因为签名加进去的不是可以随手复制的文件，而是一次对包内容的承诺：早期方案是对包内条目逐个校验，较新的方案则对整份文件做校验，无论哪种，被承诺的对象都是"这个包本身"。包改一个字节、或者被换了一套内容，承诺就对不上了。也正因为"签名对象是整个包"，才推导出前面那些规则：签名必须发生在所有改动之后（所以对齐在前、签名在后）；签名不同就是作者不同（所以覆盖安装会被拒）；换密钥之后旧包不能被新包覆盖（作者变了）。这些规则不是零散的规定，它们是同一句话的三次回声。

四、pack.log 怎么读、产物什么时候会"不对"

打包的完整过程会写进项目目录下的 pack.log。它的结构是"头部信息 + 逐条命令 + 每条命令的原始输出"，读法也相应地分三段：

还有一处和日志配合的记忆点：打包窗口在流程跑动期间是不给关闭的（免得你以为没在跑），跑完之后可以"保存 APK"或"打开所在文件夹"。保存时的默认文件名会带上应用名与版本号，并标明是签名后的包 —— 这个命名习惯建议保留，它是你日后在一堆文件里认出"哪个是能发的"的最快依据。

你看到的症状	先去哪里看	通常是什么
提示"回编失败"	pack.log 里第一条命令的输出	工程里某处资源或代码有问题；失败提示里已带尾部日志
提示"签名校验没通过"	最后一步校验的输出	密钥格式不对或证书不可用；这个包不要用
包打出来了，但设备装不上	设备上已装应用与这个包的签名关系	签名冲突：先卸载或改用别的包名（见上一节核对方法）
提示"没有反编译目录"	项目目录里是否存在反编译工程	反编译那一步没成功过，先解决反编译
"打包标记：跳过"	不用管，继续看后面的步骤	标记没写进去，但打包不受影响（这是有意的设计）

什么情况下 build 里的产物会"不对"

下面这几种情况都不算"打包出错"，但会让人误以为产物有问题 —— 提前认识它们，能省下大量"是不是工具坏了"的自我怀疑。

情况一：什么都没改就打包。 点"去打包"时，工程里只有你（或 AI）之前改的内容。如果这一轮一句话都没写，打出来的包等于"上一轮的状态 + 新的打包标记"。它完全正常，只是别指望它体现什么新改动。

情况二：以为 build 里是"历史上的每一版"。 build 永远只保存最近一次打包的三个产物（同名文件被覆盖）。想留住某一版，必须在打包完成后立即另存出去 —— 这是"保存 APK"这个动作存在的真正意义，它不只是"方便"，它是版本留存的唯一手段。

情况三：把中间产物发出去了。 这是最容易发生、也最难自查的一种：三个文件同在一个目录、时间几乎一样、体积也接近。防范办法有二：一是养成"只拿保存出来的那个包"的习惯（另存名里带应用名与版本号）；二是在发出前用校验命令看一眼签名 —— 未签名/未对齐完的包在这一步会立刻露馅。

情况四：密钥被换过，旧包装不上去。 团队统一替换了签名密钥之后，之前用旧密钥签的包与现在的新包"不同作者"，覆盖安装会被拒绝。这不是产物坏了，而是规则如此；处理方式是统一卸载重装一次，之后同一把新密钥出的包之间就能正常覆盖了。

情况五：链路全绿，但设备上就是装不上。 这几乎总是签名关系问题（设备上已有同名应用、签名不同），而不是产物本身有问题 —— 先在设备上确认已装应用的情况，再用"对比两个包的证书摘要"的方法判断，处理方式只有两条路：卸载旧包再装，或者换一个包名让两者并存。

情况六：把 build 目录整个删了。 好消息是它完全可以重新生成 —— 反编译工程还在，重新打包一次，三个文件就会重新出现。但要注意"重新生成"覆盖不了所有人：如果你已经另存过某一版交付包，它不受影响；如果没另存过，那一版就真的没有了。 这也正是本文反复强调"要留的版本立刻另存"的原因 —— build 是工作区，不是仓库。

五、交付前自检清单

清单之外还有一句经验：把包发给别人时，顺手写清三句话。 第一句是"这是什么版本、大概改了什么"，对方才有"要不要装"的判断依据；第二句是"装之前要不要卸载"，如果会覆盖安装，先说清会不会动到他的数据；第三句是"出了问题带什么信息回来"——机型、系统版本、点了什么。这三句话加起来不到半分钟，却省掉了后续一大半的来回确认，尤其是第二句，它能直接避免对方糊里糊涂丢数据。

六、两个自家改包实例：从"发错包"到"看签名发"

照例说明：以下两个例子用的都是自家应用与内部工具，素材也是我们自己的。

实例一：给自家「记账助手」换图标时，把 aligned.apk 发了出去。

这个坑我们真的踩过：当时的需求是"把应用图标换成附件里的新 logo"，AI 改完、四步链路跑完，项目目录的 build 里出现了三个文件。我们按"时间最新的那个"把包发给了同事 —— 那位同事下载、点击安装，系统直接拒绝。当时的第一反应是"包坏了"，第二反应是打开了另一个文件（恰好是对的）再发一次。事后回看，问题简单得可笑：三个文件的时间戳几乎一样，"按时间挑"这个方法从一开始就不成立。

现在的做法固定成了两步：打包跑完后用"保存"把交付包另存到项目外的归档文件夹（默认名字里就带着应用名与版本号，这次是"记账助手_2.4_signed.apk"这个名字一眼可知）；发出之前，先在打包窗口里看一眼校验输出的签名者信息 —— 确认"确实签上了、签它的就是那把密钥"再发。整个核对过程不到十秒，但从此再没出现过"装不上"的往返。

实例二：内部「巡检打卡」工具连续改了三轮，靠包内标记把版本对上了。

这是给巡检同事用的内部工具，那一周需求改了三轮：第一轮换启动页背景，第二轮调整应用名，第三轮补一处弹窗文案。三轮都出了包，都发给同一位同事测试。问题来了：他手机上装的是第几轮？"你看一下应用名"—— 应用名两轮之间没变；"你看一下启动页"—— 他记不清哪张是新图。前两轮我们靠"重装一次一定是对的"混了过去，但这种方式既不体面也不可靠。

第三轮之后我们用了包里那个现成的凭据：每次出包时，程序都会往工程的资源里写一个名字固定的样式，内容是打包时间、账号、机器码、机器名、系统用户名、程序版本、应用名、包名编码后的标记。我们让同事按这个标记回报一次，再对照项目目录 pack.log 头部的打包时间 —— 立刻就确定了"他手上是第二轮、缺第三轮"。这件事之后我们给内部流程加了一条：连续多轮的内测，每轮都改一次版本号后缀（哪怕是 .1、.2 这样的小尾号），把"对版本"这件事从回忆题变成看一眼的送分题。至于交付物的挑选与核对，仍然按实例一那套：只发另存出来的签名包、看校验信息。

两件事合起来，我们对 build 目录的理解就定型了：它不是"三个差不多的文件"，而是一条链路的三个断面；你真正要交付的只有最后一个，而"确认它是最后一个"这件事，工具已经把证据（签名校验）摆在你面前了。

七、用户评价：关于"发哪个包"的那些瞬间

下面这些引述来自内部试用与技术交流群的交流整理，主题都围绕 build 目录与交付物。

八、结语：看懂了链路，build 目录就不再是黑盒

把这篇收成几句话：三个文件是同一条链路的三个断面，能装的只有签名包；对齐必须在签名之前，这是规则逼出来的唯一顺序；校验不是多余的，它是"签没签上"的唯一裁判；中间产物可以随时重新生成，唯一值得另存的是交付包。 再配上两份材料 —— pack.log 告诉你每一步发生了什么，包内那份标记告诉你这个包是谁在什么时候打的 —— 一个包的来历就完整了。

于是你打开安卓修改大师智改工坊时，流程就是那句口号描述的样子：只需说话，就能让应用变成你想要的样子 —— 需求写一句，改完自动回编、对齐、签名、校验，一条链路从工程走到可交付的包，再一键装到设备上看效果；而"哪个文件能发给别人"这个问题，现在你已经不需要再问任何人了。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。