Android OTA [Seamless] Update - Overview of OTA[A/B] Update

Introduction

Let’s accept it, We all love our devices and would like to have them updated with the latest and greatest OS/SW, However there are times when we don’t want to switch off these devices and want them to be updated in the background seamlessly and the new update to be available to us when we restart the device next time.

This also is very important factor which largely is driven by the amount of time it takes for the OS/SW to be updated.

The below is shamelessly copied from Google’s Introduction to OTA or A/B updates.

A/B (Seamless) System Updates

A/B system updates, also known as seamless updates, ensure a workable booting system remains on the disk during an over-the-air (OTA) update. This approach reduces the likelihood of an inactive device after an update, which means fewer device replacements and device reflashes at repair and warranty centers. Other commercial-grade operating systems such as ChromeOS also use A/B updates successfully.

For more information about A/B system updates and how they work, see Partition selection (slots).

A/B system updates provide the following benefits:

·         OTA updates can occur while the system is running, without interrupting the user. Users can continue to use their devices during an OTA—the only downtime during an update is when the device reboots into the updated disk partition.

·         After an update, rebooting takes no longer than a regular reboot.

·         If an OTA fails to apply (for example, because of a bad flash), the user will not be affected. The user will continue to run the old OS, and the client is free to re-attempt the update.

·         If an OTA update is applied but fails to boot, the device will reboot back into the old partition and remains usable. The client is free to re-attempt the update.

·         Any errors (such as I/O errors) affect only the unused partition set and can be retried. Such errors also become less likely because the I/O load is deliberately low to avoid degrading the user experience.

·         Updates can be streamed to A/B devices, removing the need to download the package before installing it. Streaming means it's not necessary for the user to have enough free space to store the update package on /data or /cache.

·         The cache partition is no longer used to store OTA update packages, so there is no need to ensure that the cache partition is large enough for future updates.

·         dm-verity guarantees a device will boot an uncorrupted image. If a device doesn't boot due to a bad OTA or dm-verity issue, the device can reboot into an old image. (Android Verified Boot does not require A/B updates.)

A/B Android System Overview

Let us try and understand a high level difference between the earlier style of OTA updates [Non A/B] vs A/B with respect to certain key elements

The Android device comes preloaded with two different set of SW [Partitions sets, Software, Images – Please use what you are comfortable understaning] while leaving the factory.

When upgrading, Android ensures that there is always a working system on the device to reduce the possibility of the device bricking, which is very important from the point of view of the user and the after sales maintenance also.

The Android System mainly comprises of the following important and sritical components.

·         update_engine

·         slot A : The set of software component which might be currently active

·         slot B : The set of software component which is not active and is a candidate to be updated in the next OTA session.

Let us understand some key differences between the traditional [Recovery based] vs Seamless [A/B] style of OTA updates from a high level, We will deep dive in some or all of these later

Partition Settings Changes

In the earlier traditional [Recovery based OTA], There was only one set of partitions.

In the A/B style of OTA the device now has 2 sets or slots of the images/partitions which can be upgraded.

Bootloader Interaction Changes

In the earlier traditional [Recovery based OTA], The bootloader reads the misc partition information to decide whether to enter the Android main system or Recovery system

In the A/B style of update, The system's bootloader decides if it needs to boot from slot A or slot B.

System compilation process

In the earlier traditional [Recovery based OTA], Android used to generate boot.img – Too boot the rootfs and recovery.img – used for the recovery boot.

In the A/B style of update, Android build system uses system.img which has the rootfs inside it and no longer generates the recovery.img.

Let us now see some of these in details.

Partition Changes

Non A/B Partition Layout

The partitions in the earlier recovery based OTA mode include:

• bootloader : Stores the bootloader which is used to boot Linux
• boot: Stores the Linux kernel file [zImage] of the Android main system and the ramdisk used to mount the system and other partitions
• system: Android’s main system partition, including Android system applications and library files
• vendor: The partition mainly contains some application and library files customized by the oem/manufacturer/soc.
• userdata: The partition which holds all the application data used by apps during usage.
• cache: Temporary storage of data partitions, usually used to store OTA upgrade packages
• recovery: Store the linux kernel file and ramdisk of Recovery system
• misc: Store the data that the Android main system and Recovery system communicate with the bootloader

 A/B Partition Layout

The partitions in the new A/B [Seamless] based based OTA mode include

• bootloader : Stores the bootloader which is used to boot Linux
• boot_a & boot_b : Stores the Linux kernel file [zImage] of the Android main system and the ramdisk used to mount the system and other partitions
• system_a & system_b: Android’s main system partition, including Android system applications and library files
• vendor_a & vendor_b: The partition mainly contains some application and library files customized by the oem/manufacturer/soc.
• userdata: The partition which holds all the application data used by apps during usage.
• misc: Any misc usage

 The below pictorially shows the difference in partition strategy.

 

One thing to notice and immediately complain is that the overall storage [EMMC] usage goes high, But this is the small cost to ensure best user experience and ensure the device never becomes unusable during or after update.

A/B Partition States

Even when we have 2 sets of images/partitions , There is only one which is active and the other is a candidate for being updated.

Android defines 3 states for marking the states for these slots/partitons.

Active: The active partition ID of the system is an exclusive attribute. Only one partition of the system can be set with an active attribute.

This partition information is read by bootloader before booting the system.

Bootable: The partition is bootable. The partition set to indicates that the partition contains a complete bootable system.

Successful: The partition runs successfully. The partition set to indicates that the partition can run correctly in the last startup or the current startup.

System update process overview.

The entire A/B system is upgraded in the background [Earning its name as Seamless update]. This process can be paused, restarted from where it left and all of this can happen without the user being involved.

The update operation is transparent to the user and is completed without affecting user operations upgrade.

The device can set data download, update and upgrade scenarios and strategies for example:

• Download data only when WiFi is connected
• Low battery conditions scenario
• The specific strategies depend on the settings of oem or the User preferences.

In the next tutorial we will get into deeper details on the core principals of how the update works and some key components.