Android稳定性-50-量产前稳定性验收怎么做：风险评估、准入评审和遗留问题管理

发表于 2026-04-10 分类于 Android稳定性本文字数： 6.7k 阅读时长 ≈ 24 分钟

量产前稳定性验收和普通版本准入不一样。普通迭代版本出问题，还可能通过下一包、灰度回滚、运营通知来修正；量产版本一旦进入产线、仓储、渠道和用户手里，问题会变成供应链、售后、品牌和成本问题。稳定性验收如果只停留在“长稳跑完了、缺陷都关了”，很容易漏掉真正会在量产后放大的风险。

量产前验收要回答的问题更现实：这批软件和硬件组合能不能大规模出货，产线包和测试包是不是同一个风险状态，售后能不能拿到足够证据，遗留问题有没有可执行的处置策略，出现严重问题时能不能止损。

这篇从风险评估、准入评审和遗留问题管理三个角度写。重点不是给量产评审增加表格，而是让评审能真正决定是否放行、限量、返工或延期。

一、量产验收关注的是规模化后果

实验室里 50 台设备跑过 72 小时，不等于 5 万台设备出货后没有问题。量产把很多实验室里不明显的变量放大了：硬件批次、供应商差异、产线刷机流程、仓储温度、区域网络、用户使用路径、售后日志能力、OTA 首包策略。

所以量产前稳定性验收要比版本准入多看三件事。第一是硬件和软件组合是否一致，特别是屏、相机、触控、射频、传感器、电池、存储这些供应链可能有多个版本的部件。第二是产线流程是否会改变系统状态，例如预置数据、校准文件、分区写入、恢复出厂设置、首次开机配置。第三是出货后诊断和止损能力是否可用，例如日志导出、线上告警、售后工具、OTA 回滚或热修策略。

如果这三件事没有验收，长稳报告再漂亮也不完整。

二、验收范围要覆盖包、设备、批次和渠道

量产验收首先要确认对象。很多事故不是测试没做，而是测试对象和量产对象不一致。

对象	需要确认	风险示例
软件包	测试包、产线包、OTA 包、渠道包 fingerprint	测试包通过，产线包多了预置应用导致启动变慢
硬件批次	屏、相机、存储、电池、射频版本	某批存储 fsync 抖动导致系统卡顿
配置	区域、运营商、预装、权限、默认开关	海外配置关闭日志上报，灰度无法诊断
产线动作	刷机、校准、老化、恢复出厂、包装前检查	校准文件丢失导致相机偶发打开失败
渠道	公开版、运营商版、行业定制版	定制应用常驻引起功耗异常

量产验收报告里必须写清“本次验收覆盖了哪些对象，没有覆盖哪些对象”。没有覆盖的不是小字备注，而是遗留风险的一部分。

三、风险评估要把影响和可控性分开

量产风险不能只按严重程度排序。一个问题很严重但有明确回滚和低触发条件，和一个问题中等严重但不可监控、不可复现、不可止损，管理动作完全不同。

建议用两个维度评估：用户影响和可控性。用户影响看是否影响开机、通信、相机、支付、导航、数据、续航、升级等关键体验；可控性看能否稳定复现、能否监控、能否修复、能否规避、能否回滚。

风险类型	用户影响	可控性	量产动作
高影响低可控	高	低	不建议放行，优先修复或限量
高影响高可控	高	高	可带严格条件放行，必须有止损方案
低影响低可控	低	低	进入售后观察和专项治理
低影响高可控	低	高	可作为普通遗留管理

比如低概率重启就是高影响问题。如果没有根因、没有监控、没有规避，即使只出现一次，也可能阻断量产。相反，某个非主路径设置页偶发闪退，如果有明确修复计划且不影响主路径，可以作为遗留项带出。

四、量产验收指标要比准入指标更保守

量产前指标不能只看实验室通过率，还要看趋势稳定性和余量。因为量产后设备规模更大，低概率问题会被放大。

