2. Android系统升级基础

Android系统升级并不是简单地把一个新镜像“拷贝进去”再重启，而是一套围绕升级包分发、校验、写入、切换与回滚构建的工程体系。理解OTA、A/B无缝升级、Recovery升级、增量升级与全量升级这几个基本概念，是后续学习升级失败恢复、回滚策略和故障定位的前提。本节从升级路径、分区模型、包形态和适用场景四个角度建立整体认知。

一、核心概念：OTA是通道，升级方式是策略

OTA（Over-The-Air）指通过无线网络下发系统升级包并完成安装的机制。它描述的是“升级包如何到达设备”，而不是“升级包如何写入设备”。真正决定升级行为的是设备采用的分区与启动模型：

• Recovery升级：设备重启进入独立的Recovery分区，由Recovery程序解压并写入system、vendor、boot等分区，完成后重启进入新系统。传统A-only设备多采用此方式。
• A/B无缝升级：设备存在两套完整分区槽位（slot A与slot B）。当前运行A槽时，升级包写入B槽；写入完成后仅需一次重启切换到B槽，用户几乎无感知。
• 全量升级：升级包包含目标版本所有分区的完整镜像，不依赖设备当前版本，兼容性最好但体积最大。
• 增量升级：升级包只包含“从旧版本到新版本”的差异数据，体积小、下载快，但必须严格匹配源版本与目标版本。

二、两条升级路径的流程对比

Recovery升级与A/B无缝升级在流程上的差异，直接决定了升级耗时、可用性和回滚能力。下图给出两条路径的关键阶段与状态切换关系。

三、全量与增量：包形态与适用场景

全量包与增量包的选择，本质是下载体积、生成复杂度与失败风险之间的权衡。增量包通过二进制差分算法（如bsdiff）生成，安装时在设备端做patch合并，因此对源版本一致性要求极高。

四、典型场景与工程案例

某中端机型从Android 12升级到Android 13，采用A/B + 增量OTA方案。升级包约180MB，后台下载完成后写入slot B，用户点击“立即重启”后约20秒进入新系统。若新系统连续启动失败3次，Bootloader会将active槽位切回slot A，用户回到旧版本并收到升级失败提示。这一机制正是后续“回滚与故障恢复”章节的核心基础。

而在一些低内存、单槽位的入门设备上，只能采用Recovery + 全量OTA。升级期间设备需重启进入Recovery，写入时间可能长达数分钟，且一旦写入中断，往往需要借助外部工具重新刷机。因此这类设备在推送策略上更保守，通常选择夜间或Wi-Fi环境下执行。

# 查看当前槽位与A/B支持情况
adb shell getprop ro.boot.slot_suffix
adb shell getprop ro.build.ab_update

# 查看OTA包元数据（payload_properties.txt）
adb shell cat /data/ota_package/payload_properties.txt

# Recovery升级日志关键行
[    3.214] Verifying update package...
[    3.560] Update package verification took 0.3s
[    4.102] Installing update...
[   18.775] Write 4096 blocks to system...
[   22.310] script succeeded: result was [0.0]

五、常见误区与复盘要点

• 误区一：把OTA等同于A/B升级。OTA只是分发方式，A/B是安装模型，二者不能混为一谈。
• 误区二：认为增量包一定更快。增量包下载快，但设备端patch合并可能耗时更长，且失败率更高。
• 误区三：忽略槽位元数据。A/B升级失败常源于boot_control元数据未正确更新，而非镜像本身损坏。
• 复盘要点：升级前确认源版本、分区哈希、剩余空间与电量；升级后验证槽位状态、启动计数与系统版本号。