Partizione di avvio generica

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In Android 12, l'immagine generica boot, indicata come Generic Kernel Image (GKI), contiene il ramdisk generico e il kernel GKI.

Per i dispositivi lanciati con Android 13, il volume RAM generico viene rimosso dall'immagine boot e inserito in un'immagine init_boot distinta. Questa modifica lascia l'immagine boot con solo il kernel GKI.

Per l'upgrade dei dispositivi che continuano a utilizzare Android 12 o versioni precedenti del kernel, il ramdisk generico rimane invariato e non è richiesta una nuova immagine init_boot.

Per creare un ramdisk generico, sposta le risorse specifiche del fornitore dal ramdisk in modo che il ramdisk generico contenga solo il primo livello init e un file di proprietà contenente le informazioni sul timestamp.

Sui dispositivi che:

• Non utilizzare una partizione recovery dedicata, tutti i bit di recupero passano dal ramdisk generico al ramdisk vendor_boot.

• Utilizza una partizione recovery dedicata. Non è necessaria alcuna modifica al ramdisk recovery perché è autonomo.recovery

Architettura

I seguenti diagrammi illustrano l'architettura per i dispositivi con Android 12 o versioni successive. I dispositivi lanciati con Android 13 hanno una nuova immagineinit_boot contenente il ramdisk generico. I dispositivi che eseguono l'upgrade da Android 12 ad Android 13 utilizzano la stessa architettura di Android 12.

Avvio con Android 13, nessun recupero dedicato

Figura 1. Dispositivi che eseguono l'upgrade ad Android 13 o che lo eseguono per la prima volta, con GKI, senza recupero dedicato.

Avvio con Android 13, recupero dedicato e A/B (ramdisk dedicato)

Figura 2. Dispositivi con lancio o upgrade ad Android 13, con GKI, dedicato e recupero A/B.

Fai riferimento a questa figura se il dispositivo ha partizioni recovery_a e recovery_b.

Avvio con Android 13, recupero dedicato e non A/B (ramdisk dedicato)

Figura 3. Dispositivi con GKI, con recupero dedicato e non A/B, che eseguono l'upgrade ad Android 13 o che lo avviano.

Fai riferimento a questa figura se il dispositivo ha una partizione denominata recovery senza un suffisso dello slot.

Avvio o upgrade ad Android 12, nessun ripristino dedicato

Figura 4. Dispositivi che eseguono l'upgrade ad Android 12 o che lo eseguono per la prima volta, con GKI, senza recupero dedicato.

Avvio o upgrade ad Android 12, ripristino dedicato e A/B (ramdisk dedicato)

Figura 5. Dispositivi che eseguono l'upgrade ad Android 12 o che lo avviano, con GKI, dedicato e recupero A/B.

Fai riferimento a questa figura se il dispositivo ha partizioni recovery_a e recovery_b.

Avvio o upgrade ad Android 12, ripristino dedicato e non A/B (ramdisk dedicato)

Figura 6. Dispositivi con lancio o upgrade ad Android 12, con GKI, recupero dedicato e non A/B.

Fai riferimento a questa figura se il dispositivo ha una partizione denominata recovery senza un suffisso dello slot.

Upgrade ad Android 12, recovery-as-boot (recovery-as-ramdisk)

Figura 7. Dispositivi di cui viene eseguito l'upgrade ad Android 12, senza GKI, con avvio in modalità di ripristino.

Upgrade ad Android 12, recovery dedicato (ramdisk dedicato)

Figura 8. Dispositivi di cui viene eseguito l'upgrade ad Android 12, senza GKI, con recupero dedicato.

Contenuti delle immagini di avvio

Le immagini di avvio di Android contengono quanto segue.

• Immagine init_boot aggiunta per i dispositivi lanciati con Android 13

  • Versione dell'intestazione V4
  • Immagine ramdisk generica

• Immagine generica di boot

  • Versione dell'intestazione V3 o V4
    • Un boot_signature per la certificazione del file boot.img GKI (solo versione 4). Il GKI boot.img certificato non è firmato per l'avvio verificato. Gli OEM devono comunque firmare il file boot.img precompilato con una chiave AVB specifica per il dispositivo.
    • Generico cmdline (GENERIC_KERNEL_CMDLINE)
    • Kernel GKI
  • Immagine generica del ramdisk
    • Incluso solo nelle immagini boot da Android 12 e versioni precedenti

