Compared with the traditional OTA method, the main changes of the A/B system are:
- System partition settings The
traditional method has only one set of partition
A/B. The system has two sets of partitions, called slot A and slot B. - The way to communicate with the bootloader The
traditional bootloader determines whether to enter the Android main system or the Recovery system
A/B system by reading the misc partition information. The bootloader of the A/B system determines whether to boot from slot A or slot B through specific partition information. - The compilation process of the system The
traditional method will generate boot.img and recovery.img during compilation. The ramdisk
A/B system used in the Android main system and Recovery system respectively has boot.img instead of generating a separate recovery.img - OTA update package generation method
A/B system generates OTA package tools and commands the same as traditional methods, but the format of the generated content is different
Comparison of traditional partition and A/B system partition:
A/B system partition attributes
For the slot A and slot B partitions of the A/B system, there are the following three attributes:
| Attributes | name | Features |
|---|---|---|
| active | Active partition ID of the system | This is an exclusive attribute. Only one partition of the system can be set to the active attribute. When booting, the bootloader selects the partition set to active to start |
| bootable | Partition bootable logo | Indicates that the partition contains a complete bootable system |
| successful | Partition successfully run flag | Indicates that the partition can run correctly during the last boot or the current boot |
Typical scenario of A/B system
There are four typical application scenarios (assuming that it is currently booted from B partition): In the
figure:
The currently running system (current) is represented by a green box, and the currently unused system (unused) is represented by a gray box.
The attribute identification is red, indicating that the corresponding attribute is set in this state, and the identification is gray indicating that the attribute is not set in this state or is set to the opposite attribute, such as:
”active” 表示已经设置active属性，当前为活动分区；”active” 表示没有设置active属性
“bootable” 表示已经设置bootable属性；”bootable” 表示设置为unbootable或没有设置bootable属性
“successful” 表示已经设置successful属性，”successful” 表示没有设置successful属性
Each scene is described in detail as follows:
- Normal cases (Normal cases)
The most common scenario, for example, when the device leaves the factory, partition A and partition B can be successfully booted and run correctly, so both partitions are set to bootable and successful, but because it is booted from partition B, only partition B is set to active.
- Update in progress
Partition B detects the upgrade data and upgrades in partition A. At this time, partition A is marked as unbootable, and the successful marking is cleared; partition B is still active, bootable, and successful.
- Update is complete, wait for restart (Update applied, reboot pending)
After the B partition successfully updates the A partition, the A partition is marked as bootable. In addition, since you need to boot from partition A after restarting, you also need to set partition A to active, but since partition A has not been verified to run successfully, it is not set successful; the status of partition B becomes bootable and successful, but Not active.
- Successfully booted from the new system (System rebooted into new update)
After the device restarts, the bootloader detects that the A partition is active, so it loads the A partition system. If it can run correctly after entering the A system, the A partition needs to be marked as successful. Compared with the first general scenario, both A and B systems are set to bootable and successful, but active is switched from B partition to A partition. At this point, partition B is successfully updated and switched to partition A, and the device reenters the normal scene.
A/B system related Makefile variables
There are three main types of these variables:
- Variables that A/B system must define
AB_OTA_UPDATER := true
AB_OTA_PARTITIONS := boot system vendor
BOARD_BUILD_SYSTEM_ROOT_IMAGE := true
TARGET_NO_RECOVERY := true
BOARD_USES_RECOVERY_AS_BOOT := true
PRODUCT_PACKAGES += update_engine update_verifier
- Variables that can be optionally defined in A/B system
PRODUCT_PACKAGES_DEBUG += update_engine_client
- Variables that cannot be defined by the A/B system
BOARD_RECOVERYIMAGE_PARTITION_SIZE
BOARD_CACHEIMAGE_PARTITION_SIZE
BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE
These variables are explained in detail below.
1.必须定义的变量
AB_OTA_UPDATER := true
The main switch variables of A/B system, after setting:
recovery系统内不再具有操作cache分区的功能，bootable\recovery\device.cpp；
recovery系统使用不同的方式来解析升级文件，bootable\recovery\install.cpp
Generate A/B system related META files
AB_OTA_PARTITIONS := boot system vendor
Write the upgradeable partition of the A/B system into the file $(zip_root)/META/ab_partitions.txt
BOARD_BUILD_SYSTEM_ROOT_IMAGE := true
Put the boot ramdisk in the system partition
TARGET_NO_RECOVERY := true
No longer generate recovery.img image
BOARD_USES_RECOVERY_AS_BOOT := true
Put the recovery ramdisk in the boot.img file
PRODUCT_PACKAGES += update_engine update_verifier
Compile the update_engine and update_verifier modules, and install the corresponding applications
2. Optional variables
PRODUCT_PACKAGES_DEBUG += update_engine_client
The system comes with an update_engine_client application, you can choose whether to compile and install according to your needs
3. Variables that cannot be defined
BOARD_RECOVERYIMAGE_PARTITION_SIZE
The system does not have a recovery partition, so there is no need to set the recovery partition SIZE
BOARD_CACHEIMAGE_PARTITION_SIZE
The system does not have a cache partition, so there is no need to set the size of the cache partition
BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE
The system does not have a cache partition, and there is no need to set the TYPE of the cache partition