Introduction to Android Dynamic Partitions

Modern Android devices, particularly those launched with Android 10 and newer, utilize Dynamic Partitions as part of Project Treble. This architecture allows for flexible resizing and updating of partitions like system, vendor, product, system_ext, and odm without requiring a full reflash. All these dynamic partitions reside within a single, larger partition known as super. This design is crucial for seamless A/B updates and reducing fragmentation across the Android ecosystem. However, this flexibility comes with a trade-off: corruption of the super partition’s metadata can render a device unbootable, often leaving it stuck in a bootloop or Fastboot mode.

Understanding the structure of the super partition is paramount for recovery. It acts as a container managed by the Logical Partition Manager (LPM) and contains logical partitions defined by metadata stored within itself. When this metadata, or the underlying logical partitions, become corrupt (e.g., due to a failed OTA update, an incorrectly flashed custom ROM, or a bad kernel), the device’s bootloader can no longer correctly map and mount the necessary partitions, leading to a bricked state.

Understanding `super` Partition Corruption

Corruption of the super partition is a critical issue that often manifests as:

• Endless bootloops, usually failing before the Android logo appears.
• Device booting directly into Fastboot mode, unable to proceed further.
• Fastboot errors like 'Failed to load/verify super partition' or 'Slot _a/b not found'.
• Inability to flash new images via Fastboot, even for individual partitions.

These issues typically arise when the partition table within the super image is malformed, or one of its constituent logical partitions is damaged in a way that prevents the device from booting correctly. Traditional methods of flashing individual `system.img` or `vendor.img` files might not work because the underlying super structure is broken.

Prerequisites for Recovery

Before attempting to rebuild and flash a new super image, ensure you have the following tools and files:

• ADB & Fastboot Tools: Latest platform-tools from Google SDK.
• Stock Firmware: The full firmware package for your specific device model and region. This is crucial for obtaining clean partition images (system.img, vendor.img, etc.) and potentially a reference super.img.
• Python: Required for various firmware extraction scripts.
• `payload-dumper-go` or `payload_extractor.py`: Tools to extract individual partition images from Google/OnePlus `payload.bin` files.
• `lpmake` utility: Essential for creating the `super` image. This is typically compiled from AOSP source or found in custom recovery builds.
• Device-specific tools (Optional): For extreme cases, Qualcomm’s QPST/QFIL (for EDL mode) or MediaTek’s SP Flash Tool might be necessary.

Obtaining `lpmake`

The lpmake utility is not typically part of the standard Android SDK platform-tools. You can usually find precompiled binaries in custom recovery project repositories (like TWRP for your device), or you may need to compile it from the AOSP source code. For convenience, it’s often included in a custom recovery’s `mkbootimg` tools or a custom kernel build environment. If you compile from AOSP, it’s found under platform/system/extras/lpmake.

Step 1: Extracting Stock Partition Images

Your primary goal is to get clean, individual partition images from your stock firmware. Most modern stock firmwares (especially for Pixel, OnePlus, Xiaomi) come as a payload.bin or a set of compressed `.img` files within a ZIP archive.

Using `payload-dumper-go` (for `payload.bin`):

Download the latest release of payload-dumper-go from its GitHub page. Then, extract your firmware’s payload.bin and run:

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

This will extract all dynamic partition images (system.img, vendor.img, product.img, system_ext.img, odm.img) into a new folder. Ensure you have all necessary images for your device.

Using `firmware_extractor.sh` (for common ZIPs):

For other device types, you might find scripts like firmware_extractor.sh (often available in XDA threads) that can unpack a firmware ZIP into individual `.img` files. Alternatively, some firmware archives contain the super.img directly, which simplifies the process.

Step 2: Preparing for `super` Image Reconstruction

Rebuilding the super image requires knowing the size allocations for each logical partition and the total size of the super partition itself. This information is typically found in:

• A healthy device’s partition table (accessible via adb shell cat /proc/partitions or lpmake --device super:0:0 --list on a healthy device with `lpmake` available).
• A super_partition_sizes.json or similar configuration file within the stock firmware.
• The rawprogram_unsparse.xml and patch.xml files from Qualcomm firmware, which specify partition sizes and offsets.

If you have a stock super.img, you can inspect its structure:

lpmake --image super.img --list

This command lists the logical partitions within the stock super.img and their sizes. Note down the total super partition size and individual partition names and sizes. Common partition names include system_a, vendor_a, product_a, odm_a, system_ext_a, etc., often with a _a or _b suffix depending on the A/B slot.

