Introduction to Dynamic Partitions in Android 10+

The Android operating system has undergone significant architectural shifts over the years, aiming to enhance security, improve update mechanisms, and provide greater flexibility for device manufacturers. One of the most impactful changes introduced with Android 10 (and refined in subsequent versions) is the implementation of Dynamic Partitions. This paradigm shift moves away from the traditional, statically sized partitions like system, vendor, and product, consolidating them into a single, large logical partition called super.

For custom recovery developers, this change presents a formidable challenge. Where previously a recovery could directly mount fixed block devices, it now needs to understand and interact with the Logical Partition Manager (LPM) to correctly map and access these dynamic volumes. This article will provide a deep dive into reverse engineering Android 10+ dynamic partition layouts, offering practical insights and steps for those engaged in custom recovery (e.g., TWRP) development.

Understanding the super Partition and LPM

At the heart of dynamic partitions lies the super partition. This is a physical block device that acts as a container for all dynamically allocated partitions. Instead of having dedicated block devices for system, vendor, etc., these are now logical volumes within super. The allocation and management of these logical volumes are handled by the Logical Partition Manager (LPM), which utilizes the Linux device mapper (dm-linear and dm-verity) to create virtual block devices that the system can interact with.

Key characteristics:

• Metadata: The super partition contains metadata (metadata_v1 or metadata_v2) that describes the layout of the dynamic partitions, including their names, sizes, and groups.
• Partition Groups: Dynamic partitions are often organized into groups (e.g., qcom_dynamic_partitions) to facilitate A/B updates and management.
• A/B Support: Dynamic partitions seamlessly integrate with A/B (seamless) updates, allowing updates to be applied to an inactive slot while the device is running, significantly reducing downtime. Each dynamic partition might have _a and _b suffixes indicating the active slot.

Identifying Dynamic Partition Layout On-Device

The first step in reverse engineering is to identify the super partition on your target device. This can typically be found by examining the block device symlinks:

adb shell ls -l /dev/block/by-name | grep super

This command will usually yield an output similar to:

lrwxrwxrwx 1 root root 16 2023-10-27 10:30 super -> /dev/block/sdaX

Where sdaX (or similar, like mmcblk0pX) is the actual physical block device for the super partition.

Once identified, you can use the Android build system’s lpm_tool utility (if available on the device or compiled separately) to dump the metadata contained within the super partition. If direct access to lpm_tool on the device is not feasible, you’ll need to pull the super image and analyze it offline.

Dumping super Partition Metadata (On-Device)

If you have a rooted device with lpm_tool (often found in /system/bin or /vendor/bin), you can dump the layout directly:

adb shell lpm_tool dump /dev/block/by-name/super

An example output might look like this:

Partition 0: system_a (group: qcom_dynamic_partitions_a, attributes: 0, size: 2147483648 bytes)Partition 1: vendor_a (group: qcom_dynamic_partitions_a, attributes: 0, size: 1073741824 bytes)Partition 2: product_a (group: qcom_dynamic_partitions_a, attributes: 0, size: 536870912 bytes)Partition 3: system_b (group: qcom_dynamic_partitions_b, attributes: 0, size: 0 bytes)Partition 4: vendor_b (group: qcom_dynamic_partitions_b, attributes: 0, size: 0 bytes)

This output clearly shows the logical partitions, their respective groups (indicating A/B slots), and their current sizes. Note that partitions for the inactive slot (e.g., _b in this example) might show a size of 0 bytes if they are not currently allocated/used.

Rebuilding for Custom Recovery Development

The core challenge for custom recoveries is to parse this super metadata and dynamically create the necessary block devices that can then be mounted. A custom recovery needs to perform the following conceptual steps:

1. Locate the super partition: Identify the physical block device corresponding to super.
2. Read super metadata: Parse the metadata (either metadata_v1 or metadata_v2) to understand the logical partition layout. The format is defined in `system/core/fs_mgr/liblp/include/liblp/liblp.h` in AOSP.
3. Determine Active Slot: Identify the currently active A/B slot (usually stored in bootloader variables or `misc` partition).
4. Create Device Mapper Devices: For each active logical partition (e.g., `system_a`, `vendor_a`), use the Linux `dmsetup` utility to create a corresponding virtual block device.
5. Mount Partitions: Once the `dm` devices are created, they can be mounted as regular block devices.

Practical Steps for Offline Reverse Engineering

Step 1: Obtain a super.img

The most common way to get a super.img is from an official OTA package’s payload.bin. Tools like `payload-dumper-go` can extract `super.img` from `payload.bin`.

./payload-dumper-go -p super payload.bin

Alternatively, if your device is rooted, you can dump the `super` partition directly:

adb pull /dev/block/by-name/super super.img

Step 2: Analyze super.img Metadata

On your development machine, you can use the `lpm_tool` from the Android source tree (or a pre-compiled binary) to analyze the `super.img`.

./lpm_tool dump super.img

This will provide the same partition layout information as seen on-device, including names, sizes, and offsets within the `super` image. Pay close attention to the `extents` information, which details where each logical partition’s data resides within `super`.

Step 3: Creating Device Mapper Devices (Recovery Logic)

In a custom recovery environment (which typically runs a stripped-down Linux kernel), you would translate the parsed `lpm_tool` output into `dmsetup` commands. The `dmsetup` command creates virtual block devices based on linear mappings. For example, to create a device for `system_a`:

# Example: Assume system_a starts at offset 1024KB with size 2GB (2097152KB)dmsetup create system_a --table '0 2097152 linear /dev/block/by-name/super 2048'

Explanation of `dmsetup create`:

• `system_a`: The name of the new device mapper device (e.g., `/dev/mapper/system_a`).
• `–table ‘0 2097152 linear /dev/block/by-name/super 2048’`: This defines the mapping table.
  • `0`: The starting sector on the `dm` device.
  • `2097152`: The total number of sectors for this `dm` device (2GB / 512 bytes per sector).
  • `linear`: Specifies a linear mapping.
  • `/dev/block/by-name/super`: The underlying physical device.
  • `2048`: The starting sector on the physical device (1024KB / 512 bytes per sector).

This process needs to be repeated for every dynamic partition that the recovery needs to access (e.g., `vendor`, `product`). The `lpm_tool` output provides the exact starting sectors and lengths in bytes (which you convert to 512-byte sectors) for each extent of a logical partition.

Addressing A/B Updates in Recovery

When dealing with A/B devices, the recovery must determine the active slot (_a or _b) to correctly identify which set of dynamic partitions to map. This information is typically retrieved from the boot control block in the `misc` partition or from Android’s `boot_control` HAL. The `lpm_tool` output will clearly show partitions suffixed with `_a` or `_b`, helping the recovery logic choose the correct ones.

Conclusion

Reverse engineering Android 10+ dynamic partition layouts is a critical skill for custom recovery developers. By understanding the role of the super partition, utilizing tools like lpm_tool, and mastering the Linux `dmsetup` commands, developers can successfully adapt their recoveries to mount and interact with these modern Android storage configurations. While the initial learning curve is steeper than with static partitions, this dynamic approach offers greater flexibility and efficiency for Android updates, making it an essential component of the ecosystem to understand for any advanced system developer.