A/B OTA (Seamless Updates)

Seamless Updates Overview

A/B system updates, also known as seamless updates, revolutionized the Android upgrade process. By duplicating critical system partitions (like boot, system, and vendor), Android can apply an update to the inactive slot while the user continues to use the active slot.

The primary goals of A/B updates are:

• Zero User Downtime: The device only requires a standard reboot to apply the update.
• Safety and Rollback: If an update fails to boot, the bootloader automatically falls back to the previous, working slot.

The A/B Update Flow

When an update is triggered, the update_engine daemon orchestrates the process entirely in the background.

1. Slot Identification: update_engine determines the current active slot (e.g., _a) and sets the target to the inactive slot (_b).
2. Streaming and Writing: The payload is downloaded and streamed directly to the block devices of the inactive slot.
3. Post-install Scripts: Android executes any necessary post-install tasks (like DEX pre-optimization) on the inactive partition.
4. Slot Switch: The bootloader control block (BCB) is updated to mark the inactive slot as the next boot target.

Querying Slot Status via ADB

You can inspect the A/B slot status directly using the bootctl hardware abstraction layer (HAL) command line utility:

adb shell bootctl get-current-slot
adb shell bootctl get-number-slots
adb shell bootctl get-suffix 0

To view the active slot property via getprop:

adb shell getprop ro.boot.slot_suffix

Boot Control HAL (C++)

The Boot Control HAL is responsible for communicating slot switches to the bootloader. Below is a simplified representation of how AOSP defines the HAL interface (hardware/interfaces/boot/1.0/IBootControl.hal):

interface IBootControl {
    getNumberSlots() generates (uint32_t numSlots);
    getCurrentSlot() generates (Slot slot);
    markBootSuccessful() generates (CommandResult error);
    setActiveBootSlot(Slot slot) generates (CommandResult error);
    setSlotAsUnbootable(Slot slot) generates (CommandResult error);
};

Fallback on Failure

A critical feature of A/B updates is the rollback mechanism. Each slot has metadata tracking its bootability state. A newly updated slot is initially marked as unbootable until it successfully boots.

1. The system reboots into the new slot.
2. If the system boots successfully to the Android framework, the update_verifier service runs.
3. update_verifier validates that critical services are running and calls markBootSuccessful().
4. If the device panics or fails to boot multiple times (usually 3 retries), the bootloader marks the slot as unbootable and switches back to the previous active slot.