A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Panoramica del bootloader
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Un bootloader è un'immagine di proprietà del fornitore responsabile dell'avvio del kernel su un dispositivo. Il bootloader protegge lo stato del dispositivo ed è responsabile dell'inizializzazione del Trusted Execution Environment (TEE) e del binding della relativa radice di attendibilità. Il bootloader verifica anche l'integrità delle partizioni boot e recovery prima di trasferire l'esecuzione al kernel.
Esempio di flusso del bootloader
Ecco un esempio di flusso del bootloader:
Carica e inizializza la memoria.
Verifica il dispositivo in base alla procedura di Avvio verificato.
Verifica le partizioni di avvio, tra cui boot, dtbo, init_boot e
recovery, in base al flusso di Avvio verificato. Nell'ambito di questo passaggio, controlla la versione dell'intestazione dell'immagine di avvio e analizza l'intestazione di conseguenza.
Se vengono utilizzati gli aggiornamenti A/B, determina lo slot corrente da avviare.
Determina se deve essere avviata la modalità di recupero. Per ulteriori informazioni, consulta la sezione Supportare gli aggiornamenti OTA.
Carica le immagini di avvio, ad esempio boot.img, vendor_boot.img,
init_boot.img e altre immagini di avvio proprietarie del fornitore. Queste immagini di avvio contengono le immagini del kernel e del ramdisk.
Carica il kernel in memoria come file binario compresso eseguibile autonomamente. Il kernel si decomprime e inizia a eseguire nella memoria.
Carica le ramdisk e la sezione bootconfig nella memoria per creare initramfs.
Funzionalità aggiuntive relative al bootloader
Di seguito è riportato un elenco di funzionalità aggiuntive relative al bootloader che puoi implementare:
Overlay dell'albero dei dispositivi (DTO).
Un overlay dell'albero del dispositivo consente al bootloader di supportare configurazioni hardware diverse. Un DTO viene compilato in un blob di albero del dispositivo (DTB) utilizzato dal bootloader.
Ransomizzazione dell'indirizzo virtuale dell'immagine del kernel. Il bootloader supporta la randomizzazione dell'indirizzo virtuale in cui viene caricata l'immagine del kernel. Per
randomizzare l'indirizzo, imposta RANDOMIZE_BASE su true nella configurazione del kernel.
Il bootloader deve fornire entropia passando un valore u64 casuale nel
/chosen/kaslr-seed nodo della struttura ad albero del dispositivo.
Avvio verificato. L'Avvio verificato consente al bootloader di assicurarsi che tutto il codice eseguito provenga da una fonte attendibile.
Configurazione di avvio
Boot config è disponibile in Android 12 e versioni successive ed è un meccanismo per trasmettere i dettagli di configurazione dalla build e dal bootloader al sistema operativo.
Prima di Android 12, vengono utilizzati i parametri della riga di comando del kernel con il prefisso androidboot.
Aggiornamenti over-the-air (OTA). I dispositivi Android sul campo possono ricevere e installare aggiornamenti OTA per il sistema, il software delle app e le regole relative ai fusi orari. Questa funzionalità ha implicazioni sull'implementazione del bootloader. Per informazioni generali sull'OTA, consulta
Aggiornamenti OTA. Per maggiori dettagli sull'implementazione OTA specifica del bootloader, consulta Supportare gli aggiornamenti OTA.
Associazione alla versione.
Il collegamento delle versioni associa le chiavi di sicurezza al sistema operativo e alla versione del livello di patch. Il vincolo della versione garantisce che un malintenzionato che scopre una vulnerabilità in una versione precedente del sistema o del software TEE non possa eseguire il rollback di un dispositivo alla versione vulnerabile e utilizzare le chiavi create con la versione più recente. Il bootloader deve fornire determinate informazioni per supportare il binding delle versioni. Per ulteriori informazioni, consulta
Informazioni sulla versione nelle proprietà AVB.
Riga di comando del kernel
Concatena la riga di comando del kernel dalle seguenti posizioni:
Riga di comando del bootloader: insieme di parametri statici e dinamici determinati dal bootloader
Device tree: dal nodo chosen/bootargs
defconfig: da CONFIG_CMDLINE
boot.img: dalla riga di comando (per gli offset e le dimensioni, consulta
system/core/mkbootimg/bootimg.h
A partire da Android 12, per i parametri androidboot.* che dobbiamo passare allo spazio utente di Android, possiamo utilizzare bootconfig anziché la riga di comando del kernel.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