For example, a common configuration might show:

Partition: system_a (size: 2147483648, readonly)Partition: vendor_a (size: 1073741824, readonly)Partition: product_a (size: 536870912, readonly)Partition: odm_a (size: 268435456, readonly)

And a total super device size of 10737418240 bytes (10GB).

Step 3: Rebuilding the `super` Image with `lpmake`

Once you have all individual partition images and their correct sizes, you can use lpmake to create a new super.img. The syntax is critical and must accurately reflect your device’s partition layout and sizes. You need to specify the metadata size, block size, and the total size for the `super` device.

A typical `lpmake` command structure looks like this:

lpmake --metadata-size 65536 	--super-name super 	--block-size 4096 	--partition system_a:readonly:system.img 	--partition vendor_a:readonly:vendor.img 	--partition product_a:readonly:product.img 	--partition odm_a:readonly:odm.img 	--partition system_ext_a:readonly:system_ext.img 	--device super:10737418240 	--sparse 	--output super_new.img

• --metadata-size 65536: Standard metadata size for dynamic partitions. Do not change unless you have specific information.
• --super-name super: The name of the `super` device.
• --block-size 4096: Standard block size.
• --partition system_a:readonly:system.img: Defines a logical partition. Replace system_a with the correct partition name for your device/slot, and system.img with the path to your extracted image. Use readonly for system partitions, resize for data-like partitions (though typically not used when rebuilding a stock image).
• --device super:10737418240: This is the total capacity of the physical super partition in bytes. This is crucial and must match your device’s actual super partition size. (10737418240 bytes = 10GB).
• --sparse: Generates a sparse image, which is faster to flash via Fastboot.
• --output super_new.img: The name of your output file.

Important Considerations:

• Partition Names: Ensure you use the exact partition names (`system_a`, `vendor_a`, etc.) as defined by your device’s stock firmware. Incorrect names will lead to boot failures.
• Partition Sizes: The sizes of the individual `.img` files (e.g., `system.img`) are automatically accounted for by `lpmake`. The crucial size is the total --device super:SIZE_IN_BYTES.
• A/B Slots: If your device supports A/B slots, you are typically rebuilding for slot `_a`. After flashing, the device might automatically switch to slot `_b` if `_a` is marked as unbootable, or you can manually switch using `fastboot set_active a`.

Step 4: Flashing the Rebuilt `super` Image

Once super_new.img is successfully created, you can flash it to your device via Fastboot.

1. Reboot your device into Fastboot mode. (Usually by holding Volume Down + Power from off state, or via adb reboot bootloader).
2. Open a terminal or command prompt in the directory where `super_new.img` is located.
3. Execute the flash command:

   fastboot flash super super_new.img

4. After the flash completes, reboot your device:

   fastboot reboot

If the device boots successfully, congratulations! You’ve recovered your device. You might need to perform a factory reset from recovery if you encounter data-related issues or bootloops after flashing, as the `userdata` partition might be expecting a different configuration.

Troubleshooting Common Issues

• `lpmake` errors (e.g., `Failed to create super device`): Double-check the total size specified with `–device super:SIZE`. It must be large enough to accommodate all logical partitions. Also, verify that all input `.img` files exist and are correctly named.
• `fastboot` errors (e.g., `Failed to write super`): Ensure your Fastboot tools are up-to-date and your device is in the correct Fastboot mode. Sometimes, switching USB ports or cables helps. If the error persists, the physical super partition might be severely damaged, requiring EDL/Download mode flashing of a full factory image.
• Device still bootloops after flashing:
1. Verify that the correct stock images were used.
2. Try clearing `userdata` from Fastboot: fastboot erase userdata then fastboot -w (which erases userdata and cache).
3. If you have a custom recovery installed, boot into it and try flashing the full stock firmware or a custom ROM.
4. As a last resort, explore device-specific EDL (Emergency Download) or Download Mode tools to flash a complete factory image, which bypasses the standard Fastboot process.

Conclusion

Rebuilding a corrupt super partition is an advanced recovery technique that can bring a bricked Android device back to life. It requires meticulous attention to detail, especially regarding partition names and sizes, and a solid understanding of the Android dynamic partition structure. Always ensure you have reliable stock firmware and the correct tools. While challenging, successfully navigating this process offers a profound understanding of modern Android’s low-level architecture and the satisfaction of rescuing a seemingly dead device.