Partizione di avvio generica

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 solo con 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 sui timestamp.

Sui dispositivi che:

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

Avvio/upgrade del dispositivo, GKI, nessun ripristino dedicato

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

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

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

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)

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

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

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 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)

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

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)

Avvio/upgrade del dispositivo, nessun GKI, avvio in modalità di recupero

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)

Avvio/upgrade del dispositivo, nessun GKI, ripristino 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 generica del ramdisk

  • Immagine generica di boot

    • Versione dell'intestazione V3 o V4
      • Un boot_signature per la certificazione del file boot.img GKI (solo v4). 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

Componente o variabile Eseguire l'upgrade del dispositivo senza partizione di ripristino Eseguire l'upgrade del dispositivo con la partizione di ripristino Avviare il dispositivo senza partizione di ripristino Avvia il dispositivo con la partizione di ripristino A/B Avviare il dispositivo con una partizione di ripristino diversa da 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.

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 la ramdisk generica devono installare un elenco di file che è consentito installare nella 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 lanciati con Android 13, con upgrade ad Android 12 e 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

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 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 come utente root a /first_stage_ramdisk. Per informazioni dettagliate sull'installazione dei moduli in /, consulta la console della prima fase.

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 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 del ramdisk e dei 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 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

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 tutti i file fstab installati nella ramdisk generica 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 si avvia la 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 quanto segue:

    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 dalla 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 del ramdisk e dei 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 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

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 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 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 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 quanto segue:

    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 dalla 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.