电脑版做内测包：内测名、版本号、签名与分发

一、内测包的四件交付物：名字、版本、签名、渠道

很多团队第一次做内测，注意力全放在“界面改成什么样”上，结果包发出去才发现：测试同事手机里同时装着正式版和内测版，分不清谁是谁；新包盖不上旧包，只能卸载重装，测试数据全丢；群里翻半天找不到某个问题对应的是哪一次构建。这些都不是界面问题，而是交付问题。

一个能被称作“内测包”的 APK，至少要同时满足四个条件。第一，它有一个能被认出来的名字，桌面图标下面、系统设置的应用信息里、通知栏标题里，都显示这个名字。第二，它有一个能比较的版本，测试同事报问题时说得清“我装的是哪一版”，系统也愿意把新包盖到旧包上。第三，它有一个稳定的签名，覆盖安装时系统校验通过，应用数据原样保留。第四，它有一个可追溯的分发渠道，谁在什么时候拿到了哪一个文件，出了问题能对得上日志和构建记录。

交付物	具体指什么	没做好会怎样
内测名	桌面上显示的应用名称，例如“记账助手 内测版”	测试同事找不到包，或者把内测版当成正式版反馈问题
版本	versionCode 给系统比较，versionName 给人看	新包装不上、旧包被当成新包、问题版本说不清
签名	同一把私钥连续签多个内测版本	覆盖安装失败，只能卸载，测试数据丢失
渠道	内网盘、企业群、设备管理平台，加上文件校验值	拿到错包、旧包，问题无法复现

这四件事里，前三件都在 APK 内部，改起来并不复杂，难的是每一步都留下可核对的结果。智能修改电脑版面向 Windows 10/11 64 位，安装包约 6.86 MB，运行需要 .NET Framework 4.6.2 及以上。把 APK 拖进去，它会自动完成反编译、按需求改代码和资源、回编、对齐、签名、校验，还可以把成品直接装到手机或模拟器上预览。我们要做的，是把“内测”这件事拆成明确的需求和明确的验收动作。

官网是 www.apkeditor.cn，介绍与下载页在 https://www.apkeditor.cn/ai-version.aspx。本教程只讨论自有版权或已经获得授权的应用，流程里的每一个命令、每一段日志，都可以在你的测试设备上复现。

图 1：内测包不是一次“打包”，而是一条从需求到分发的交付链

二、第一步：划定改动范围，给自家应用留一条可回退的基线

动手之前先做一件看起来“不产出”的事：把这次内测要改什么、不改什么写清楚。内测包最容易出问题的地方，往往不是 AI 改错了，而是需求边界含糊，改着改着把包名、启动入口、权限或者核心业务逻辑一起动了，最后装不上、跑不起来，还找不到是哪一步引入的。

建议把改动分成三栏。第一栏是“本次必改”，通常包括应用显示名、图标、启动页、versionName、versionCode，以及一到两个与内测目的直接相关的界面或配置。第二栏是“本次不改”，明确写出包名、签名主体、权限清单、核心业务逻辑、数据存储结构都不动。第三栏是“待确认”，例如 targetSdk 是否升级、是否要加新的渠道配置，这类改动影响面大，不适合和内测改名混在同一批里。

包名尤其要守住。包名是 Android 识别一个应用的身份证，覆盖安装、数据目录、权限授予、桌面快捷方式都绑在它上面。内测阶段保持包名不变，才能用新包直接盖旧包，验证升级路径。只有一种情况需要新包名：你要让内测版和正式版同时装在一台手机上做对比。这时应用会变成两个独立条目，数据不共享，覆盖升级也测不了，属于另一种交付策略，后文会单独讲。

基线要留得足够完整。至少保存五样东西：当前正式版的原始 APK；正式签名用的密钥文件与别名；当前版本的包名、versionCode、versionName；测试机型和 Android 版本清单；一份能装回去的回滚包。签名文件不要只放在某位同事的电脑桌面上，至少两份离线备份，口令单独保管。很多“覆盖安装失败”最后追下去，不是工具的问题，而是这次打包换了另一把钥匙。

基线项	示例	用途
包名	com.example.ledger	确认覆盖安装的目标，避免装成另一个应用
versionCode	1040201	新包必须比它大，系统才允许升级
versionName	1.4.2-beta.1	测试同事报问题时引用
签名指纹	证书 SHA-256 摘要	核对这次与上次是不是同一把钥匙
回滚包	上一个可用的正式版或内测版	内测出严重问题时，先退回可用状态

内测的第一原则不是“改得多”，而是“退得回”。基线留全了，后面每一次尝试都只是可撤销的实验；基线没留，任何一次失败都会变成事故。

• 确认应用是自己开发、自己持有版权，或已获得权利人明确授权；
• 确认本次只做内测交付所需的改动，不涉及去除付费、绕过授权校验等功能；
• 确认包名、签名主体、权限清单不变；
• 确认已有原始 APK、密钥备份和回滚包；
• 确认测试机型覆盖低版本和高版本 Android，至少各一台。

三、第二步：导入自家 APK，先看懂包名、版本与启动入口

打开智能修改电脑版，把要改的 APK 拖进窗口即可。它支持的导入类型包括 APK、JAR、APKS、XAPK、APKM 和 CLASS，内测手机应用最常见的是单个 APK；如果拿到的是带配置包的 XAPK 或 APKS，先确认主包和各个 split 是否齐全，后续分发时不要漏文件。导入后工具会调用 aapt 读取图标、应用名、包名、版本、SDK 和启动页信息，这些信息会在项目详情里展示。

