Introduction to A/B Partitions and Project Treble

The Android ecosystem has continuously evolved, introducing significant architectural changes to improve update mechanisms, security, and device longevity. One such pivotal change is the adoption of A/B (Seamless) System Updates, often associated with Project Treble. Introduced with Android 7.0 Nougat and mandated for devices launching with Android 8.0 Oreo and later, A/B partitions allow for system updates to be installed in the background while the device is in use, drastically reducing downtime during reboots. Instead of a single set of system partitions (e.g., system, vendor, boot), A/B devices have two sets (system_a, system_b, vendor_a, vendor_b, boot_a, boot_b). While this enhances user experience, it introduces new complexities for custom kernel developers.

Understanding A/B Partitioning: The Core Concept

At its heart, A/B partitioning operates on the principle of having two complete sets of root partitions, designated as Slot A and Slot B. While one slot is active and running the operating system, the inactive slot can be updated. Upon the next reboot, the device switches to the newly updated slot. If the update fails or encounters issues, the device can seamlessly revert to the previously functional slot. This design prevents ‘bricking’ due to failed updates and ensures a fallback mechanism. From a kernel perspective, this means the bootloader must be aware of which slot is currently active and which boot image to load.

Key Partitions Affected by A/B

• boot_a / boot_b: Contains the kernel and ramdisk.
• system_a / system_b: The main Android OS partition.
• vendor_a / vendor_b: OEM-specific binaries and HAL implementations.
• dtbo_a / dtbo_b (Device Tree Blob Overlay): For devices using DTBO.

The crucial aspect for kernel developers is the boot partition. On non-A/B devices, a single boot.img contains the kernel and initial ramdisk. On A/B devices, you’re dealing with boot_a.img and boot_b.img, and the bootloader selects which one to use based on the active slot.

Impact on Custom Kernel Development

Custom kernel development on A/B devices requires a more nuanced approach than on traditional A-only partitioned devices. The primary challenges and considerations include:

1. Boot Image Structure and Slot Management

The boot.img on A/B devices still contains the kernel and ramdisk, but the bootloader’s logic for selecting and loading it is slot-aware. When flashing a custom kernel, developers must ensure it is applied to the correct active slot or both slots for consistency. If only one slot is updated, an OTA (Over-The-Air) update to the inactive slot could overwrite your custom kernel, or a reboot to the previously active slot might load an old kernel.

2. Ramdisk and Fstab Changes

The initial ramdisk (initramfs) contains the init process and `fstab` entries that define how various partitions are mounted. On A/B devices, the fstab entries often reference partitions generically (e.g., /dev/block/by-name/system), with the bootloader handling the slot-specific redirection (e.g., to system_a or system_b). Custom kernels that modify ramdisk content must be careful to preserve this slot-awareness.

3. Device Tree Blob (DTB/DTBO)

Many modern Android devices utilize Device Tree Blobs (DTBs) to describe hardware configurations to the kernel. On A/B devices, there might also be a dtbo (Device Tree Blob Overlay) partition. When building a custom kernel, ensuring compatibility with the correct DTB/DTBO for both slots is vital, especially if you’re making hardware-specific changes that affect device tree nodes.

4. Flashing Procedures

The standard fastboot flash boot command on A/B devices typically flashes to the currently active slot. For robust custom kernel installations, developers often need to manage both slots explicitly.

Practical Steps for Custom Kernel Builders on A/B Devices

Here’s a generalized workflow and command examples for building and flashing custom kernels on A/B devices:

1. Extracting the Stock Boot Image

Before modifying, it’s good practice to extract the stock boot image for reference.

adb reboot bootloaderfastboot getvar current-slot # To check the active slotfastboot pull boot_a.img boot_a.img # Or boot_b.img depending on current slot

Alternatively, you can extract the boot.img directly from the device’s factory image or a dumped firmware.

2. Deconstructing and Reconstructing the Boot Image

Tools like AOSP's mkbootimg or third-party utilities (e.g., AnyKernel3, Android Image Kitchen) are essential for this.

Manual Deconstruction (Conceptual):

# Assuming boot.img is your target (can be _a or _b)unmkbootimg boot.img # This creates kernel and ramdisk files

Inside the extracted ramdisk directory, you might find files like init.rc, fstab.qcom, etc. Inspect these for slot-related logic if you’re making deep changes.

Reconstruction:

After compiling your custom kernel (Image.gz for ARM, Image.gz-dtb for ARM64 with DTB embedded, or separate dtb.img), you’ll repack it with the ramdisk.

mkbootimg --kernel  --ramdisk  --cmdline "console=ttyS0,115200 rootwait androidboot.hardware=qcom androidboot.selinux=permissive" --base 0x00000000 --pagesize 4096 --output custom_boot.img

Note: The --cmdline, --base, and --pagesize arguments must match your device’s stock boot image parameters. Extract these from your stock boot.img using tools like magiskboot or bootimg_info.

3. Flashing the Custom Kernel to Both Slots

To ensure your custom kernel persists across updates or slot changes, it’s best to flash it to both slots.

adb reboot bootloader# Flash to Slot A (if not already active)fastboot set_active a # Optional, if b is activefastboot flash boot_a custom_boot.img# Flash to Slot Bfastboot set_active bfastboot flash boot_b custom_boot.img# Set active slot back to your preference or defaultfastboot set_active a # Or bfastboot reboot

Some custom recovery environments (like TWRP) can also manage A/B slot flashing more conveniently.

4. Verifying Installation

After rebooting, you can verify your kernel version:

adb shell uname -a

Or check the active slot:

adb shell getprop ro.boot.slot_suffix

Challenges and Best Practices

• OTA Compatibility: Custom kernels can break OTA updates if the update mechanism expects specific kernel properties or modifies the inactive slot in a way that conflicts with your kernel. Always back up.
• Magisk and Root: Root solutions like Magisk often modify the boot image dynamically. Understanding how Magisk patches the ramdisk is crucial if you’re integrating it with your custom kernel build process.
• Device Specifics: A/B implementation details can vary slightly between OEMs. Always consult device-specific documentation or community forums (e.g., XDA Developers) for any quirks.
• Kernel Source Matching: Ensure your custom kernel is built from source code compatible with your device’s Android version and hardware. Mismatched kernel versions can lead to boot loops or instability.
• Testing Both Slots: Thoroughly test your custom kernel by explicitly switching and booting from both Slot A and Slot B to catch any unforeseen issues.

Conclusion

A/B partitions fundamentally change how Android devices handle updates and, by extension, how custom kernels are built and installed. While they provide significant benefits for end-users, kernel developers must adapt to the dual-slot system, understanding its implications on boot image structure, ramdisk management, and flashing procedures. By meticulously following best practices and utilizing the right tools, custom kernel builders can successfully navigate the complexities of A/B partitioning, continuing to enhance and optimize the Android experience for enthusiasts.