AB 系统OTA升级介绍

Ansen360

已于 2023-11-25 21:15:24 修改

阅读量1.5w

点赞数 10

分类专栏： Android # Framework 文章标签： ab系统升级流程 ab系统

于 2016-02-05 18:27:24 首次发布

本文链接：https://blog.csdn.net/qq_25804863/article/details/49868153

版权

Android 同时被 2 个专栏收录

83 篇文章 17 订阅

订阅专栏

Framework

39 篇文章 11 订阅

订阅专栏

A/B System 概述

Android从7.0开始,引入了新的OTA升级方式 A/B System Updates

A/B系统是指设备上有A和B两套可以工作的系统(用户数据只有一份,为两套系统共用),我们可以理解为一套系统分区,另外一套为备份分区.其系统版本可能一样,也可能不一样;通过升级,可以将旧版本也更新为新版本.当然,设备出厂时这两套系统肯定是一样的.

Android 7.0上传统OTA方式和新的A/B系统方式都存在,编译时只能选择其中的一种OTA方式.由于A/B系统在分区上与传统OTA的分区设计不一样,二者无法兼容,所以7.0以前的系统无法通过OTA方式升级为A/B系统.

7.0以前传统的OTA方式：
设备上有一个Android主系统和一个Recovery系统，Android主系统运行时检测是否需要升级，如果需要升级，
则将升级的数据包下载并存放到cache分区，重启系统后进入Recovery系统，并用cache分区下载好的数据更新Android主系统，
更新完成后重新启动进入Android主系统。如果更新失败，设备重启后就不能正常使用了，唯一的办法就是重新升级，直到成功为止。

而A/B系统主要由运行在Android后台的update_engine和两套分区‘slot A’和‘slot B’组成。
Android系统从其中一套分区启动，在后台运行update_engine监测升级信息并下载升级数据，
然后将数据更新到另外一套分区，写入数据完成后从更新的分区启动

与传统OTA方式相比，A/B系统的变化主要有：

1、系统的分区设置 
    传统方式只有一套分区
    A/B系统有两套分区，称为slot A和slot B
2、跟bootloader沟通的方式 
    传统方式bootloader通过读取misc分区信息来决定是进入Android主系统还是Recovery系统
    A/B系统的bootloader通过特定的分区信息来决定从slot A还是slot B启动
3、系统的编译过程 
    传统方式在编译时会生成boot.img和recovery.img分别用于Android主系统和Recovery系统的ramdisk
    A/B系统只有boot.img，而不再生成单独的recovery.img
4、OTA更新包的生成方式 
    A/B系统生成OTA包的工具和命令跟传统方式一样，但是生成内容的格式不一样了

A/B 系统更新可带来以下好处：

OTA 更新可以在系统运行期间进行，而不会打断用户。用户可以在 OTA 期间继续使用其设备。在更新期间，唯一的一次宕机发生在设备重新启动到更新后的磁盘分区时。
更新后，重新启动所用的时间不会超过常规重新启动所用的时间。
如果 OTA 无法应用（例如，因为刷机失败），用户将不会受到影响。用户将继续运行旧的操作系统，并且客户端可以重新尝试进行更新。
如果 OTA 更新已应用但无法启动，设备将重新启动回旧分区，并且仍然可以使用。客户端可以重新尝试进行更新。
任何错误（例如 I/O 错误）都只会影响未使用的分区组，并且用户可以进行重试。由于 I/O 负载被特意控制在较低水平，以免影响用户体验，因此发生此类错误的可能性也会降低。更新包可以流式传输到 A/B 设备，因此在安装之前不需要先下载更新包。流式更新意味着用户没有必要在 /data 或 /cache 上留出足够的可用空间来存储更新包。
缓存分区不再用于存储 OTA 更新包，因此无需确保缓存分区的大小要足以应对日后的更新。
dm-verity 可保证设备将使用未损坏的启动映像。如果设备因 OTA 错误或 dm-verity问题而无法启动，则可以重新启动到旧映像。（Android 验证启动不需要 A/B 更新。）

A/B 更新对 2016 Pixel 分区大小有什么影响？

OTA 系统分区

在非 A/B 系统Android设备上,闪存空间通常包含以下分区:

boot
    boot分区中包含了Linux内核和最小的根文件系统(会被加载到RAM中去).它装载了系统和其它分区,并且boot分区还被用来启动system分区中的运行环境.
system
    system分区中包含在 Android 开源项目 (AOSP)上提供源代码的系统应用和库.在正常操作期间,此分区被装载为只读分区;其内容仅在 OTA 更新期间更改.
vendor
    vendor分区中包含在 Android 开源项目 (AOSP) 上未提供源代码的系统应用和库.在正常操作期间,此分区被装载为只读分区;其内容仅在 OTA 更新期间更改.
userdata
    存储由用户安装的应用所保存的数据等.OTA 更新过程通常不会触及该分区.
cache
    几个应用使用的临时保留区域（访问此分区需要使用特殊的应用权限），用于存储下载的 OTA 更新包。其他程序也可使用该空间，但是此类文件可能会随时消失。安装某些 OTA 更新包可能会导致此分区被完全擦除。缓存还包含 OTA 更新的更新日志。