图标解析有一个容易忽略的细节：工具会取最高密度的原图，而不是随手抓第一张。aapt 输出里 65534 表示“任意密度”，是一个哨兵值，不能当成最高密度去排序。你在详情页看到的那张图标，通常就是资源里清晰度最高的那一张。如果图标是自适应图标，前景和背景是分开的两层资源，替换时要一起考虑，否则在 Android 8 及以上可能出现前景被裁切、背景露白的问题。

每个项目会在工作目录下生成一个 8 位随机名的独立目录，里面有 config.ini、history.ini、source.apk，反编译工程放在 apktool 目录，反编译日志写到 apktool.log。source.apk 是原始包的副本，改坏了可以回到这里重新开始；config.ini 记录项目的关键配置，history.ini 记录你在详情页输入过的需求原文。理解这套目录，后面排查“到底改了哪一版”会轻松很多。

导入完成后，不要急着写需求。先把下面这几个字段抄到自己的记录里，它们决定了后面所有验收动作：包名决定装到哪里、盖掉谁；versionCode 决定系统认不认这是升级；versionName 决定测试同事怎么描述问题；minSdk 决定能装到哪些测试机；targetSdk 决定新系统上的行为边界；启动 Activity 决定 am start 能不能把应用拉起来；图标密度决定桌面显示清不清楚。

字段	在哪里看	对内测的意义
包名	项目详情、aapt 解析结果	覆盖安装的目标，不能随意改
versionCode	项目详情、aapt 解析结果	升级判断依据，必须递增
versionName	项目详情、应用信息页	人读的版本，报问题时引用
minSdk / targetSdk	项目详情、aapt 解析结果	决定兼容范围和新系统行为
启动页 / Activity	项目详情、aapt 解析结果	am start 拉起应用时的组件名
图标	项目详情缩略图	桌面识别度，注意自适应图标分层

如果项目列表里已经有同名项目，建议新建一个而不是在旧项目上继续改。每个项目目录独立保存 source.apk 和历史需求，新建项目等于给这次内测留了一份干净起点。旧项目可以保留，作为“上一版是怎么改的”的对照。项目列表支持查看历史、打开详情、浏览项目文件，删除时只允许删 Project 的直接子目录，这个限制是为了避免误删工具链或其他数据。

图 2：导入后的第一件事不是改，而是把包名、版本、启动入口抄进基线表

四、第三步：把需求写成清单，别让 AI 猜你的内测标准

智能修改电脑版的详情页有一个需求输入框，右侧是 AI 工作区。输入框下面准备了 3000 条话术，分成界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加六类，每类 500 条，点一下就能填进输入框。话术的作用是帮你起个头，真正决定结果的，是你把内测标准写得多具体。内测包最怕“帮我改个内测版”这种一句话需求，AI 只能按常见做法猜，猜出来的名字、版本、图标尺寸未必符合你的预期。

建议用“四段式”写需求：这次的目标是什么，现状是什么，具体改哪几处，改完怎么验收。四段都写清楚，AI 执行时就不会自由发挥，你验收时也有对照物。下面是一份可以直接套用的内测需求示例，针对一个自家记账应用。

这份示例里，每一行都对应一个可检查的结果。“默认资源和英文资源都要改”避免了切换系统语言后名字又变回正式名；“保留原有自适应图标结构”避免了只换一张方图导致新系统上图标被裁切；“不改包名、不改权限、不改业务逻辑”是给 AI 的硬边界；“能直接覆盖旧包安装”则把签名和版本号的要求提前说清楚了。

图标和启动页最好通过附件提供原图，而不是在文字里描述“用一个蓝色的 logo”。附件系统支持一次多选文件，每个文件都要写用途，用途至少 10 个字；工具会校验文件是否存在、是不是目录、是不是 0 字节、能不能读取，任何一项不通过都不会把这条附件带进需求。校验通过后，附件会按“序号 + 路径 + 说明”拼进需求，一起发给 AI。这样做的目的是让每一次修改都能追溯到具体素材，而不是靠记忆。

• 图标：优先 512×512 或 1024×1024 的 PNG，背景透明；自适应图标的前景主体放在中间安全区域内，四周留边，避免被系统圆形或圆角遮罩切掉。
• 启动页：按主要测试机分辨率准备，常见 1080×1920 或 1440×2560；背景和文字分开说明，避免把关键文字压在可能被裁切的边缘。
• 应用名：中文建议不超过 8 个字再加“内测版”后缀，太长会被桌面截断；不要使用特殊符号和表情。
• 版本：直接写目标值，不要写“版本号加一”，否则 AI 需要先读当前值再计算，容易产生歧义。
• 范围：一次只改一组强相关的内容，名称、版本、图标、启动页可以放一批，业务界面调整放另一批，便于定位问题。

需求写好后点“立刻修改”，工具会把需求原文和日期写进 history.ini，然后把需求送进右侧 AI 工作区执行。AI 完成后会在项目目录里留下 ai_done.flag，主窗口每 2 秒轮询一次，读到这个文件就删除并刷新状态，等待上限是 1 小时。这个机制意味着你不需要盯着进度条，但也不要在 AI 执行期间反复点“立刻修改”，否则容易把同一批需求重复送进去。详情页的历史记录按最新在上排列，保留完整原文，右侧有“选择”可以把旧需求回填到输入框，适合在上一版基础上微调。

判断一条内测需求写得好不好，有个简单标准：把需求发给一个没见过这个应用的人，他能不能只靠文字和附件判断改完是什么样。能，AI 也能；不能，AI 只能猜。

图 3：一条合格的内测需求，应该能直接当作验收单使用