常见指标包括：非预期重启为 0，Watchdog 为 0，开机失败为 0，OTA 失败率低于目标线，核心路径 Crash/ANR 不高于上一稳定版本，相机、通话、蓝牙、Wi-Fi、定位、支付扫码等专项指标不劣化，待机功耗和温升不劣化，存储满、低电量、弱网、高温等极限场景没有阻断问题。

指标	量产建议口径	验收说明
非预期重启	0，或有充分非版本排除证据	需要 pstore、bootreason、同批次对比
system_server Watchdog	0	原则上不带出
OTA 升级成功率	达到目标，失败可诊断	首包尤其重要
核心 App Crash/ANR	不劣于基线	要分渠道和预装差异
待机功耗	不劣于上一量产版本	关注定制应用和网络条件
温升	压力场景不触发异常降频或关机	要看环境温度
日志能力	可导出、可上报、可关联版本	影响售后定位

量产指标更保守，不是为了卡版本，而是因为出货后修复成本高。

五、完整案例：存储批次差异导致的量产风险

某产品准备量产，软件版本 P2.0.18 已经完成稳定性长稳。80 台实验室设备跑 96 小时，没有 Watchdog，没有 kernel panic，Crash/ANR 指标也在目标线内。按照普通准入，它可以进入发布。

但量产验收时，测试团队增加了 30 台产线抽样机，其中 10 台来自新存储批次。恢复出厂后进行应用安装、相册扫描、OTA 升级和低存储压力组合测试时，3 台新批次设备出现系统明显卡顿，最严重的一台在 OTA 后首次开机阶段停留 9 分钟。logcat 没有直接 crash，bugreport 显示 system_server 多次等待 installd 和 vold，kernel log 里有多段 I/O latency spike。

如果把它当普通卡顿缺陷，可能会被写成“低概率，后续优化”。但放到量产验收里，这个问题必须升级：它只出现在新存储批次，命中 OTA 和首次开机路径，用户影响高，而且一旦出货很难通过售后快速定位。

验收团队把风险写成：新存储批次在 OTA 后首次开机路径出现 I/O 抖动，引起系统服务等待和启动时间异常。接着拉入存储供应商、BSP、Framework、OTA 和产线团队。进一步测试发现，新批次 eMMC 在高温下 flush latency 明显高于旧批次，OTA 后 dexopt 和媒体扫描叠加时放大了问题。

最终动作不是简单修一个 App，而是三条线并行：BSP 调整存储调度参数，OTA 首启阶段延后部分媒体扫描，产线增加新批次存储抽检压力项。量产结论也不是“通过”或“不通过”一句话，而是：P2.0.18 不允许覆盖新存储批次出货；旧批次可限量放行；P2.0.19 修复后新批次需完成 50 台 x 48 小时首启和 OTA 压力验证。

这个案例说明，量产验收必须把实验室稳定性、硬件批次和产线状态连起来看。否则问题可能在测试报告里是一次卡顿，在量产后就是一批售后故障。

六、产线包一致性检查

量产前最基础的动作，是确认测试包、产线包、OTA 包和渠道包的一致性。不要只看文件名，要看 fingerprint、分区镜像、vendor 版本、安全补丁、预置应用列表和关键配置。

常用命令：

adb shell getprop ro.build.fingerprint
adb shell getprop ro.vendor.build.fingerprint
adb shell getprop ro.product.vendor.name
adb shell getprop ro.build.version.incremental
adb shell getprop ro.boot.verifiedbootstate
adb shell pm list packages -f > packages.txt
adb shell settings list global > settings_global.txt
adb shell settings list secure > settings_secure.txt
adb shell df -h > df.txt

对比两个包可以保存摘要：

#!/usr/bin/env bash
set -euo pipefail
serial="$1"
out="mp_check_${serial}_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$out"
for prop in ro.build.fingerprint ro.vendor.build.fingerprint ro.build.version.incremental ro.boot.verifiedbootstate; do
  adb -s "$serial" shell getprop "$prop" >> "$out/props.txt"