• vendor_boot (per maggiori dettagli, consulta Partizioni ditiboot del fornitore)

  • vendor_boot intestazione
    • cmdline (BOARD_KERNEL_CMDLINE) specifico del dispositivo
  • vendor_boot immagine ramdisk
    • lib/modules
    • Risorse di recupero (se non è presente un recupero dedicato)
  • dtb immagine

• recovery immagine

  • Versione dell'intestazione V2
    • cmdline specifico del dispositivo per il recupero, se necessario
    • Per la partizione di ripristino non A/B, i contenuti dell'intestazione devono essere autonomi; consulta Immagini di ripristino. Ad esempio:
    • cmdline non è concatenato a boot e vendor_boot cmdline.
    • L'intestazione specifica il DTBO di recupero, se necessario.
    • Per la partizione di ripristino A/B, i contenuti possono essere concatenati o dedotti da boot e vendor_boot. Ad esempio:
    • cmdline viene concatenato a boot e vendor_boot cmdline.
    • Il DTBO può essere dedotto dall'intestazione vendor_boot.
  • recovery immagine ramdisk
    • Risorse di recupero
    • Per la partizione di ripristino non A/B, i contenuti del ramdisk devono essere autonomi; consulta Immagini di ripristino. Ad esempio:
    • lib/modules deve contenere tutti i moduli del kernel necessari per avviare la modalità di recupero
    • Il ramdisk di ripristino deve contenere init.
    • Per la partizione di ripristino A/B, il ramdisk di ripristino viene anteposto al ramdisk generico e vendor_boot, pertanto non deve essere autonomo. Ad esempio:
    • lib/modules potrebbe contenere solo i moduli del kernel aggiuntivi necessari per avviare la modalità di recupero, oltre ai moduli del kernel nella ramdisk vendor_boot.
    • Il link simbolico in /init potrebbe esistere, ma è oscurato dal file binario /init di primo livello nell'immagine di avvio.

Contenuti dell'immagine ramdisk generica

Il ramdisk generico contiene i seguenti componenti.

• init
• system/etc/ramdisk/build.prop
• ro.PRODUCT.bootimg.* build oggetti
• Directory vuote per i punti di montaggio: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/
• first_stage_ramdisk/
  • Directory vuote duplicate per i punti di montaggio: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

Integrazione dell'immagine di avvio

I flag di compilazione controllano la modalità di compilazione delle immagini init_boot, boot, recovery e vendor_boot. Il valore di una variabile di bordo booleana deve essere la stringa true o essere vuota (valore predefinito).

• TARGET_NO_KERNEL. Questa variabile indica se la compilazione utilizza un'immagine di avvio predefinita. Se questa variabile è impostata su true, imposta BOARD_PREBUILT_BOOTIMAGE sulla posizione dell'immagine di avvio precompilata (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img).

• BOARD_USES_RECOVERY_AS_BOOT. Questa variabile indica se il dispositivo utilizza l'immagine recovery come immagine boot. Quando utilizzi GKI, questa variabile è vuota e le risorse di recupero devono essere spostate in vendor_boot.

• BOARD_USES_GENERIC_KERNEL_IMAGE. Questa variabile indica che la scheda utilizza GKI. Questa variabile non influisce su sysprops o PRODUCT_PACKAGES.

  Si tratta dell'opzione GKI a livello di scheda; tutte le seguenti variabili sono limitate da questa variabile.

• BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. Questa variabile controlla se le risorse di recupero del ramdisk vengono create per vendor_boot.

  • Se impostato su true, le risorse di recupero vengono create solo per vendor-ramdisk/ e non per recovery/root/.

  • Se è vuoto, le risorse di recupero vengono create solo per recovery/root/ e non per vendor-ramdisk/.

• BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. Questa variabile controlla se le chiavi GSI AVB vengono create per vendor_boot.

  • Se impostato su true, se BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

    • È impostato, le chiavi AVB GSI vengono create per $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.

    • Se non è impostato, le chiavi AVB GSI vengono create per $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

  • Se vuoto, se BOARD_RECOVERY_AS_ROOT:

    • È impostato, le chiavi AVB GSI vengono create per $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.

    • Se non è impostato, le chiavi AVB GSI vengono create per $ANDROID_PRODUCT_OUT/ramdisk/avb.

• BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. Questa variabile controlla se l'immagine recovery contiene o meno un kernel. I dispositivi lanciati con Android 12 e che utilizzano la partizione A/B recovery devono impostare questa variabile su true. I dispositivi lanciati con Android 12 e che utilizzano non A/B devono impostare questa variabile su false per mantenere l'immagine di recupero indipendente.

• BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. Questa variabile controlla se $OUT/boot*.img viene copiato in IMAGES/ nei file di destinazione.

  • aosp_arm64 deve impostare questa variabile su true.

  • Gli altri dispositivi devono lasciare vuota questa variabile.

• BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. Questa variabile controlla se viene generatoinit_boot.img e ne imposta le dimensioni. Se impostato, il ramdisk generico viene aggiunto a init_boot.img anziché a boot.img e richiede l'impostazione delle variabili BOARD_AVB_INIT_BOOT* per vbmeta a catena.

Combinazioni consentite

I dispositivi con una partizione recovery dedicata possono impostarePRODUCT_BUILD_RECOVERY_IMAGE su true o vuoto. Per questi dispositivi, se è impostato BOARD_RECOVERYIMAGE_PARTITION_SIZE, viene creata un'immagine recovery.

Attivare vbmeta a catena per l'avvio

La funzionalità vbmeta a catena deve essere attivata per le immagini boot e init_boot. Specifica quanto segue:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

Per un esempio, consulta questa modifica.

Sistema come root

Il sistema come root non è supportato per i dispositivi che utilizzano GKI. Su questi dispositivi, BOARD_BUILD_SYSTEM_ROOT_IMAGE deve essere vuoto. Il sistema come utente root non è supportato nemmeno per i dispositivi che utilizzano partizioni dinamiche.

Configurazioni dei prodotti

I dispositivi che utilizzano il file ramdisk generico devono installare un elenco di file che è consentito installare nel file ramdisk. Per farlo, specifica quanto segue in device.mk:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

Il file generic_ramdisk.mk impedisce inoltre ad altri file di makefile di installare accidentalmente altri file nella ramdisk (sposta questi file in vendor_ramdisk).

Configura dispositivi

Le istruzioni di configurazione variano in base ai dispositivi che vengono lanciati con Android 13, a quelli che eseguono l'upgrade ad Android 12 e a quelli che vengono lanciati con Android 12. Android 13, sono configurati in modo simile a come erano con Android 12

• Dispositivi di cui è stato eseguito l'upgrade ad Android 12:

  • Può conservare il valore di BOARD_USES_RECOVERY_AS_BOOT. In questo caso, utilizza configurazioni precedenti e le nuove variabili di compilazione devono essere vuote. Se questi dispositivi:

    • Imposta BOARD_USES_RECOVERY_AS_BOOT su true, l'architettura è come mostrato nella Figura 3.

    • Imposta BOARD_USES_RECOVERY_AS_BOOT su vuoto, l'architettura è come mostrato Figura 4.

  • Puoi impostare BOARD_USES_RECOVERY_AS_BOOT su vuoto. In questo caso, utilizzano nuove configurazioni. Se questi dispositivi:

    • Non utilizzare una partizione recovery dedicata, l'architettura è come mostrato nella Figura 1 e l'opzione di configurazione del dispositivo è Opzione 1.

    • Utilizza una partizione recovery dedicata, l'architettura è mostrata nella Figura 2a o nella Figura 2b e l'opzione di configurazione del dispositivo è Opzione 2a o Opzione 2b.

• I dispositivi lanciati con Android 12 devono impostare BOARD_USES_RECOVERY_AS_BOOT su vuoto e utilizzare nuove configurazioni. Se questi dispositivi:

  • Non utilizzare una partizione recovery dedicata, l'architettura è quella mostrata nella Figura 1 e l'opzione di configurazione del dispositivo è Opzione 1.

  • Utilizza una partizione recovery dedicata, l'architettura è mostrata nella Figura 2a o nella Figura 2b e l'opzione di configurazione del dispositivo è Opzione 2a o Opzione 2b.