五、versionCode 与 versionName：系统认数字，测试同事认名字

内测包里最容易被糊弄过去的两个字段，就是 versionCode 和 versionName。它们看起来都叫“版本号”，实际上一个给系统做比较，一个给人做标识，职责完全不同。把这两个字段搞清楚，后面“为什么新包装不上”“为什么测试同事说的版本对不上”“为什么分发平台不认这次构建”这些问题，基本都能自己回答。

对比项	versionCode	versionName
数据类型	32 位整数	字符串
谁在用	Android 的包管理器、应用商店、分发平台	测试同事、产品经理、应用信息页
比较规则	数值大的是新版本，数值小会被拒绝降级	不做数值比较，只用于展示和记录
能否带后缀	不能，必须是纯数字	可以，例如 1.4.2-beta.1
是否必须递增	每次对外分发都应递增	不强制，建议与版本语义同步

versionCode 是 Android 判断“谁更新”的唯一依据。它的取值必须落在 1 到 2100000000 之间，0 和负数不合法，超过上限在解析阶段就会出问题。系统安装新包时，会拿新包的 versionCode 和已安装包的 versionCode 比较：大于或等于，才可能继续走签名校验；小于，直接拒绝，报 INSTALL_FAILED_VERSION_DOWNGRADE。只有调试版本在特定条件下才允许用参数强行降级，内测分发不应该依赖这种做法，因为测试同事不会每次都记得加参数。

versionName 则完全是给人看的。它可以是 1.4.2-beta.1，也可以是 1.4.2 内测第一版，Android 不会拿它做任何升级判断。应用商店会展示它，系统的应用信息页会展示它，测试同事报问题时引用的也是它。很多人误以为把 versionName 写大一点就能“强制升级”，这是不成立的；真正决定能不能盖上去的，是 versionCode 和签名。反过来，versionCode 对了但 versionName 没改，包能装，测试同事却会以为还是旧版本，沟通成本立刻上升。

给内测包设计一套可读又可排序的编码规则，比每次临时想一个数字可靠得多。下面这套规则适合大多数中小应用：versionCode 等于主版本乘以一百万，加次版本乘以一万，加修订号乘以一百，加构建号。约束是次版本、修订号、构建号都在 0 到 99 之间。这样既能从数字反推出语义，又能保证递增。

versionName	计算方式	versionCode
1.4.2-beta.1	1×1000000 + 4×10000 + 2×100 + 1	1040201
1.4.2-beta.2	1×1000000 + 4×10000 + 2×100 + 2	1040202
1.4.3	1×1000000 + 4×10000 + 3×100 + 0	1040300
1.5.0-rc.1	1×1000000 + 5×10000 + 0×100 + 1	1050001
2.0.0	2×1000000 + 0 + 0 + 0	2000000

如果团队更习惯按日期出 nightly 包，也可以用日期编码，例如 2026 年 10 月 21 日的第一版写成 2026102101。它同样是纯数字、单调递增，而且一眼能看出构建日期。缺点是与语义版本脱钩，测试同事无法从 versionCode 判断功能范围，只能靠 versionName。两种方案没有绝对优劣，关键是全团队统一，并且写进发布规范，不要这一次用语义编码、下一次用日期编码。

内测阶段最常见的五个版本错误，可以对照下面这份清单自查。第一，改了界面却没改 versionCode，新包和旧包的版本号完全一样，某些分发平台会认为没有更新，测试同事也分不清手里是哪一次构建。第二，versionCode 写小了，覆盖安装直接被系统拒绝。第三，用 13 位时间戳当 versionCode，超过了 32 位整数的表达范围，解析阶段就失败。第四，versionName 里带空格或奇怪符号，部分工具展示异常，问题单里引用的版本号对不上。第五，应用名里塞了版本号，每出一版桌面名称就变一次，测试同事反而更难找。

记住一句话：versionCode 是对系统的承诺，必须一次比一次大；versionName 是对人的说明，必须一眼看得懂。两者都改，才算一次完整的内测发版。

六、内测名与正式名：包名不动，显示名怎么分层

一个 Android 应用其实有三层“身份”。最底层是包名，系统用它区分应用、定位数据目录、判断覆盖关系；中间层是签名，系统用它确认“新包是不是同一个作者出的”；最上层是显示名，也就是用户看到的应用名称。内测改名只动最上层，包名和签名都保持不变，这样既能一眼区分内测版，又不破坏覆盖升级的链路。

显示名通常来自清单里 application 的 label 属性，实际项目多半引用一个字符串资源，例如 app_name。这个资源可能有多个语言版本：默认资源、英文资源、中文资源，甚至更多。只改默认资源，切换系统语言后名称就可能回退；只改中文，英文测试机上仍然是正式名。所以需求里要明确“所有语言资源都改”，改完至少切换一次系统语言复核。若应用里有 Activity 单独设置了 label，最近任务列表可能显示另一个名字，这也要一起检查。

显示位置	名称来源	内测名是否生效
桌面图标下方	application 的 label	是，覆盖安装后通常立即更新
设置里的应用信息	application 的 label	是，可直接核对
最近任务卡片	Activity 或 application 的 label	多数生效，Activity 单独设置时要额外检查
通知标题	代码里设置的标题	不一定，取决于代码是否引用资源
已创建的通知渠道	首次创建时写入系统	否，渠道名不会因应用更新自动改变

