Partizione di avvio generica

In Android 12, l'immagine boot generica, 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 fuori dal ramdisk, in modo che il ramdisk generico contenga solo la prima fase init e un file di proprietà contenente informazioni sul timestamp.

Sui dispositivi che:

  • Non utilizzare una partizione recovery dedicata, tutti i bit di ripristino si spostano 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 e 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

Avvio/upgrade del dispositivo, GKI, nessun ripristino 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 A/B e dedicato (ramdisk dedicato)

Avvio/upgrade del dispositivo, GKI, dedicato e ripristino A/B

Figura 2. Dispositivi che verranno introdotti o eseguono l'upgrade ad Android 13, con GKI, recupero A/B e dedicato.

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)

Lancio/upgrade del dispositivo, GKI, recupero dedicato e non A/B

Figura 3. Dispositivi con lancio o upgrade ad Android 13, 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.

Avvio o upgrade ad Android 12, nessun ripristino dedicato

Avvio/upgrade del dispositivo, GKI, 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)

Avvio/upgrade del dispositivo, GKI, dedicato e ripristino A/B

Figura 5. Dispositivi che eseguono l'upgrade ad Android 12 o che lo avviano, con GKI, dedicato e ripristino 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)

Avvia/esegui l'upgrade del dispositivo, GKI, recupero dedicato e non A/B

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

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

Esegui l'upgrade ad Android 12 con ripristino come avvio (ripristino come ramdisk)

Avviare/eseguire l'upgrade del dispositivo, nessun GKI, ripristino all'avvio

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

Esegui l'upgrade ad Android 12, recupero dedicato (ramdisk dedicato)

