📚 课程目录第4章 OTA 升级流程

4. OTA 升级流程

OTA 升级并不是“点一下更新按钮，等进度条走完”这么简单。它是一条跨越网络、存储、系统服务、引导程序与分区镜像的完整链路。任何一个阶段的状态异常，都可能导致升级失败、卡在进度条、重启后回滚，甚至设备无法开机。理解这条链路的阶段划分、关键状态与日志位置，是后续稳定性诊断的基础。

一、核心原理：四阶段链路与状态机

Android A/B（无缝）OTA 的典型链路可拆为四个阶段：下载 → 校验 → 写入 → 重启生效。每个阶段都有明确的状态标记，系统通过 update_engine、boot_control HAL 与 update_verifier 协同推进。

下载阶段：由 update_engine 从 OTA 服务器拉取 payload，写入 /data/ota_package 或直接流式处理。关键状态：IDLE → CHECKING_FOR_UPDATE → DOWNLOADING。
校验阶段：对 payload 做签名验证与哈希校验，确认来源可信、内容完整。关键状态：VERIFYING，失败则进入 REPORTING_ERROR。
写入阶段：将新镜像写入非当前启动槽（slot B），并更新 boot_control 的 slot 元数据。关键状态：FINALIZING → UPDATED_NEED_REBOOT。
重启生效：重启后引导程序切换到新槽，update_verifier 校验新系统完整性，成功后标记 boot_successful，否则触发回滚。

这四个阶段并非线性独立，而是由状态机驱动。若在 UPDATED_NEED_REBOOT 之前断电，升级可重试；若在重启后校验失败，则依赖回滚机制恢复旧槽。

二、方法流程：各阶段关键动作与日志定位

排查 OTA 问题时，第一步是确认“卡在哪个阶段”。不同阶段的日志来源不同，定位手段也不同。

阶段	关键动作	典型日志/命令	常见异常
下载	建立连接、分块拉取 payload	`logcat -s update_engine` 中 `Downloading`	网络超时、存储不足、HTTP 403
校验	验证签名、比对哈希	`PayloadVerifier`、`VerifyPayload`	签名不匹配、payload 损坏
写入	写 slot B、更新元数据	`bootctl`、`FINALIZING`	分区空间不足、写失败
重启生效	切换槽位、校验新系统	`update_verifier`、`boot_successful`	校验失败、回滚、无法开机

例如，若 update_engine_client --status 长期停留在 DOWNLOADING，应优先检查网络与 /data 剩余空间；若停留在 VERIFYING，则重点看签名与 payload 来源；若已到 UPDATED_NEED_REBOOT 但重启后回滚，则问题在 update_verifier 或新系统本身。

三、案例场景：一次“重启后回滚”的排查

某设备 OTA 下载与写入均成功，状态显示 UPDATED_NEED_REBOOT，但重启后仍进入旧系统。抓取日志发现：

update_verifier: Failed to verify /dev/block/sda3
update_verifier: dm-verity verification failed
boot_control: Mark boot unsuccessful, rolling back to slot A

这说明新槽写入的镜像哈希与 vbmeta 中记录不一致，update_verifier 校验失败，触发回滚。进一步检查发现，写入阶段曾出现一次 write error，但 update_engine 未正确重试，导致 slot B 数据不完整。修复方式是增加写入重试与写后校验，并在 FINALIZING 后强制比对分区哈希。

注意：不要只看“升级成功”提示。A/B OTA 的“成功”仅代表写入完成，真正生效要等重启后 update_verifier 通过。若忽略这一步，很容易把回滚误判为“升级没生效”。

四、误区与复盘

误区一：把下载完成当成升级完成。下载只是第一步，校验和写入失败同样会导致升级失败。
误区二：忽略 slot 元数据。boot_control 中的 slot_suffix、bootable 标记若未正确更新，重启后仍会进入旧槽。
误区三：只看主日志。update_engine、update_verifier、bootctl 分属不同 tag，需分别抓取。
复盘要点：建立“阶段—状态—日志—命令”对照表，每次异常先定位阶段，再查对应日志，避免盲目重启或反复重试。

实践建议：在测试环境模拟断电、断网、存储满、签名错误四类故障，观察各阶段状态迁移与日志输出，形成自己的排查路径。这样在真实 OTA 异常时，才能快速判断是下载、校验、写入还是重启生效环节出了问题。

掌握这条完整链路后，后续的稳定性诊断就有了清晰的坐标系：任何异常都可以先归入四个阶段之一，再结合状态与日志逐层收敛。OTA 的稳定性，本质上就是对这条链路每个环节的可观测性与可恢复性的持续建设。