一、先看全局：四步打包链路与检查点地图

电脑版打包不是“一个打包按钮”，而是一条四步链路。理解这条链路，你看到报错时才知道应该退回到哪一步，而不是对着成品反复重试。四步依次是：回编、对齐、签名、校验。

1. 回编：apktool 把工程目录重新编译成未签名 APK，产物通常在 build\unsigned.apk。这一步只解决“代码和资源能不能编译通过”，还不涉及签名。
2. 对齐：zipalign 把 APK 内未压缩数据的起始位置调整到 4 字节边界，并让共享库按页边界摆放。对齐发生在签名之前，顺序不能反。
3. 签名：apksigner 用你的密钥对包体签名，把 v1、v2、v3（可选 v4）签名信息写进去。签名决定这个包的身份，也决定它能不能覆盖旧版本。
4. 校验：apksigner verify 重新解析签名块，确认摘要、证书链、签名方案都成立，并打印证书信息。它是“签没签上、签对没签对”的唯一可靠证据。

apktool b -f -o build\unsigned.apk 工程目录
zipalign -f -p 4 build\unsigned.apk build\aligned.apk
apksigner sign --ks release.jks --ks-key-alias release --out build\release.apk build\aligned.apk
apksigner verify --verbose --print-certs build\release.apk

上面的命令是通用写法，电脑版实际执行时会补充路径、口令和方案参数，完整过程记录在 pack.log 里。你不需要背命令，但要知道每一步的输入和输出：输入错了，后面全错；输出不对，后面不用看。

为什么 verify 要单独占一步

因为“执行了签名命令”和“签名真的有效”是两件事。密钥不是 PKCS#8 格式、证书链缺中间证书、别名对应的私钥与证书不匹配，这类问题在签名阶段未必会以醒目的方式失败，只有在 verify 阶段才会被明确指出来。电脑版在四步链路里特意多走一步 verify，就是为了把“到底签没签上”变成一条可以复查的结论，而不是靠感觉。

verify 的结论还应该和你的密钥对上。只看“Verifies”不够，还要看打印出来的证书 SHA-256 指纹是不是你预期的那个。指纹不对，说明选错了密钥；这时候包虽然“签名有效”，但升级链路已经断了。

pack.log：这条链路的黑匣子

每个项目在电脑版的工作目录下都有独立目录，pack.log 就写在项目目录里，记录回编、对齐、签名、校验各阶段的命令、输出和结果。出问题时先看它，比反复点“去打包”有效得多。日志里出现 error、failed、Exception、DOES NOT VERIFY 之类的字样，就要停下来定位；最后一段 verify 的结论和产物路径，则是交付前的必看项。

打包成功后，电脑版会自动把成品保存一份到桌面，方便直接取用。桌面文件要检查三件事：文件名是否符合命名规范、修改时间是不是本次打包时间、大小是否与日志里的产物一致。三者有任何一项对不上，都可能是旧包或复制失败，不要直接发给测试同事。

把四步链路当成一条流水线：每一步只接受上一步的合格产物。未签名包不拿去安装，未对齐包不拿去签名，未 verify 的包不拿去交付。

二、版本号：versionCode 给系统看，versionName 给人看

版本号是最容易被忽略、也最容易造成“明明打包成功却装不上”的字段。它由两个值组成：versionCode 是整数，Android 系统只认它来判断新旧；versionName 是字符串，给用户和测试看。两个都要查，但作用完全不同。

2.1 两个字段分别管什么

versionCode 是升级判断的唯一依据。新包的 versionCode 小于设备上已安装的版本，系统会拒绝覆盖安装并报 INSTALL_FAILED_VERSION_DOWNGRADE；等于已安装版本时，用 adb install -r 可以重装，但应用商店和多数内测分发平台不会把它当成新版本。想让人顺利升级，versionCode 必须严格大于线上版本。

versionName 不参与升级判断，但它会出现在系统设置的应用信息、关于页面和崩溃日志里。versionName 写错，测试同事报告问题时说的是错版本，客服也会把问题归到错误的发布批次上。建议统一成“主版本.次版本.修订号”的格式，灰度包加 -beta 后缀，例如 2.8.0-beta.1。

还有第三个字段必须顺带确认：包名。包名是应用在系统里的身份，改包名等于换了一个新应用，旧应用的数据不会自动跟过来，桌面图标会多出一个而不是替换。改包名有时是刻意为之，比如内测版和正式版要共存；但如果是手滑改的，必须在出包前发现。

