2. Android系统架构基础：分层结构、启动流程、分区布局与OTA关键组件

Android系统并非一个单一的整体，而是由多层软件栈与硬件协同构成的复杂体系。对于从事OTA升级开发的工程师而言，理解系统架构是开展一切工作的前提：OTA升级的本质是对系统分区中的镜像文件进行替换与校验，而这一过程深度依赖系统的启动流程、分区布局以及底层组件的协作。本章将系统梳理Android的分层结构、启动流程、分区布局，并重点剖析与OTA升级直接相关的关键组件，为后续章节的升级包制作、差分算法、AB切换与升级脚本编写打下坚实的认知基础。

上图展示了Android系统从应用层到硬件层的完整分层结构，以及右侧对应的分区布局。OTA升级并非只涉及某一个分区，而是需要系统层、HAL层与内核层的协同配合。下面我们将逐一深入剖析各层级的核心职责与OTA的关联。

2.1 Android系统分层结构详解

核心原理：五层架构与边界职责

Android系统自底向上可分为Linux内核层、硬件抽象层（HAL）、系统服务层（Native/Java）、Java API框架层和应用层。每一层都有明确的边界与通信协议，层与层之间通过Binder、HIDL/AIDL、系统调用等机制交互。从OTA开发视角看，最需要关注的是：内核层负责块设备读写与dm-verity校验，HAL层负责Boot Control（AB槽切换）与恢复模式控制，系统服务层负责升级包的下载、校验与触发，应用层负责用户交互与状态展示。

判断方法：如何快速定位分层问题

在实际开发中，当OTA升级出现异常时，可以通过以下方法快速定位问题所在层级：

• 应用层问题：升级包下载失败、进度条卡住、用户界面无响应——检查SystemUpdateClient的日志（logcat -s SystemUpdate）。
• 系统服务层问题：升级包校验失败、UpdateEngine报错——查看update_engine日志（/data/misc/update_engine/logs/）。
• HAL层问题：槽位切换失败、无法进入recovery——检查bootcontrol HAL的selinux权限与返回值。
• 内核层问题：分区写入失败、dm-verity校验错误——查看dmesg中的块设备错误信息。

案例拆解：一次典型的OTA失败分层排查

某设备在OTA升级到一半时提示“系统损坏”，重启后无法进入系统。排查过程如下：

1. 首先查看应用层日志，发现升级进度在87%时中断，无用户主动取消操作。
2. 查看update_engine日志，发现错误码为kErrorIOError，定位到写入system_b分区时发生I/O错误。
3. 进一步查看dmesg，发现内核报错mmcblk0p23: I/O error, dev mmcblk0, sector 123456，确认是eMMC坏块导致。
4. 最终结论：问题出在内核层与硬件层，而非软件逻辑错误。处理方案是更换eMMC芯片，并优化升级脚本增加坏块重试机制。

常见误区与总结

• 误区一：认为OTA只是“拷贝文件”。实际上，OTA涉及分区表校验、文件系统兼容性、SELinux上下文、AVB签名验证等多个环节。
• 误区二：忽略HAL层的作用。Boot Control HAL是AB升级的核心，如果HAL实现不完整，系统将无法正确切换槽位。
• 总结：分层架构是OTA升级的骨架，理解每一层的职责与接口，是进行后续开发与排障的基础。

2.2 Android启动流程与OTA的关联

核心原理：从BootROM到System Server

Android的启动流程可以简化为：BootROM → Bootloader → Kernel → init进程 → Zygote → System Server → 应用启动。对于OTA升级而言，最关键的两个阶段是Bootloader阶段（负责读取misc分区中的bootloader_message，决定进入正常系统还是recovery模式）和Kernel/init阶段（负责挂载分区、启动关键服务）。

在AB升级方案中，Bootloader还需要读取misc分区中的boot_ctrl信息，确定当前活动槽位（slot），并引导对应槽位的boot分区。如果升级过程中断电，Bootloader可以通过回滚机制自动切换到上一个可用槽位。

操作流程：启动流程中的OTA检查点

实战场景：升级后首次启动的验证

在OTA升级完成后，设备会重启进入新系统。此时需要验证：

1. Bootloader是否正确切换了槽位（检查getprop ro.boot.slot_suffix）。
2. 新系统的dm-verity是否通过校验（查看dmesg | grep verity）。
3. 关键服务是否正常启动（如service list | grep update）。

常见误区与总结

