A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Descripción general del bootloader
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Un bootloader es una imagen propiedad del proveedor responsable de iniciar el kernel en un dispositivo. El bootloader protege el estado del dispositivo y es responsable de inicializar el entorno de ejecución confiable (TEE) y vincular su raíz de confianza. El bootloader también verifica la integridad de las particiones boot y recovery antes de transferir la ejecución al kernel.
Ejemplo de flujo de bootloader
Este es un ejemplo de flujo del bootloader:
Cargar e inicializar la memoria
Verifica el dispositivo según el flujo de inicio verificado.
Verifica las particiones de inicio, incluidas boot, dtbo, init_boot y recovery, según el flujo de inicio verificado. Como parte de este paso, verifica la versión del encabezado de la imagen de arranque y analiza el encabezado según corresponda.
Si se usan actualizaciones A/B, determina el espacio actual para iniciar.
Determina si se debe iniciar el modo de recuperación. Para obtener más información, consulta Compatibilidad con actualizaciones OTA.
Carga las imágenes de arranque, como boot.img, vendor_boot.img, init_boot.img y otras imágenes de arranque de proveedores propietarios. Estas imágenes de arranque contienen las imágenes del kernel y del ramdisk.
Carga el kernel en la memoria como un objeto binario comprimido que se puede ejecutar de forma automática. El kernel se descomprime y comienza a ejecutarse en la memoria.
Carga los discos RAM y la sección bootconfig en la memoria para crear initramfs.
Funciones adicionales relacionadas con el bootloader
A continuación, se muestra una lista de funciones adicionales relacionadas con el bootloader que puedes implementar:
Superposición del árbol de dispositivos (DTO).
Una superposición de árbol de dispositivos permite que el bootloader admita diferentes configuraciones de hardware. Un DTO se compila en un BLOB de árbol de dispositivos (DTB) que usa el bootloader.
Aleatorización de direcciones virtuales de la imagen del kernel El bootloader admite la aleatoriedad de la dirección virtual en la que se carga la imagen del kernel. Para aleatorizar la dirección, establece RANDOMIZE_BASE en true en la configuración del kernel.
El bootloader debe proporcionar entropía pasando un valor u64 aleatorio en el nodo del árbol del dispositivo /chosen/kaslr-seed.
Inicio verificado. El inicio verificado permite que el bootloader se asegure de que todo el código ejecutado provenga de una fuente confiable.
Configuración de inicio
La configuración de inicio está disponible en Android 12 y versiones posteriores, y es un mecanismo para pasar detalles de configuración de la compilación y el bootloader al sistema operativo.
Antes de Android 12, se usaban parámetros de línea de comandos del kernel con el prefijo androidboot.
Actualizaciones inalámbricas (OTA). Los dispositivos Android en el campo pueden recibir e instalar actualizaciones inalámbricas del sistema, el software de apps y las reglas de zona horaria. Esta función tiene implicaciones en la implementación del bootloader. Para obtener información general sobre las actualizaciones OTA, consulta Actualizaciones OTA. Para obtener detalles sobre la implementación de OTA específica del bootloader, consulta Compatibilidad con actualizaciones OTA.
Vinculación de versión:
La vinculación de versiones vincula las claves de seguridad al sistema operativo y a la versión del nivel de parche. La vinculación de versiones garantiza que un atacante que descubra una debilidad en una versión anterior del sistema o del software de TEE no pueda revertir un dispositivo a la versión vulnerable y usar claves creadas con la versión más reciente. El bootloader debe proporcionar cierta información para admitir la vinculación de versiones. Para obtener más información, consulta Información de la versión en las propiedades AVB.
Línea de comandos del kernel
Concatena la línea de comandos del kernel desde las siguientes ubicaciones:
Línea de comandos del bootloader: Es un conjunto de parámetros estáticos y dinámicos que determina el bootloader.
Árbol de dispositivos: desde el nodo chosen/bootargs
defconfig: del CONFIG_CMDLINE
boot.img: Desde la línea de comandos (para los desplazamientos y el tamaño, consulta system/core/mkbootimg/bootimg.h).
A partir de Android 12, para los parámetros androidboot.* que debemos pasar al espacio de usuario de Android, podemos usar bootconfig en lugar de la línea de comandos del kernel.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-07-27 (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."]]