2.2 为什么查

查版本号是为了避免三类事故：第一，版本没涨，灰度用户装不上，测试以为包坏了；第二，版本名写错，线上问题无法定位到具体批次；第三，包名被改，用户升级后数据“消失”，实际上是装了两个应用。三类事故都不难查，难的是出事后才想起查。

2.3 怎么查

导入 APK 后，电脑版会用 aapt 解析并显示应用名、包名、版本号、SDK 和启动页。先在详情页把原始 APK 的包名和版本记下来，改完再对比。打包完成后，对成品再跑一次解析，确认输出与工程里的值一致。

aapt dump badging build\release.apk | findstr /i "package"
package: name='com.example.jizhang' versionCode='20800' versionName='2.8.0'

装到设备后，再用 dumpsys 复核设备上真正生效的版本。命令输出里的 versionCode 和 versionName 才是系统认的值，和你以为的值可能不一致，尤其是覆盖安装没有成功、设备上还是旧包的时候。

adb shell dumpsys package com.example.jizhang | findstr versionName versionCode

2.4 通过标准

• 成品 APK 的 versionCode 严格大于线上或设备上已安装版本的 versionCode。
• versionName 与发布计划一致，灰度包带有可识别的后缀。
• 包名与上一版完全一致，除非你明确要做一个可共存的新应用。
• 设备 dumpsys 显示的 versionCode、versionName 与成品 APK 的解析结果一致。

2.5 版本号与灰度：先想清楚回滚路径

灰度不是“先发一小部分人”，而是一套版本号计划。灰度包的 versionCode 必须高于当前线上包，否则灰度用户连装都装不上；后续正式包的 versionCode 又必须高于灰度包，才能让灰度用户平滑升级到正式版。发版前把这三个数字写下来，能省掉大量临时救火。

灰度发现问题时，正确动作是关掉服务端开关、停止继续放量，然后发一个 versionCode 更高的修复包。不能把旧包重新发给已经升级的用户，因为系统不允许降级；也不要教用户在正式环境用 -d 参数强装，那会把数据置于风险中。版本号只向上走，这是发布纪律。

2.6 失败处理

遇到 INSTALL_FAILED_VERSION_DOWNGRADE，先把设备上的 versionCode 和成品 APK 的 versionCode 并排打印出来，确认是不是数字没涨。是就改工程重新打包；只是测试机上想临时回退，可以用 adb install -r -d，但要清楚这只适合测试设备，不能写进交付流程。遇到包名被改，先决定是修复还是将错就错：修复就改回原包名重打；将错就错就要准备数据迁移方案和新应用上架，不能假装无事发生。

三、签名方式四选一：默认、JKS、PEM+PK8、随机签名

签名是应用的身份证明。Android 不关心这个身份“是谁”，但非常在意它“有没有变”。同一个包名，前后两次安装必须使用同一张证书，否则系统拒绝覆盖。电脑版提供四种签名方式，选哪一种，取决于这个包要活多久、要不要升级、给谁用。

3.1 默认签名：省事，但要知道边界

默认签名省去了准备密钥的步骤，导入 APK、改完需求就能直接出包，适合临时验证改动、看看图标换得对不对、启动页有没有生效。它的边界必须清楚：默认签名不是你的发布身份，不适合上架，也不适合跨版本长期升级。如果设备上已经装了用你自己 JKS 签名的包，再装默认签名包会直接签名冲突。

所以默认签名可以用于“今天改、今天看”的场景，不能用于“下周还要给同一批人升级”的场景。判断标准很简单：这个包未来还需要覆盖安装吗？需要，就换 JKS 或 PEM+PK8；不需要，默认签名足够。

3.2 JKS、keystore：长期升级的主方案

JKS 是最常见的长期方案。一个应用固定一个密钥库、一个别名，所有版本都用它签。你需要保管三样东西：密钥库文件、store 口令、key 口令，有些密钥库这两个口令相同；别名也要记，签名时选错别名同样会失败。建议把密钥库放在加密盘或密码管理器里，至少保留两份离线备份，不要提交到代码仓库，也不要通过聊天工具随意外发。

出包前先查一次证书指纹，出包后再查一次，两次一致才算通过。keytool 能看到密钥库里的证书信息，apksigner verify 能看到成品实际使用的证书信息，两边对得上，升级链就是连续的。

keytool -list -v -keystore release.jks -alias release
apksigner verify --print-certs build\release.apk