内测名的命名，建议采用“正式名 + 空格 + 内测版”的稳定结构，例如“记账助手 内测版”，英文环境用“Ledger Beta”。这样测试同事在桌面上一眼能分辨，又不会因为每版都改名字而找不到。名称长度要克制，中文控制在 10 个字以内，英文控制在 18 个字符以内；超长的名称在桌面会被省略号截断，反而看不出后缀。不要用“测试”“临时”“新新新”这类无法判断来源的词，也不要在名称里塞版本号，版本信息交给 versionName 和应用信息页。

这里有一个必须提前决定的分支：内测版和正式版是“覆盖”还是“并存”。覆盖式内测保持同一个包名，用同一把签名钥匙，versionCode 递增，新包直接盖旧包。优点是升级路径真实、数据连续、测试成本低；缺点是同一台手机只能留一个版本，测试同事想对比正式版就得再找一台设备。并存式内测给包名加后缀，例如 com.example.ledger.beta，系统会把它当成另一个应用，两个版本可以同时安装、各自保留数据；缺点是它无法验证覆盖升级，应用内分享、推送、第三方登录等依赖包名的能力可能要重新配置，维护成本明显更高。

策略	包名 / 签名	适合场景	代价
覆盖式内测	包名不变，签名不变，versionCode 递增	连续多轮内测，重点验证升级和数据保留	一台设备只能装一个版本
并存式内测	包名加后缀，签名可同可不同	正式版与内测版对比演示，互不干扰	测不了覆盖升级，数据不共享，配置成本高

对大多数团队的第一次内测，建议从覆盖式开始。它最接近正式发版的真实路径，也最能暴露签名和版本号的问题。等内测流程跑顺了，再为需要对比演示的场景单独做并存包。无论选哪种，都要在分发说明里写清楚：这是覆盖包还是并存包，装之前要不要卸载旧版，旧版数据会不会保留。测试同事最怕的不是麻烦，而是不知道会不会丢数据。

覆盖安装之后，桌面名称理论上会立即更新，但部分桌面会缓存图标和名称，短时间内仍显示旧值。遇到这种情况，先打开系统设置里的应用信息确认名称已经变了，再重启桌面或重启手机观察；不要急着重装，重装会清掉数据，把本来用于验证升级的现场破坏掉。图标也是同样的道理，自适应图标在不同厂商的桌面上有不同遮罩形状，替换后要在至少两台不同品牌的手机上确认，别只在一台模拟器上看。

图 4：改名只动最上层，包名和签名决定应用还是不是“同一个应用”

七、第四步：签名四选一，先想清楚能不能覆盖安装

签名不是给 APK 加密，也不是防别人打开压缩包，它解决的是两个问题：这个包是谁发的，以及这个包在签发之后有没有被改过。Android 在安装和更新时都会校验签名。新包的签名和已安装包的签名一致，系统才认为“这是同一个开发者的升级”；不一致，直接报 INSTALL_FAILED_UPDATE_INCOMPATIBLE，连覆盖的机会都不给。此时唯一的办法是先卸载旧应用，而卸载会清掉应用数据，内测里最容易丢的就是登录态、草稿和本地配置。

所以内测签名策略的核心不是“哪个更安全”，而是“同一款应用从第一版到最后一版，是不是同一把钥匙”。智能修改电脑版提供四种签名方式：默认签名、JKS 或 keystore、PEM 加 PK8、随机签名，支持 v1、v2、v3、v4 四种签名方案，默认启用 v1、v2、v3。选择之前，先把这四种方案各自管什么弄清楚。

签名方案	保护范围	主要生效版本	在内测里的作用
v1	JAR 签名，逐个条目校验	Android 7.0 及以下主要依赖，新系统兼容校验	覆盖老测试机的兼容性，minSdk 低于 24 时不能省
v2	整包签名，校验整个 APK 文件	Android 7.0 及以上	防整包被替换，绝大多数内测机的实际校验依据
v3	在 v2 基础上支持密钥轮换	Android 9.0 及以上	为将来换签名钥匙留出正规路径
v4	增量安装签名	Android 11.0 及以上，配合 adb 增量安装	日常内测分发不必单独依赖，v2/v3 才是主体

默认启用 v1、v2、v3 是一个稳妥的组合。它同时照顾了老设备、新设备和未来的密钥轮换；v2 和 v3 让 Android 7 以上的手机有整包校验，v1 让 minSdk 较低的应用仍能装到老机器上。个别团队为了“包小一点”只保留 v2，结果测试组里的旧手机装不上；也有人只保留 v1，新系统虽然能装，但整包校验缺失，verify 结果里 v2、v3 都是 false，后续排查会很别扭。内测阶段没有必要在这上面省体积。

四种签名方式的选择，可以按“这把钥匙要用多久”来判断。默认签名最省事，适合只做一次演示、之后不打算覆盖升级的场景；如果同一款应用要连续出多个内测版，建议从第一版就用 JKS 把钥匙固定下来。JKS 或 keystore 是 Java 体系的标准密钥库，里面有证书、私钥和别名，配合口令使用。它适合长期维护，能保证每一版都是同一把钥匙，覆盖安装最稳。PEM 加 PK8 适合团队已经有现成密钥材料的场景：PEM 提供证书，PK8 提供 PKCS#8 格式的私钥，两者必须严格配对。随机签名每次生成新钥匙，适合一次性的界面演示或截图，绝不能用于需要升级的内测。

方式	密钥来源	能否连续覆盖升级	推荐场景
默认签名	工具内置	需确认多次打包是否一致，不宜作为长期方案	临时演示、一次性验证
JKS / keystore	自家密钥库，别名加口令	能，推荐长期使用	连续多轮内测、正式发版
PEM + PK8	现成证书与私钥文件	能，前提是证书与私钥配对且长期保管	已有企业签名体系、从其他工具迁移
随机签名	每次新生成	不能，每版都算不同作者	一次性演示、截图、功能验证

