Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Bootloader overview
Stay organized with collections
Save and categorize content based on your preferences.
A bootloader is a vendor-proprietary image responsible for bringing up the
kernel on a device. The bootloader guards the device state and is responsible
for initializing the Trusted Execution Environment (TEE)
and binding its root of trust. The bootloader also verifies the integrity of the
boot and recovery partitions before moving execution to the kernel.
Example bootloader flow
Here's an example bootloader flow:
Load and initialize memory.
Verify the device according to Verified Boot flow.
Verify the boot partitions, including boot, dtbo, init_boot, and
recovery, according to the Verified Boot flow. As part of this step, check the
boot image header
version and parse the header accordingly.
If A/B updates are used, determine the current slot to
boot.
Determine if recovery mode should be booted. For more
information, see
Supporting OTA Updates.
Load the boot images, such as boot.img, vendor_boot.img,
init_boot.img, and other proprietary vendor boot images. These boot images
contain the kernel and ramdisk images.
Load the kernel into memory as a self-executable compressed
binary. The kernel decompresses itself and starts executing into memory.
Load ramdisks and the bootconfig section into memory
to create initramfs.
Additional bootloader-related features
Following is a list of additional bootloader-related features that you can
implement:
Device tree overlay (DTO).
A device tree overlay lets the bootloader to
support different hardware configurations. A DTO is compiled into a device
tree blob (DTB) which is used by the bootloader.
Kernel image virtual address randomization. The bootloader supports
randomizing the virtual address at which the kernel image is loaded. To
randomize the address, set RANDOMIZE_BASE to true in the kernel config.
The bootloader must provide entropy by passing a random u64 value in the
/chosen/kaslr-seed device tree node.
Verified Boot. Verified Boot lets
the bootloader to ensure all executed code comes from a trusted source.
Boot config.
Boot config
is available in Android 12 and higher and is a mechanism for passing
configuration details from the build and bootloader to the operating system.
Prior to Android 12, kernel command-line parameters with the prefix of
androidboot are used.
Over-the-air (OTA) updates. Android devices in the field can receive and
install OTA updates to the system, app software, and
time zone rules. This feature has implications on your bootloader
implementation. For general information on OTA, see
OTA updates. For bootloader-specific OTA implementation
details, see
Supporting OTA updates.
Version binding.
Version binding binds
security keys to the operating system and patch level version. Version binding
ensures that an attacker who discovers a weakness in an old version of the
system or the TEE software can't roll a device back to the vulnerable version
and use keys created with the newer version. The bootloader must provide certain
information to support version binding. For further information, see
Version information in AVB properties.
Kernel command line
Concatenate the kernel command line from the following locations:
Bootloader command line: set of static and dynamic parameters determined by
the bootloader
Device tree: from the chosen/bootargs node
defconfig: from CONFIG_CMDLINE
boot.img: from the command line (for offsets and sized, refer to
system/core/mkbootimg/bootimg.h
As of Android 12, for androidboot.* parameters that
we need to pass to Android userspace, we can use
bootconfig instead
of the kernel command line.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-06-18 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-06-18 UTC."],[],[],null,["# Bootloader overview\n\nA *bootloader* is a vendor-proprietary image responsible for bringing up the\nkernel on a device. The bootloader guards the device state and is responsible\nfor initializing the [Trusted Execution Environment (TEE)](/docs/security/features/trusty)\nand binding its root of trust. The bootloader also verifies the integrity of the\n`boot` and `recovery` partitions before moving execution to the kernel.\n\nExample bootloader flow\n-----------------------\n\nHere's an example bootloader flow:\n\n1. Load and initialize memory.\n\n2. Verify the device according to [Verified Boot flow](/docs/security/features/verifiedboot).\n\n3. Verify the boot partitions, including `boot`, `dtbo`, `init_boot`, and\n `recovery`, according to the Verified Boot flow. As part of this step, check the\n [boot image header](/docs/core/architecture/bootloader/boot-image-header)\n version and parse the header accordingly.\n\n4. If [A/B updates](/docs/core/ota/ab) are used, determine the current slot to\n boot.\n\n5. Determine if recovery mode should be booted. For more\n information, see\n [Supporting OTA Updates](/docs/core/architecture/bootloader/updating).\n\n6. Load the boot images, such as `boot.img`, `vendor_boot.img`,\n `init_boot.img`, and other proprietary vendor boot images. These boot images\n contain the kernel and ramdisk images.\n\n 1. Load the kernel into memory as a self-executable compressed\n binary. The kernel decompresses itself and starts executing into memory.\n\n 2. Load ramdisks and the bootconfig section into memory\n to create `initramfs`.\n\nAdditional bootloader-related features\n--------------------------------------\n\nFollowing is a list of additional bootloader-related features that you can\nimplement:\n\n- *Device tree overlay (DTO).*\n A [device tree overlay](/docs/core/architecture/dto) lets the bootloader to\n support different hardware configurations. A DTO is compiled into a *device\n tree blob (DTB)* which is used by the bootloader.\n\n- *Kernel image virtual address randomization.* The bootloader supports\n randomizing the virtual address at which the kernel image is loaded. To\n randomize the address, set `RANDOMIZE_BASE` to `true` in the kernel config.\n The bootloader must provide entropy by passing a random u64 value in the\n `/chosen/kaslr-seed` device tree node.\n\n- *Verified Boot.* [Verified Boot](/docs/security/features/verifiedboot) lets\n the bootloader to ensure all executed code comes from a trusted source.\n\n- *Boot config.*\n [Boot config](/docs/core/architecture/bootloader/implementing-bootconfig)\n is available in Android 12 and higher and is a mechanism for passing\n configuration details from the build and bootloader to the operating system.\n Prior to Android 12, kernel command-line parameters with the prefix of\n `androidboot` are used.\n\n- *Over-the-air (OTA) updates.* Android devices in the field can receive and\n install OTA updates to the system, app software, and\n time zone rules. This feature has implications on your bootloader\n implementation. For general information on OTA, see\n [OTA updates](/docs/core/ota). For bootloader-specific OTA implementation\n details, see\n [Supporting OTA updates](/docs/core/architecture/bootloader/updating).\n\n- *Version binding* .\n [Version binding](/docs/security/features/keystore/version-binding) binds\n security keys to the operating system and patch level version. Version binding\n ensures that an attacker who discovers a weakness in an old version of the\n system or the TEE software can't roll a device back to the vulnerable version\n and use keys created with the newer version. The bootloader must provide certain\n information to support version binding. For further information, see\n [Version information in AVB properties](/docs/core/architecture/bootloader/version-info-avb).\n\nKernel command line\n-------------------\n\nConcatenate the kernel command line from the following locations:\n\n- Bootloader command line: set of static and dynamic parameters determined by\n the bootloader\n\n- Device tree: from the `chosen/bootargs` node\n\n- `defconfig`: from `CONFIG_CMDLINE`\n\n- `boot.img`: from the command line (for offsets and sized, refer to\n [`system/core/mkbootimg/bootimg.h`](https://android.googlesource.com/platform/system/tools/mkbootimg/+/refs/heads/android16-release/include/bootimg/bootimg.h)\n\nAs of Android 12, for `androidboot.*` parameters that\nwe need to pass to Android userspace, we can use\n[bootconfig](/docs/core/architecture/bootloader/implementing-bootconfig) instead\nof the kernel command line."]]
