Introduction: Navigating Android’s Dynamic Partition Revolution
The landscape of Android custom ROM development has undergone significant transformations, particularly with the advent of Android 10’s dynamic partitions and Android 11’s widespread adoption of the `super_partition` architecture. Gone are the days of static `system`, `vendor`, and `product` partitions being directly flashed; now, these are logical partitions residing within a single, larger `super_partition`. This shift, primarily driven by Google’s desire for seamless updates (A/B updates) and reduced device fragmentation, presents both challenges and opportunities for custom ROM developers. This handbook will guide you through understanding, preparing for, and successfully building custom ROMs for devices leveraging the `super_partition`.
Understanding Dynamic Partitions and super_partition
The Evolution: From Static to Dynamic
Before Android 10, each system-critical partition (`system`, `vendor`, `product`, `odm`, `oem`) occupied a fixed block of storage on the device. Flashing a new ROM often involved overwriting these individual partitions. With dynamic partitions, introduced with Project Treble and expanded upon, these partitions no longer have dedicated physical space. Instead, a large `super_partition` is created on the device’s storage, and within it, logical partitions are defined and resized dynamically during updates or flashing.
The key concept here is ‘logical’ vs. ‘physical’. The `super_partition` itself is a physical partition. Inside it, `system`, `vendor`, `product`, etc., are logical volumes managed by the Linux Device Mapper (DM-verity and DM-linear). This allows for greater flexibility, especially for A/B updates, where one set of logical partitions can be active while another is being updated in the background.
How super_partition Impacts Custom ROMs
For custom ROM development, the `super_partition` introduces several critical considerations:
- Flashing Mechanism: Traditional `fastboot flash system system.img` commands are no longer sufficient. Instead, `fastboot update` with a `full_zip` or specific `fastboot flash super ` (less common for custom ROMs) combined with `fastboot reboot fastboot` to enter `fastbootd` mode for flashing individual logical partitions is required.
- Device Tree Configuration: The device tree (`BoardConfig.mk`, `device.mk`) must correctly define the `super_partition` layout and its constituent logical partitions.
- Storage Management: Developers must ensure that their built images respect the dynamic sizing capabilities and limitations within the `super_partition`.
Setting Up Your Build Environment
Before diving into device-specific modifications, ensure you have a robust AOSP/LineageOS build environment set up. This typically involves:
- Operating System: Ubuntu 18.04 LTS or newer (e.g., 20.04 LTS, 22.04 LTS).
- Prerequisites: Install necessary packages.
sudo apt updatesudo apt install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libstdc++6 lib32ncurses5-dev x11proto-core-dev libx11-dev libgl1-mesa-dev libxml2-utils xsltproc bc rsync liblz4-tool libncurses5 libncurses5-dev
- JDK: Appropriate Java Development Kit version for your Android version. Android 11+ typically requires OpenJDK 11.
- Repo Tool: Download and configure the `repo` tool.
mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/reposudo chmod a+x ~/bin/repo
- Source Sync: Initialize and sync your chosen ROM source (e.g., LineageOS).
repo init -u https://github.com/LineageOS/android.git -b lineage-18.1 # For Android 11repo sync -j$(nproc)
Modifying Device Trees for super_partition
The core of adapting to `super_partition` lies within your device’s tree (`device//`).
BoardConfig.mk Configuration
Key variables to look for and understand in `BoardConfig.mk`:
- `BOARD_SUPER_PARTITION_SIZE`: Defines the total size of the `super_partition` on the device. This must be equal to or slightly larger than the sum of all logical partitions it will contain.
- `BOARD_SUPER_PARTITION_GROUPS`: Specifies the partition groups within `super_partition`. Typically, you’ll see `main_a` and `main_b` for A/B devices, or just `main` for non-A/B.
- `BOARD_MAIN_SIZE`: (Or `BOARD__SIZE`) The maximum size for a given partition group.
- `BOARD_MAIN_PARTITION_LIST`: Lists the logical partitions belonging to that group, e.g., `system vendor product odm`.
Example `BoardConfig.mk` snippets:
# Dynamic Partition ConfigurationBOARD_SUPER_PARTITION_SIZE := 9663676416 # Example: ~9GB (in bytes)BOARD_SUPER_PARTITION_GROUPS := main_a main_bBOARD_MAIN_A_SIZE := $(BOARD_SUPER_PARTITION_SIZE)BOARD_MAIN_B_SIZE := $(BOARD_SUPER_PARTITION_SIZE)BOARD_MAIN_PARTITION_LIST := system vendor product odm# Inherit from a common dynamic partition configuration (if available)TARGET_BOARD_INFO_FILE := build/make/target/board/AndroidBoard.mk
device.mk Configuration
In `device.mk`, you’ll define the individual sizes of the logical partitions within the super group. These sizes are *minimum* required sizes; the dynamic partition manager will allocate space as needed up to the `BOARD_MAIN_SIZE`.
# Inherit from dynamic partition configuration$(call inherit-product, $(SRC_TARGET_DIR)/product/product_launched_with_dynamic_partitions.mk)# Define logical partition sizesPRODUCT_USE_DYNAMIC_PARTITIONS := truePRODUCT_BUILD_SUPER_PARTITION := trueBOARD_PRODUCTIMAGE_PARTITION_SIZE := 2013265920 # 1.87GBBOARD_SYSTEMIMAGE_PARTITION_SIZE := 4294967296 # 4GBBOARD_VENDORIMAGE_PARTITION_SIZE := 1073741824 # 1GB# Optionally, configure other partitions like odm, oem, etc.
Ensure these sizes are adequately large to contain your built images but not excessively large as to waste space or exceed the `BOARD_SUPER_PARTITION_SIZE` capacity.
Building the Custom ROM
With your device tree correctly configured for dynamic partitions, the build process remains largely similar:
- Set up Environment:
source build/envsetup.sh
- Choose Device:
(replace “ with your device’s codename).lunch lineage_-userdebug
- Start Build:
mka bacon -j$(nproc)
During the build, the system will generate individual `.img` files for `system`, `vendor`, `product`, etc., as well as a `super_empty.img` (a placeholder for the super partition structure) and a `full_zip` (e.g., `lineage—-UNOFFICIAL-.zip`) containing all necessary images and flashing scripts.
Flashing Your Custom ROM
Flashing a custom ROM onto a device with `super_partition` requires a slightly different approach than older methods. You generally cannot directly flash individual `system.img`, `vendor.img` etc., to a dynamic partition group.
Recommended Method: `fastboot update`
The most reliable method is to use the `fastboot update` command with the generated ROM zip package.
- Reboot to Fastboot Mode: Power off your device, then hold Volume Down + Power (or your device’s specific key combo).
- Execute Flash Command: Navigate to your `out/target/product//` directory and run:
fastboot update <ROM_ZIP_FILE>.zip
This command intelligently handles the `super_partition` structure, first erasing the existing logical partitions and then flashing the new images within the `super_partition`. It also handles A/B slot switching if applicable.
Alternative for Individual Logical Partitions (Advanced): fastbootd
If you need to flash individual logical partitions (e.g., for development or debugging), you must use `fastbootd`.
- Reboot to Fastboot Mode: As above.
- Enter fastbootd: From fastboot mode, type:
fastboot reboot fastboot
Your device will reboot into `fastbootd`, which operates from the recovery partition and allows flashing of dynamic partitions.
- Flash Logical Partitions: Now you can flash individual images:
fastboot flash system system.imgfastboot flash vendor vendor.imgfastboot flash product product.img# ... and so on for other logical partitions
- Reboot: After flashing, reboot the device:
fastboot reboot
Always ensure your `fastboot` binary is up-to-date, preferably from the latest Android SDK Platform-Tools.
Troubleshooting Common Issues
Android Mobile Specs & Compare Directory
Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
Compare Devices Specs →