• 误区：认为启动流程与OTA无关。实际上，OTA升级后的首次启动是验证升级成功与否的关键环节，很多问题（如SELinux策略错误、分区挂载失败）都在此时暴露。
• 总结：启动流程决定了OTA升级的“入口”和“出口”，理解Bootloader与init的交互逻辑，是设计可靠升级方案的前提。

2.3 分区布局与OTA升级的映射关系

核心原理：分区是OTA操作的最小单元

Android设备的分区布局因芯片平台和系统版本而异，但核心分区基本一致。以下是OTA开发中最常涉及的分区及其作用：

操作流程：动态分区下的OTA升级

在Android 10及以上版本中，system、vendor等分区被合并到super分区中。OTA升级时，系统通过update_engine调用liblp库来调整super分区内的逻辑分区大小，然后写入新镜像。具体流程如下：

1. 读取当前super分区的逻辑分区表（位于super分区头部）。
2. 计算新镜像所需的空间，必要时调整其他逻辑分区的大小。
3. 写入新镜像到目标逻辑分区。
4. 更新分区表并同步。

# 查看当前动态分区布局
lpdump /dev/block/by-name/super
# 输出示例：
# Slot 0:
#   Partition name: system
#   Size: 2048 MB
#   Extent 1: 2048 MB (linear, offset 0)
#   Partition name: vendor
#   Size: 512 MB
#   Extent 1: 512 MB (linear, offset 2048 MB)

案例拆解：分区空间不足导致的升级失败

某设备在OTA升级时提示“空间不足”，但df -h显示/data分区仍有大量剩余空间。排查后发现，问题出在cache分区：由于系统将升级包缓存到cache分区，而cache分区仅有100MB，升级包大小为1.2GB，导致写入失败。解决方案是修改升级策略，将缓存路径改为/data/ota_cache，并增加空间检查逻辑。

常见误区与总结

• 误区：认为分区布局是固定的。实际上，不同厂商、不同芯片平台的分区表差异很大，OTA脚本必须适配具体设备。
• 总结：分区布局是OTA升级的“操作对象”，理解每个分区的特性（只读/可写、大小、挂载点）是编写可靠升级脚本的基础。

2.4 OTA升级涉及的关键组件

核心原理：四大核心组件

OTA升级的完整链路涉及以下关键组件，它们各自承担不可替代的职责：

• UpdateEngine（AB OTA）：运行在系统服务层，负责管理整个AB升级流程，包括下载、校验、写入、切换槽位。它通过Binder接口与应用层通信，通过BootControl HAL与Bootloader交互。
• Recovery（非AB OTA）：独立的恢复模式系统，包含内核和ramdisk。在非AB方案中，系统重启进入recovery模式，执行升级脚本（/sdcard/update.zip）并写入分区。
• BootControl HAL：硬件抽象层接口，提供getCurrentSlot()、setActiveBootSlot()、markBootSuccessful()等方法，是AB升级中槽位切换的关键。
• update_engine_client：命令行工具，用于调试和手动触发升级，支持--payload、--headers等参数。

操作流程：AB OTA升级的标准调用链

# 1. 应用层发起升级请求
adb shell cmd update_engine --payload=file:///data/ota/update.zip --headers="--metadata_size=65536" --update

# 2. UpdateEngine解析payload，校验签名
# 3. 通过BootControl HAL获取当前槽位
# 4. 写入非活动槽位分区
# 5. 写入完成后，调用setActiveBootSlot()切换槽位
# 6. 重启设备，Bootloader引导新槽位

实战场景：使用update_engine_client进行手动升级

在开发调试阶段，经常需要绕过应用层直接触发升级。以下是一个典型的调试流程：

1. 将升级包push到设备：adb push update.zip /data/ota/
2. 构造headers文件：echo -e "FILE_HASH=...\nFILE_SIZE=...\nMETADATA_HASH=..." > headers.txt
3. 执行升级：adb shell cmd update_engine --payload=file:///data/ota/update.zip --headers=@/data/ota/headers.txt --update
4. 监控进度：adb shell cmd update_engine --progress

常见误区与总结

• 误区：混淆AB升级与Recovery升级。AB升级无需重启进入recovery，用户体验更好，但对分区布局和Bootloader要求更高。
• 总结：UpdateEngine与BootControl HAL是AB升级的核心，Recovery是非AB升级的核心。理解它们的差异，有助于根据产品需求选择合适的技术方案。