Introduction to Android Dynamic Partitions

Android’s dynamic partitions, introduced with Project Treble, revolutionized how system updates and custom ROMs are handled. Unlike traditional fixed-size partitions (like /system, /vendor, /data), dynamic partitions allow for flexible resizing and allocation of space from a common ‘Super partition’. This flexibility is crucial for Generic System Images (GSIs), A/B updates, and custom development, providing a more robust and adaptable partitioning scheme.

This advanced guide will walk you through the process of adding new dynamic partitions to an Android device’s build system. While modern devices typically already use dynamic partitions for core components like /system, /vendor, and /product, understanding how to define and manage them allows for creating custom partitions (e.g., for specialized kernel modules, specific GSI overlays, or development purposes) or fine-tuning existing ones. We will focus on modifying the Android Open Source Project (AOSP) build configuration to achieve this, using a hypothetical ‘my_treble_overlay’ partition as an example.

Understanding the Dynamic Partitioning Scheme

Before diving into modifications, let’s briefly recap the core concepts:

• Super Partition: This is the physical partition on the device (e.g., /dev/block/by-name/super) that houses all dynamic logical partitions. Its size is fixed.
• Dynamic Logical Partitions: These are virtual partitions (e.g., system, vendor, product, odm, and any custom ones you create) that are allocated space dynamically from the Super partition.
• Partition Groups: Dynamic partitions are often organized into groups within the Super partition (e.g., qcom_dynamic_partitions, google_dynamic_partitions). These groups help manage space allocation and flashing.

The total size of all dynamic partitions within a group must not exceed the Super partition’s capacity. When defining new partitions or resizing existing ones, you’re essentially telling the AOSP build system how to allocate space within this Super partition structure.

Prerequisites

To follow this guide, you will need:

• A working AOSP build environment setup.
• The full device source code for your target Android device.
• Basic familiarity with Android’s build system and shell commands.
• A device with dynamic partitions enabled (most modern devices running Android 10+).

Step 1: Locate Device Configuration Files

The primary files we’ll modify are located in your device’s AOSP tree, typically under device/<manufacturer>/<codename>/:

• BoardConfig.mk: Defines build-time board-level configurations, including partition sizes and properties.
• device.mk: Defines product-level configurations, including which packages to include and partition details.
• fstab.<codename>: Defines how partitions are mounted at boot.

Step 2: Defining New Partitions in BoardConfig.mk

BoardConfig.mk is where you declare the existence and properties of your dynamic partitions. We’ll add a new dynamic partition called my_treble_overlay. This example will also show how to manage the explicit sizes of vendor and product if they are part of the dynamic scheme.

Navigate to device/<manufacturer>/<codename>/BoardConfig.mk and add or modify the following:

# Enable dynamic partitions if not already enabled (modern devices typically have this)1
BOARD_SUPER_PARTITION_CONTENTS := system product vendor system_ext odm my_treble_overlay

# Define the partition groups and their contents
# Adjust 'qcom_dynamic_partitions' to your device's specific group name if different.
BOARD_SUPER_PARTITION_GROUPS := qcom_dynamic_partitions
BOARD_QCOM_DYNAMIC_PARTITIONS_PARTITION_LIST := system product vendor system_ext odm my_treble_overlay

# Define the total size of the Super partition (consult your device's existing BoardConfig.mk)
# Example: 8GB super partition. Adjust this value carefully based on your device.
BOARD_SUPER_PARTITION_SIZE := 8589934592 # 8GB

# Define individual partition sizes within the Super partition.
# These sizes are *maximum* sizes. The actual size can be smaller depending on image content.
# Consult your device's existing values for system, vendor, product, etc.
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 3221225472 # 3GB
BOARD_PRODUCTIMAGE_PARTITION_SIZE := 1073741824 # 1GB
BOARD_VENDORIMAGE_PARTITION_SIZE := 1073741824 # 1GB
BOARD_SYSTEM_EXTIMAGE_PARTITION_SIZE := 536870912 # 512MB
BOARD_ODMIMAGE_PARTITION_SIZE := 268435456 # 256MB

# Define the size for our new dynamic partition
BOARD_MY_TREBLE_OVERLAYIMAGE_PARTITION_SIZE := 268435456 # 256MB

# Total allocated dynamic partition space must not exceed BOARD_SUPER_PARTITION_SIZE.
# Sum: 3GB + 1GB + 1GB + 512MB + 256MB + 256MB = 6.0GB (leaving ~2GB free in 8GB Super partition)

Important Considerations:

• BOARD_SUPER_PARTITION_SIZE: This is the total physical size of your Super partition. Do NOT change this unless you know what you are doing and are modifying your device’s partition table directly (which is extremely risky). Typically, you’ll work within the existing Super partition size.
• Partition Sizes (e.g., BOARD_VENDORIMAGE_PARTITION_SIZE): These define the maximum logical size that a partition can grow to within the Super partition. The actual image size can be smaller. Ensure the sum of all _PARTITION_SIZE definitions does not exceed BOARD_SUPER_PARTITION_SIZE.
• Partition Naming: For new partitions, follow the naming convention (e.g., BOARD_MY_TREBLE_OVERLAYIMAGE_PARTITION_SIZE corresponds to a partition named my_treble_overlay).

Step 3: Integrating Partitions into device.mk

Next, you need to inform the build system about the new partition and include any necessary files or packages for it. Open device/<manufacturer>/<codename>/device.mk.

Ensure dynamic partitions are enabled (usually already present for Treble devices):

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_FULL_TREBLE := true
# If your device is retrofit, you might also have:
# PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Now, add your new partition to the list of images to be built and packaged:

# Add your new partition to the list of product packages (or a more suitable variable)
PRODUCT_PACKAGES += 
    fs_config_my_treble_overlay # If you have a specific fs_config for it

# Define the image type and properties for the new partition
PRODUCT_COPY_FILES += 
    device/<manufacturer>/<codename>/prebuilts/my_treble_overlay/some_file.img:$(TARGET_COPY_OUT_MY_TREBLE_OVERLAY)/some_file.img

# Mount points for dynamic partitions are usually handled by fstab, 
# but you might need to specify TARGET_COPY_OUT_MY_TREBLE_OVERLAY here.
TARGET_COPY_OUT_MY_TREBLE_OVERLAY := $(PRODUCT_OUT)/my_treble_overlay

If your new partition is intended to hold custom binaries or libraries, you would define their inclusion in device.mk or an associated .mk file. For example, to include a specific binary:

PRODUCT_PACKAGES += my_custom_binary

# And define my_custom_binary somewhere, e.g., in Android.bp or another .mk file

# like this (simplified):

# my_custom_binary { src:
        
        
        

            

                
            
            

                
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 →