1. 课程导入
在 Android 设备的整个生命周期中，系统更新是维持安全性、兼容性与用户体验的关键环节。无论是手机、平板、车机、电视盒子还是 IoT 终端，只要设备出厂后还需要修复漏洞、增加功能或适配新运营商要求，就离不开 OTA。OTA 是 Over-The-Air 的缩写，直译为“空中下载”，在 Android 语境中，它特指通过无线网络向设备下发并安装系统镜像或补丁包的一整套机制。它不仅是“下载一个 zip 包然后重启”这么简单，而是涉及包体生成、签名校验、传输协议、A/B 分区切换、回滚保护、差分升级、失败恢复等多个层面的系统工程。
从工程视角看，Android OTA 的稳定性问题往往不是单点故障，而是“包体—传输—校验—写入—切换—启动”这条链路中某一环出现异常后，被放大成用户可见的卡死、反复重启、无法开机或数据丢失。因此，本课程不把 OTA 当作一个简单的升级按钮，而是把它视为一条完整的信号链与状态机，逐段拆解其原理、工具、日志与排障方法。
1.1 核心原理：OTA 不是复制文件，而是受控的状态迁移
Android OTA 的核心可以概括为三个关键词：包体、校验、切换。升级包通常由 ota_from_target_files 或 ota_from_target_files.py 生成，内部包含目标版本镜像、差分补丁、元数据以及签名信息。设备端由 update_engine 或 recovery 中的 applypatch 负责解析与写入。写入完成后，系统通过 bootloader 的 slot 选择或 recovery 的 --wipe 逻辑完成启动切换。
传统 A 方案（非 A/B）依赖 recovery 分区，升级时设备重启进入 recovery，由 recovery 解压并写入 system、vendor 等分区，失败时容易停留在 recovery 或半砖状态。A/B 方案则引入两个对称的 slot（slot_a 与 slot_b），当前运行 slot 保持可用，新版本写入另一个 slot，写入并校验成功后通过 boot_control HAL 将启动标记切到新 slot。若新 slot 启动失败，bootloader 可自动回退到旧 slot，从而显著提升升级成功率与可恢复性。
关键认知：OTA 的稳定性目标不是“升级一定成功”，而是“升级失败时设备仍能回到可用状态”。A/B 方案、回滚保护、postinstall 校验、payload 元数据签名，都是围绕这一目标设计的。
1.2 发展历程：从 recovery 到 A/B，再到虚拟 A/B 与增量更新
Android OTA 的演进大致可分为四个阶段。早期 Android 2.x 到 4.x 以 recovery 升级为主，包体为完整块状更新，体积大、耗时长，失败后依赖用户手动进入 recovery 清除数据。Android 5.0 到 7.0 期间，块差分（block-based OTA）逐渐成熟，通过 bsdiff 或 imgdiff 生成差分包，减少下载量，但 recovery 路径的失败恢复能力仍然有限。
Android 7.0 引入 A/B 无缝更新，Android 10 之后虚拟 A/B（Virtual A/B）进一步在动态分区上实现类似能力，减少专用分区占用。Android 11 之后，增量 OTA、压缩算法（如 lz4、zstd）、payload 签名与元数据校验不断增强。到了 Android 13/14，OTA 已与 update_engine、boot_control、dm-verity、avb 深度耦合，稳定性诊断必须同时理解包体、分区、启动链与日志系统。
1.3 学习目标：从“会升级”到“能定位、能复现、能收敛”
本课程的学习目标分为三层。第一层是建立完整认知：理解 OTA 包体结构、A/B 与虚拟 A/B 的差异、update_engine 的工作流程、boot_control 的切换逻辑。第二层是掌握诊断工具：能够阅读 logcat、update_engine_log、recovery.log、dmesg、avb 校验输出，能够使用 adb、fastboot、payload_dumper、ota_from_target_files 等工具复现问题。第三层是形成工程方法：面对“升级失败”“卡在开机动画”“反复重启”“回滚不生效”等场景，能够按链路分段定位，而不是盲目重刷。
- 概念层：OTA、A/B、slot、payload、postinstall、rollback、dm-verity、AVB。
- 工具层：adb、fastboot、update_engine_client、payload_dumper、avbtool、lpdump。
- 方法层：日志分级、时间线对齐、分区状态检查、失败注入与回滚验证。
1.4 核心概念与常见误区
初学者最容易把 OTA 等同于“下载安装包”。实际上，OTA 包通常不是普通 APK，而是包含 payload.bin、payload_properties.txt、care_map、metadata 等文件的专用格式。另一个常见误区是认为“升级失败就是包坏了”。在很多案例中，包体本身合法，但设备因电量不足、存储空间不够、slot 标记异常、verity 校验失败或 bootloader 版本不匹配而失败。因此，诊断时必须先确认失败发生在哪一段。
| 概念 | 含义 | 稳定性关注点 |
|---|---|---|
| A/B Slot | 两套对称分区，当前运行一套，新版本写入另一套 | 切换标记、回滚计数、slot 是否可启动 |
| payload.bin | OTA 实际写入数据的主体，含操作列表与校验信息 | 签名、哈希、差分基准版本是否匹配 |
| postinstall | 写入完成后在后台执行的校验与优化步骤 | 失败会导致回滚或标记 slot 不可用 |
| dm-verity | 块设备完整性校验机制 | 校验失败会触发重启或进入 recovery |
| rollback | 新版本启动失败后回退旧版本 | 回滚索引、防降级版本号、bootloader 配合 |
1.5 案例场景：一次“升级后卡在开机动画”的排查思路
假设设备通过 A/B OTA 升级后卡在开机动画。第一步不是重刷，而是确认当前 slot 与启动状态：
adb shell getprop ro.boot.slot_suffix
adb shell getprop ro.boot.verifiedbootstate
adb shell update_engine_client --status
adb shell dmesg | grep -i "avb\|verity\|slot"若 update_engine_client --status 显示 postinstall 失败，则问题可能出在写入后的校验阶段；若 bootloader 日志显示 slot_a 的 successful 标记未置位，则可能是切换逻辑或回滚计数异常；若 dmesg 出现 dm-verity 错误，则要检查 system/vendor 分区哈希是否与 vbmeta 匹配。通过这条链路，可以把“卡开机”拆成可验证的若干段。
排障提示：先看时间线，再看分区状态，最后看包体。时间线能告诉你失败发生在下载、校验、写入、postinstall 还是启动阶段；分区状态能告诉你 slot 是否被正确标记；包体检查通常放在最后，因为大多数现场问题并非包体本身损坏。
1.6 整体课程框架
后续 29 章将围绕“原理—工具—场景—复盘”展开。前半部分建立 OTA 基础：包体结构、A/B 与虚拟 A/B、update_engine 流程、boot_control 与启动链。中段进入诊断工具与日志体系：logcat、update_engine_log、recovery.log、dmesg、avb 校验、payload 解析。后段聚焦典型异常：下载失败、校验失败、写入中断、postinstall 失败、回滚不生效、反复重启、变砖恢复。最后通过综合案例与复盘方法，把零散知识收敛为可复用的诊断路径。
学习建议：每章至少准备一台可刷机的测试设备或模拟环境，边学边抓日志。OTA 稳定性诊断高度依赖现场证据，只看文档不抓日志，很难形成真正的定位能力。
本章作为导入，不要求你立刻记住所有命令，但需要建立一个基本判断：OTA 是一条从包体到启动的完整链路，稳定性问题必须按链路分段定位。接下来每一章都会围绕这条链路的一个环节展开，逐步补齐你的诊断工具箱。