A/B Slot Partitions in Fastboot: How Seamless Updates Change the Way You Flash

Most Pixel phones and a large share of other Android devices released since Android 8.0 ship with two complete copies of the OS partitions instead of one. Boot, system, and vendor each exist as a slot A and a slot B version, and the device runs from whichever slot is currently marked active. This design, officially called A/B or seamless updates, is why OTA updates install in the background while you keep using the phone, and it's also why flashing an A/B device with commands written for an older single-slot layout can silently target the wrong slot.

Why A/B Partitions Exist

Before A/B, an OTA update had to overwrite the live system partition, which meant the device was unusable during the update and, if power was lost partway through, could end up in an unbootable state with no fallback. With two slots, an update writes entirely to the inactive slot while the device keeps running normally on the active one. Once the write finishes and passes a boot verification check, the bootloader switches the active slot on the next reboot. If the new slot fails to boot a set number of times, the bootloader automatically falls back to the previous, known-good slot — this automatic fallback is the main practical benefit and the reason A/B updates are far less likely to brick a device than the single-partition scheme they replaced.

Reading Slot State

From fastboot mode, check which slot is currently active and whether the device even uses this layout:

fastboot getvar current-slot
fastboot getvar slot-count

A slot-count of 1 means the device is single-partition and none of this applies. A slot-count of 2 confirms A/B, and current-slot reports either a or b. From a running system rather than fastboot mode, the same information is available through the property system:

adb shell getprop ro.boot.slot_suffix

This returns _a or _b, matching the partition name suffixes used internally (boot_a, boot_b, system_a, system_b, and so on).

How Flashing Targets a Slot

When you run fastboot flash boot boot.img on an A/B device without specifying a suffix, fastboot writes to whichever slot is currently active — it resolves boot to boot_a or boot_b automatically based on current-slot. This is usually what you want for normal patching, since it updates the slot the device will actually boot into next. You can also target a specific slot explicitly regardless of which one is active:

fastboot flash boot_a boot.img
fastboot flash boot_b boot.img

This matters when you're patching a boot image for root and want the change to persist across the next OTA. Google's seamless updates write the new OTA to the inactive slot, so if you only patched the currently active slot, the very next OTA lands on the untouched slot and boots unrooted — catching people off guard the first time it happens.

Switching the Active Slot Manually

Fastboot can change which slot boots next without flashing anything, which is useful for testing a change on one slot while keeping a known-good fallback on the other:

fastboot --set-active=a
fastboot --set-active=b
fastboot --set-active=other

The other shorthand switches to whichever slot isn't currently active, without needing to know which letter that is. After switching, reboot to confirm the device actually boots the new slot before making further changes — if it doesn't boot, the bootloader's automatic fallback should revert to the previous slot on its own, but confirming manually avoids relying on that as the only safety net.

How This Relates to Dynamic Partitions

A/B slotting and dynamic partitions (super.img) solve different problems and are easy to conflate. A/B controls which full copy of the OS boots and enables fallback on a failed update. Dynamic partitions control how system, vendor, and product are resized and packed inside a single super partition, replacing what used to be separate fixed-size partitions for each. A device can have A/B slots, dynamic partitions, both, or neither, depending on when it launched and which Android version it shipped with. Checking fastboot getvar super-partition-name alongside fastboot getvar slot-count tells you which combination you're dealing with before attempting a custom ROM or GSI install.

Common Mistakes on A/B Devices

• Copying flash commands from a single-slot device's guide and assuming they patch both slots — they only touch the active one unless you explicitly flash both.
• Assuming a factory image flash-all script handles slot switching correctly on every device; most official Google scripts do, but community-modified versions for other brands sometimes flash only the active slot and leave stale data on the other.
• Forgetting that unlocking the bootloader, wiping data, and A/B slot state are three independent things — switching slots doesn't unlock anything, and unlocking doesn't touch which slot is active.

Related: Dynamic Partitions and super.img: What Changed for Fastboot Flashing · fastboot getvar all: Read Device Info Before Flashing

Source: Android Open Source Project — A/B (Seamless) System Updates