Poiché aosp_arm64 genera solo GKI (e non vendor_boot o il recupero), non è un target completo. Per le aosp_arm64configurazioni di compilazione, consulta generic_arm64.

Opzione 1: nessuna partizione di ripristino dedicata

I dispositivi senza partizione recovery contengono l'immagine boot generica nella partizione boot. Il ramdisk vendor_boot contiene tutte le risorse di recupero, incluso lib/modules (con i moduli del kernel del fornitore). Su questi dispositivi, la configurazione del prodotto eredita da generic_ramdisk.mk.

Impostare i valori BOARD

Imposta i seguenti valori:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

File binari e link simbolici di inizializzazione

Il ramdisk vendor_boot può contenere un link simbolico /init a /system/bin/init e init_second_stage.recovery in /system/bin/init. Tuttavia, poiché il ramdisk generico viene concatenato dopo il ramdisk vendor_boot, il simbolico/init viene sovrascritto. Quando il dispositivo si avvia in modalità di ripristino, il codice binario /system/bin/init è necessario per supportare l'inizializzazione di secondo livello. I contenuti di vendor_boot + ramdisk generici sono i seguenti:

• /init (da ramdisk generico, creato da init_first_stage)
• /system/bin/init (da vendor_ramdisk, creato da init_second_stage.recovery)

Spostare i file fstab

Sposta tutti i file fstab installati nel ramdisk generico in vendor_ramdisk. Per un esempio, consulta questa modifica.

Installare i moduli

Puoi installare moduli specifici per il dispositivo su vendor_ramdisk (salta questo passaggio se non hai moduli specifici per il dispositivo da installare).

• Utilizza la variante vendor_ramdisk del modulo quando il modulo viene installato nel /first_stage_ramdisk. Questo modulo dovrebbe essere disponibile dopo che init viene eseguito il root in /first_stage_ramdisk, ma prima che init venga eseguito il root in /system. Per alcuni esempi, consulta Checksum dei metadati e Compressione A/B virtuale.

• Utilizza la variante recovery del modulo quando il modulo viene installato in /. Questo modulo dovrebbe essere disponibile prima che init passi il controllo dell'accesso amministrativo a /first_stage_ramdisk. Per informazioni dettagliate sull'installazione dei moduli in /, consulta la console di primo livello.

Console della prima fase

Poiché la console della prima fase si avvia prima che init passi il controllo dell'accesso come amministratore a /first_stage_ramdisk, devi installare la variante recovery dei moduli. Per impostazione predefinita, entrambe le varianti del modulo vengono installate in build/make/target/product/base_vendor.mk, quindi se il file makefile del dispositivo eredita da quel file non è necessario installare esplicitamente la variante build/make/target/product/base_vendor.mk.recovery

Per installare esplicitamente i moduli di recupero, utilizza quanto segue.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

In questo modo, linker, sh e toybox vengono installati su $ANDROID_PRODUCT_OUT/recovery/root/system/bin, che a sua volta viene installato su /system/bin in vendor_ramdisk.

Per aggiungere i moduli necessari per la console della prima fase (ad esempio adbd), utilizza quanto segue.

PRODUCT_PACKAGES += adbd.recovery

In questo modo, i moduli specificati vengono installati in $ANDROID_PRODUCT_OUT/recovery/root/system/bin, che a sua volta viene installato in /system/bin in vendor_ramdisk.

Controlli di congruenza dei metadati

Per supportare i checksum dei metadati durante il montaggio della prima fase, i dispositivi che non supportano GKI installano la variante ramdisk dei seguenti moduli. Per aggiungere il supporto di GKI, sposta i moduli in $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Per un esempio, consulta questo elenco di modifiche.

Compressione A/B virtuale

Per supportare la compressione A/B virtuale, snapuserd deve essere installato su vendor_ramdisk. Il dispositivo dovrebbe ereditare da virtual_ab_ota/compression.mk, che installa la variante vendor_ramdisk di snapuserd.

Modifiche alla procedura di avvio

La procedura di avvio in modalità di ripristino o in Android non cambia, con la seguente eccezione:

• Il ramdisk build.prop si sposta in /second_stage_resources in modo che il secondo livello init possa leggere il timestamp della build dell'avvio.

Poiché le risorse passano dal ramdisk generico al ramdisk vendor_boot, il risultato della concatenazione del ramdisk generico al ramdisk vendor_boot non cambia.

Rendi disponibile e2fsck

I file make del dispositivo possono ereditare da:

• virtual_ab_ota/launch_with_vendor_ramdisk.mk se il dispositivo supporta A/B virtuale, ma non la compressione.

• virtual_ab_ota/compression.mk se il dispositivo supporta la compressione A/B virtuale.

I file make del prodotto vengono installati $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. In fase di esecuzione, la prima fase init passa il controllo a /first_stage_ramdisk, quindi esegue /system/bin/e2fsck.

Opzione 2a: partizione di recupero A/B e dedicata

Utilizza questa opzione per i dispositivi con partizioni recovery A/B, ovvero con recovery_a e recovery_b partition. Questi dispositivi includono i dispositivi A/B e A/B virtuali di cui la partizione di ripristino è aggiornabile, con la seguente configurazione:

AB_OTA_PARTITIONS += recovery

Il ramdisk vendor_boot contiene i bit del fornitore dei moduli kernel del ramdisk e del fornitore, tra cui:

• File fstab specifici del dispositivo

• lib/modules (inclusi i moduli del kernel del fornitore)

Il ramdisk recovery contiene tutte le risorse di recupero. Su questi dispositivi, la configurazione del prodotto eredita da generic_ramdisk.mk.

Impostare i valori BOARD

Imposta i seguenti valori per i dispositivi con partizione recovery A/B:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

File binari e link simbolici di inizializzazione

Il ramdisk recovery può contenere un link simbolico /init -> /system/bin/init e init_second_stage.recovery in /system/bin/init. Tuttavia, poiché il ramdisk di avvio viene concatenato dopo il ramdisk recovery, il link simbolico /init viene sovrascritto. Quando il dispositivo si avvia in modalità di ripristino, il file binario /system/bin/init è necessario per supportare l'inizializzazione di secondo livello.

Quando il dispositivo si avvia in recovery, i contenuti di recovery + vendor_boot + ramdisk generici sono i seguenti:

• /init (da ramdisk, compilato da init_first_stage)
• /system/bin/init (dal ramdisk recovery, compilato da init_second_stage.recovery ed eseguito da /init)

Quando il dispositivo si avvia in Android, i contenuti di vendor_boot + i ramdisk generici sono i seguenti:

• /init (da ramdisk generico, creato da init_first_stage)

Spostare i file fstab

Sposta i file fstab installati nel ramdisk generico in vendor_ramdisk. Per un esempio, consulta questa modifica.

Installare i moduli

Se vuoi, puoi installare moduli specifici per il dispositivo su vendor_ramdisk (salta questo passaggio se non hai moduli specifici per il dispositivo da installare). Init non cambia utente root. La variante vendor_ramdisk dei moduli viene installata nella directory principale di vendor_ramdisk. Per esempi di installazione di moduli in vendor_ramdisk, consulta Console di primo livello, Checksum dei metadati e Compressione A/B virtuale.

Console della prima fase

Per installare la variante vendor_ramdisk dei moduli, utilizza quanto segue:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

In questo modo, linker, sh e toybox vengono installati su $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, che a sua volta viene installato su /system/bin in vendor_ramdisk.

Per aggiungere i moduli necessari per la console di primo livello (ad esempio adbd), abilita la variante vendor_ramdisk di questi moduli caricando le patch pertinenti su AOSP, quindi utilizza quanto segue:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

In questo modo, i moduli specificati vengono installati in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin. Se il ramdisk vendor_boot viene caricato in modalità di ripristino, il modulo è disponibile anche in recovery. Se il vendor_boot ramdisk non viene caricato in modalità di ripristino, il dispositivo può anche installare adbd.recovery.

Controlli di congruenza dei metadati

Per supportare i checksum dei metadati durante il montaggio della prima fase, i dispositivi che non supportano GKI installano la variante ramdisk dei seguenti moduli. Per aggiungere il supporto di GKI, sposta i moduli in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Per un esempio, consulta questo elenco di modifiche.

