Introduction: Unraveling Android Dynamic Partitions

Android’s dynamic partitions, introduced with Android 10, revolutionized how storage is managed on devices. Instead of fixed-size physical partitions like system, vendor, and product, dynamic partitions reside within a single logical super partition. This flexible approach allows for seamless A/B updates, efficient storage utilization, and greater customization. However, managing these dynamic partitions often involves command-line tools like lpmake and lprepair, which can be a source of frustration when errors occur during upgrades, custom ROM flashing, or system modifications.

lpmake is responsible for creating and manipulating super partition images, bundling various logical partitions into a single, flashable entity. lprepair, on the other hand, is a crucial utility designed to fix corrupted metadata within the super partition, often a lifesaver when an update goes awry or partition data becomes inconsistent. This guide delves into common errors encountered with these tools and provides expert-level debugging strategies to get your device back on track.

Common Scenarios Leading to Dynamic Partition Tool Errors

Errors with lpmake and lprepair typically manifest during critical system operations:

• Flashing Custom ROMs or Kernels: When installing a custom Android build (e.g., LineageOS) or a custom kernel, the build process or flashing script often uses lpmake to generate the necessary super image. Incompatible builds or incorrect configurations can lead to `lpmake` failures.
• Android Version Upgrades: Major Android version bumps (e.g., Android 11 to 12) sometimes require changes to partition layouts or sizes. If the upgrade process encounters an issue with existing dynamic partition metadata, `lprepair` might be needed, or `lpmake` might fail to create a new `super` image.
• Resizing Logical Partitions: Advanced users attempting to resize logical partitions (e.g., increasing system partition size for more app storage) manually or through custom scripts can easily introduce inconsistencies that trigger `lpmake` or `lprepair` errors.
• Corrupted `super` Partition Metadata: Unexpected power loss, incomplete flashes, or faulty storage can corrupt the crucial metadata residing in the `super` partition, rendering the device unbootable or leading to `lprepair` failures.

Deep Dive into `lpmake` Errors and Solutions

lpmake errors often stem from incorrect input, misconfigured device parameters, or issues with the source images.

Error Type 1: Invalid Geometry or Layout

This is one of the most common `lpmake` errors. It typically means that the partitions you’re trying to combine don’t fit into the `super` partition’s defined size, or their extents overlap, or there’s a mismatch in block sizes.

Debugging Steps:

1. Check Device-Specific Parameters: The physical size of the `super` partition and its groups are defined in your device’s build configuration (e.g., BOARD_SUPER_PARTITION_SIZE, BOARD_SUPER_PARTITION_GROUPS). You can often find these in your device’s `device.mk` or `BoardConfig.mk` files if you have access to the source, or in recovery logs during an attempted flash.
2. Inspect Existing Partitions: If your device is still bootable or can enter recovery, use `adb shell` to inspect the actual block devices and their sizes. The `by-name` symlinks are often helpful:

   adb shell ls -l /dev/block/by-name

   Look for the `super` partition and any other logical partitions you expect.

3. Verify `lpmake` Command Arguments: Ensure the `lpmake` command you are using correctly specifies the `super` partition size and the desired partition groups and their capacities. A common mistake is to specify a `super` partition size smaller than the sum of all logical partitions it’s supposed to contain, plus metadata overhead.

Solution:

Adjust your `lpmake` command or configuration to match the device’s actual `super` partition size and group definitions. Ensure that the total size of all logical partitions (system, vendor, product, etc.) does not exceed the `super` partition’s capacity, accounting for metadata. For example, if you are creating a new `super.img` with two groups, `main_a` and `main_b`:

lpmake --metadata-size 65536 --super-name super --block-size 4096 --partition-size 1073741824 --device super:1073741824 --group main_a:800000000 --group main_b:800000000 --partition system_a:readonly:400000000:main_a --image system_a=system.img --partition vendor_a:readonly:200000000:main_a --image vendor_a=vendor.img --partition product_a:readonly:100000000:main_a --image product_a=product.img --sparse --output super.img

Double-check `device`, `group`, and `partition` sizes carefully. `–super-name super` typically refers to `/dev/block/by-name/super`.

Error Type 2: Metadata/Group Errors

These errors occur when `lpmake` cannot properly define the partition groups or individual logical partitions within the `super` image. This could be due to invalid group names, incorrect capacities, or attempting to add a partition to a non-existent group.

Debugging Steps:

1. Review Group Definitions: Ensure that all `–partition` arguments reference an existing and correctly defined `–group`.
2. Check for Typographical Errors: Simple typos in group or partition names can lead to perplexing errors.

Solution:

Strictly adhere to the established partition group names (e.g., `qcom_dynamic_partitions_a`, `qcom_dynamic_partitions_b` or `main_a`, `main_b`) and ensure partition-to-group assignments are correct. If you’re adapting a build script, compare it against a known working configuration for your device.

Error Type 3: Block Device/Sparse Image Issues

Sometimes, the problem isn’t `lpmake` itself, but the input images it’s trying to process. `lpmake` expects specific formats, often sparse images.

Debugging Steps:

1. Verify Sparse Image Integrity: If your input images (e.g., `system.img`, `vendor.img`) are sparse, ensure they are not corrupted and are in the correct sparse format. You can try converting a sparse image to a raw image to inspect it:

   simg2img system.img system.raw.img

   If `simg2img` fails, your sparse image is likely corrupted.

2. Check File Paths and Permissions: Ensure `lpmake` has read access to all input image files and write access to the output directory.

Solution:

Re-generate the input sparse images from reliable sources. If you’re building from source, ensure your build environment is correctly configured to produce valid sparse images. Always confirm that `lpmake` is receiving the expected file types.

Troubleshooting `lprepair` Errors and Fixes

lprepair is designed to mend broken dynamic partition metadata. Errors here usually indicate severe corruption or a fundamental incompatibility preventing the repair.

Role of `lprepair`

When the `super` partition’s metadata gets corrupted (e.g., due to an interrupted flash, a bad update, or disk errors), the device might fail to boot, showing