done
adb -s "$serial" shell pm list packages -f | sort > "$out/packages.txt"
adb -s "$serial" shell settings list global | sort > "$out/settings_global.txt"
adb -s "$serial" shell df -h > "$out/df.txt"

一致性检查的输出要进入验收材料。没有这一步，后面所有测试结论都可能建立在错误对象上。

七、遗留问题要分成四类处理

量产前几乎不可能做到缺陷为零。关键是把遗留问题分类，而不是把所有未关闭缺陷塞进附件。

第一类是不得遗留：非预期重启、Watchdog、开机失败、数据丢失、OTA 主流程失败、核心通信失败。第二类是可带条件遗留：有明确影响范围、规避方案、监控指标和修复计划的问题。第三类是普通遗留：非主路径、低影响、有修复排期的问题。第四类是转专项治理：短期不阻断量产，但暴露平台能力不足的问题，例如日志采集不完整、自动化覆盖不足、功耗归因困难。

类别	是否可放行	必要条件	示例
不得遗留	否	修复并验证	Watchdog、数据丢失
条件遗留	可限量	监控、规避、owner、期限	某区域低概率蓝牙回连慢
普通遗留	可	修复计划	非主路径设置页闪退
专项治理	可转长期	目标和里程碑	日志平台缺少 HAL 状态

遗留问题评审要避免一句“风险可控”。可控必须写成具体动作。

八、量产评审会怎么开

量产评审会不适合逐条读测试报告。建议按决策顺序组织。

先确认验收对象：包、机型、批次、渠道、产线状态是否一致。再确认硬阻断项：是否存在重启、Watchdog、开机失败、OTA 失败、数据丢失。接着看核心指标：Crash、ANR、功耗、温升、专项路径是否和基线一致。然后看 Top Issue 和遗留问题：哪些关闭，哪些带条件，哪些不允许量产。最后形成动作：放行、限量、返工、补测、延期。

每个动作都要写到 owner 和时间点。量产会议最怕结论是“原则同意，后续关注”。这句话不能指导产线，也不能指导售后。

九、售后诊断能力也是验收项

量产后很多问题不会在实验室复现。用户手里的设备可能无法长时间连接 adb，也不能随意抓完整 bugreport。因此售后诊断能力必须提前验收。

至少要确认：用户授权后能否导出关键日志，Crash/ANR/重启是否能上报，日志中是否包含 build、设备型号、硬件批次、渠道和时间，售后工具能否识别 OTA 前后版本，严重问题是否能触发回滚或暂停推送。

如果一个遗留问题没有诊断能力，风险等级要上调。因为它不仅可能发生，还可能发生后查不清。

十、常见误判

第一，把实验室长稳通过当成量产通过。量产还要看产线包、硬件批次、渠道配置和售后链路。

第二，把缺陷关闭率当成主要结论。关闭率高不代表没有高风险遗留，一个未关闭的重启问题可能比二十个 UI 缺陷更重要。

第三，忽略产线动作。刷机、校准、恢复出厂、预置数据都可能改变系统状态。

第四，遗留问题只写 owner，不写期限和止损。量产后没有时间慢慢补证据。

第五，忽略区域和渠道差异。运营商定制、海外网络、行业预装都可能改变功耗、网络和稳定性表现。

十一、检查清单

测试包、产线包、OTA 包、渠道包 fingerprint 是否一致或差异已解释。
硬件批次和供应商版本是否覆盖，特别是相机、屏、存储、电池、射频。
产线刷机、校准、老化、恢复出厂流程是否完成抽样验证。
非预期重启、Watchdog、开机失败、OTA 失败、数据丢失是否清零。
Crash、ANR、功耗、温升、核心专项是否和量产基线对比。
Top Issue 是否关闭，未关闭项是否有量产动作。
遗留问题是否分类，并写明影响、规避、监控、owner、期限。
售后日志、线上告警、问题上报、回滚或暂停推送链路是否可用。
限量出货条件和扩大出货条件是否明确。
评审结论是否能指导产线执行。

十二、输出物模板

# 量产前稳定性验收结论

