Android A/B System OTA分析（三）主系统和bootloader的通信

Android从7.0开始引入新的OTA升级方式，A/B System Updates，这里将其叫做A/B系统，涉及的内容较多，分多篇对A/B系统的各个方面进行分析。本文为第三篇，主系统和bootloader的通信。

本文为洛奇看世界(guyongqiangx)原创，转载请注明出处。
文章链接：https://blog.csdn.net/guyongqiangx/article/details/72480154

Android A/B 系统基础入门系列《Android A/B 系统》已完结，文章列表：

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

Android A/B System OTA分析（二）系统image的生成

Android A/B System OTA分析（三）主系统和bootloader的通信

Android A/B System OTA分析（四）系统的启动和升级

Android A/B System OTA分析（五）客户端参数

Android A/B System OTA分析（六）如何获取 payload 的 offset 和 size

更多关于 Android OTA 升级相关文章，请参考《Android OTA 升级系列专栏文章导读》。

本文基于AOSP 7.1.1_r23 (NMF27D)代码进行分析。

1. 传统系统的沟通机制

传统方式中，Android主系统同bootloader和recovery系统通过存放于misc分区的bootloader_message结构进行通信。

struct bootloader_message {char command[32];char status[32];char recovery[768];/* The 'recovery' field used to be 1024 bytes.  It has only ever* been used to store the recovery command line, so 768 bytes* should be plenty.  We carve off the last 256 bytes to store the* stage string (for multistage packages) and possible future* expansion.*/char stage[32];char reserved[224];
};

android系统或recovery系统根据操作更新bootloader_message的command成员，并写入misc分区；
bootloader启动后读取misc分区并解析得到bootloader_message，根据command内容选择相应的操作，command可能的内容包括：
- "update-radio/hboot"
  - 指示bootloader更新firmware
- "boot-recovery"
  - 指示bootloader加载recovery系统，进入recovery mode

2. `A/B`系统的沟通机制

2.1 `boot_control`的接口定义

A/B系统中，指定了用于通信的HAL层boot_control功能的定义，但没有指定通信数据具体的存储实现，这点有别于传统方式下AOSP定义的存储于misc分区的bootloader_message结构。

HAL层的boot_control，其定义位于文件中hardware/libhardware/include/hardware/boot_control.h：

/*** Every hardware module must have a data structure named HAL_MODULE_INFO_SYM* and the fields of this data structure must begin with hw_module_t* followed by module specific information.*/
typedef struct boot_control_module {struct hw_module_t common;/** (*init)() perform any initialization tasks needed for the HAL.* This is called only once.*//* init 用于HAL初始化调用，仅启动时调用一次 */void (*init)(struct boot_control_module *module);/** (*getNumberSlots)() returns the number of available slots.* For instance, a system with a single set of partitions would return* 1, a system with A/B would return 2, A/B/C -> 3...*//* 返回系统slot分区套数，1套slot包含boot, system和vendor分区 */unsigned (*getNumberSlots)(struct boot_control_module *module);/** (*getCurrentSlot)() returns the value letting the system know* whether the current slot is A or B. The meaning of A and B is* left up to the implementer. It is assumed that if the current slot* is A, then the block devices underlying B can be accessed directly* without any risk of corruption.* The returned value is always guaranteed to be strictly less than the* value returned by getNumberSlots. Slots start at 0 and* finish at getNumberSlots() - 1*//* 返回系统当前所在的slot位置 */unsigned (*getCurrentSlot)(struct boot_control_module *module);/** (*markBootSuccessful)() marks the current slot* as having booted successfully** Returns 0 on success, -errno on error.*//* 标记当前slot为已经成功启动 */int (*markBootSuccessful)(struct boot_control_module *module);/** (*setActiveBootSlot)() marks the slot passed in parameter as* the active boot slot (see getCurrentSlot for an explanation* of the "slot" parameter). This overrides any previous call to* setSlotAsUnbootable.* Returns 0 on success, -errno on error.*//* 标记指定slot为可启动 */int (*setActiveBootSlot)(struct boot_control_module *module, unsigned slot);/** (*setSlotAsUnbootable)() marks the slot passed in parameter as* an unbootable. This can be used while updating the contents of the slot's* partitions, so that the system will not attempt to boot a known bad set up.* Returns 0 on success, -errno on error.*//* 标记指定slot为不可启动 */int (*setSlotAsUnbootable)(struct boot_control_module *module, unsigned slot);/** (*isSlotBootable)() returns if the slot passed in parameter is* bootable. Note that slots can be made unbootable by both the* bootloader and by the OS using setSlotAsUnbootable.* Returns 1 if the slot is bootable, 0 if it's not, and -errno on* error.*//* 返回指定slot是否可启动 */int (*isSlotBootable)(struct boot_control_module *module, unsigned slot);/** (*getSuffix)() returns the string suffix used by partitions that* correspond to the slot number passed in parameter. The returned string* is expected to be statically allocated and not need to be freed.* Returns NULL if slot does not match an existing slot.*//* 返回指定slot的系统分区后缀，例如“_a”/“_b”等 */const char* (*getSuffix)(struct boot_control_module *module, unsigned slot);/** (*isSlotMarkedSucessful)() returns if the slot passed in parameter has* been marked as successful using markBootSuccessful.* Returns 1 if the slot has been marked as successful, 0 if it's* not the case, and -errno on error.*//* 返回指定slot是否已经标记为成功启动 */int (*isSlotMarkedSuccessful)(struct boot_control_module *module, unsigned slot);void* reserved[31];
} boot_control_module_t;

