A/B Partitions (Seamless Updates) - AOSP Foundations

Before Android 7.0, installing an OS update was a frustrating experience. The phone would download the update, reboot into a special Recovery mode, and lock the user out for 15 to 20 minutes while it agonizingly overwrote the /system partition. If the battery died during this process, the phone was permanently bricked.

To drastically improve user experience and safety, Google introduced A/B Seamless Updates.

The Dual-Slot Architecture

A device that supports A/B updates possesses two complete, duplicate sets of the core operating system partitions (like boot, system, and vendor).

These duplicate sets are referred to as Slot A and Slot B.

The Userdata Partition: Note that there is only ever one userdata partition. Both slots share the exact same user data (photos, apps, databases).

# You can query which slot the device is currently running from
adb shell getprop ro.boot.slot_suffix
# Output: _a or _b

The Seamless Update Process

Assume you are currently using your phone, and the system is actively running from Slot A.

Background Download: The phone downloads the OTA update zip file while you are using it.
Background Flashing: The update_engine daemon silently flashes the new update directly to the inactive, offline partitions in Slot B. You can continue playing games or browsing the web while this happens.
Boot Control Switch: Once the flash is complete, the boot_control HAL updates a flag in the bootloader, marking Slot B as the active slot for the next boot.
Reboot: The phone prompts you to restart. It reboots exactly as fast as a normal restart, but it launches the new OS from Slot B.

Failsafe Rollback

The greatest advantage of the A/B architecture is absolute safety.

If the new update on Slot B contains a catastrophic bug that causes the device to boot loop, the bootloader is smart enough to detect the failure. After three failed boot attempts, the bootloader automatically flips the active flag back to Slot A, booting the user back into the old, perfectly functioning operating system without losing any data.

# Developers can manually force the bootloader to switch slots
fastboot set_active other
fastboot reboot

The only downside to traditional A/B architecture is the massive storage requirement. Duplicating the system and vendor partitions can easily consume 4GB to 8GB of extra physical flash storage.