批量安装 APK,同一批设备里,测试组装测试包、客服组装正式包、展示机组装演示包。只要有一次发错文件,第二天就会收到“为什么这台功能不一样”的消息。批量安装真正难的,是版本对应关系。
- 设备组:哪一批机器;
- 渠道或用途:测试、正式、演示;
- 当前版本:versionName 与 versionCode;
- 回滚包:上一版安装包的位置与校验值。
版本矩阵怎么记
不必上系统,一张表就够,但要每天更新:
| 设备组 | 用途 | 当前版本 | versionCode | 回滚包 | 更新时间 |
|---|---|---|---|---|---|
| A 组 01-10 | 功能测试 | 3.2.1 | 30201 | v3.2.0 / 校验已记 | 11-07 |
| B 组 01-20 | 客服值守 | 3.1.8 | 30108 | v3.1.7 / 校验已记 | 11-06 |
| C 组 01-05 | 门店演示 | 3.0.9 | 30009 | 不升级 | 11-03 |
versionCode 比 versionName 更可靠。覆盖安装时系统只认前者,版本号写错会导致“装不上”或“装上了但没变”。
按灰度顺序装,不要一次全推
批量安装建议分三轮:
- 单台验证:选一台非关键设备,完整走一遍登录、启动、核心功能。
- 小组灰度:同型号、同系统版本的 3 到 5 台,观察半天。
- 全量推送:按分组执行,每组装完立即抽查 2 台。
三轮之间要有明确的放行条件,例如“启动无崩溃、关键页面能打开、通知正常”。没有条件,灰度就只是延迟了事故。
正式包和测试包签名不同,无法覆盖安装。遇到 INSTALL_FAILED_UPDATE_INCOMPATIBLE,要么换同签名包,要么卸载后重装,而卸载会清掉应用数据。装之前先确认签名,别在全量阶段才发现。

回滚要留三样东西
回滚不是“再装一次旧包”这么简单,至少要保留:
- 旧安装包本体:按版本号归档,不要只留最新一版;
- 校验值:MD5 或 SHA256,防止文件被替换或传坏;
- 数据兼容说明:新版本是否升级过数据库、缓存格式,降级后会不会读不出来。
第三项最容易被忽略。应用升级时改了本地数据结构,回滚后可能直接崩溃或要求清数据。涉及本地数据库的版本,回滚前先备份应用数据。
批量安装时逐台记录成功、失败、跳过及错误码。失败的设备单独重试,不要整组重装。整组重装会把已经成功的设备再折腾一遍,也掩盖了真正的失败原因。
一次完整的批量安装流程
- 确认安装包版本、签名和校验值,登记到版本矩阵。
- 选一台非关键设备安装,验证启动、登录与核心功能。
- 在小组内灰度 3 到 5 台,观察半天并记录异常。
- 按分组全量推送,每组装完抽查 2 台。
- 逐台核对 versionCode,确认没有“假成功”。
- 更新版本矩阵中的当前版本与更新时间。
- 保留旧包与校验值,标注数据兼容情况,供回滚使用。
批量安装 APK 报错的具体错误码,可以对照批量安装失败错误码处理;文件怎么归档与校验,见文件分发目录规范。需要在一台电脑上对多台设备执行安装任务,可参考诺程投屏产品页的设备管理说明。
常见问题
覆盖安装失败,提示版本降级怎么办?
系统默认不允许安装 versionCode 更低的包。需要回滚时先卸载再安装,或使用允许降级的调试方式;卸载前备份应用数据。
批量安装需要每台都确认吗?
通过 ADB 安装通常不需要逐台点确认,但仍受“USB 安装”开关限制。建议装完抽查 versionCode,避免出现假成功。
怎么避免把测试包推到客服组?
用版本矩阵固定“设备组-用途-版本”的对应关系,安装前核对分组和校验值,并按小组灰度后再全量。