4、OTA升级流程总览：从服务器下发到设备安装的完整生命周期
OTA（Over-The-Air）升级并非单一动作，而是一条由云端控制台、分发服务器、设备端升级引擎、系统分区存储与启动引导器共同参与的工程链路。从用户点击“检查更新”到设备重启进入新系统，整个过程可拆解为检查、下载、校验、安装、重启五个阶段。每个阶段都有独立的失败模式与恢复策略，理解这条生命周期的完整视图，是设计可靠升级方案、排查升级故障的前提。本章将沿着这条链路逐段拆解，明确每个环节的输入、输出、关键判断逻辑与常见陷阱。
上图展示了OTA升级的完整生命周期。值得注意的是，检查与下载阶段通常运行在用户态（Android系统中为SystemUpdateService），而校验与安装阶段则可能切换到recovery模式或使用update_engine守护进程执行。重启阶段涉及启动引导器（Bootloader）对启动槽位的选择，这是A/B无缝升级机制的核心决策点。
4.1 检查阶段：版本比对与升级策略判定
核心原理：检查阶段的目标是回答“当前设备是否需要升级”以及“允许升级到什么版本”。设备端将当前系统版本号、设备型号、运营商定制标识、已安装应用列表摘要等信息上报给OTA服务器。服务器根据设备画像匹配可用的升级策略，返回升级包元数据（版本号、包大小、校验值、下载URL）或“无可用更新”的响应。
判断方法与操作流程：
- 触发方式：用户手动点击“设置→系统→系统更新”，或系统定时任务自动触发（通常每24小时一次）。
- 请求构造：设备发送
POST /v1/update/check请求，携带device_model、current_version、build_fingerprint、carrier_id等字段。 - 服务器决策：服务器执行三步判断——版本号是否高于当前版本、设备型号是否在灰度名单中、当前网络环境是否允许（如仅Wi-Fi下推送大包）。
- 响应处理：若返回
200 OK且包含update_available: true，则进入下载阶段；否则进入静默等待周期。
实战场景：某厂商在Android 14发布后，对老机型（Android 12）执行“分阶段推送”。首轮仅向5%用户开放检查接口，观察24小时内是否有异常崩溃率上升。若崩溃率低于0.2%，则逐步扩大到30%、100%。这种灰度策略依赖检查阶段的rollout_percentage字段，设备端无需感知，服务器端动态控制。
常见误区：检查阶段不应只比对版本号大小。Android版本号并非单调递增的整数，例如13.1.0.5可能比13.1.0.10更新（因为构建时间戳不同）。正确做法是比对完整的build_fingerprint或使用服务器下发的security_patch_level作为优先级依据。
| 检查项 | 数据来源 | 判定逻辑 | 失败处理 |
|---|---|---|---|
| 版本号 | Build.VERSION.INCREMENTAL | 服务器版本 > 当前版本 | 返回无更新 |
| 设备兼容性 | ro.product.device | 在支持列表中 | 返回错误码1001 |
| 网络条件 | ConnectivityManager | Wi-Fi或允许移动数据 | 延迟到Wi-Fi环境 |
| 存储空间 | StatFs | 剩余空间 > 包大小×2 | 提示用户清理 |
4.2 下载阶段：传输可靠性与断点续传
核心原理：下载阶段将升级包从服务器传输到设备本地存储。Android系统默认使用DownloadManager或自研下载引擎，支持HTTP/HTTPS协议。关键设计在于：升级包可能达到1-3GB（全量包），必须支持断点续传、分块校验和网络切换恢复。
操作流程：
- 分块下载：将文件切分为1MB大小的块，每块独立计算CRC32，下载完成后逐块校验。
- 断点续传：记录已下载的字节偏移量，网络中断后从偏移量继续请求
Range: bytes=xxx-。 - 存储策略：优先写入
/data/ota_package/目录，若空间不足则提示用户清理或使用/cache分区。 - 并发控制：限制最大下载速度为10MB/s，避免影响前台应用体验。
// 下载状态机示例
enum DownloadState {
IDLE, // 初始状态
CONNECTING, // 建立连接
DOWNLOADING, // 传输中
PAUSED, // 用户暂停或网络中断
COMPLETED, // 全部字节落盘
FAILED // 不可恢复错误
}
经验提醒：下载完成后不要立即进入校验阶段。先检查文件总大小是否与服务器返回的Content-Length一致，再检查最后一块的CRC。实际案例中，有设备因代理服务器缓存了不完整的响应导致包损坏，但HTTP状态码仍为200。
4.3 校验阶段：完整性、签名与安全认证
核心原理：校验阶段是安全防线，防止下载的升级包被篡改或损坏。Android采用两级校验：完整性校验（哈希比对）和签名校验（非对称加密验证）。完整性校验确保文件没有传输错误，签名校验确保文件确实来自可信的OTA服务器。
判断方法：
- 哈希校验：计算整个文件的SHA-256值，与服务器下发的
package_sha256比对。若不一致，删除文件并重新下载。 - 签名验证：使用内置的OTA公钥（存储在
/system/etc/security/otacerts.zip）验证升级包的RSA签名。签名覆盖文件头部元数据+所有内容块。 - 版本兼容性：解析升级包中的
META-INF/com/android/metadata，检查pre-build字段是否与当前系统指纹匹配。
风险说明：签名验证失败时，系统必须拒绝安装并记录recovery日志。切勿尝试“绕过签名”强制安装，这会导致设备进入不可信状态，后续所有OTA更新都将被拒绝。
| 校验类型 | 算法 | 密钥存储 | 失败后果 |
|---|---|---|---|
| 完整性 | SHA-256 | 服务器下发哈希值 | 重新下载 |
| 签名 | RSA-2048 / ECDSA | 设备内置公钥 | 终止升级 |
| 兼容性 | 字符串比对 | 升级包metadata | 提示版本不匹配 |
4.4 安装阶段：分区写入与系统切换
核心原理：安装阶段将升级包中的镜像文件写入系统分区。传统模式（非A/B）下，设备重启进入recovery模式，挂载/system、/vendor等分区并执行写入。A/B（无缝）模式下，系统在后台将新系统写入备用槽位（Slot B），写入完成后只需切换启动槽位即可，无需长时间停机。
操作流程（以A/B为例）：
- 解包：使用
update_engine解析升级包中的payload.bin，获取分区写入清单。 - 写入：将
system.img、vendor.img等写入slot B对应的块设备（如/dev/block/by-name/system_b）。 - 更新引导：写入完成后，更新
misc分区中的启动控制信息，标记slot B为可启动状态。 - 清理：删除升级包文件，释放存储空间。
案例拆解：某设备在安装阶段频繁失败，日志显示Failed to write to /dev/block/by-name/vendor_b: No space left on device。排查发现vendor分区在出厂时被错误分配了过小的大小（仅64MB），而新版本vendor镜像需要128MB。解决方法是修改分区表并重新刷机，而非调整升级包。此案例说明安装阶段必须提前检查分区大小，而非等到写入时才发现。
4.5 重启阶段：启动引导与回滚机制
核心原理：重启阶段是升级的“最后一公里”。设备重启后，Bootloader根据misc分区中的指令选择启动槽位。若新系统启动失败（如内核panic、关键服务崩溃），Bootloader或init进程会触发回滚，自动切换回旧槽位。
判断方法：
- 启动成功判定：系统启动后，
SystemServer完成核心服务注册，并写入boot_completed属性。若30秒内未写入，则判定失败。 - 回滚触发：连续两次启动失败后，Bootloader强制回滚到旧槽位，并清除新槽位的启动标记。
- 用户反馈：若新系统正常启动，但用户手动回滚（通过设置中的“卸载更新”），系统会清除新槽位数据并切换回旧槽位。
经验总结：重启阶段最常见的失败是“启动循环”。建议在升级包安装完成后，先不立即重启，而是执行一次“预启动检查”——验证关键分区的挂载点、文件系统完整性、SELinux上下文是否正确。这能减少约30%的重启失败率。
总结复盘：OTA升级的五个阶段环环相扣，任何一环的疏忽都可能导致升级失败或设备变砖。检查阶段要关注灰度策略，下载阶段要保证传输可靠性，校验阶段要严守安全底线，安装阶段要确保分区空间与写入正确，重启阶段要设计好回滚机制。实际工程中，建议为每个阶段增加详细的日志埋点（使用logcat的SystemUpdate标签），并上报到云端分析平台，以便快速定位大规模升级故障。