The vendor_boot Partition

As Android evolved its partition architecture to achieve the Generic Kernel Image (GKI), the absolute separation of generic framework code and proprietary vendor code became a strict requirement.

While the init_boot partition isolates the generic Android ramdisk, the vendor_boot partition was introduced to isolate the hardware-specific early-boot requirements.

The Need for a Vendor Ramdisk

When the Linux kernel first boots, it immediately needs access to basic storage drivers to mount the massive /system and /vendor partitions.

Historically, these proprietary storage drivers (often compiled as .ko kernel modules by the SoC vendor) were stuffed directly into the generic ramdisk inside the boot partition. This meant Google's generic ramdisk was polluted with proprietary code.

To solve this, Android introduced the Vendor Ramdisk.

Contents of vendor_boot

The vendor_boot partition contains the vendor_boot.img file, which is exclusively composed of:

1. Vendor Kernel Modules: Crucial .ko files that the kernel must load immediately to talk to the physical flash storage or display panel.
2. Device Trees (DTB): The Device Tree Blob, which provides the kernel with a rigid hardware map of the physical motherboard (e.g., where the RAM is physically located, and which pins control the LEDs).
3. Vendor Init Scripts: Proprietary init.rc scripts required to initialize specific hardware before the main OS mounts.

# Inspecting the loaded kernel modules on a running device
adb shell lsmod

The Two-Stage Ramdisk Boot

With the introduction of vendor_boot (alongside init_boot), the Android early boot sequence now involves merging two distinct ramdisks in memory.

1. The bootloader extracts the generic ramdisk (from init_boot) into RAM.
2. The bootloader extracts the vendor ramdisk (from vendor_boot) and physically overlays it on top of the generic ramdisk in memory.
3. The Linux kernel boots and mounts this combined, merged ramdisk.
4. The generic init process begins, but it now has immediate access to the vendor's storage drivers required to mount the actual physical /vendor and /system partitions.

By keeping vendor_boot strictly isolated, a user can flash a generic, updated init_boot image directly from Google, while leaving the proprietary vendor_boot image completely untouched, ensuring the hardware continues to function perfectly.

# Unpacking a vendor_boot image to see the proprietary driver layout
unpack_bootimg --boot_img vendor_boot.img --out unpacked_vendor/