JKS 的密码处理要单独强调。签名口令不要拼进命令行，也不要写进需求文本，工具通过环境变量读取口令，不会把它带进命令行参数和日志。密钥库文件至少两份离线备份，别名和两个口令分开保管，团队里至少两个人知道如何恢复。密钥库的有效期建议设置得足够长，例如 25 年以上；到期后再想用同一身份签名会非常麻烦。可以定期用 keytool 查看证书链、有效期和指纹，确认文件没有损坏。

PEM 加 PK8 的坑主要在配对。PEM 里是证书，PK8 里是私钥，两者必须来自同一对密钥；拿 A 证书配 B 私钥，签名阶段可能不报错，verify 或安装阶段才暴露。迁移前先用 openssl 分别查看证书和私钥的公钥信息，比对是否一致，再导入工具。导入后做一次完整的签名和 verify，把证书的 SHA-256 指纹记录下来，和原工具签出来的包比对。如果指纹一致，说明迁移成功；不一致，说明拿错了文件。

签名一致性的判断，可以归结为一个简单公式：包名相同、签名相同、versionCode 不小于已安装版本，三者同时满足，覆盖安装才会成功。任何一个不满足，都会走到不同的失败分支。包名不同是“另一个应用”，签名不同是“不同作者”，versionCode 更小是“降级”。排查装机问题时，按这个顺序逐一排除，比盲目重装有效得多。

内测签名只有一条铁律：同一款应用，从第一版内测到正式版，钥匙不换。要换钥匙，就必须接受“先卸载、数据清零”的代价，并提前通知测试同事。

图 5：覆盖安装看三件事——包名、签名、versionCode

八、第五步：回编、对齐、签名、verify，把 pack.log 读成验收单

AI 改完 apktool 工程后，智能修改电脑版会自动走打包流程。这个流程固定为四步：先用 apktool 回编出未签名包，再用 zipalign 做对齐，然后用 apksigner 签名，最后用 apksigner verify 校验签名结果。四步的顺序不能乱，尤其是“对齐必须在签名之前、签名之后不能再改包”这一条，违反了就会出现“明明签了名，安装却报签名无效”的怪现象。

第一步回编，把 apktool 目录里的资源和 smali 重新编译成 APK。这一步最常见的失败是资源引用错误、XML 格式错误、同名资源冲突，详细堆栈会写进 apktool.log。第二步对齐，把 APK 里的未压缩数据按 4 字节边界摆放，减少运行时的内存拷贝；带 so 的应用建议加 -p，让未压缩的 so 按页对齐，避免在新系统上出现加载异常。第三步签名，把证书和私钥写进 APK 的签名块。第四步 verify，单独再验一遍，确认“到底签没签上”。多这一步非常值得，密钥格式不对、别名不对、口令不对，往往只有 verify 会明确报出来。

整个打包过程会写进 pack.log，包括每一步的输入、输出和结果。读日志时不要只看最后一行，按阶段看：回编阶段有没有 BUILD SUCCESSFUL 或等价的成功标记；对齐阶段有没有生成新的对齐包；签名阶段有没有输出签名后的文件；verify 阶段有没有逐项列出 v1、v2、v3 的校验结果。只要有一个阶段没有产物，后面的阶段即使“执行了”，也只是对着旧文件操作，最后装上的可能是上一次的包。

日志现象	大概率原因	处理办法
回编阶段报资源或 XML 异常	改动的资源格式不对，或引用了不存在的资源	看 apktool.log 定位文件和行号，回退该处改动
zipalign 提示无法打开 zip	回编没有产出文件，或路径写错	先解决回编，再重新对齐
apksigner 提示无法加载签名者	密钥库路径、口令或别名不正确	核对别名，确认口令环境变量已生效
verify 提示 DOES NOT VERIFY	签名后又改了包，或签名过程被中断	不要修补，直接重新对齐、重新签名
verify 显示 v2 或 v3 为 false	签名参数只启用了 v1，或最小 SDK 设置导致方案被跳过	改回默认的 v1+v2+v3，重新签名
verify 显示 v1 为 false 且 minSdk 很低	没有启用 JAR 签名，老设备会装不上	启用 v1，重新签名并复验

verify 的输出值得逐行读。它会列出“Verified using v1 scheme”“Verified using v2 scheme”“Verified using v3 scheme”分别是 true 还是 false，列出签名者数量，通常应该是 1；还会打印签名者证书的 DN、SHA-256 摘要和密钥算法。DN 里能看到组织名和证书主题，SHA-256 摘要是这把钥匙的指纹。把这次 verify 的指纹和上一版内测包的指纹对比，一致就说明覆盖升级不会因签名受阻；不一致就不要再往下装，先查清楚为什么换了钥匙。

verify 通过之后，再用 aapt 对最终包做一次“读回”确认：包名、versionCode、versionName、application-label、launchable-activity、sdkVersion、targetSdkVersion 是否与需求一致。这一步是在装到手机之前发现“改错字段”的最后机会。尤其是应用名和版本号，AI 改的是工程里的资源，回编后是否真的写进最终 APK，只有读回包才能确认。把 aapt 的输出和第二步抄下来的基线表放在一起比对，改动项应该只有你要求的那几处。

