Introduction: The Evolution of Android Partitioning

For years, Android devices relied on a fixed partition layout, with dedicated blocks for system, vendor, userdata, and more. This rigid structure, while straightforward, presented significant challenges for device manufacturers, update delivery, and custom ROM development. Android 10 (and later refined in Android 11) introduced a revolutionary change: Dynamic Partitions, spearheaded by the enigmatic `super` partition. This innovation fundamentally alters how system, vendor, and product images are stored and managed, bringing unprecedented flexibility and efficiency to the Android ecosystem. This guide delves deep into the architecture of Dynamic Partitions, demystifying the `super` partition and equipping you with the knowledge to navigate this modern storage paradigm.

From Fixed Layouts to Flexible Futures: Why Dynamic Partitions?

Prior to dynamic partitions, device storage was divided into several fixed-size partitions like `/system`, `/vendor`, `/product`, `/odm`, `/userdata`, and others. Even with A/B (seamless update) slots, these partitions maintained predetermined sizes. This approach led to several inefficiencies:

• Storage Waste: If the `/system` partition had 4GB allocated but the actual system image only used 3GB, 1GB of space was permanently wasted, even if `/vendor` or `/product` needed more space.
• Complex Updates: OTA updates often required specific partition sizes or complex remapping to fit new image versions, especially if a component like `system_ext` grew significantly.
• Project Treble Limitations: While Project Treble aimed for vendor independence, fixed partition sizes could still pose issues for Generic System Images (GSIs) that had different size requirements than the OEM’s stock system.

Dynamic partitions address these problems by abstracting the physical layout. Instead of fixed blocks, a single large `super` partition acts as a container for all system-related logical partitions. This virtualized approach allows partitions to be resized, added, or removed on the fly, similar to Logical Volume Management (LVM) in Linux.

Unveiling the `super` Partition: The Monolithic Container

At the heart of dynamic partitioning lies the `super` partition. Physically, `super` is a single, contiguous block of storage on the device. However, within this physical block, multiple logical partitions are created and managed. These logical partitions replace the traditional fixed partitions that were previously found directly on the disk.

Logical Partitions Within `super`

The `super` partition typically houses several key logical partitions:

• system: Contains the core Android OS framework.
• vendor: Holds device-specific hardware abstraction layers (HALs) and drivers provided by the SoC vendor.
• product: Includes OEM-specific apps and features.
• system_ext: Stores modules that extend the system partition functionality, often OEM-specific.
• odm: Original Design Manufacturer specific components.
• vbmeta_system, vbmeta_vendor: These are metadata partitions for Verified Boot, crucial for ensuring the integrity of the images within `super`.

Each of these is a logical volume residing within the `super` partition, dynamically allocated space as needed. This design means that the `/system` you interact with is no longer a direct physical block but a virtualized volume managed by the Linux kernel’s Device Mapper (`dm-verity` and `dm-linear`) and Android’s partition management tools.

Under the Hood: How Dynamic Partitions Work

The magic of dynamic partitions is orchestrated through a layer of abstraction. When a device boots, the bootloader reads the partition table, identifies the `super` partition, and then loads its metadata. This metadata, often referred to as `super_metadata`, contains a map of all logical partitions, their sizes, and their physical locations (extents) within the `super` block.

The Role of `super_metadata`

The `super_metadata` is critical. It defines the layout of all logical volumes contained within `super`. This metadata is typically stored at the beginning or end of the `super` partition itself, often duplicated for redundancy. During an OTA update, the update engine (or `fastbootd` when flashing) updates this metadata to reflect new partition sizes or layouts before writing the actual image data.

Allocation and Extents

When a logical partition needs space, it’s allocated in chunks called