keytool 输出里的 SHA-256 指纹是一串带冒号的十六进制，verify 输出里的证书 SHA-256 digest 可能不带冒号。比较时去掉冒号、统一大小写，避免因为格式差异误判。除了指纹，证书的 DN 也应该一致，DN 里通常包含组织名和证书用途，是辅助判断的好线索。

3.3 PEM+PK8：已有证书体系怎么接进来

PEM+PK8 适合已经有证书链的团队。PEM 是证书文件，可以包含中间证书；PK8 是 PKCS#8 格式的私钥。最常见的坑是私钥格式不对：文件头写着 BEGIN RSA PRIVATE KEY，这是 PKCS#1，不是 PKCS#8，需要先转换；文件头是 BEGIN PRIVATE KEY 的，通常才是 PKCS#8。证书链的顺序也要注意，叶子证书在前，中间证书在后，顺序反了 verify 会报证书链问题。

电脑版会把签名口令通过环境变量传给签名工具，不拼进命令行，也不写进日志。这一点比手工拼命令更安全，因为命令行参数可能被进程列表或历史记录看到。你仍然要保管好口令本身，不要把口令贴在需求描述、文件名或共享文档里。

3.4 随机签名：只适合一次性演示

随机签名每次打包都会生成一张新证书。它解决的是“不想管密钥”的问题，代价是升级链断裂：这次装上的包，下次随机签名包不能覆盖；要装新包只能先卸载，应用数据会一起消失。它适合一次性演示、临时样机、发完就删的场景，不适合需要持续升级的内部工具，更不适合对外发布。

如果你只是想快速看效果，随机签名没问题；如果测试同事明天还要在这个包上升级，今天就该换成 JKS。判断成本很低，返工成本很高，出包前问一句“这个包还要不要升级”，能避免大多数签名事故。

还要区分一件事：签名方案不同，不等于签名不同。v1、v2、v3 是保护包体的不同技术手段，只要证书相同，系统就认作同一个发布者；反过来，证书不同，即使三个方案都齐全，也照样覆盖失败。查冲突要查证书，不是查方案数量。

3.5 怎么查、怎么算通过

1. 确认设备上现有版本的签名。最稳妥的办法是取出已安装的 APK，再对取出的文件跑 verify，而不是凭记忆。
2. 确认本次签名用的密钥库、别名、证书链与现有版本一致。JKS 看 SHA-256 指纹，PEM 看证书内容。
3. 打包完成后对成品跑 verify --print-certs，核对 Signer #1 的证书 SHA-256 digest。
4. 如果计划启用密钥轮换，确认 v3 已开启，并保留旧密钥用于过渡；没有轮换计划就不要随意换证书。

通过标准是：成品证书 SHA-256 与基线完全一致，DN 一致，签名方案符合计划，设备覆盖安装成功。四项缺一不可。只看“安装成功”不够，因为测试设备可能刚好是干净的；只看“verify 通过”也不够，因为证书可能选错。

四、v1/v2/v3/v4 与 zipalign：顺序错了全白干

签名方案解决“包体怎么被保护”，对齐解决“包内数据怎么摆放”。两件事都做对，包才算合格；任何一件顺序颠倒，verify 都会给出否定结论。电脑版默认启用 v1+v2+v3，覆盖从老设备到新系统的主要场景。

4.1 为什么要同时保留 v1 和 v2/v3

只签 v2 的包在 Android 7.0 及以上没问题，但在 Android 5.x、6.x 上识别不了 v2，会直接安装失败。只签 v1 的包虽然兼容最广，但保护强度不如 v2/v3，部分应用商店也会提示签名方案过旧。v1+v2+v3 同时开启，是现代 Android 应用的常规组合：老设备走 v1，新设备走 v2/v3，谁也不耽误。

v4 的定位不太一样。它生成的是 APK 旁边的 .idsig 文件，主要用于 adb 增量安装，不属于 APK 本体。打包时开启 v4 不会影响普通安装；交付时只复制 APK 也能正常装机。不要把 .idsig 当成必需产物，也不要因为它没被复制就判定打包失败。

4.2 zipalign 到底在做什么

APK 本质是一个 zip。zip 里的条目有的压缩、有的不压缩，未压缩条目在文件里的起始位置不一定是 4 的倍数。zipalign 会重写 zip 结构，让未压缩数据按 4 字节边界对齐，-p 参数还会让共享库按页边界对齐。对齐后的包在读取资源时可以直接映射，减少额外的内存拷贝，部分应用商店也会把对齐作为检查项。