Compressione A/B virtuale

Per supportare la compressione A/B virtuale, snapuserd deve essere installato su vendor_ramdisk. Il dispositivo dovrebbe ereditare da virtual_ab_ota/compression.mk, che installa la variante vendor_ramdisk di snapuserd.

Modifiche alla procedura di avvio

Quando si avvia Android, la procedura di avvio non cambia. vendor_boot + la ramdisk generica è simile alla procedura di avvio esistente, tranne per il fatto che fstab viene caricato da vendor_boot. Poiché system/bin/recovery non esiste, first_stage_init lo gestisce come un normale avvio.

Quando avvii il dispositivo in modalità di ripristino, la procedura di avvio cambia. Il ripristino + vendor_boot + ramdisk generico è simile alla procedura di ripristino esistente, ma il kernel viene caricato dall'immagine boot anziché dall'immagine recovery. La procedura di avvio per la modalità di ripristino è la seguente.

1. Il bootloader si avvia ed esegue le seguenti operazioni:

   1. Sposta il recovery + vendor_boot + ramdisk generico in /. Se l'OEM duplica i moduli del kernel nel ramdisk di ripristino aggiungendoli a BOARD_RECOVERY_KERNEL_MODULES, vendor_boot è facoltativo.
   2. Esegue il kernel dalla partizione boot.

2. Il kernel monta il ramdisk su /, quindi esegue /init dal ramdisk generico.

3. Viene avviata l'inizializzazione della prima fase, che esegue le seguenti operazioni:

   1. Imposta IsRecoveryMode() == true e ForceNormalBoot() == false.
   2. Carica i moduli del kernel del fornitore da /lib/modules.
   3. Chiama DoFirstStageMount(), ma salta il montaggio perché IsRecoveryMode() == true. Il dispositivo non libera il ramdisk (perché / è ancora lo stesso), ma chiama SetInitAvbVersionInRecovery().
   4. Avvia l'inizializzazione del secondo stadio da /system/bin/init dal ramdisk recovery.

Rendi disponibile e2fsck

I file make del dispositivo possono ereditare da:

• virtual_ab_ota/launch_with_vendor_ramdisk.mk se il dispositivo supporta A/B virtuale, ma non la compressione.

• virtual_ab_ota/compression.mk se il dispositivo supporta la compressione A/B virtuale.

I file make del prodotto vengono installati $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. In fase di esecuzione, la prima fase init esegue /system/bin/e2fsck.

Opzione 2b: partizione di recupero dedicata e non A/B

Utilizza questa opzione per i dispositivi con una partizione recovery non A/B, ovvero il dispositivo ha una partizione denominata recovery senza un suffisso dello slot. Questi dispositivi includono:

• dispositivi non A/B.
• Dispositivi A/B e A/B virtuali, la cui partizione di ripristino non è aggiornata. (Questo è insolito.)

Il ramdisk vendor_boot contiene i bit del fornitore dei moduli kernel del ramdisk e del fornitore, tra cui:

• File fstab specifici del dispositivo
• lib/modules (inclusi i moduli del kernel del fornitore)

L'immagine recovery deve essere autonoma. Deve contenere tutte le risorse necessarie per avviare la modalità di ripristino, tra cui:

• L'immagine del kernel
• L'immagine DTBO
• Moduli del kernel in lib/modules
• Inizializzazione di primo livello come link simbolico /init -> /system/bin/init
• File binario di inizializzazione di secondo livello /system/bin/init
• File fstab specifici del dispositivo
• Tutte le altre risorse di recupero, incluso il file binario recovery

Su questi dispositivi, la configurazione del prodotto eredita da generic_ramdisk.mk.

Impostare i valori BOARD

Imposta i seguenti valori per i dispositivi non A/B:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

File binari e link simbolici di inizializzazione

Il ramdisk recovery deve contenere un link simbolico /init -> /system/bin/init e init_second_stage.recovery in /system/bin/init. Quando il dispositivo si avvia in modalità di recupero, il file binario /system/bin/init è necessario per supportare l'inizializzazione sia della prima sia della seconda fase.