## 1. 验收对象
- 产品 / 机型：<product / model>
- 软件版本：<fingerprint / build id>
- 产线包：<fingerprint / checksum>
- OTA 包：<version / checksum>
- 硬件批次：<camera / display / storage / battery / RF>
- 渠道范围：<公开版 / 运营商 / 海外 / 行业>

## 2. 覆盖摘要
| 项目 | 覆盖范围 | 结果 | 未覆盖风险 |
| --- | --- | --- | --- |
| 长稳 |  |  |  |
| OTA |  |  |  |
| 产线抽样 |  |  |  |
| 极限场景 |  |  |  |

## 3. 阻断项检查
| 阻断项 | 结果 | 证据 | 结论 |
| --- | --- | --- | --- |
| 非预期重启 |  |  |  |
| Watchdog |  |  |  |
| 开机失败 |  |  |  |
| 数据丢失 |  |  |  |

## 4. 遗留问题
| 问题 | 类别 | 影响范围 | 放行条件 | Owner | 截止时间 |
| --- | --- | --- | --- | --- | --- |

## 5. 量产结论
- 结论：<放行 / 限量 / 返工 / 延期>
- 限制条件：<批次 / 渠道 / 数量 / 区域>
- 扩大条件：<补测或灰度指标>
- 停止条件：<触发即暂停产线或 OTA>
- 售后要求：<日志、告警、回滚、升级策略>

十三、限量量产不是模糊放行

量产评审里常见一个结论：先限量。这句话如果没有数字和边界，等于没有结论。限量量产必须回答四个问题：限多少，限哪些批次或渠道，观察什么，满足什么条件才能扩大。

限量可以按数量、区域、渠道、硬件批次或用户类型控制。比如旧存储批次允许 2 万台，新存储批次暂停；公开渠道允许首批 5%，运营商定制版等待补测；某区域网络配置不同，先排除该区域。限制条件要能被产线和渠道执行，不能只存在评审纪要里。

限量维度	适用场景	例子
数量	总体风险可控但需要观察	首批 5000 台，48 小时无异常后扩大
批次	供应链差异明显	仅旧存储批次放行，新批次补测
渠道	定制配置风险不同	公开版放行，运营商版等待预装功耗验证
区域	网络或法规配置差异	国内版放行，海外弱网补测
功能开关	某能力风险高	默认关闭实验性低功耗策略

限量量产的扩大条件也要写清楚。比如“G1 售后无同类投诉，线上 Crash/ANR 不高于基线，OTA 成功率达到 99.5%，无新增重启和 Watchdog”。只有这样，限量才是风险控制，不是模糊放行。

十四、产线验证和 OTA 验证要双轨看

量产版本通常同时面对两条路径：新机产线刷入和老用户 OTA 升级。这两条路径的风险不同。产线刷入关注分区完整性、校准文件、预置应用、首次开机和恢复出厂；OTA 关注升级前后数据保留、分区切换、首次启动耗时、回滚、低电量和低存储。

很多团队只重视 OTA，因为线上用户多；也有团队只重视产线，因为量产评审围绕出货。实际上两条都不能少。一个包在产线新机上表现正常，不代表 OTA 后旧数据环境也正常；一个 OTA 验证通过，也不代表产线校准和预置流程不会引入差异。

1
2

产线路径：刷机 -> 校准 -> 老化 -> 恢复出厂 -> 首次开机 -> 包装前检查
OTA 路径：旧版本状态 -> 下载 -> 安装 -> 重启切换 -> 首次解锁 -> 数据和应用恢复

验收结论要分别写两条路径。如果产线通过但 OTA 未覆盖，不能写整体通过；如果 OTA 通过但产线包和测试包不一致，也不能写整体通过。双轨清楚，风险才不会混在一句话里。

十五、验收后的 72 小时跟踪

量产评审通过后，稳定性工作还没有结束。首批出货或首轮 OTA 后的 72 小时非常关键，很多低概率问题会在这个窗口出现趋势。建议提前定义 72 小时跟踪计划。