对齐必须在签名之前完成。zipalign 会改变文件布局，签名后再对齐，v2/v3 的摘要就对不上了；verify 会明确报失败。正确顺序是：回编得到未签名包 → 对齐 → 签名 → verify。不要为了绕过报错去关闭 v2/v3，那等于用降低安全性换一个假通过。

工程目录 → build\unsigned.apk → build\aligned.apk → build\signed.apk → verify
zipalign -c -v 4 build\signed.apk

4.3 怎么查、看到什么算通过

对齐用 zipalign 的检查模式复核，命令返回 0 且输出 Verification successful，才算对齐合格。签名方案用 apksigner verify --verbose 查看，输出里 v1、v2、v3 对应行都应为 true。两个检查要分别在成品上跑，不能拿 unsigned.apk 的检查结果代替。

如果 minSdk 低于 24，却看到 v1 为 false，即使设备能装，也要退回去开启 v1，因为老设备会失败。如果 v2 或 v3 为 false，先检查是不是签名后被改动、或者对齐放到了签名之后；确认顺序无误再查密钥和 apksigner 版本。通过标准是：对齐成功、三个方案按计划为 true、verify 总体通过、证书指纹正确。

4.4 失败处理

• 看到 ZIP entry 未对齐：回到 unsigned.apk 重新 zipalign，再重签，不要试图用压缩工具“修一下”。
• verify 报 DOES NOT VERIFY：先排查签名后是否又动过包，再排查对齐顺序，最后才怀疑密钥。
• 老设备装不上：检查 v1 是否开启、minSdk 与签名方案是否匹配。
• 对齐检查找不到命令：确认使用的是电脑版工具链里的 zipalign，而不是系统里版本不明的旧工具。

五、verify 与 pack.log：把“签没签上”变成证据

verify 是四步链路的最后一步，也是交付前最值得看的一步。它做三件事：解析 APK 里的签名块，按声明的方案验证包体摘要，检查证书链与签名者信息，最后打印结论。它不负责判断版本号对不对、页面能不能打开，但能明确回答“这个包有没有被完整签名”。

Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Signer #1 certificate DN: CN=Internal Release, O=Example Team
Signer #1 certificate SHA-256 digest: 1a2b3c4d5e6f...

第一行 Verifies 表示签名整体有效；三行 scheme 表示各方案是否被成功验证；Signer #1 的 DN 和 SHA-256 是证书身份。看到 Verifies 只说明“包和证书对得上”，还要看证书是不是你要的那张。指纹不对，包再完整也不能发。

verify 不检查对齐，也不检查应用能否启动，更不检查资源和代码是否符合预期。所以它通过之后，仍然要跑 zipalign 检查、装机预览和页面核对。把 verify 当成“签名关”的闸门，而不是“整个包”的验收。

5.1 pack.log 怎么读

pack.log 在项目目录里，按时间顺序记录回编、对齐、签名、校验四个阶段。读日志从后往前看：先看最后一段 verify 的结论，再找最后一个 error 或 Exception，然后回到对应阶段看输入。这样比从头逐行读快得多，也不容易被中间的正常输出干扰。

findstr /i "error failed exception verify" pack.log

通过标准是：四个阶段都有完成记录，verify 结论为通过，产物路径与桌面文件一致，日志里没有未处理的错误。失败处理则是：先定位阶段，再判断是环境问题、输入问题还是密钥问题；修好后完整重跑四步，不要只补跑失败的那一步，因为后续产物已经不可信。

5.2 自动存桌面：最后一米的检查

打包成功后，电脑版会自动把成品保存到桌面。这个设计省去了翻目录的时间，但也带来一个风险：桌面上可能同时存在多个同名文件，旧包被新包覆盖，或者复制失败后留下一个旧文件。发出去之前，至少核对文件名、修改时间、文件大小三项。

文件名要能看出应用、版本、渠道和日期；修改时间应该是刚刚；大小要与日志记录一致。需要更严格的核对时，计算一次 SHA-256，把值写进发布记录，接收方收到后可以复算比对。Windows 自带 certutil 就能算，不需要额外工具。

certutil -hashfile release.apk SHA256

如果桌面没有新文件，先看工作目录所在磁盘是否可写、剩余空间是否足够，再去项目目录的 build 下找原始产物。找到后可以手工复制到桌面，但文件名要按规范改好，并确认复制的是本次生成的版本，而不是上一次的残留。复制完成后重新算一次哈希，确保传输没有损坏。

