The boot & init_boot Partitions

The Legacy Monolith and the Update Bottleneck

Imagine trying to update a car's steering wheel, but the manufacturer forces you to replace the entire engine along with it. Early Android architecture suffered from exactly this kind of tight coupling. The system bundled hardware components and framework components into a single file. Whenever engineers needed to update a framework utility, they had to rebuild the vendor's core kernel.

The culprit was the legacy boot.img file residing in the boot partition. This compressed binary contained two distinct pieces of software fused together. The first piece was the hardware-specific Linux kernel compiled by the silicon vendor. The second piece was the generic ramdisk containing Google's core framework scripts and the init binary.

Tip: Beginners often assume the boot partition contains the bootloader itself. The bootloader actually lives on completely separate raw storage memory, not inside the boot partition.

This architectural flaw directly violated the strict separation principles introduced in Project Treble. Engineers attempting to push a generic system update to an older device would hit a wall. They needed the framework's updated init binary to boot the new system, but that binary was permanently baked into the vendor's compiled boot.img.

The following 3-step explanation illustrates the architectural shift:

1. The legacy design forced framework and vendor code into a single file.
2. Google broke this monolith apart to separate the components.
3. This split created two distinct and isolated partitions.

Now that the boundaries are clear, we need to understand exactly what resides inside each new partition.

The Modern Architecture: boot vs init_boot

The partition split solved the update bottleneck, but it created a new structural challenge. Engineers now needed to know exactly which components belonged in which partitions to avoid bricking devices. Starting with Android 13, the rigid monolith no longer exists. Google defined strict owners for the two new partition spaces.

Inside the modern boot partition, you will find only the Generic Kernel Image. The kernel remains completely agnostic to the Android version running above it. Silicon vendors and Google maintain this partition exclusively, free from any framework code.

Meanwhile, the modern init_boot partition contains the generic ramdisk. This ramdisk houses the core init binary and the essential init.rc configuration files. The Google framework maintains this partition entirely.

You can verify this physical separation using the unpack_bootimg tool on a modern Android device. Extracting the boot.img reveals that it no longer contains a ramdisk, leaving only the raw kernel binary behind.

Common Mistake: Because init_boot contains the init binary, beginners assume it is where the device starts executing code. The bootloader still looks for and loads the boot partition first before doing anything else.

Now that the components are separated on disk, the system needs a reliable way to piece them back together in memory.

The Modern Boot Sequence in Action

A kernel cannot start the Android system without a root file system, but the generic ramdisk now lives in a completely different partition. The boot process needs a mechanism to combine these isolated parts dynamically at startup.

The following 3-step explanation outlines the boot sequence:

1. The bootloader pushes both binaries into RAM sequentially.
2. The kernel takes control and mounts the generic ramdisk.
3. The kernel executes the init process to start user-space.

This physical separation fundamentally changes how engineers flash devices during development. When updating a device, you must explicitly flash both partitions using the fastboot command-line tool.

# Flash the kernel and the generic ramdisk to their isolated partitions
fastboot flash boot boot.img
fastboot flash init_boot init_boot.img

A common mistake developers make is deploying a custom AOSP build but forgetting to flash the new init_boot image alongside the boot image.

Warning: Forgetting to flash init_boot on Android 13 or higher will cause an immediate kernel panic upon boot. The kernel will load successfully but crash when it cannot find the root file system.

Beyond fixing local flashing routines, this boot sequence enables a massive shift for the Android ecosystem at large.

The Impact: GKI and Modular Updates

Storing the ramdisk separately seems like a lot of extra engineering effort just to clean up a file structure. The real motivation was solving the Android update fragmentation crisis.

By isolating the framework code in init_boot, Google made the Generic Kernel Image practical. The GKI project aims to use a single, standardized Linux kernel across different Android devices.

Did You Know: Beginners often confuse GKI with GSI. GKI stands for Generic Kernel Image, which standardizes the core operating system kernel. GSI stands for Generic System Image, which standardizes the Android framework and user interface.

With the new architecture, Google can push an update to the core init process for millions of devices simultaneously. They no longer require companies like Qualcomm or MediaTek to recompile a single line of C code for their custom kernels. The vendor keeps their isolated boot partition, and Google updates the init_boot partition independently.

This decoupling drastically reduces the engineering cost of pushing framework updates, keeping older devices alive longer.

Shifting from a monolithic file to a modular architecture solved one of Android's biggest update bottlenecks. Separating the Generic Kernel Image from the framework ramdisk built a system that respects the boundaries of vendor hardware.

The generic ramdisk is just the framework's piece of the puzzle. If Google owns init_boot, how do vendors load their proprietary kernel modules and scripts before the system partition mounts?