跟踪内容包括：激活量、OTA 成功率、开机失败、Crash/ANR、非预期重启、售后工单、用户反馈、关键模块专项指标、日志上报成功率。每个指标要有 owner 和看板地址。出现异常时，必须知道谁能暂停 OTA、谁能通知产线、谁能拉取日志、谁能决定回滚。

时间窗口	重点动作	输出
0-6 小时	看激活和升级是否顺利	首批状态快报
6-24 小时	看 Crash/ANR/重启趋势	稳定性趋势报告
24-48 小时	看售后和区域差异	风险复评
48-72 小时	判断是否扩大	扩大或暂停结论

72 小时跟踪计划要在量产前就写好。出了问题再临时找数据，通常已经错过最佳止损窗口。

十六、量产风险要反哺下一轮研发

量产验收发现的问题，不应该只影响当前版本。它还应该反哺下一轮研发计划。比如本次发现新存储批次 I/O 抖动，下一轮就要把存储批次纳入常规稳定性矩阵；本次发现售后日志缺少硬件批次字段，下一轮就要改日志规范；本次发现产线恢复出厂后配置差异，下一轮就要增加产线配置自动比对。

建议量产验收报告最后增加“反哺项”：测试矩阵更新、平台工具更新、准入标准更新、供应商要求更新、产线检查项更新。这些动作不一定阻断当前出货，但会决定下一次量产是否更稳。

反哺项示例：
1. 稳定性矩阵新增 storage_vendor 维度，覆盖高温 + OTA + 低存储组合。
2. 产线检查脚本新增 ro.vendor.build.fingerprint 和校准文件摘要比对。
3. 售后日志新增硬件批次、渠道包版本、首次开机耗时字段。
4. 准入阻断项新增 OTA 首启超过目标线且无解释不得放行。

量产验收不是一次性关卡，而是把真实出货风险带回工程系统的入口。

十七、量产验收中的供应商协同

Android 设备量产稳定性经常牵涉供应商：相机模组、屏、触控、存储、射频、蓝牙、传感器、电池、充电 IC。很多底层问题不是主机厂单方面能快速闭环的，验收阶段必须把供应商协同机制纳入风险评估。

供应商协同不是等问题发生后临时拉群。量产前应该确认每个关键部件的固件版本、变更记录、已知问题、压力测试结果和问题响应窗口。对高风险部件，要求供应商提供日志解释方式和固件回退方案。比如存储 I/O 抖动问题，如果供应商不能解释延迟尖峰，也不能提供筛选或固件策略，那么即使实验室复现概率低，量产风险也不能轻易降低。

部件	验收关注	需要供应商提供
相机	打开、切换、首帧、功耗	provider 日志说明、固件版本、已知 timeout
存储	OTA、低存储、fsync、温度	延迟规格、批次差异、筛选建议
屏/触控	唤醒、黑屏、触控无响应	驱动版本、ESD 策略、异常寄存器
蓝牙	回连、车机、音频	协议栈补丁说明、兼容性列表
电池/充电	温升、关机、电量跳变	校准数据、保护阈值、异常日志

量产评审结论中，如果某个风险依赖供应商响应，就要写明供应商 owner 和截止时间。不要把“等待供应商分析”作为可无限期延长的状态。

十八、抽样策略要覆盖最坏组合

量产抽样不是随机拿几台设备跑一遍。稳定性问题往往出现在最坏组合：新硬件批次、低电量、低存储、高温、弱网、旧版本 OTA、多预装渠道、用户数据多。抽样策略要有意识地覆盖这些组合。

可以把抽样分成三层。第一层是基础代表性样本，覆盖主要硬件批次和渠道。第二层是风险样本，覆盖新供应商、新固件、新配置。第三层是极限组合样本，把高风险环境叠加起来。样本数量不一定巨大，但每个样本为什么被选中要说得清。

