Baseline: AOSP android-14.0.0_r1. Android's boot path is a chain from platform reset code through a bootloader, a kernel, and early userspace. The diagram is a model, not a universal device recipe: the Android release, device launch level, boot-header version, A/B design, recovery design, and vendor packaging all matter. Nothing here instructs you to write an image.
Before you start#
Read What Is Android?, Programs, Memory & System Calls, ADB & a Safe Lab, and Bytes, Hex, and Trust. You should know what a process and kernel are, and how to identify your ADB target. For physical boot-image editing, this chapter is not sufficient preparation; do not use it as a flashing guide.
Learning goals#
By the end, you can describe ROM → bootloader → kernel → early userspace without mistaking it for a fixed partition sequence; distinguish physical partition, logical partition, filesystem, and directory; explain the separate purposes of boot, init_boot, vendor_boot, vbmeta, super, slots, recovery, DTB/DTBO, and bootconfig; and identify what evidence is needed before asserting the layout of one device.
The boot path and vocabulary#
- Platform reset / boot ROM
Begins at a platform-defined entry and locates the next stage.
- Bootloader stages
Initialize hardware, select a boot target, apply trust policy, and load kernel-associated data.
- Linux kernel
Establishes memory/drivers, consumes boot data, and launches early userspace.
- Android init, PID 1
Performs staged userspace setup and supervises configured services.
At reset the processor begins at a platform-defined address. Early immutable or tightly controlled code (often called boot ROM) initializes enough hardware to locate the next trusted stage. Vendor bootloader stages initialize memory and storage, choose normal boot/recovery/another target, verify the boot chain under device policy, load kernel-associated data, and transfer control. “Bootloader” is a role and can mean multiple binaries. Verified Boot establishes integrity relative to configured keys and policy; a valid signature is not a proof that the code is bug-free.
The kernel starts, initializes memory management and drivers, consumes hardware/boot parameters, mounts an early root filesystem, and launches Android init (PID 1). The bootloader can provide a device tree and command line/bootconfig. A device tree describes hardware to the kernel; it is not Android's directory tree. A DTB is a compiled device-tree blob; a DTBO is an overlay blob that augments or changes a base description. Bootconfig is a structured key-value channel for boot parameters that expands the traditional kernel command line (kernel bootconfig docs). Exact delivery and image placement vary.
Component/partition map (conditional examples, not a device specification)
- Physical backing: super
- A storage region that can back multiple dynamic logical partitions.
- Logical block device: system
- A mapped block-device region, not an ordinary directory inside super.
- Filesystem
- Structured content made available from a block device.
- Mounted directory view
- A path such as /system exposes content; pathname alone does not reveal physical packaging.
| Name/component | Typical role | What not to infer |
|---|---|---|
boot | Kernel image; older layouts may also carry a generic ramdisk. Some modern GKI layouts use it for the kernel without the generic ramdisk. | A boot name does not prove its header version or contents. |
init_boot | Generic ramdisk on supported Android 13+ launch/layout designs (generic boot). | Not present on every Android 13+ device; Android release alone does not determine layout. |
vendor_boot | Vendor boot data, commonly vendor ramdisk fragments and possibly bootconfig/DTB-related data according to header/layout (vendor boot). | It is not the same as the vendor userspace partition. |
dtbo | Device-tree overlay image on designs that use a separate partition. | Not universal; DTBO is not a replacement for the base DTB. |
recovery / recovery-in-boot design | Recovery environment or recovery boot path. Some devices share boot resources or use recovery-as-ramdisk. | A separate recovery partition is not guaranteed. |
vbmeta (and chained metadata) | AVB descriptors/metadata connecting integrity verification to protected images and rollback policy. | It is not just a checksum file, nor necessarily one standalone metadata object. |
system, vendor, product, system_ext, odm | Logical or physical filesystems carrying common platform, vendor, product, extension, and OEM-specific userspace, subject to interface contracts. | Names and split vary; directories visible at runtime need not correspond one-to-one to physical partitions. |
super | Physical backing space for dynamic logical partitions on devices using dynamic partitions. | super is not system; logical partitions are block devices, not directories. |
slot suffixes such as _a, _b | Slot-selection/update metadata may choose a bootable set of slot-aware partitions. | A/B does not mean every partition is duplicated (some have only one copy), and A/B is separate from dynamic partitioning. |
userdata | User/app data, often encrypted according to device policy. | It is not the Android system image. |
This is a role map only. A partition can be logical rather than a physical GPT entry, a device can combine or omit roles, and actual image contents depend on boot image header version and board build configuration. Android 14 documentation identifies core system/vendor partition roles, but products and launch histories differ. For real work inspect the matching device's boot header metadata, AVB chain, fstab, build configuration, and vendor documentation together.
Header version is a separate question from Android version
The boot image header describes how boot-image fields and payloads are laid out. A parser must first identify the header version, then interpret fields according to that version; never assume that offsets or ramdisk placement are stable across versions. Useful fields include header version, kernel and ramdisk sizes/locations (where represented), page size in older formats, OS version/patch metadata, header size, and references to DTB, bootconfig, or vendor ramdisk data in applicable formats. Some values live in related images or metadata rather than the boot header. The canonical AOSP guide is Boot image header; use its versioned tables rather than a random image-tool blog.
Practice#
Read-only lab: identify evidence, not a guessed layout
Prerequisites: workstation shell, Android SDK Platform-Tools, and a booted disposable emulator/Cuttlefish device you control. This lab is observation only. It does not require root, an Android source checkout, or a boot image download. Commands below run on the workstation, with the command after adb shell run on the device.
adb devices -l
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.sdk
adb shell getprop ro.boot.slot_suffix
adb shell cat /proc/cmdline
adb shell ls -l /dev/block/by-name/
Expected: one authorized device ends in device; release/API values are populated; slot suffix may be _a/_b or empty; cmdline contains kernel parameters; by-name links may be absent or restricted. Failure outputs are evidence too: no device means stop and fix the ADB connection; unauthorized means approve only your own workstation; permission denied or missing path means this build does not expose the view. Do not “fix” that by rooting or changing policy.
Write a two-column note: Observed (exact output, with sensitive identifiers removed) and Not established. ro.boot.slot_suffix is a clue, not proof of all slot contents; /proc/cmdline is not the full bootconfig/AVB record; partition symlinks do not reveal payload layout. Compare your observation with the map above and explicitly state what remains unknown. For an offline, synthetic v3 header exercise, use the self-contained fixture in Read Android Boot Images; it teaches field offsets only and is not a real image.
Bootloader fastboot runs in the bootloader environment; fastbootd is a userspace implementation used for operations such as logical-partition work. Supported operations vary. This chapter intentionally gives no flash, erase, unlock, or block-write command.
Knowledge check#
- Does Android release number alone tell you whether the device has
init_boot? Why not? - Is
superthe same assystem? What does “logical” mean here? - What can
/proc/cmdlinetell you, and what does it not establish about AVB or bootconfig? - Explain the difference between a DTB and a DTBO.
Answers#
- No. Device launch history, boot-header/layout design, and vendor configuration determine image arrangement.
- No. On dynamic-partition devices,
superis physical backing space containing logical block partitions such assystem; it is not a filesystem directory. - It exposes kernel command-line parameters. It is not a complete record of bootconfig, image contents, AVB verification, or trust policy.
- DTB is a compiled base hardware description; DTBO is an overlay applied to a base description where the platform's boot design supports it.
Checkpoint#
Submit a one-page boot flow with the ROM/bootloader/kernel/init boundary and a table with at least six image/partition roles. For each claim mark universal role, conditional example, or device evidence required. Pass if you do not infer an image map from Android version or partition name, and correctly separate super from system, DTB from DTBO, and integrity from safety. If not, revisit the component table and redo the read-only lab with the observed/not-established distinction.
Sources#
- AOSP bootloader overview and boot image header — boot flow and versioned image format.
- AOSP partitions overview, generic boot, and ramdisk partitions — partition roles and layout caveats. The ramdisk page is historical for Android 11 and lower; it directs Android 12+ readers to generic boot documentation.
- Dynamic partitions, A/B updates, and fastbootd.
- Vendor boot partitions — vendor ramdisk, DTB, and bootconfig sections in header v4.
- Kernel bootconfig — structured boot parameters that extend the kernel command line.
- Verified Boot and device-tree overlays.
- Pinned AOSP 14 init source tree.