• 回编有产物，且产物时间戳是本次构建；
• 对齐在签名之前完成，签名之后没有再改动包内文件；
• verify 显示 v1、v2、v3 均为 true，签名者数量为 1；
• 证书 SHA-256 指纹与上一版一致；
• aapt 读回的包名、版本、应用名、启动 Activity 与需求一致；
• 最终 APK 复制到分发目录时，文件名带版本号和构建日期。

图 6：pack.log 不是给机器看的流水账，而是给交付人看的验收单

九、第六步：装到测试机，用 adb、am start、dumpsys 复核

打包完成后，智能修改电脑版可以自动把成品装到已连接的手机或模拟器：先通过 adb 找设备，再安装，然后用 am start 拉起应用，最后用 dumpsys 复核前台应用是不是它。启动组件名有三档查找顺序：先读 config.ini 里记录的 LaunchableActivity，读不到就用 cmd package resolve-activity 查询，再不行走旧方式兜底。手机通过投屏窗口预览，模拟器会被提到最前。自动流程适合快速看效果，但内测交付不能只看“能打开”，还要手工复核版本、签名和覆盖安装。

手工装包的第一步是确认设备在线。运行 adb devices -l，看到设备序列号和 device 状态才算连上；显示 unauthorized 说明手机还没确认调试授权，需要在屏幕上点允许；列表为空则先检查数据线、驱动和开发者选项。一台电脑连多台设备时，后续每条命令都要加 -s 加序列号，否则 adb 会报“more than one device”。模拟器同样适用这套命令，只是序列号通常是 emulator-5554 这类形式。

adb install -r 里的 -r 表示替换已安装的同包名应用并保留数据，这是验证覆盖升级的关键参数。不要用 -d 去强行降级，那个参数只适合调试场景，内测包一旦依赖它，测试同事换台电脑就装不上。安装成功后，命令会输出 Success。如果输出 Failure，后面括号里就是失败原因，先按原因查，不要反复重试。安装完成后用 pm list packages 确认包名存在，再用 dumpsys package 读取系统里记录的 versionCode 和 versionName，和 aapt 读回的结果对照。系统里显示的版本才是测试同事看到的版本。

启动应用用 am start -W，-W 表示等待启动完成并输出结果。组件名可以写成“包名/Activity 全名”，也可以写成“包名/.MainActivity”这种相对形式。不确定 Activity 名时，先用 cmd package resolve-activity --brief 查：它会输出包名和当前首选的启动 Activity。如果 am start 报 Error type 3，说明组件不存在或包名写错；报 SecurityException，说明该 Activity 没有导出或缺少权限，这时要回头看清单，而不是硬改启动命令。启动结果里的 Status 为 ok、LaunchState 正常、TotalTime 有数值，才算真正拉起来了。

最后用 dumpsys 复核前台应用。dumpsys activity activities 里找 mResumedActivity，dumpsys window 里找 mCurrentFocus，两者都应该指向你的包名和 Activity。为什么要多这一步？因为 am start 返回 ok 只代表命令被接受，不代表界面真的在前台；有的应用启动后立刻跳到别的页面，有的被权限弹窗挡住，有的因为崩溃又退回桌面。dumpsys 给出的是系统当前状态，比肉眼看一秒更可靠。再配合 logcat 看有没有 FATAL EXCEPTION，基本就能确认这次内测包“装得上、起得来、在前台”。

命令	用途	预期结果
adb devices -l	确认设备连接与授权	至少一台状态为 device
adb install -r	覆盖安装并保留数据	输出 Success
dumpsys package	读取系统记录的版本信息	versionCode 与 versionName 与需求一致
resolve-activity	查询启动组件名	输出包名与可启动 Activity
am start -W	拉起应用并等待结果	Status ok，TotalTime 有值
dumpsys activity / window	确认前台应用	焦点与前台都指向目标包

分发：文件名、校验值与发布说明

内测包不要用“最新版.apk”“测试.apk”这种名字发出去。文件名至少包含应用名、versionName、versionCode 和构建日期，例如 Ledger-1.4.2-beta.1-1040201-20261021.apk。这样测试同事在下载目录里一眼能看出新旧，问题单里贴文件名就能对上构建。分发渠道优先用公司内网盘、设备管理平台或受控的群文件，不要把内测包放到公开可搜索的链接里；访问范围本身就是一道安全边界。

每个包附一份校验值。Windows 上可以用 certutil -hashfile 文件名 SHA256 计算，把结果和发布说明放在一起。测试同事下载后先核对，再安装；校验值不一致，说明文件在传输过程中损坏或被替换，直接重新下载。发布说明写四件事：本次版本号和 versionCode、改了什么、已知问题、装包方式（覆盖还是先卸载）。如果有签名变更，必须用醒目位置写清楚“本次需要先卸载，数据会清空”，不要指望大家自己发现。

升级验证：用两个版本走一遍完整路径

升级验证不要只装新包。正确做法是先装上一个基线版本，正常使用一段时间，制造一些本地数据，例如登录、改一条记录、存一个草稿；然后不卸载，直接安装新包；装完先看系统里的版本号有没有变，再打开应用看数据还在不在，最后看新功能或新界面有没有生效。这个顺序能同时验证签名一致、versionCode 递增、数据保留和功能落地，是内测交付最有价值的一次检查。

1. 在测试机上安装上一版内测包，登录并创建两条本地数据；
2. 记录系统应用信息里的 versionName 和 versionCode；
3. 用 adb install -r 安装新包，全程不卸载；
4. 再次读取版本信息，确认已经变成新值；
5. 打开应用，确认登录态和本地数据仍在，新界面已生效；
6. 在备用设备上做一次降级安装，确认系统按预期拒绝；
7. 把每一步的截图、命令输出和版本号记进发布记录。