Quando il dispositivo si avvia in recovery, i contenuti delle ramdisk di recovery sono come segue:

• /init -> /system/bin/init (da recovery ramdisk)
• /system/bin/init (dal ramdisk recovery, compilato da init_second_stage.recovery ed eseguito da /init)

Quando il dispositivo si avvia in Android, i contenuti di vendor_boot + i ramdisk generici sono i seguenti:

• /init (da ramdisk, compilato da init_first_stage)

Spostare i file fstab

Sposta tutti i file fstab installati nel ramdisk generico nel vendor_ramdisk e nel ramdisk recovery. Per un esempio, consulta questa modifica.

Installare i moduli

Puoi installare moduli specifici per il dispositivo su vendor_ramdisk e recovery ramdisk (salta questo passaggio se non hai moduli specifici per il dispositivo da installare). init non cambia utente root. La variante vendor_ramdisk dei moduli viene installata nella directory principale di vendor_ramdisk. La variante recovery dei moduli viene installata nella directory principale della ramdisk recovery. Per esempi di installazione di moduli nei ramdisk vendor_ramdisk e recovery, consulta Console di primo livello e Checksum dei metadati.

Console della prima fase

Per installare la variante vendor_ramdisk dei moduli, utilizza quanto segue:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

In questo modo, linker, sh e toybox vengono installati su $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, che a sua volta viene installato su /system/bin in vendor_ramdisk.

Per aggiungere i moduli necessari per la console di primo livello (ad esempio adbd), abilita la variante vendor_ramdisk di questi moduli caricando le patch pertinenti su AOSP, quindi utilizza quanto segue:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

In questo modo, i moduli specificati vengono installati in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin.

Per installare la variante recovery dei moduli, sostituisci vendor_ramdisk con recovery:

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

Controlli di congruenza dei metadati

Per supportare i checksum dei metadati durante il montaggio della prima fase, i dispositivi che non supportano GKI installano la variante ramdisk dei seguenti moduli. Per aggiungere il supporto di GKI, sposta i moduli in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Per supportare i checksum dei metadati durante il montaggio della prima fase in modalità di ripristino, attiva la variante di ripristino di questi moduli e installali.

Modifiche alla procedura di avvio

Quando si avvia Android, la procedura di avvio non cambia. vendor_boot + la ramdisk generica è simile alla procedura di avvio esistente, tranne per il fatto che fstab viene caricato da vendor_boot. Poiché system/bin/recovery non esiste, first_stage_init lo gestisce come un normale avvio.

Quando si avvia la modalità di ripristino, la procedura di avvio non cambia. La diga RAM di recupero viene caricata nello stesso modo della procedura di recupero esistente. Il kernel viene caricato dall'immagine recovery. La procedura di avvio per la modalità di recupero è la seguente.

1. Il bootloader si avvia ed esegue le seguenti operazioni:

   1. Esegue il push del ramdisk di ripristino su /.
   2. Esegue il kernel dalla partizione recovery.

2. Il kernel monta il ramdisk su /, quindi esegue /init, che è un link simbolico a /system/bin/init dal ramdisk recovery.

3. Viene avviata l'inizializzazione della prima fase, che esegue le seguenti operazioni:

   1. Imposta IsRecoveryMode() == true e ForceNormalBoot() == false.
   2. Carica i moduli del kernel del fornitore da /lib/modules.
   3. Chiama DoFirstStageMount(), ma salta il montaggio perché IsRecoveryMode() == true. Il dispositivo non libera il ramdisk (perché / è ancora lo stesso), ma chiama SetInitAvbVersionInRecovery().
   4. Avvia l'inizializzazione del secondo stadio da /system/bin/init dal ramdisk recovery.

Timestamp delle immagini di avvio

Il seguente codice è un esempio di file del timestamp dell'immagine boot:

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

• Al momento della compilazione, viene aggiunto un file system/etc/ramdisk/build.prop al ramdisk generico. Questo file contiene informazioni sul timestamp della compilazione.

• In fase di esecuzione, la prima fase init copia i file dalla ramdisk in tmpfs prima di liberare la ramdisk in modo che la seconda fase init possa leggere questo file per impostare le proprietà dei timestamp delle immagini boot.