六、安装三关：覆盖安装、签名冲突、降级

打包成功只代表文件生成了，离“能交付”还有三关：装得上、拉得起、版本对。三关都过，才算一次合格的出包。安装阶段的报错通常很直接，关键是要看懂错误码对应的原因，不要一遇到失败就卸载重装。

6.1 第一关：覆盖安装成功

用 adb install -r 安装，-r 表示替换已存在的应用并保留数据。输出 Success 才算通过。如果设备上原本没有这个应用，去掉 -r 也能装；但交付前的升级验证，一定要在“已装旧版”的设备上做，否则测不出签名冲突和版本降级。

adb devices -l
adb install -r "D:\release\Jizhang_2.8.0_v20800_neice_jks_20261021.apk"

安装成功的判定不只看最后一行。安装过程中如果出现“Performing Streamed Install”后长时间无响应，可能是包体过大、设备存储不足或 USB 连接不稳定；如果输出 Failure 后面跟着错误码，直接查下表。安装完成后，设备桌面上应该只有一个同包名应用，而不是多出一个图标。

6.2 第二关：启动正确的页面

装上了不等于能打开。改过启动页、主题、资源或清单文件后，最常见的故障是启动 Activity 找不到、主题资源缺失、应用一打开就闪退。先让系统解析启动组件，再显式拉起，最后看前台应用是不是它。

adb shell cmd package resolve-activity --brief com.example.jizhang
adb shell am start -W -n com.example.jizhang/.MainActivity
adb shell dumpsys activity activities | findstr mResumedActivity

am start -W 会等待启动完成并输出 Status、LaunchState、TotalTime。Status 为 ok，说明启动请求被接受；TotalTime 明显异常偏大，说明启动过程可能在等资源或网络。dumpsys 里的 mResumedActivity 应该是你的包名和 Activity，而不是桌面或其他应用。三者都符合，第二关才算过。

6.3 第三关：版本与安装状态正确

最后用 dumpsys package 确认设备上真正生效的 versionCode、versionName，以及 firstInstallTime、lastUpdateTime。升级安装后，lastUpdateTime 应该是刚刚，firstInstallTime 应该保持很久以前；如果两个时间都变了，说明应用被卸载重装过，数据可能已经丢失。

adb shell dumpsys package com.example.jizhang | findstr versionName versionCode firstInstallTime lastUpdateTime

通过标准是：版本号与成品解析值一致、启动页面正确、旧数据还在、应用没有在启动后几秒内崩溃。任何一项不对，都先回到工程排查，不要用“再装一次”掩盖问题。

6.4 安装报错对照表

这张表里最需要克制的是 UPDATE_INCOMPATIBLE。卸载重装确实能让包装上，但应用数据会一起没；对内部工具来说，本地数据库、登录态、离线缓存都可能很重要。正确顺序永远是：先确认是不是签名选错，能换回原密钥就换；确实无法找回密钥，再导出数据、卸载、重装。

6.5 安全升级演练

1. 在测试设备上保留上一版，记录已安装包的证书指纹和 versionCode。
2. 用应用自带的导出功能备份关键数据，不依赖“应该不会丢”。
3. 用同一密钥签名的新包执行 adb install -r，确认输出 Success。
4. 启动应用，检查首屏、登录态、核心数据和设置项是否正常。
5. 用 dumpsys 确认版本号与更新时间，确认不是卸载重装。
6. 保留旧包与 pack.log，写清本次签名指纹，方便回溯。

6.6 实例一：自家记账 App 的升级包

背景是自家记账 App 从 2.7.0（20700）升级到 2.8.0（20800）。这次改动包括换新 logo、应用名加“内测版”后缀、去掉自家开屏广告、替换启动页背景。应用只在自己的测试机和同事手机上流转，但数据是真实的账本，升级不能丢。

以前的做法是手工 apktool 回编，再凭记忆找签名命令，偶尔忘记对齐，偶尔用了默认签名。最严重的一次，测试机上出现签名冲突，为了赶紧看效果直接卸载重装，本地账本数据没有导出，只能从备份恢复。后来每次出包都要反复确认，效率很低。

现在的做法是：把 source.apk 拖进安卓修改大师电脑版，详情页写清改动，先确认详情页显示的包名和原始版本；改完点“去打包”，签名方式选 JKS，指定 release.jks 和 release 别名，方案保持 v1+v2+v3；工具自动完成回编、对齐、签名、verify，并尝试安装到已连接的测试机。