降级测试容易被忽略，但它能验证“版本号真的在起作用”。把旧包再装回去，系统应该报 INSTALL_FAILED_VERSION_DOWNGRADE；如果居然装成功了，说明新包的 versionCode 没有真正递增，或者测试机上装的并不是你以为的版本。签名不一致的测试可以在备用设备上做：先装一个用默认签名或随机签名打的包，再装正式 JKS 签名的包，系统应该报 INSTALL_FAILED_UPDATE_INCOMPATIBLE。看清这两个失败长什么样，以后遇到时就不会慌。

十、两个自家应用实例，以及一份能照着查的失败清单

流程讲完，最后落到两个真实场景：一个是自家 App 出内测版，一个是自家内部工具给测试组发版。两个场景都用智能修改电脑版，但关注点不同：前者更在意桌面识别、覆盖升级和数据保留，后者更在意环境配置、版本可追溯和分发纪律。每个场景都按“以前怎么做、现在怎么做、改完怎么验证”三段写，方便你对照自己的项目。

实例一：自家记账 App 出内测版

以前怎么做：在 Android Studio 里改 app_name，顺手把 versionCode 加一，打一个 release 包。签名用的是某位同事电脑上的密钥库，别名和口令靠记忆，换一台电脑就找不到。图标只替换了一张 192×192 的 PNG，新手机上是糊的；启动页改完只在一台旧模拟器上看过。发给测试组时文件名叫 app-release.apk，群里同时躺着三个同名文件。测试同事装不上，报 INSTALL_FAILED_UPDATE_INCOMPATIBLE，现场只能用“卸载再装”解决，登录态和本地账目全丢，最后花了半天重新录数据。

现在怎么做：先把正式版的 APK、JKS 密钥库、别名、口令位置、versionCode 和 versionName 抄进基线表，再导入智能修改电脑版。需求按四段式写：应用名改为“记账助手 内测版”，中英文资源都改；versionName 改为 1.4.2-beta.1，versionCode 改为 1040201；图标用附件 logo-512.png，保留自适应图标分层；启动页用附件 splash-bg.png；包名、权限、记账逻辑都不动。签名选择 JKS，沿用正式版那把钥匙，确认口令通过环境变量传入。AI 改完，工具自动回编、对齐、签名、校验，pack.log 里四个阶段都有产物。手工再跑一次 apksigner verify --print-certs，把证书 SHA-256 指纹和正式版比对，一致才进入分发。

改完怎么验证：先在测试机上装上一版正式版，登录并创建两条账目；用 adb install -r 装新包，不卸载；打开系统应用信息，确认名称是“记账助手 内测版”、versionName 是 1.4.2-beta.1、versionCode 是 1040201；回到桌面看图标和名称；打开应用确认登录态和两条账目都在；再进启动页看新背景和“内部测试”小字；最后把系统语言切到英文，确认名称变成 Ledger Beta。全部通过后，把 APK 按“应用名-版本-构建号-日期”重命名，计算 SHA-256，连同发布说明一起发到内测群。

这个实例里，真正解决问题的不是“AI 会改图”，而是把签名、版本、验收三件事固定下来。需求里写死目标版本号，避免了下一次“版本号加一”算出不同结果；JKS 固定钥匙，避免了换电脑就换签名；aapt 读回和 dumpsys 复核，避免了“以为改了其实没改”。同样的一套动作，换成自家电商展示 App 或教学 App 也成立，只是把图标、启动页和文案换掉。

实例二：自家内部工具给测试组发版

以前怎么做：内部巡检工具要在测试环境和内网正式环境之间切换，API 地址写在构建配置里，每换一次环境就改常量、重新编译、重新打包。测试组拿到的包没有统一命名，有人装的是测试环境，有人装的是正式环境，提问题时说不清自己那一版连的是哪个地址。versionName 手写在清单里，偶尔忘了改；versionCode 有时重复，覆盖安装时灵时不灵。更麻烦的是，有人遇到安装失败就顺手卸载，结果本地保存的巡检草稿和登录配置全没了，第二天要重新配一遍。

现在怎么做：把内部工具当作正式产品来发内测。需求里写清三件事：应用名改为“巡检助手 内测版”；API 地址从测试环境切到内网正式环境，并保留一个只在内测包显示的EnvironmentIndicator；versionName 改为 2.3.0-beta.3，versionCode 改为 2030003，主题色同步换成内测用的橙色。附件里放一份环境说明，写明正式环境地址、账号申请方式和回滚地址。签名继续用团队 JKS，不换钥匙。AI 完成后，除了看 pack.log 和 verify，还额外用 aapt 读回 application-label 和 versionName，确认没有把正式包的环境配置带进来。分发给测试组时，文件名带环境标识，例如 Inspect-2.3.0-beta.3-2030003-internal-20261021.apk，附 SHA-256 和“本次为覆盖安装，请勿卸载”的说明。

改完怎么验证：先在一台测试机上装上一版内测包，确认首页顶部显示的是测试环境标识，登录后保存一条巡检草稿；覆盖安装新包，确认版本号变成 2.3.0-beta.3，首页环境标识变成内网正式，草稿还在，登录态没掉；再打开设置页看主题色是否变成橙色；最后让测试组按同样的步骤在另一台设备上复现一遍，并把 dumpsys package 的版本输出贴进验收记录。环境切换这类改动，最怕“包换了但配置没换”，所以验证时必须看运行时界面，而不是只看构建日志。

