The partition table: what each Android partition actually does
Almost every decision in flashing work comes down to one question: which partition am I about to write, and what is in it? Get that right and most operations become low-risk. Get it wrong and you overwrite something unique to the device.
This is the reference I keep coming back to. It is written for Qualcomm-style layouts, but the concepts carry across.
The partitions you will actually deal with
| Partition | What is in it · risk if overwritten |
|---|---|
| boot | Kernel and ramdisk. Replaceable from firmware. Safe to reflash with a matching image. |
| recovery | Stock or custom recovery. Safe, and the usual target when installing TWRP. |
| system | Android itself. Replaceable. Safe with a matching build. |
| vendor | Device-specific drivers and HALs — including the audio configuration. Comes from firmware, so replaceable, but it must match the system build. |
| userdata | Your apps and files. Wiped routinely during flashing. |
| persist | Sensor, camera and sometimes fingerprint calibration. Unique to your device. Wiping it produces faults that look like hardware failure. |
| modemst1 / modemst2 / fsg | NV storage — IMEI and RF calibration. Unique and irreplaceable. |
| misc | Small flags telling the bootloader what to do next, such as booting to recovery. Harmless in itself, but corruption here causes odd boot behaviour. |
| modem (NON-HLOS) | Modem firmware. From the package, but variant-specific. |
| vbmeta | Verified boot metadata. Determines whether modified images are accepted. |
| sbl1 / tz / rpm / aboot | The boot chain. Replaceable from firmware, but damage here is what produces a device that reaches nothing at all. |
Three entries in that table carry data that exists nowhere else: persist, the modemst group, and anything else holding calibration. Every other partition can be rebuilt from a firmware package. Those cannot.
Why the GPT itself matters most
The partition table defines where every one of the above begins and ends. It is not a partition in the ordinary sense — it is the map.
Flashing a GPT from a different device or variant repartitions your storage to someone else’s layout. Everything that was there is now at the wrong offsets, including the partitions holding data you cannot replace. This is why the GPT sits at the top of the cross-variant risk list.
It is also why dumping your own table with printgpt before you start is worth the two minutes — covered in the EDL connection guide.
A/B devices
Newer devices often have two copies of the main partitions, suffixed _a and _b. The system runs from one slot while updates install to the other, then the device switches.
For repair this means two things. Flashing to the inactive slot changes nothing until the slot switches. And a device that boots fine after a bad flash may be running the other slot rather than the one you wrote — which produces a lot of confusion if you do not know the mechanism exists.
Frequently asked questions
- Which partitions are safe to flash without a backup?
- boot, recovery, system and vendor, provided the images match your device. Those come from firmware.
- What happens if I wipe persist?
- Sensors and camera calibration go. Auto-rotate, proximity detection during calls and focus behaviour all degrade, and it looks exactly like a hardware fault.
- Can I restore persist from a firmware package?
- The package may contain a generic persist image, which gets the device running but with factory-default rather than your device’s own calibration.
- Why does my device have two of everything?
- A/B slots for seamless updates. Check which slot is active before concluding a flash did nothing.
- Is userdata the only thing wiped by a factory reset?
- Essentially yes, plus cache. Identity and calibration partitions are deliberately untouched by a normal reset.
Unsure what a partition on your device holds? Send me the name and your model. Names vary by manufacturer and some are genuinely non-obvious.