2.2 `boot_control`的存储和功能实现

对于boot_control，AOSP仅定义了其功能接口，并没有提供具体的代码实现，各厂家根据这个头文件，自定义其存储和功能实现。

使用grep工具搜索代码中的boot_control关键字，可以发现AOSP代码里面包含了三个平台的boot_control实现：

Google平台的Brillo
Intel平台的edison
QualComm

2.2.1 `Google`平台`Brillo`的实现

AOSP代码中，system\extra\boot_control_copy 定义了bootctrl.default实现：

$ ls -lh system/extras/boot_control_copy/
total 36K
-rw-r--r-- 1 ygu users  458 Mar 31 08:50 Android.mk
-rw-r--r-- 1 ygu users  11K Mar 31 08:50 NOTICE
-rw-r--r-- 1 ygu users 7.7K Mar 31 08:50 boot_control_copy.c
-rw-r--r-- 1 ygu users 5.1K Mar 31 08:50 bootinfo.c
-rw-r--r-- 1 ygu users 2.0K Mar 31 08:50 bootinfo.h

各文件的内容如下：

bootinfo.h定义了结构体BrilloSlotInfo和BrilloBootInfo

BrilloBootInfo包含结构体BrilloBootInfo，作为boot_control的私有数据实现，定义如下：

  typedef struct BrilloSlotInfo {uint8_t bootable : 1;uint8_t reserved[3];} BrilloSlotInfo;typedef struct BrilloBootInfo {// Used by fs_mgr. Must be NUL terminated.char bootctrl_suffix[4];// Magic for identification - must be 'B', 'C', 'c' (short for// "boot_control copy" implementation).uint8_t magic[3];// Version of BrilloBootInfo struct, must be 0 or larger.uint8_t version;// Currently active slot.uint8_t active_slot;// Information about each slot.BrilloSlotInfo slot_info[2];uint8_t reserved[15];} BrilloBootInfo;

结构体BrilloBootInfo占用32字节，系统复用misc分区的bootloader_message结构体，将BrilloBootInfo存放在偏移量为864字节的成员slot_suffix[32]中，整个misc分区数据结构的框图如下：

bootinfo.c实现了对BrilloBootInfo进行存取操作的接口
- 存取操作
  - bool boot_info_load(BrilloBootInfo *out_info)
  - bool boot_info_save(BrilloBootInfo *info)
- 校验和复位操作
  - bool boot_info_validate(BrilloBootInfo* info)
  - void boot_info_reset(BrilloBootInfo* info)
- 指定分区的打开操作
  - int boot_info_open_partition(const char *name, uint64_t *out_size, int flags)

boot_control_copy.c实现了boot_control模块的功能

  /* This boot_control HAL implementation emulates A/B by copying the* contents of the boot partition of the requested slot to the boot* partition. It hence works with bootloaders that are not yet aware* of A/B. This code is only intended to be used for development.*/boot_control_module_t HAL_MODULE_INFO_SYM = {.common = {.tag                 = HARDWARE_MODULE_TAG,.module_api_version  = BOOT_CONTROL_MODULE_API_VERSION_0_1,.hal_api_version     = HARDWARE_HAL_API_VERSION,.id                  = BOOT_CONTROL_HARDWARE_MODULE_ID,.name                = "Copy Implementation of boot_control HAL",.author              = "The Android Open Source Project",.methods             = &module_methods,},.init                 = module_init,.getNumberSlots       = module_getNumberSlots,.getCurrentSlot       = module_getCurrentSlot,.markBootSuccessful   = module_markBootSuccessful,.setActiveBootSlot    = module_setActiveBootSlot,.setSlotAsUnbootable  = module_setSlotAsUnbootable,.isSlotBootable       = module_isSlotBootable,.getSuffix            = module_getSuffix,};

代码实现了boot_control_module_t模块接口的功能，这里不再对每一个函数实现进行注释，但需要特别指出的是，函数module_setActiveBootSlot内部会根据传入的slot参数将对应分区boot_X内容复制到boot分区（系统上应该存在三个分区，如boot，boot_a和boot_b），bootloader不需要改动代码去检查到底是从哪个分区启动，只管加载boot分区就好了，带来的问题就是，一旦启动失败（例如，kernel挂载system分区失败，根本没有进入Android环境），bootloader无法切换到另外一个slot。注释中也提到，这种方式不需要修改bootloader，其代码实现只是用于开发目的，最终产品不应该是这样的。

2.2.2 `Intel`平台`edison`的实现

AOSP代码中，hardware\bsp\intel\soc\common\bootctrl定义了bootctrl.edison的实现：

$ ls -lh hardware/bsp/intel/soc/common/bootctrl/
total 20K
-rw-r--r-- 1 ygu users  860 Mar 31 08:47 Android.mk
-rw-r--r-- 1 ygu users 9.1K Mar 31 08:47 bootctrl.c
-rw-r--r-- 1 ygu users 1.5K Mar 31 08:47 bootctrl.h

各文件的内容如下：

bootctrl.h定义了结构体slot_metadata_t和boot_ctrl_t

boot_ctrl_t包含结构体slot_metadata_t，作为boot_control的私有数据实现，定义如下：

  #define BOOT_CONTROL_VERSION    1typedef struct slot_metadata {uint8_t priority : 4;uint8_t tries_remaining : 3;uint8_t successful_boot : 1;} slot_metadata_t;typedef struct boot_ctrl {/* Magic for identification - '\0ABB' (Boot Contrl Magic) */uint32_t magic;/* Version of struct. */uint8_t version;/* Information about each slot. */slot_metadata_t slot_info[2];uint8_t recovery_tries_remaining;} boot_ctrl_t;

跟Brillo类似，系统复用misc分区的bootloader_message结构体，将boot_ctrl_t存放在偏移量为864字节的成员slot_suffix[32]中，整个misc分区数据结构的框图如下：

bootctrl.c实现了boot_ctrl_t存取操作和boot_control的模块功能

boot_ctrl_t存取操作
- int bootctrl_read_metadata(boot_ctrl_t *bctrl)
- int bootctrl_write_metadata(boot_ctrl_t *bctrl)

boot_control模块功能

    /* Boot Control Module implementation */boot_control_module_t HAL_MODULE_INFO_SYM = {.common = {.tag                 = HARDWARE_MODULE_TAG,.module_api_version  = BOOT_CONTROL_MODULE_API_VERSION_0_1,.hal_api_version     = HARDWARE_HAL_API_VERSION,.id                  = BOOT_CONTROL_HARDWARE_MODULE_ID,.name                = "boot_control HAL",.author              = "Intel Corporation",.methods             = &bootctrl_methods,},.init                 = bootctrl_init,.getNumberSlots       = bootctrl_get_number_slots,.getCurrentSlot       = bootctrl_get_current_slot,.markBootSuccessful   = bootctrl_mark_boot_successful,.setActiveBootSlot    = bootctrl_set_active_boot_slot,.setSlotAsUnbootable  = bootctrl_set_slot_as_unbootable,.isSlotBootable       = bootctrl_is_slot_bootable,.getSuffix            = bootctrl_get_suffix,};

由于没有bootloader的代码，所以对于如何通过结构体slot_metadata_t的成员priority和priority来选择启动哪一个slot并不清楚，无法对结构体成员的作用有更详细的说明。

值得一提的是，通过读取linux命令行参数androidboot.slot_suffix=来确定当前系统在哪一个slot上运行（见bootctrl_get_active_slot函数）。

2.2.3 `QualComm`平台的实现

AOSP代码中，hardware\qcom\bootctrl定义了bootctrl.$(TARGET_BOARD_PLATFORM)的实现（具体名字依赖于TARGET_BOARD_PLATFORM变量设定）：

$ ls -lh hardware/qcom/bootctrl/
total 28K
-rw-r--r-- 1 ygu users  944 Mar 31 08:47 Android.mk
-rw-r--r-- 1 ygu users 1.5K Mar 31 08:47 NOTICE
-rw-r--r-- 1 ygu users  19K Mar 31 08:47 boot_control.cpp

QualComm平台的实现比较特别，没有单独定义boot_control的私有数据，而是将A/B系统相关信息存放到gpt表上。
从GPT内容的第3个逻辑块LBA 2开始，依次存放的是每个GPT分区的详细信息Partition Entry，单个Partition Entry占用128个字节，从其第48个字节开始存放的是分区属性（Attribute flags）。A/B系统将每个slot分区的信息，存放到分区属性的Bit 48开始的位置上。

QualComm平台详细的A/B系统分区属性如下：

关于GPT分区的详细信息，可以参考另外一篇文章：<<博通机顶盒平台GPT分区和制作工具>>的第1部分，关于GPT的介绍。

在代码实现中比较特别的是：

统计系统中boot开头的分区数作为slot总数（见get_number_slots函数）
访问系统的属性ro.boot.slot_suffix来确定当前系统在哪一个slot上运行（见get_current_slot函数）

2.3.4 `Broadcom`机顶盒平台的实现

在Broadcom单独提供的代码中（非AOSP代码），vendor/broadcom/bcm_platform/hals/boot_control定义了bootctrl.$(TARGET_BOARD_PLATFORM)的实现（如bootctrl.bcm7252ssffdr4）：

$ ls -lh vendor/broadcom/bcm_platform/hals/boot_control/
total 20K
-rw-r--r-- 1 ygu users 1.3K Mar 30 16:09 Android.mk
-rw-r--r-- 1 ygu users  11K May  6 16:26 boot_control.cpp
-rw-r--r-- 1 ygu users 1.1K Mar 30 16:09 eio_boot.h

eio_boot.h定义了结构体eio_boot_slot和eio_boot

eio_boot包含结构体eio_boot_slot，作为boot_control的私有数据实现，定义如下：
```
  struct eio_boot_slot {char suffix[8];int  valid;int  boot_try;int  boot_ok;int  boot_fail;};struct eio_boot {int    magic;int    current;struct eio_boot_slot slot[2];};
```
结构体eio_boot的数据存放在名为eio的分区上。
Broadcom机顶盒平台eio_boot结构框图如下：

boot_control.cpp实现了eio_boot存取操作和boot_control的模块功能

  struct boot_control_module HAL_MODULE_INFO_SYM = {.common = {.tag                = HARDWARE_MODULE_TAG,.module_api_version = BOOT_CONTROL_MODULE_API_VERSION_0_1,.hal_api_version    = HARDWARE_HAL_API_VERSION,.id                 = BOOT_CONTROL_HARDWARE_MODULE_ID,.name               = "boot control hal for bcm platform",.author             = "Broadcom",.methods            = &boot_control_module_methods,.dso                = 0,.reserved           = {0}},.init                    = init,.getNumberSlots          = getNumberSlots,.getCurrentSlot          = getCurrentSlot,.markBootSuccessful      = markBootSuccessful,.setActiveBootSlot       = setActiveBootSlot,.setSlotAsUnbootable     = setSlotAsUnbootable,.isSlotBootable          = isSlotBootable,.getSuffix               = getSuffix,.isSlotMarkedSuccessful  = isSlotMarkedSuccessful,};

Broadcom平台的分区后缀名不同于常见的_a/_b，而是采用_i/_e，这里略去对函数内容的注释。

2.3 `boot_control`的测试工具

除了定义HAL层的接口外，AOSP也提供了boot_control模块调用的工具bootctl，位于：
system/extras/bootctl/bootctl.c

默认情况下，bootctl不会参与编译，可以在包含update_engine是将其添加到PRODUCT_PACKAGES，如下：

PRODUCT_PACKAGES += \update_engine \update_verifier \bootctl

bootctl工具很简单，通过命令行调用boot_control的功能接口，以下是在Broadcom参考平台上运行bootctl的例子：

bcm7252ssffdr4:/ $ su
bcm7252ssffdr4:/ # which bootctl
/system/bin/bootctl
bcm7252ssffdr4:/ # bootctl --help
bootctl - command-line wrapper for the boot_control HAL.Usage:bootctl COMMANDCommands:bootctl hal-info                       - Show info about boot_control HAL used.bootctl get-number-slots               - Prints number of slots.bootctl get-current-slot               - Prints currently running SLOT.bootctl mark-boot-successful           - Mark current slot as GOOD.bootctl set-active-boot-slot SLOT      - On next boot, load and execute SLOT.bootctl set-slot-as-unbootable SLOT    - Mark SLOT as invalid.bootctl is-slot-bootable SLOT          - Returns 0 only if SLOT is bootable.bootctl is-slot-marked-successful SLOT - Returns 0 only if SLOT is marked GOOD.bootctl get-suffix SLOT                - Prints suffix for SLOT.SLOT parameter is the zero-based slot-number.
64|bcm7252ssffdr4:/ #
64|bcm7252ssffdr4:/ # bootctl hal-info
HAL name:            boot control hal for bcm platform
HAL author:          Broadcom
HAL module version:  0.1
bcm7252ssffdr4:/ # bootctl get-number-slots
2
bcm7252ssffdr4:/ # bootctl get-current-slot
0
bcm7252ssffdr4:/ # bootctl get-suffix 0
_i
bcm7252ssffdr4:/ # bootctl get-suffix 1
_e

最后的bootctl get-suffix调用可以看到，在我的测试平台上，slot A和slot B的分区命名后缀分别为_i和_e。

基于bootctl的基础上，Android系统提供了两个基于Brillo平台的测试代码，分别位于以下路径：

system/extras/tests/bootloader
external/autotest/server/site_tests/brillo_BootLoader

后续打算写一篇博客来单独介绍如何在Android下运行这些测试例子进行单元测试。

2.4 `boot_control`的调用

2.4.1 `bootloader`读取`boot_control`私有实现的数据

设备启动后bootloader会读取boot_control私有实现的数据，来判断从哪一个slot启动，由于各家实现的私有数据结构不一样，所以无法详细说明如何解析和处理的过程。

2.4.1 `boot_control_android`调用`boot_control`

文件system/update_engine/boot_control_android.cc中，类BootControlAndroid有一个私有成员module_：

// The Android implementation of the BootControlInterface. This implementation
// uses the libhardware's boot_control HAL to access the bootloader.
class BootControlAndroid : public BootControlInterface {...private:// NOTE: There is no way to release/unload HAL implementations so// this is essentially leaked on object destruction.boot_control_module_t* module_;...
};

在BootControlAndroid的Init方法内，获取boot_control_module_t模块指针并赋值给module_成员，然后调用module_->init进行boot_control的初始化，如下：

bool BootControlAndroid::Init() {const hw_module_t* hw_module;int ret;#ifdef _UE_SIDELOAD// For update_engine_sideload, we simulate the hw_get_module() by accessing it// from the current process directly.# 对于update_engine_sideload应用，直接将HAL_MODULE_INFO_SYM转换为hw_modulehw_module = &HAL_MODULE_INFO_SYM;ret = 0;if (!hw_module ||strcmp(BOOT_CONTROL_HARDWARE_MODULE_ID, hw_module->id) != 0) {ret = -EINVAL;}
#else  // !_UE_SIDELOAD# 对于update_engine应用，通过BOOT_CONTROL_HARDWARE_MODULE_ID获取hw_moduleret = hw_get_module(BOOT_CONTROL_HARDWARE_MODULE_ID, &hw_module);
#endif  // _UE_SIDELOADif (ret != 0) {LOG(ERROR) << "Error loading boot_control HAL implementation.";return false;}# 通过hw_module得到boot_control_module_t，从而后面可以愉快地调用其各种功能实现函数module_ = reinterpret_cast<boot_control_module_t*>(const_cast<hw_module_t*>(hw_module));# 调用boot_control的init函数module_->init(module_);LOG(INFO) << "Loaded boot_control HAL "<< "'" << hw_module->name << "' "<< "version " << (hw_module->module_api_version>>8) << "."<< (hw_module->module_api_version&0xff) << " "<< "authored by '" << hw_module->author << "'.";return true;
}

初始化完成后，就可以通过module_成员来调用各种boot_control的操作了。

2.4.2 `update_verifier`调用`boot_control`

文件bootable/recovery/update_verifier/update_verifier.cpp中，获取boot_control_module_t指针，检查当前slot分区是否已经标记为successful，如果没有，则尝试verify_image并将当前slot标记为successful，具体代码如下：

int main(int argc, char** argv) {...# 直接根据名称"bootctrl"获取模块const hw_module_t* hw_module;if (hw_get_module("bootctrl", &hw_module) != 0) {SLOGE("Error getting bootctrl module.\n");return -1;}# 将"bootctrl"模块转化为"boot_control_module_t"结构体boot_control_module_t* module = reinterpret_cast<boot_control_module_t*>(const_cast<hw_module_t*>(hw_module));# 调用initmodule->init(module);# 获取当前slotunsigned current_slot = module->getCurrentSlot(module);# 检查当前slot是否标记为successfulint is_successful= module->isSlotMarkedSuccessful(module, current_slot);SLOGI("Booting slot %u: isSlotMarkedSuccessful=%d\n", current_slot, is_successful);# 如果当前slot没有标记为successful，说明当前启动可能存在问题if (is_successful == 0) {// The current slot has not booted successfully.# 检查"ro.boot.verifymode"，是否其它原因导致失败# 不是其它原因导致失败的情况下，重新调用verify_image验证...# verify_image验证成功，尝试标记当前slot为successfulint ret = module->markBootSuccessful(module);if (ret != 0) {SLOGE("Error marking booted successfully: %s\n", strerror(-ret));return -1;}SLOGI("Marked slot %u as booted successfully.\n", current_slot);}# 完成操作，退出update_verifierSLOGI("Leaving update_verifier.\n");return 0;
}

整个A/B系统中，基于boot_control的上层应用操作已经实现了，各家需要单独实现boot_control的底层操作，同时bootloader也需要配合解析boot_control的私有数据，从而选择相应的slot来启动Android系统。

3. 其它

到目前为止，我写过 Android OTA 升级相关的话题包括：

基础入门：《Android A/B 系统》系列
核心模块：《Android Update Engine 分析》系列
动态分区：《Android 动态分区》系列
虚拟 A/B：《Android 虚拟 A/B 分区》系列
升级工具：《Android OTA 相关工具》系列

更多这些关于 Android OTA 升级相关文章的内容，请参考《Android OTA 升级系列专栏文章导读》。

如果您已经订阅了动态分区和虚拟分区付费专栏，请务必加我微信，备注订阅账号，拉您进“动态分区 & 虚拟分区专栏 VIP 答疑群”。我会在方便的时候，回答大家关于 A/B 系统、动态分区、虚拟分区、各种 OTA 升级和签名的问题。

除此之外，我有一个 Android OTA 升级讨论群，里面现在有 400+ 朋友，主要讨论手机，车机，电视，机顶盒，平板等各种设备的 OTA 升级话题，如果您从事 OTA 升级工作，欢迎加群一起交流，请在加我微信时注明“Android OTA 讨论组”。此群仅限 Android OTA 开发者参与~

公众号“洛奇看世界”后台回复“wx”获取个人微信。