内部工具的内测，核心是把“环境”和“版本”变成可核对的信息。应用名告诉测试同事这是内测、不是正式；versionName 和 versionCode 告诉他们这是第几版；首页的环境标识告诉他们连的是哪套服务；分发文件名和校验值告诉运维这是不是同一个文件。四层信息叠起来，问题单才有复现基础。这里也再次提醒：只对自有版权或已获授权的内部应用做这类修改，不要把同样的方法用在别人的商业应用上。

常见失败排查：从报错反推是哪一环出了问题

内测装包失败，报错信息其实已经把范围缩得很小。下面这张表按“系统报错、最可能原因、处理动作”整理，覆盖了覆盖安装、签名、版本、对齐、启动几个高频环节。排查时按表走，不要一上来就卸载重装；卸载会清数据，把原本可以验证的问题现场毁掉。

现象或报错	最可能原因	处理动作
INSTALL_FAILED_UPDATE_INCOMPATIBLE	新包与已安装包签名不一致	换回同一 JKS 重签；确需换钥匙则备份后卸载
INSTALL_FAILED_VERSION_DOWNGRADE	新包 versionCode 小于已安装版本	按编码规则增大 versionCode，重新打包
INSTALL_PARSE_FAILED_NO_CERTIFICATES	包未签名，或签名块在后续操作中损坏	重新对齐、重新签名，verify 通过后再装
INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES	包内存在不一致的签名信息	用单一签名者重新签名，不要叠加多次签名
INSTALL_FAILED_INVALID_APK	回编产物损坏、对齐异常或文件传输不完整	核对 SHA-256，重新回编对齐，换条数据线重传
INSTALL_FAILED_OLDER_SDK	应用的 minSdk 高于测试机 Android 版本	换符合要求的测试机，或评估后调整 minSdk
INSTALL_FAILED_TEST_ONLY	清单里带了测试专用属性	内测交付包应按正常包处理，去掉该属性后重打
INSTALL_FAILED_USER_RESTRICTED	厂商系统限制了 USB 安装	按系统提示开启安装权限，登录厂商账号后重试
am start 报 Error type 3	组件名或包名写错，启动 Activity 不存在	用 resolve-activity 查出正确组件名再启动
桌面名称没变	改错资源、只改默认语言，或桌面缓存	aapt 读回 label，切换语言复核，重启桌面
图标模糊或被裁切	图标分辨率不足，或自适应图标分层被破坏	换高分辨率原图，按前景背景分层重做
覆盖安装后数据丢失	中途卸载过，或包名被改成了另一个应用	核对包名，恢复备份；后续坚持覆盖安装
启动后立刻闪退	资源替换不完整、启动页素材尺寸异常或代码改动冲突	用 logcat 抓 FATAL EXCEPTION，回退最近一次改动
verify 只有 v1 为 true	签名时只启用了 v1，v2/v3 被关闭	恢复默认 v1+v2+v3，重新签名并复验

排查顺序建议固定为：先看 install 报错，再看 verify 结果，再看 aapt 读回，最后看 logcat。这个顺序从“包能不能进系统”一路查到“应用能不能跑起来”，比凭经验猜快得多。

用户评价：五个人眼里的内测交付

下面是五位使用者在各自场景里的反馈，关注点不同，但都落在“少一次返工、多一条可核对的结果”上。

以前最怕发内测包，签名一换就要挨个通知卸载。现在把 JKS 固定下来，versionCode 按规则递增，测试同事直接覆盖装，数据都在。verify 打印的证书指纹我每次都存一份，出问题一对就知道是不是同一把钥匙。

—— 阿凯 · 独立开发者

我们小团队没有专职打包，最需要的是流程稳定。把内测名、versionName、versionCode 一次写进需求，AI 改完直接回编签名，pack.log 四步都有记录。以前改个名字要半小时，现在几分钟，剩下的时间都花在验收上。

—— 米粒 · 小团队 Android 开发

从测试组的角度，最有用的是应用名带“内测版”，设置里能看到明确的 versionName。提问题时我只要贴版本号和文件名，开发就能找到对应构建。分发时附 SHA-256 也省事，下载坏了一眼能看出来。

—— 老周 · 测试组长

给客户做交付时，内测包和正式包必须分得清。我用同一套 JKS 连续出包，靠 versionCode 保证升级，靠 aapt 读回确认名称和版本，最后用 dumpsys 看前台是不是目标应用。整套动作走下来，现场很少再出现“装错包”的尴尬。

—— 林同学 · 外包交付工程师

内部工具换环境最怕配置带错。现在把环境说明当附件一起写进需求，改完先在首页看环境标识，再覆盖安装看配置有没有保留。版本号和文件名都带环境信息，测试组再也不会把测试环境的包当成正式环境来提问题。

—— 陈工 · 企业内应用维护

合规提醒：只改自己的应用

本文所有流程都建立在“自有版权或已获授权”的前提下：应用是你自己开发的，或者你拿到了权利人明确的修改与分发授权。请勿用于破解、去除付费限制、绕过授权校验、篡改他人商业应用或二次分发不属于你的软件。签名密钥、证书和口令属于敏感材料，按公司安全规范保管，不要上传到公开仓库，也不要写进需求文本或群公告。内测分发范围要受控，发布说明里写清使用范围和保密要求。

做到这里，一个内测包才算真正交付：名字能认、版本能升、签名能盖、分发能查。下次再出第二版，你只需要改需求里的版本号和改动项，复用同一把钥匙、同一套验收命令，就能把“发内测”从一次紧张的现场操作，变成一条可重复的流水线。只需说话，就能让应用变成你想要的样子；而让这句话稳定落地的，是签名、版本和验收这些看起来不性感、却最省心的细节。