Stop Ruining Partition Storage: Understanding A/B Partition Flashing
Flashing a modern Android phone the way you flashed a phone from 2016 is the fastest route to a storage mess that only shows up weeks later. The old method assumed one system partition, one recovery, and a wipe that fixed almost anything. Modern phones do not work like that. They carry two complete system slots, share one data partition, and keep a bootloader scorecard for every boot attempt. Flash the wrong slot, wipe the wrong thing, or interrupt an update at the wrong moment, and the damage hides until the next update fails or the phone refuses to fall back.
This guide explains the slot model in plain language, shows you the exact commands that reveal your slot state, and lists the five mistakes that ruin partition storage on slot devices. You will finish knowing which slot to flash, which partitions to leave alone, and what to check before every reboot.
How A/B Slots Actually Work on a Modern Android Phone
Your phone keeps two copies of the system, called slot A and slot B. Only one slot boots at a time while the other waits as a spare. When an update arrives, the phone writes it to the spare slot while you keep using the active one. A reboot then switches to the updated slot. That design makes updates safer, because a bad update can simply fall back to the previous system instead of leaving you with a dead phone.
The dual-slot update system changes the meaning of every flashing habit you learned on older phones. A system flash no longer touches “the system”. It touches one slot. A data wipe no longer touches one system. It touches the single data partition both slots share. Keep those two facts separate and most slot mistakes disappear before they happen.
What lives inside slot A and slot B
Each slot holds its own boot image, system image, and vendor image. The two slots are complete, independent copies of the running system. The bootloader decides which slot boots, and it records how many times each slot has tried to boot. A slot that fails to boot several times gets marked unbootable, and the bootloader falls back to the other slot on its own. That automatic fallback is the reason a bad update feels like a minor annoyance instead of a bricked phone.
Data lives outside the slots on a shared data partition. Both slots read the same apps, files, and settings. That sharing is efficient, and it creates a rule you must respect: a data wipe affects both slots at once, because there is only one data partition. A system flash affects only the slot you target. Confusing those two scopes is the root of most partition damage I see in support threads.
What the bootloader tracks about each slot
The bootloader keeps a small scorecard for every slot: which slot is active, whether it booted successfully, and how many boot attempts it has used. A slot that boots cleanly earns its success flag. A slot that fails repeatedly loses trust until the bootloader refuses it. This scorecard is the real control centre of the slot system, and it is the first thing to read when anything goes wrong after a flash.
Reading the slot success flags
The success flags tell you which slots the bootloader trusts right now. A slot with a success flag is a proven system. A slot without one is untested or previously failed. Before you flash anything, read both flags. If the spare slot has never booted successfully, treat it as unproven and test it before you depend on it.
Why one shared data partition changes every wipe
On an old single-partition phone, wiping data was a contained reset. On a slot phone, wiping data erases the files both slots need, while leaving the slot problem itself untouched. Wiping data to fix a slot problem destroys files that a simple slot switch would have saved. That is why the first rescue step on a slot device is always a slot switch, never a wipe.
Check Your Current Slot Before You Flash Anything
Always check the current slot before you flash. The bootloader and the system both report it, and the check takes seconds. Flashing without that check is guessing, and guessing is how a new build lands in the wrong slot while the phone keeps booting the old system.
The four fastboot commands that tell you the truth
Run these commands from a computer with fastboot available, with the phone in bootloader mode. Read the output before you change anything.
fastboot getvar current-slotfastboot getvar slot-successful:afastboot getvar slot-successful:bfastboot --set-active=aadb shell getprop ro.boot.slot_suffix
The current-slot query tells you which system runs now. The two success queries tell you which slots the bootloader trusts. The set-active command changes the active slot, and the getprop line confirms the slot suffix from inside Android. Change the active slot only when you have a reason and a fallback plan. A slot switch is reversible by switching back, so it is a safe rescue step. A slot wipe is not reversible in the same way, so treat wipe commands with far more caution.
When to flash the inactive slot
Flash a system image to the inactive slot when you want to test a new build while keeping the working system safe. If the new build fails, the bootloader falls back to the proven slot and you lose nothing but a few minutes. This is the correct way to try a new ROM or a new vendor image on a slot device, and it is the habit that separates careful flashers from people who rebuild their phones every month.
When the active slot is the right target
Flash to the active slot only when you intend to replace the running system at once and you accept the risk that a bad flash leaves you without a working system until you recover. Most owners should almost never do this. The spare slot exists precisely so you do not have to gamble the running system on an untested image.
Let Background Slot Updates Finish on Their Own Schedule
Background slot updates write to the inactive slot while you use the phone normally. Do not interrupt that process by rebooting at random or by flashing files during an update. An interrupted update can leave the inactive slot half written. The phone will still boot from the active slot, but the next update may struggle with the damaged spare, and the failure will look like a mysterious update error with no clear cause.
Why interrupting an update damages the spare slot
A half-written slot carries inconsistent images and stale metadata. The update system may refuse to overwrite it cleanly, or it may report success while leaving a slot that cannot boot. Let the update finish and let the phone reboot on its own schedule. Patience protects the spare slot for the day you truly need it, and that day usually arrives without warning.
How to test an update on the spare slot for a full day
A spare slot is a test laboratory that most owners never use deliberately. When a system update arrives, let it install to the spare slot and boot into it for a full day of normal use. Test calls, messages, and your most used apps before you accept the update as permanent. If anything breaks, switch back to the previous slot and wait for a fixed update. That deliberate test turns background updates from a passive process into an active safety practice. If the update leaves you stuck, the emergency recovery command that calms boot loop panic is the rescue order to follow, because switching slots rescues a failed update in seconds.
Shared Partitions Are the Foundation You Rarely Touch
Shared partitions hold radio firmware, bootloader code, and calibration data that both slots use. Flashing those partitions with the wrong file damages both slots at once. Update shared partitions only with files made for your exact model and region, and only when the device notes require it. A system update rarely needs a manual shared partition flash, because the update package handles shared parts itself.
Radio, bootloader and calibration data live outside the slots
The modem, the bootloader, and the calibration tables sit outside the A/B system. A bad radio flash can kill mobile signal on both slots. A bad bootloader flash can stop the phone from starting at all. That is why manual flashes of shared partitions should be rare and deliberate, never part of a routine update, and never done with a file meant for a different model.
Back up persist and modem identity before any shared flash
The persist partition and the modem identity area are small, and their loss causes lasting damage that no update can repair. A backup copied to a computer costs minutes and can save a phone that no factory image can fix. Treat shared partitions as the foundation of the house. You can repaint the rooms often, but you should rarely touch the foundation. The same caution applies before any big change, and the guide on the critical warning before flashing custom ROMs makes the same point for custom systems, because a tested fallback beats a hopeful upgrade.
Five Slot Mistakes That Ruin Partition Storage
Most slot damage comes from a small set of repeated mistakes. Learn them once and you will recognise every one of them before it costs you data.
1. Flashing a single-system image with no slot awareness
The most common mistake is flashing an old style single system image onto a slot device without slot awareness. The image lands in one slot while metadata still points elsewhere, and the phone boots an unexpected system. Use the slot aware flashing tool for your device rather than a generic raw writer. The correct tool understands slot metadata and updates the bootable flags properly.
2. Wiping data to fix a slot problem
Data wipes do not repair slot metadata, and they destroy files that a simple slot switch would have saved. Owners who respect slots will also value fixing a boot loop without wiping personal files, because slot switching is often the fastest repair in that situation.
3. Marking both slots unbootable through repeated bad flashes
Disabling the fallback by marking both slots unbootable through repeated bad flashes leaves the phone needing a full factory image restore. Avoid that state by verifying each flash before the next one. One verified flash at a time is slower than batch flashing, and it is the only pace that keeps a fallback alive.
4. Using a raw writer that skips slot metadata
A raw writer that copies bytes without updating metadata can leave a freshly flashed slot marked unbootable. The bootloader then skips your new system and boots the old one. That confusing result looks like a failed flash when the real fault is missing metadata. Always prefer the tool your device community recommends for slot devices.
5. Forcing every update onto the same slot
Keep both slots healthy by alternating them across updates rather than forcing every update onto one slot. A slot that never boots can hide a problem that appears only when you need it most. Regular alternation proves both slots boot and both hold a working system. A fallback you never tested is a rumour, not a rescue plan. Boot each slot at least once after a major update cycle, and record the slot state after every update in your maintenance note, including the active slot, the success flags, and any update error that appeared.
Frequently Asked Questions About A/B Partition Flashing
How do I know if my phone uses A and B slots?
Check the slot property on the device with adb shell getprop ro.boot.slot_suffix, or look up the device specifications for background updates. Phones from recent years usually use slots, while older phones use a single system partition with a recovery partition. The flashing method differs completely between the two designs, so confirm the design first.
Does the spare slot waste storage space?
It uses extra storage for a second system image, but that cost buys update safety and instant rollback. The spare slot does not duplicate your photos or apps, because data stays shared. The storage cost is a fair price for a phone that survives a failed update, and it is far cheaper than a factory reset.
Can I delete the spare slot to free space?
No. The slot system expects both slots to exist, and deleting one breaks updates and rollback. Free space by removing media and unused apps instead. The spare slot is infrastructure, not clutter, and the automatic snapshot habit in the module that automates a system backup on every reboot complements slot notes, because a snapshot plus a slot record together describe the whole system state at a point in time.
What should I do first when an update fails?
Try the slot switch before any wipe. Switch to the previous slot, boot, and check whether the phone works normally. If it does, you have a working phone and time to investigate. Only consider a wipe after the slot switch has been tried and the problem is clearly in the shared data, not in a slot.
Your Next Step: Query Your Slot State Today
A and B partitions turn updates from a risky overwrite into a safe switch between two complete systems. Owners who check the current slot, flash to the right target, and leave shared partitions alone keep that safety intact. Owners who flash blindly trade a clever safety net for a confusing storage mess. Your concrete next step is to query your current slot and success flags today and write them down. That single note makes every future flash safer. If you ever face a failed update, try the slot switch before any wipe. For the full rescue order, continue with the emergency recovery command that calms boot loop panic as your next guide.