出包后的核对步骤是：aapt 解析成品，确认 versionCode 为 20800、versionName 为 2.8.0、包名未变；verify 打印的证书 SHA-256 与 keytool 查到的基线一致；zipalign 检查通过；adb install -r 输出 Success；am start 拉起记账首页；dumpsys 显示 mResumedActivity 是记账首页，versionName 为 2.8.0；桌面文件时间为本次打包时间；最后打开账本，确认历史记录还在。

这次还补了一条规矩：签名方式固定为 JKS，不再为了省事选随机签名；每次升级前先让应用导出账本备份；测试机保留上一版安装包和对应 pack.log。规则写进清单后，升级从“每次紧张”变成了“照着做”。

七、渠道包与文件名：内部工具多渠道的落地方法

渠道包不是“把同一个 APK 改个名字”。它通常意味着同一份应用代码，在不同环境、不同渠道下带有不同配置：接口地址、渠道标识、主题色、默认页面、功能开关。文件名只是标签，包里的配置才是事实。渠道包管理的核心，是让标签和事实始终对得上。

7.1 先决定：同包名还是不同包名

同包名多渠道，指的是所有渠道共用 applicationId，只是内置配置不同。优点是升级链统一、签名统一、用户数据连续；缺点是一台设备同时只能装一个渠道，切换渠道要先卸载。内部工具通常用这种模式，测试机和正式机分开即可。

不同包名多渠道，指的是每个渠道用不同 applicationId，例如内测版加 .beta 后缀。优点是可以共存、可以并行测试；缺点是它们是两个独立应用，数据不共享，签名可以不同但维护成本更高。这个决定要在第一次发布前做完，事后改包名等于换应用，数据迁移很麻烦。

7.2 渠道之间什么该变、什么不能变

最常见的渠道事故是“环境串包”：测试包发给了正式用户，正式包连到了测试库。避免这类事故不能只靠细心，要靠流程：每个渠道单独出包、单独验证、单独命名、单独记录；正式包出包前用文本搜索确认没有测试域名；装机后打开关于页，确认环境标识与渠道一致。

7.3 文件名规范：让包自己说明身份

推荐格式：应用名_版本名_v版本号_渠道_签名类型_日期.apk。例如 Jizhang_2.8.0_v20800_neice_jks_20261021.apk。字段顺序固定，文件名可以按字母排序，也可以一眼看出渠道和版本。渠道码用固定的小写英文，不要在文件名里写“最终版”“最终版2”“改好的”这类无法追溯的词。

• 只用英文字母、数字、下划线、短横线和点，不用空格和特殊符号，避免复制到不同系统后乱码。
• 版本号写 versionCode，不要只写 versionName，因为升级判断看的是前者。
• 渠道码与渠道记录表一致，neice 就一直是 neice，不要今天写 test、明天写 beta。
• 日期用 8 位数字，方便排序；同一天多次出包可以加序号，但不要覆盖旧包。
• 文件名长度控制在可读范围内，不要把整段需求描述塞进去。

7.4 用电脑版出一个渠道包

电脑版的项目是一包一项目。做多渠道时，可以为每个渠道保留一个项目：导入同一个原始 APK，改该渠道需要变的配置，签名统一选 JKS，打包后按规范命名。渠道少的时候，这种方式最直观，每个渠道的改动都能在项目里复查。渠道很多、需要批量产出时，可以配合经典版的多渠道打包能力，但签名、版本号和命名规范要保持同一套。

每个渠道包出完后，都要单独 verify，不要因为“同一个工程”就跳过。签名相同不代表包体相同；改过接口地址或资源后，包体摘要已经变了，必须重新校验。装到对应设备后，打开关于页或环境提示，确认渠道标识、接口环境和文件名三者一致。

7.5 渠道记录表

7.6 实例二：自家内部巡检工具的三个渠道包

自家内部巡检工具，包名 com.internal.patrol，版本 3.5.0（30500），需要三个渠道：neice 连测试接口，prod 连内网正式接口，offline 不请求接口、只存本地。三个包同包名、同签名、同 versionCode，只有接口配置、主题色和关于页文案不同。

以前是手工改常量再重打包，渠道多了以后经常串：有一次把 neice 包当成 prod 发到运维群，第二天巡检数据写进了测试库，排查了半天才发现是包拿错了。文件名只写了“巡检工具最新”，没有任何渠道信息，是事故的直接原因。

