第一章 课程导入：学习目标、核心概念与整体框架
Android系统升级与OTA（Over-The-Air，空中下载）开发，是移动终端、智能车载、电视大屏、IoT设备等产品生命周期管理中不可或缺的技术环节。本章作为整个课程的起点，旨在帮助学习者建立全局视野：明确学习目标、厘清核心概念、搭建知识框架，并深刻理解系统升级能力在设备从出厂到退役全过程中的战略价值。我们将从工程实践的角度，剖析OTA不仅仅是“推送一个安装包”，而是一套涉及构建、签名、差分、传输、校验、分区写入、回滚保障的复杂系统工程。
1.1 学习目标与课程定位
本课程面向具备一定Android基础（熟悉系统架构、了解分区布局）的系统工程师、BSP工程师、应用层开发者和测试工程师。通过30章的系统学习，学习者应达到以下目标：第一，能够独立完成从AOSP源码编译到OTA升级包生成的完整流程；第二，深入理解升级包格式（ZIP结构、payload.bin、metadata等）与签名机制；第三，掌握A/B系统无缝升级的原理与实现，以及非A/B系统的Recovery升级路径；第四，具备排查升级失败、回滚异常、分区空间不足等实际问题的能力；第五，了解FOTA（Firmware Over-The-Air）服务端架构与客户端升级器的交互逻辑。
课程内容按照“基础概念 → 构建系统 → 包生成 → 客户端升级 → 服务端与运维 → 安全与排障”的逻辑递进。每一章都配有实战案例或代码分析，确保学习者不仅“听得懂”，更能“做得出”。
学习路径建议：前5章是地基，必须彻底掌握分区表、Bootloader、Recovery镜像的作用；第6-12章聚焦升级包生成与差分算法；第13-20章深入A/B升级与动态分区；第21-25章讲解FOTA服务端与设备端协同；最后5章为高级排障与安全加固。建议每学完一章，在模拟器或开发板上动手验证。
1.2 核心概念：升级包、分区与升级模式
在Android系统中，一次完整的OTA升级涉及三个核心对象：升级包（Update Package）、目标分区（Target Partitions）和升级执行器（Updater）。升级包是一个ZIP文件，内部包含可执行的二进制补丁、文件元数据、签名信息和edify脚本。根据生成方式的不同，升级包分为全量包（Full OTA）和增量包（Incremental OTA）。全量包包含系统完整镜像，体积大但兼容性强；增量包仅包含从旧版本到新版本的差异数据，体积小但依赖严格的版本基线。
分区布局是升级的基础。传统Android设备采用system、vendor、boot、recovery等固定分区。从Android 10开始，动态分区（Dynamic Partition）成为主流，system、vendor等分区不再直接对应物理分区，而是由super分区内的逻辑卷管理。这给OTA带来了新的挑战：升级过程中需要调整逻辑卷大小、处理快照与回滚。此外，A/B（无缝）升级机制将系统分为slot A和slot B，升级在后台写入非活动slot，完成后通过重启切换，极大降低了升级失败导致变砖的风险。
| 对比维度 | 全量包（Full OTA） | 增量包（Incremental OTA） |
|---|---|---|
| 生成方式 | 直接打包当前系统镜像 | 基于旧版本与新版差异生成 |
| 包体积 | 大（通常1-2GB） | 小（通常50-200MB） |
| 升级条件 | 无严格版本限制 | 必须从指定基线版本升级 |
| 失败风险 | 较低（完整写入） | 较高（依赖旧文件哈希匹配） |
| 适用场景 | 首次发布、跨版本大升级 | 日常安全补丁、小功能迭代 |
升级模式主要分为两类：Recovery模式升级和A/B无缝升级。Recovery模式是传统的升级方式，设备重启进入Recovery系统，执行升级脚本，将新系统写入system等分区。这种方式升级期间设备不可用，且如果中途断电，可能造成系统损坏。A/B升级则利用双槽位设计，升级在后台进行，用户无感知，重启后自动切换槽位，若新系统启动失败，可自动回滚到旧槽位。
经验提醒：在车载或医疗等对可用性要求极高的场景，A/B升级几乎是强制要求。但在低端IoT设备上，由于存储空间有限，非A/B升级仍然常见。选择哪种模式，本质上是存储成本与可靠性的权衡。
1.3 整体框架：从源码到设备终端的升级链路
一个完整的OTA升级链路，从开发者的代码提交开始，到终端用户设备上的系统更新完成，跨越了构建、发布、分发、执行四个阶段。理解这条链路，有助于定位问题所在环节。
- 构建阶段：开发者修改AOSP或厂商代码，通过
make或soong编译系统生成目标文件（target files zip）。该zip文件包含了system.img、vendor.img等原始镜像以及文件元数据，是生成OTA包的“原材料”。 - 包生成阶段：使用
ota_from_target_files工具，基于目标文件生成全量包或增量包。增量包需要提供旧版本的目标文件作为基线。此阶段还会生成签名所需的密钥对，并将公钥嵌入设备端。 - 分发阶段：升级包上传至FOTA服务器。设备端通过HTTPS或自定义协议下载升级包。此阶段涉及断点续传、校验下载完整性（MD5/SHA256）、以及流量控制。
- 执行阶段：设备端升级器（如
update_engine或Recovery中的updater）解析升级包，校验签名，执行edify脚本或二进制payload，将数据写入目标分区。完成后，根据A/B或非A/B模式进行重启或提示用户重启。
风险提示：升级包签名是安全底线。如果签名密钥泄露，攻击者可以构造恶意升级包，完全控制设备。生产环境中，必须使用硬件安全模块（HSM）存储私钥，并实施严格的密钥轮换策略。
1.4 案例拆解：一次典型的A/B系统OTA升级流程
为了将抽象概念具体化，我们模拟一个实际场景：某品牌手机运行Android 13，当前系统位于slot A，版本号为V1。现在要升级到V2版本，采用A/B无缝升级。
初始状态：设备存储中，slot A的system、vendor、boot分区均为V1版本；slot B分区为空闲或旧版本。FOTA服务器已生成V1到V2的增量包（约120MB）。
升级过程：
- 设备端
update_engine在后台下载增量包，并校验签名与哈希。 - 下载完成后，
update_engine将payload（二进制增量数据）写入slot B的对应分区。此过程不干扰用户当前使用的slot A。 - 写入完成后，系统设置一个“启动成功”标记（boot_success）。此时设备提示用户重启以完成升级。
- 用户重启后，Bootloader根据标记切换到slot B。如果slot B的V2系统成功启动并运行，系统会清除回滚标记，并可能将slot A标记为可覆盖。
- 如果slot B启动失败（例如内核崩溃），Bootloader自动回滚到slot A，设备仍可正常运行V1版本。
关键参数与日志：在/data/misc/update_engine/log中，可以看到类似INFO - Update completed successfully的日志。若失败，会出现ERROR - Error applying payload并附带具体错误码（如kDownloadTransferError或kPayloadMismatchError）。
复盘要点：此案例中，增量包生成时使用的基线版本必须与设备当前版本完全一致。如果用户设备已经通过其他途径修改了系统文件（如root），导致文件哈希不匹配，增量包应用将失败。因此，OTA系统必须包含强制校验逻辑，并在失败时提供全量包作为兜底方案。
1.5 常见误区与总结复盘
初学者在理解OTA时，常陷入以下误区：误区一：认为OTA只是简单的文件拷贝。实际上，分区写入涉及文件系统权限、SELinux标签、dm-verity哈希树更新等复杂操作。误区二：忽视升级包签名的重要性。在开发调试阶段，使用testkey签名尚可，但发布版本必须使用正式密钥，否则设备无法通过验证。误区三：混淆A/B升级与“热升级”。A/B升级虽然无需进入Recovery，但依然需要重启才能切换系统，并非不重启。误区四：认为增量包可以跨任意版本。增量包对基线版本有严格限制，跨版本升级必须使用全量包或连续多个增量包。
总结本章，我们明确了课程的学习目标，掌握了升级包、分区、升级模式三大核心概念，并梳理了从构建到执行的完整链路。OTA开发不仅是技术实现，更是对设备安全性、用户体验和运维效率的综合考量。在后续章节中，我们将逐一深入每个技术细节，从构建系统的配置开始，逐步揭开OTA开发的全貌。
本章核心收获：1. 能区分全量包与增量包的适用场景；2. 能描述A/B升级与Recovery升级的流程差异；3. 能说出OTA链路中的四个关键阶段；4. 理解签名与校验在安全中的核心地位。请务必在开发板上完成一次全量包的生成与升级，建立感性认识。