抽样设计示例：
基础样本：A05/A06 各 20 台，覆盖公开版和运营商版。
风险样本：新存储批次 15 台，新相机模组 10 台。
极限样本：低电量 10 台，低存储 10 台，高温 10 台，旧版本 OTA 20 台。
组合样本：新存储批次 + OTA + 低存储 8 台，连续 48 小时。

抽样策略写清后，量产评审才能理解测试结论的代表性。否则“抽测通过”这句话无法支撑大规模出货。

十九、量产验收要关注恢复能力

稳定性验收通常关注问题是否发生，但量产更要关注发生后能否恢复。用户设备不可能永远不遇到异常，关键是异常是否会造成不可恢复后果。

恢复能力包括：系统服务 crash 后能否自动拉起，网络断连后能否恢复，蓝牙回连是否需要用户重启，OTA 失败后能否回滚，低存储清理后系统是否恢复，温度降低后性能是否恢复，异常重启后数据是否完整。一个问题如果能自动恢复、可监控、无数据损坏，量产风险和不可恢复问题完全不同。

验收报告可以增加恢复能力表：

场景	异常触发	恢复方式	用户影响	验收结论
OTA 中断	断电或低电	A/B 回滚	延迟升级	可接受或需优化提示
蓝牙断连	车机切换	自动回连	短时无声	需看回连时长
低存储卡顿	剩余空间过低	清理后恢复	操作变慢	需提示和保护
温升降频	高负载高温	降温后恢复	性能下降	需避免关机

恢复能力清楚，遗留问题的风险评估才更接近真实用户体验。

二十、量产验收结论要能被产线执行

量产验收结论如果只写给研发和测试看，就还不完整。它必须能被产线执行。产线关心的是：哪个包可以刷，哪些批次可以放，哪些设备需要拦截，哪些失败码必须停线，哪些抽检项必须增加，哪个时间点可以扩大生产。

因此结论里要避免抽象词。不要只写“新存储批次谨慎放行”，而要写“storage_vendor=B 的批次暂停出货，已刷机设备进入隔离区；P2.0.19 完成 50 台 OTA 首启验证后复评”。不要只写“关注 OTA 成功率”，而要写“OTA 失败率超过 0.5% 或连续 3 台同批次失败时暂停推送并通知版本 owner”。

产线执行口径示例：
允许：storage_vendor=A，公开渠道包 P2.0.18，首批 10000 台。
暂停：storage_vendor=B，等待 P2.0.19 修复验证。
新增抽检：每 500 台抽 5 台做恢复出厂 + 首次开机耗时检查。
停线条件：开机失败、校准文件缺失、OTA 首启超过 8 分钟且同批次连续 2 台出现。
联系人：产线质量 owner、版本 owner、BSP owner。

量产评审的最终读者不只是会议室里的人，还包括真正执行刷机、抽检、入库、发货和售后接待的人。结论越具体，执行偏差越小。

二十一、量产后的问题回流路径

出货后发现稳定性问题，不能只走普通缺陷流程。量产后问题需要同时进入售后、版本、研发、质量和供应链视图。否则售后看到的是用户投诉，研发看到的是零散 bug，供应链看到的是个别退机，没人能及时判断是否为批量风险。

建议建立量产问题回流路径：售后工单触发稳定性标签，线上告警关联 build 和硬件批次，版本 owner 每日查看首批问题，质量 owner 判断是否升级为量产 Top Issue，供应链 owner 参与批次分析。这个路径提前设计好，问题发生时才不会临时找人。

量产验收报告可以把回流路径作为附件：问题入口、分级规则、响应时限、升级联系人、暂停条件。这样验收不是在出货前结束，而是延伸到真实用户环境。

二十二、小结

量产前稳定性验收的重点，是把版本风险放到真实出货链路里判断。它不仅看软件是否稳定，还看硬件批次是否一致、产线流程是否可靠、遗留问题是否可控、售后诊断是否能支撑止损。

一份合格的量产验收结论，应该能让产线知道能不能刷，渠道知道能不能发，售后知道怎么查，版本 owner 知道什么条件下必须暂停。只有做到这一步，稳定性验收才真正保护了量产质量。