现在用电脑版为三个渠道各保留一个项目。每个项目只改该渠道的接口地址、主题色和关于页环境标识，签名统一用 JKS，方案保持 v1+v2+v3，打包后按“应用名_版本名_v版本号_渠道_签名类型_日期”命名。三个包分别 verify，证书指纹一致；分别装到测试机、内网机、离线机；打开关于页确认环境标识；用 dumpsys 确认版本号都是 30500。

验证也按渠道区分：neice 包要能连测试接口并在关于页显示“测试环境”；prod 包要连内网正式接口，飞行模式下应明确提示网络不可用，而不是静默写本地；offline 包在飞行模式下仍能完成本地巡检并保存。三个包都通过后，才把文件名、渠道、证书指纹、验证设备写进记录表。

后来还遇到一次“文件名对了、内容不对”的情况：同事把 prod 包复制了一份，改名成 neice 发出去。文件名只是标签，不能证明内容。现在的规矩是：接收方装机后必须看关于页的环境标识；发送方必须附上本次 verify 的证书指纹和 pack.log 摘要。两边都核对，才算交付完成。

八、装机预览：adb 安装、am start 与 dumpsys 复核

电脑版在打包完成后会自动走一遍装机预览：先找已连接的设备，安装成品，再按三档顺序解析启动组件，用 am start 拉起，用 dumpsys 复核前台应用。手机通过投屏窗口显示，模拟器会被提到最前。这个流程解决的是“改完到底长什么样”，但自动流程失败时，仍然要会用 adb 手工复核。

8.1 自动预览做了什么

1. 通过 adb 查找可用设备，优先使用已授权且在线的那一台。
2. 安装成品 APK，覆盖设备上的同包名旧版。
3. 解析启动组件：先读项目配置里的启动 Activity，再用系统命令解析，最后用旧方式兜底。
4. 用 am start -W 显式拉起启动页，等待启动结果。
5. 用 dumpsys 确认前台应用确实是刚装的包，再打开投屏或模拟器窗口。

这条链路的价值在于“装完立刻看”。改图标、改应用名、换启动页、去开屏广告，这些改动只有装机后才能确认效果。但自动预览成功也不等于交付合格，还要人工看首屏、点几个关键入口、确认数据没有异常。

8.2 手工复核命令

adb devices -l
adb install -r "D:\release\Patrol_3.5.0_v30500_prod_jks_20261021.apk"
adb shell cmd package resolve-activity --brief com.internal.patrol
adb shell am start -W -n com.internal.patrol/.MainActivity
adb shell dumpsys activity activities | findstr mResumedActivity
adb shell dumpsys package com.internal.patrol | findstr versionName versionCode

通过标准：adb devices 显示状态为 device；install 输出 Success；resolve-activity 返回明确的包名和 Activity；am start 输出 Status: ok；dumpsys 的前台 Activity 属于目标包；版本号与成品一致。五项都满足，装机复核才算完成。

如果应用启动后闪退，先看 logcat。清空旧日志、重新启动、抓取最新崩溃堆栈，通常能直接看到 Resources$NotFoundException、ClassNotFoundException 或主题相关的错误。改过资源名、删过图片、换过主题，最容易出这类问题。修法是回到工程改引用，重新走四步链路，而不是在设备上打补丁。

adb logcat -c
adb shell am start -W -n com.internal.patrol/.MainActivity
adb logcat -d | findstr AndroidRuntime

8.3 设备没授权怎么办

adb devices 显示 unauthorized，表示电脑看到了设备，但设备还没允许这台电脑调试。按顺序排查：解锁手机屏幕，看有没有“允许 USB 调试吗”的弹窗，勾选“始终允许”并确定；没有弹窗就去开发者选项里撤销 USB 调试授权，拔掉数据线重插；再不行就重启 adb 服务，先执行 adb kill-server，再执行 adb start-server。

• 数据线只能充电：换一根支持数据传输的线，或换一个 USB 口。
• USB 模式不对：把连接方式从“仅充电”改成“文件传输”。
• Windows 驱动缺失：设备管理器里出现未知设备时，安装厂商驱动。
• 品牌限制：部分机型需要打开“USB 安装”，或登录账号后才能安装。
• 安全软件拦截：手机管家、企业管控应用可能阻止安装，需要临时放行。
• 多个 adb 版本冲突：关闭其他占用 adb 的软件，使用电脑版工具链里的 adb。