recovery
    包含第二个完整的 Linux 系统，其中包括一个内核和特殊的恢复二进制文件（该文件可读取一个软件包并使用其内容来更新其他分区）。
misc
    执行恢复操作时使用的微小分区，可在应用 OTA 更新包并重新启动设备时，隐藏某些进程的信息。

A/B系统的分区

bootloader
    存放用于引导linux的bootloader
boot_a和boot_b
    分别用于存放两套系统各自的linux kernel文件和用于挂载system和其他分区的ramdisk
system_a和system_b
    Android主系统分区，分别用于存放两套系统各自的系统应用程序和库文件
vendor_a和vendor_b
    Android主系统分区， 分别用于存放两套系统各自的开发厂商定制的一些应用和库文件，很多时候开发厂商也直接将这个分区的内容直接放入system分区
userdata
    用户数据分区，存放用户数据，包括用户安装的应用程序和使用时生成的数据
misc或其他名字分区
    存放Android主系统和Recovery系统跟bootloader通信的数据，由于存放方式和分区名字没有强制要求，所以部分实现上保留了misc分区（代码中可见Brillo和Intel的平台），另外部分实现采用其他分区存放数据（Broadcom机顶盒平台采用名为eio的分区）。

两者区别为: A/B系统boot,system和vendor分区从传统的一套变为两套,叫做slot A和slot B;并且不再需要cache和recovery分区,同时misc分区也不是必要的

Tips:
什么是Bootloader? 
在嵌入式操作系统中，Bootloader在操作系统内核运行之前运行，可以初始化硬件设备、建立内存空间映射图，为调用操作系统内核
准备好正确的环境。Bootloader和硬件是相关的，且厂商一般都会对bootloader加锁，这样就不能随便刷机了。 
当然bootloader也是可以解锁的，这里不得不提一下root和bootloader解锁分别是怎么一回事：root是通过内核漏洞获取最高的权
限，也就是所谓的超级用户（su,superuser），属于系统层面，root之后就可以修改system分区的数据；bootloader解锁则属于硬
件层面的解锁boot和recovery分区，解锁bootloader不会root手机

Fastboot和recovery的区别？ 
Bootloader过程中，先做一些初始化，然后根据组合键做不同的事情，这个过程内核没有加载，机器只是在按顺序执行指令。 
Fastboot：在这种模式下，可以修改手机的硬件，并且允许我们发送一些命令给Bootloader。如使用电脑刷机，则需要进入fastboot
模式，通过电脑执行命令将系统镜像刷到通过USB刷到手机中。 
Recovery：Recovery是一个小型的操作系统，并且会加载部分文件系统，这样才能从sdcard中读取升级包。

OTA 升级流程

非A/B系统OTA 更新包含以下步骤：

设备会与 OTA 服务器进行定期确认，并被告知是否有更新可用，包括更新软件包的 URL 和向用户显示的描述字符串。
将更新下载到缓存或数据分区，并根据 /system/etc/security/otacerts.zip 中的证书验证加密签名。系统提示用户安装更新。
设备重新启动进入恢复模式，引导恢复分区中的内核和系统启动，而非引导分区中的内核。
恢复分区的二进制文件由 init 启动。它会在 /cache/recovery/command 中寻找将其指向下载软件包的命令行参数。
恢复操作会根据 /res/keys （包含在恢复分区中的 RAM 磁盘的一部分）中的公钥来验证软件包的加密签名。
从软件包中提取数据，并根据需要使用该数据更新引导、系统和/或供应商分区。系统分区上其中一个新文件包含新恢复分区内容。
设备正常重启。 1.加载最新更新的引导分区，在最新更新的系统分区中装载并开始执行二进制文件。 2.作为正常启动的一部分，系统会根据所需内容（预先存储为 /system 中的一个文件）检查恢复分区的内容。二者内容不同，所以恢复分区会被所需内容重新刷写（在后续引导中，恢复分区已经包含新内容，因此无需重新刷写）。

系统更新完成！更新日志可以在 /cache/recovery/last_log.# 中找到。

A/B系统的启动:

1.手机启动后,BootLoader会去读取slot metadata,来确定从哪个slot启动
2.检查是否有可启动的分区,如果没有则,直接进入bootloader的recovery mode（即bootloader下的刷机模式）,一般是进入fastboot命令行.
3.如果有可启动的分区,则选择可启动分区中优先级最高的slot(例如,直接选择当前设置为active的分区)
4.检查所选择分区的retry count(retry count表示当前分区可以尝试启动的次数),
如果retry count等于0启动成功(启动成功的分区会标记为successful),大于0则继续尝试从当前分区启动,并且累计递减,
而小于0则将所选择分区标记为无效分区(通常设置为unbootable),然后重复第2步,查找下一个可以启动的分区
5.最后从当前slot的boot中启动Linux内核,并且挂载system和其他分区
6.Linux启动后,通过dm-verify机制校验system分区,完成后加载system分区内包含的rootfs,通过/init程序解析/init.rc脚本,完成Android系统的启动

参考内容:

Android A/B System OTA分析（一）概览

Google官方A/B 系统更新介绍