One of the most significant engineering advancements in the Android ecosystem over the past several years has been the introduction of the A/B (Seamless) System Updates feature. First introduced in Android 7.0 Nougat, this partition scheme revolutionizes the over-the-air (OTA) update process. It allows for a much safer, more reliable, and user-friendly update experience by essentially keeping a complete, redundant copy of the operating system on the device. This guide delves into the problems with the old update method and explains how the A/B partition system works its magic behind the scenes.
The Problem: The Fragility of Traditional OTA Updates
Prior to the A/B system, Android used a single set of system partitions (`/system`, `/vendor`, etc.). The traditional OTA update process, often called the “recovery update” method, was fraught with potential problems:
- Update Interruption Risk: The update was applied directly to the live system partition while the device was in a special “recovery mode.” If this process was interrupted for any reason—a dead battery, a software crash, or a corrupted download—the device could be left in an unbootable state, often referred to as being “bricked.” The user’s only recourse was often a full factory reset, leading to data loss.
- Extended Device Downtime: During the entire update process, which could take 15-20 minutes or more, the device was completely unusable. The user would be stuck staring at an “Installing system update…” screen, unable to make calls, send texts, or use any apps. This was a significant inconvenience.
- Storage Space Issues: The update package had to be downloaded to the user’s data partition, and there had to be enough free space for the system to unpack and apply the patch files, which could sometimes fail on devices with low storage.
This process was risky for the user and created support headaches for device manufacturers. A more robust and fault-tolerant solution was needed.
Introducing A/B Partitions: A Seamless and Safe Update Experience
The A/B partition system solves these problems by creating two full sets of system partitions. These sets are referred to as “slots,” typically Slot A and Slot B. At any given time, one slot is “active” and is the one the device is currently booted from. The other slot is “inactive” and can be written to in the background without affecting the running system.
The core idea is simple but powerful: updates are applied to the inactive slot while the user continues to use their device normally.
Key Advantages of the A/B System:
- Fault Tolerance: If an update fails to apply correctly to the inactive slot, it doesn’t matter. The active slot is untouched, and the device can continue to function normally. The failed update can simply be discarded.
- Seamless Updates: The update installation happens in the background as a low-priority process. The user can continue to use their phone for calls, browsing, and gaming. The only “downtime” is the few seconds it takes to reboot the device.
- Automatic Rollback: If an update is successfully installed, but the device fails to boot from the newly updated slot, the bootloader will automatically detect this failure and roll back to the previous, known-good slot. This prevents bad updates from bricking devices.
How A/B System Updates Work Internally (A Step-by-Step Breakdown)
The process involves the operating system, the update client, and the bootloader all working in concert.
Let’s assume the device is currently running on Slot A (the active slot), and a new OTA update is available.
- Update Download: The system’s update client downloads the OTA update package from the manufacturer’s server.
- Background Installation: The update daemon starts applying the update, but it directs all its write operations to the partitions in the inactive slot, Slot B. This happens as a streaming process; the update is applied block by block directly from the network to the inactive partition, meaning a large amount of free space on the data partition is not required. This process is done with low I/O priority, so it doesn’t interfere with the user’s active session.
- Post-Installation Steps: Once the update has been fully written to the partitions in Slot B, the system runs any post-installation steps on that slot, such as recompiling app code via the dex2oat process.
- Marking the Slot as Active: When everything is complete, the update daemon updates the bootloader’s flags, marking Slot B as the “active” and “bootable” slot for the next boot. Slot A is now considered the inactive slot.
- User Reboot: The user is prompted to reboot their device. This is the only interruption they experience.
- Booting into the New Slot: On reboot, the bootloader reads the updated flags and boots the device from the partitions in Slot B, which now contains the new version of Android.
- Successful Boot Confirmation: The new operating system confirms to the bootloader that the boot was successful. The bootloader then marks Slot B as definitively good. Slot A is now kept as a fallback until the next update. If the boot had failed, the bootloader would have automatically reverted to booting from Slot A.
The next time an OTA update is available, the entire process repeats in reverse, with the update being applied to the now-inactive Slot A.
A/B Partitions vs. The Traditional Recovery Method
| Feature | Traditional (Non-A/B) | A/B (Seamless) Updates |
|---|---|---|
| Number of System Partitions | One set (`system`, `vendor`, etc.). | Two sets (Slot A and Slot B). |
| Installation Environment | Device reboots into a separate recovery mode. | Installs in the background on the live, running system. |
| User Downtime | 15-20+ minutes of total unusability. | Only the time it takes to reboot (typically < 30 seconds). |
| Failure Scenario | High risk of a “bricked” device, requiring a factory reset. | Low risk. Device automatically rolls back to the previous working slot. |
| Storage Requirement | Requires significant free space on `/data`. No `/cache` partition. | Does not require space on `/data` for the update package. Recovery partition is removed. |
For more technical implementation details, the official Android Open Source Project (AOSP) documentation is the definitive source.
Frequently Asked Questions
Does the A/B partition system use more storage space?
Yes, this is the primary trade-off. Because there are two complete sets of system partitions, the space reserved for the operating system on the device’s internal storage is roughly doubled. For example, if the system partitions take up 8GB, an A/B device would reserve around 16GB. However, this is partially offset by the removal of the dedicated `/recovery` and `/cache` partitions, which are no longer needed. In an era of devices with 128GB or more of storage, this trade-off is widely considered worthwhile for the massive gain in reliability.
How do I know if my Android phone uses the A/B system?
There is no simple user-facing setting to check this. However, a reliable indicator is the update experience itself. If your phone installs a system update in the background and only requires a quick reboot at the end, it is almost certainly using the A/B seamless update system. Devices that reboot first and then show a lengthy “installing” progress bar are using the older method. All Google Pixel devices and most modern Android phones from major manufacturers have used the A/B system for several years.
Does the A/B system make it harder to install custom ROMs?
It changes the process, but doesn’t necessarily make it harder. For developers and enthusiasts in the custom ROM community (like those using LineageOS), the A/B system requires different tools and procedures. For example, instead of flashing a ROM to a `/system` partition, they must flash it to the inactive slot and then switch the active slot. Custom recoveries like TWRP have also had to adapt to this new partition layout.
What is Virtual A/B?
Virtual A/B is a newer iteration of the seamless update concept, designed to bring its benefits to devices without having to dedicate double the physical space for system partitions. It uses Android’s Dynamic Partitions and snapshotting capabilities to create an isolated, updatable instance of the system on the existing `/data` partition. It offers the same seamless update experience and rollback protection but with a much smaller storage footprint, making it easier for manufacturers to implement on a wider range of devices. It’s another step towards making the Android update process as seamless as possible, similar to the goals of Project Mainline.