Android 11 及以上支持无线调试。在开发者选项里打开无线调试，选择“使用配对码配对设备”，电脑端先 adb pair 配对地址，再 adb connect 连接地址。配对端口和连接端口不是同一个，以手机屏幕显示的为准；连接成功后 adb devices 会多出一台带 IP 和端口的设备。

8.4 模拟器连不上怎么办

先确认模拟器已经完全启动，并且设置里开启了 ADB 调试。很多模拟器的 adb 端口不是默认的 5555，具体端口看模拟器文档或它的调试设置。可以尝试 adb connect 127.0.0.1:端口；连接后如果设备状态是 offline，等几秒再查，或者重启模拟器。

电脑上同时装了多个 adb 版本时，容易出现“命令行能连、工具连不上”的情况。统一使用电脑版工具链里的 adb，关闭其他 IDE 或手机助手自带的 adb 服务，再执行 adb kill-server 和 adb start-server。防火墙或安全软件拦截本地端口时，也会导致连接失败，可以临时关闭后测试。

还有一种情况是“装上了但一启动就崩”。如果应用带有原生库，而模拟器是 x86_64、APK 里只有 arm64-v8a 的库，启动时可能找不到对应 ABI。用 adb shell getprop ro.product.cpu.abi 查模拟器主 ABI，再检查 APK 的 lib 目录；这种问题换真机验证最快，不要误判成签名或版本问题。

8.5 装机故障速查

九、出包前检查清单与交付收尾

前面八节讲的都是单项检查，最后把它们收成一张可以照着执行的清单。清单按“版本与身份、签名与证书、回编与对齐、verify 与日志、渠道与归档、装机与预览、合规”七组排列，每组都写成可勾选的动作。出包前过一遍，交付后再过一遍，能挡住绝大多数低级事故。

9.1 版本与身份

9.2 签名与证书

9.3 回编、对齐与签名方案

9.4 verify 与日志

9.5 渠道与归档

9.6 装机与预览

9.7 十条最短路径

1. 导入 APK，记下原始包名、versionCode、versionName。
2. 确认改动只发生在自有或已获授权的应用上。
3. 把 versionCode 提到高于线上版本，versionName 写成发布计划里的值。
4. 选对签名方式，正式升级一律用原 JKS 或原 PEM+PK8。
5. 点“去打包”，让工具完成回编、对齐、签名、verify。
6. 看 pack.log 最后一段 verify 结论，确认没有遗留错误。
7. 核对桌面成品的文件名、时间、大小与证书指纹。
8. adb install -r 覆盖安装，am start 拉起启动页。
9. dumpsys 复核前台应用和版本号，手动点一遍关键功能。
10. 把 APK、pack.log、证书指纹和渠道记录一起归档。

用户评价：来自一线打包人的 5 条反馈

“以前最怕签名出错，装不上还以为是包坏了，卸载重装把测试数据弄丢过。现在固定先看 verify 打出来的证书指纹，再点安装，返工少了很多。”

—— 老周，安卓开发工程师

“独立开发没人帮我检查，随机签名图省事，结果第二天想升级只能卸载。后来把签名方式写进清单，JKS 备份两份，心里踏实多了。”

—— 小柯，独立开发者

“我们内部工具三个渠道，以前文件名只写‘最新’，发错过一次测试包。现在文件名带渠道和版本，装完还要看关于页的环境标识，终于不再靠记忆。”

—— 阿岚，企业 IT 运维

“我最常看的是 pack.log，失败时从后往前找最后一个错误，比点十次重新打包有用。桌面文件我也会对时间和大小，避免拿到旧包。”

—— 木子，测试工程师

“带团队以后才发现，出包规范比工具更重要。版本、证书、命名、日志四件事固定下来，新人照着清单做也不会出大错。”

—— 陈工，外包团队负责人

出包前的十分钟检查，换来的是交付后的踏实。安卓修改大师智改工坊把这条链路做得足够直观：安卓修改大师电脑版负责回编、对齐、签名、校验和装机预览，你负责核对版本、证书、渠道和日志。工具把重复劳动接过去，判断标准仍然握在你自己手里。只需说话，就能让应用变成你想要的样子；而能不能放心交付，取决于你有没有把这份清单走完。

更多版本介绍与下载入口见官网 www.apkeditor.cn，或直接打开 https://www.apkeditor.cn/ai-version.aspx。下一次点“去打包”之前，先把这份检查清单放在手边。