A deep dive into modern Android file systems and partitions.

Android divides device storage into system partitions (containing the OS) and vendor partitions (hardware-specific code). System partitions include boot, system, and (since Android 13) init_boot. Vendor partitions include vendor, odm, and related partitions. Project Treble introduced this split in Android 8–11 so that system and vendor code can be updated independently. Other partitions support updates or hold user data.

Core System Partitions

boot – Contains the Linux kernel (Generic Kernel Image, GKI) and, on older devices, the generic ramdisk.
init_boot – Introduced in Android 13. Holds the generic ramdisk separately from the kernel (moved out of boot).
system – The main system image with the Android OS and frameworks.
system_ext – Additional system resources and proprietary modules that extend the base system image.
system_dlkm – Partition for GKI kernel modules, allowing Google-signed modules to be updated independently. Mandatory for Android 13+ devices.
product – Stores product-specific libraries or modules, often for regional or carrier variants.
generic_bootloader – Holds the device-independent bootloader image.
pvmfw – For devices with protected virtualization (Android T+), this contains the Protected VM Firmware.

Vendor-Specific Partitions

vendor_boot – Contains vendor-specific boot code and a vendor ramdisk.
recovery – Holds the recovery image used during OTA updates or manual recovery mode. On A/B devices, recovery may be booted as a ramdisk instead.
misc – A small partition (≥4 KB) used by recovery/bootloader to store update flags.
vbmeta – Contains metadata for Android Verified Boot (AVB), ensuring cryptographic integrity of all partitions.
vendor – Vendor-supplied binaries, HALs, and hardware-specific code. Read-only and only updated in major releases.
vendor_dlkm – Vendor kernel modules stored separately for independent updates.
odm – Optional. OEM/SoC-specific customizations and device trees.
odm_dlkm – Kernel modules specific to the ODM partition.
radio – Optional. Baseband or modem firmware for devices with separate radio hardware.

Non-Updatable / User Data Partitions

cache – Temporary storage, typically 50–100 MB on A/B devices.
userdata – Main user data (apps, settings, media). Not affected by system OTAs.
metadata – Stores encryption metadata (keys for userdata). Unencrypted itself and wiped on factory reset.

A/B (“Seamless”) System Updates

Modern Android devices use A/B system updates, also called seamless updates. Each critical partition has two copies: Slot A and Slot B.

The device boots from the active slot while updates are applied to the inactive slot in the background.
If the update fails, the bootloader reverts to the old slot.
This reduces downtime since the update installs while the phone is in use.

The bootloader manages slot states with flags:

Bootable flag – Marks a slot as valid.
Successful flag – Set after a successful boot.
Retry count – Limits failed boots before falling back to the other slot.

Android 10 introduced virtual A/B with snapshots to speed up the update process further.

Dynamic Partitions and the Super Partition

Starting in Android 10, devices can use dynamic partitions grouped inside a super partition.

super is a physical partition that contains logical partitions such as system, vendor, product, system_ext, and odm.
Logical partitions can be resized or added during OTA updates.
This avoids wasted space and allows new partitions without manually repartitioning the flash storage.

Not all partitions can be dynamic. For example, boot, dtbo, and vbmeta remain static since they are required by the bootloader.

Benefits:

More efficient storage use (no large pre-allocated slack space).
Easier OTA updates with partition resizing.
Enables DSU (Dynamic System Updates) and GSI installation.

Generic System Images (GSI) and DSU

A Generic System Image (GSI) is a pure AOSP build meant to run on any Treble-compatible device.

Used by developers and OEMs to test compatibility with Android’s Treble interfaces.
Can be flashed onto the inactive slot or run via DSU (Dynamic System Updates).
DSU allows temporary booting into a GSI without overwriting the main OS.

This makes testing new Android versions or verifying vendor implementations much easier.

Partitioning in Android 14 and Beyond

Key changes in recent Android versions:

Android 13 introduced the init_boot partition and made system_dlkm mandatory.
Android 14+ formalized the generic_bootloader and pvmfw partitions.
Dynamic partitions are now expected on all new devices (Android 11+).
Kernel modules (system_dlkm, vendor_dlkm, odm_dlkm) are separated to allow independent updates.
Stronger integration of virtualization and modular components ensures higher security and flexibility.

Overall, Android’s partitioning has evolved to maximize modularity, resilience, and update safety. Seamless updates, dynamic resizing, and Treble compliance make the modern Android partition scheme robust for both end-users and developers.

A deep dive into modern Android file systems and partitions.

Table of contents