Avvio/upgrade del dispositivo, nessun GKI, recupero 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 intestazione V4
    • Immagine ramdisk generica

  • Immagine boot generica

    • Versione 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 il Boot verificato. Gli OEM devono comunque firmare l'elemento boot.img predefinito con una chiave AVB specifica per il dispositivo.
      • Generico cmdline (GENERIC_KERNEL_CMDLINE)
      • Kernel GKI
    • Immagine ramdisk generica
      • Incluso solo nelle immagini boot da Android 12 e versioni precedenti

  • Immagine vendor_boot (per maggiori dettagli, vedi Partizioni di avvio del fornitore)

    • vendor_boot intestazione
      • cmdline (BOARD_KERNEL_CMDLINE) specifici per dispositivo
    • Immagine ramdisk vendor_boot
      • lib/modules
      • Risorse di recupero (se non è presente un recupero dedicato)
    • Immagine dtb

  • Immagine recovery

    • 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 è concatenato a boot e vendor_boot cmdline.
      • Il valore 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 moduli kernel aggiuntivi necessari per avviare la modalità di ripristino, oltre ai moduli kernel nel 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 (il 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 predefinita (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 ripristino ramdisk sono 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:

      • È impostata, le chiavi AVB GSI sono progettate 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 sono 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 concatenato.

Combinazioni consentite

Componente o variabile Eseguire l'upgrade del dispositivo senza partizione di ripristino Eseguire l'upgrade del dispositivo con la partizione di ripristino Avvia il dispositivo senza partizione di ripristino Avvia il dispositivo con la partizione di recupero A/B Avvia il dispositivo con la partizione di ripristino non A/B aosp_arm64
Contiene boot sì sì sì sì sì sì
Contiene init_boot (Android 13) no no sì sì sì sì
Contiene vendor_boot facoltativo facoltativo sì sì sì no
Contiene recovery no sì no sì sì no
BOARD_USES_RECOVERY_AS_BOOT true vuoto vuoto vuoto vuoto vuoto
BOARD_USES_GENERIC_KERNEL_IMAGE vuoto vuoto true true true true
PRODUCT_BUILD_RECOVERY_IMAGE vuoto true o vuoto vuoto true o vuoto true o vuoto vuoto
BOARD_RECOVERYIMAGE_PARTITION_SIZE vuoto > 0 vuoto > 0 > 0 vuoto
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT vuoto vuoto true vuoto vuoto vuoto
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT vuoto vuoto true true true vuoto
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE vuoto vuoto vuoto true vuoto vuoto
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES vuoto vuoto vuoto vuoto vuoto true

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.

Attiva vbmeta concatenato 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.

System as-root

Il sistema come root non è supportato per i dispositivi che utilizzano GKI. Su questi dispositivi, BOARD_BUILD_SYSTEM_ROOT_IMAGE deve essere vuoto. Inoltre, System as-root non è supportato per i dispositivi che usano partizioni dinamiche.

Configurazioni del prodotto

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 anche ad altri makefile di installare accidentalmente altri file sul ramdisk (sposta questi file in vendor_ramdisk).

Configura dispositivi

Le istruzioni di configurazione variano in base al dispositivo, se viene lanciato con Android 13, se viene eseguito l'upgrade ad Android 12 o se viene lanciato con Android 12. Android 13 ha una configurazione simile a quella di Android 12

  • Dispositivi aggiornati 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.

    • È possibile impostare BOARD_USES_RECOVERY_AS_BOOT come vuoto. In questo caso, utilizzano nuove configurazioni. Se tali 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.

  • 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 è quella 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 build, consulta generic_arm64.

Opzione 1: nessuna partizione di ripristino dedicata

I dispositivi senza una partizione recovery contengono l'immagine boot generica nella partizione boot. Il ramdisk vendor_boot contiene tutte le risorse di ripristino, tra cui lib/modules (con moduli 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

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. All'avvio del dispositivo, è necessario il file binario /system/bin/init per supportare l'init della seconda fase. 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 i file fstab installati nella ramdisk generica in vendor_ramdisk. Per un esempio, consulta questa modifica.

Installa moduli

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

  • Utilizza la variante vendor_ramdisk del modulo quando il modulo viene installato in /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 maggiori dettagli sull'installazione dei moduli in /, consulta Console di prima fase.

Console della prima fase

Poiché la console della prima fase viene avviata prima del passaggio di init a /first_stage_ramdisk, devi installare la variante recovery dei moduli. Per impostazione predefinita, entrambe le varianti del modulo sono installate su build/make/target/product/base_vendor.mk, quindi se il file makefile del dispositivo eredita da questo file non devi installare esplicitamente la variante recovery.

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

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

In questo modo ti assicuri che linker, sh e toybox vengano installati su $ANDROID_PRODUCT_OUT/recovery/root/system/bin, che a sua volta verrà 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 ti assicuri che i moduli specificati vengano installati in $ANDROID_PRODUCT_OUT/recovery/root/system/bin, che a sua volta verrà 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 del ramdisk dei seguenti moduli. Per aggiungere il supporto per 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 deve ereditare da virtual_ab_ota/compression.mk, che installa la variante vendor_ramdisk di snapuserd.

Modifiche al processo di avvio

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

  • Ramdisk build.prop passa a /second_stage_resources in modo che la seconda fase init possa leggere il timestamp della build di 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 il test A/B virtuale, ma non la compressione.

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

I makefile del prodotto installano $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. Durante il runtime, la prima fase init esegue il passaggio root 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 ramdisk e i moduli del kernel 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 A/B recovery:

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

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 è 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 file fstab

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

Installa 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ò optionally installare anche 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 per 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 delle modifiche.

Compressione A/B virtuale

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

Modifiche al processo di avvio

Quando avvii Android, il processo di avvio non cambia. Il ramdisk generico vendor_boot + è simile al processo di avvio esistente, ad eccezione del 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 in Recovery mode, il processo di avvio cambia. Il ramdisk di ripristino + vendor_boot + generico è simile al processo di ripristino esistente, ma il kernel viene caricato dall'immagine boot anziché dall'immagine recovery. La procedura di avvio della modalità di ripristino è la seguente.

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

    1. Invia recupero + vendor_boot + ramdisk generico a /. Se l'OEM duplica i moduli del kernel nel ramdisk di recupero aggiungendoli a BOARD_RECOVERY_KERNEL_MODULES, il valore 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'init della seconda fase da /system/bin/init da recovery ramdisk.

Rendi disponibile e2fsck

I file make del dispositivo possono ereditare da:

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

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

I makefile del prodotto installano $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. In fase di esecuzione, la prima fase init esegue /system/bin/e2fsck.

Opzione 2b: partizione di ripristino 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 slot. Questi dispositivi includono:

  • dispositivi non A/B;
  • Dispositivi A/B e A/B virtuali, di cui la partizione di ripristino non è aggiornabile. (Si tratta di una situazione insolita).

Il ramdisk vendor_boot contiene i bit del ramdisk e i moduli del kernel 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 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 seconda fase /system/bin/init
  • File fstab specifici per il dispositivo
  • Tutte le altre risorse di recupero, incluso il file binario recovery

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

Imposta 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

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 ripristino, il file binario /system/bin/init è necessario per supportare l'init sia di prima fase che di 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 (da recovery ramdisk, 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 file fstab

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

Installa 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 sulla radice del ramdisk recovery. Per esempi di installazione di moduli nei ramdisk vendor_ramdisk e recovery, consulta la console della prima fase e i 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 nel ripristino, abilita la variante di ripristino di questi moduli e installa anche questi.

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. Il recupero della ramdisk viene caricato 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 collegamento 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.