第一章：OTA升级概述

大家好，我是你们的老朋友。今天咱们聊聊OTA升级。

OTA，全称Over-The-Air，说白了就是「空中升级」。你想想看，手机不用连电脑，不用刷机，点一下「检查更新」就能把系统给换了——这就是OTA干的事。

我在做AOSP移植的头两年，对OTA的理解其实挺浅的。总觉得不就是把新系统包推下去，解压覆盖就完事了？后来踩了坑才知道，这里面的门道深着呢。

什么是OTA升级

OTA升级，本质上是一个增量更新过程。系统把新旧两个版本之间的差异打包成一个升级包，然后通过无线网络下发到设备上，设备在本地完成解包、校验、刷写、重启这一整套流程。

为什么要用增量？因为全量包太大了。一个完整的系统镜像动辄几个GB，用户流量扛不住，服务器带宽也扛不住。增量包通常只有几十到几百MB，用户体验好得多。

我记得第一次给客户做OTA方案时，对方产品经理问：「不就是个升级吗，搞这么复杂干嘛？」后来设备在升级过程中断电变砖了，他才明白——嗯，OTA这事儿，真不是闹着玩的。

OTA升级的三种模式

目前Android主流的OTA模式有三种：非AB模式、AB模式、虚拟AB模式。我一个个说。

1. 非AB模式（传统模式）

这是最老的方式，Android 7.0之前都在用。升级时，系统会进入Recovery模式，把新系统直接覆盖到当前分区上。

缺点很明显：升级过程中一旦断电或出错，设备就变砖了。你只能通过线刷救回来。

我曾经在一个低端平板上用过这种方案，结果测试时连续三次升级失败，最后不得不加了个「升级前备份」的逻辑。说实话，挺狼狈的。

2. AB模式（无缝升级）

Android 7.0引入的。系统有两个完整的系统分区：A槽和B槽。你在A槽正常使用时，升级包在B槽后台安装。安装完成后，下次重启自动切换到B槽。

好处是什么？

• 升级失败可以回滚到旧系统
• 用户几乎感觉不到升级过程
• 没有变砖风险

但代价也大：分区空间翻倍。对于存储空间紧张的低端设备来说，这简直是噩梦。

3. 虚拟AB模式

这是Android 13开始推的新方案。它结合了前两者的优点：

• 不需要两个完整的分区
• 只对升级过程中修改的数据块做备份
• 既节省空间，又支持回滚

说白了，虚拟AB模式就是「假装有两个分区，实际上只备份了差异部分」。这个设计很巧妙，我当初看到这个方案时，忍不住拍了一下大腿——早该这么干了！

模式	空间占用	回滚能力	推荐场景
非AB	低	无	低端设备、开发板
AB	高	强	中高端手机、平板
虚拟AB	中	强	所有设备（推荐）

OTA升级在Android系统中的位置

OTA升级不是孤立的模块，它贯穿了整个Android系统架构。我画个简单的层次图给你看：

应用层：SystemUI（显示更新通知）
        Settings（检查更新界面）
        Google Play Services（FOTA服务）

框架层：UpdateEngine（核心升级引擎）
        RecoverySystem（触发恢复模式）
        OtaPackage（解析升级包）

系统服务层：update_engine（AB模式守护进程）
           recovery（非AB模式恢复程序）
           bootctl（引导控制）

内核层：dm-verity（分区校验）
        dm-snapshot（快照支持）
        block device（块设备操作）

硬件层：eMMC/UFS存储
        BootROM（引导ROM）

你看，从用户点一下「检查更新」，到最终系统重启完成，中间经过了这么多层。每一层都可能出问题。

我记得有一次，客户反馈升级后设备无法开机。查了两天才发现，是内核层的dm-verity校验没通过——因为升级包里的签名和实际分区不匹配。这种问题，光看应用层日志是永远找不到的。

所以，做OTA移植，你得对整个系统架构有全局视野。不能只盯着某一个模块看，否则出了问题你连从哪查起都不知道。

好了，第一章就聊到这儿。下一章咱们深入讲讲升级包的生成流程，包括差分算法怎么选、签名怎么配、包结构长什么样——这些都是实战中绕不开的硬骨头。

有什么问题，欢迎在评论区留言。咱们下章见。