Partizione di avvio generica

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

Per i dispositivi lanciati con Android 13, il ramdisk generico viene rimosso dall'immagine boot e inserito in un'immagine init_boot separata. 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 è necessario utilizzare 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 init di prima fase e un file di proprietà che contenga informazioni sul timestamp.

Sui dispositivi che:

  • Non utilizzare una partizione recovery dedicata, tutti i bit di ripristino vengono spostati 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 immagine init_boot contenente il ramdisk generico. I dispositivi che eseguono l'upgrade da Android 12 ad Android 13 utilizzano la stessa architettura di Android 12.

Lancio con Android 13, nessun recupero dedicato

Avvio/upgrade del dispositivo, GKI, nessun ripristino dedicato

Figura 1. Dispositivi che eseguono l'avvio o l'upgrade ad Android 13, con GKI, senza ripristino dedicato.

Lancio con Android 13, ripristino dedicato e A/B (ramdisk dedicato)

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

Figura 2. Dispositivi che eseguono l'avvio o l'upgrade ad Android 13, con GKI, recovery dedicata e A/B.

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

Lancio con Android 13, ripristino dedicato e non A/B (ramdisk dedicato)

Avvio/upgrade del dispositivo, GKI, recovery dedicato e non A/B

Figura 3. Dispositivi che vengono lanciati o aggiornati ad Android 13, con GKI, recovery dedicato e non A/B.

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

Avvio o upgrade ad Android 12, nessun ripristino dedicato

Avvio/upgrade del dispositivo, GKI, nessun ripristino dedicato

Figura 4. Dispositivi che eseguono l'avvio o l'upgrade ad Android 12, con GKI, nessun ripristino dedicato.

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

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

Figura 5. Dispositivi che vengono lanciati o aggiornati ad Android 12, con GKI, recovery dedicata e 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)

Avvio/upgrade del dispositivo, GKI, recovery dedicato e non A/B

Figura 6. Dispositivi che vengono lanciati o aggiornati ad Android 12, con GKI, recovery dedicato e non A/B.

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

Esegui l'upgrade ad Android 12, recovery-as-boot (recovery-as-ramdisk)

Avvio/upgrade del dispositivo, nessun GKI, recovery-as-boot

Figura 7. Dispositivi che eseguono l'upgrade ad Android 12, senza GKI, recovery-as-boot.

Upgrade ad Android 12, recovery dedicata (ramdisk dedicata)

Avvio/upgrade del dispositivo, nessun GKI, ripristino dedicato

Figura 8. Dispositivi che eseguono l'upgrade ad Android 12, nessun GKI, recovery dedicato.

Contenuti delle immagini di avvio

Le immagini di avvio di Android contengono quanto segue.

  • init_boot immagine 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 boot.img di GKI (solo v4). Il GKI certificato boot.img non è firmato per l'avvio verificato. I produttori OEM devono comunque firmare il file boot.img precompilato con una chiave AVB specifica del dispositivo.
      • Generico cmdline (GENERIC_KERNEL_CMDLINE)
      • Kernel GKI
    • Immagine ramdisk generica
      • Inclusi solo nelle immagini boot di Android 12 e versioni precedenti

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

    • vendor_boot header
      • cmdline specifico per il dispositivo (BOARD_KERNEL_CMDLINE)
    • vendor_boot ramdisk image
      • lib/modules
      • Risorse di recupero (se non è previsto un recupero dedicato)
    • dtb immagine

  • recovery immagine

    • Header version 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. Vedi Immagini di ripristino. Ad esempio:
      • cmdline non è concatenato a boot e vendor_boot cmdline.
      • L'intestazione specifica il DTBO di ripristino, 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 ramdisk image
      • Risorse per il recupero
      • Per la partizione di ripristino non A/B, i contenuti del ramdisk devono essere autonomi. Vedi Immagini di ripristino. Ad esempio:
      • lib/modules deve contenere tutti i moduli kernel necessari per l'avvio della 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 del kernel aggiuntivi necessari per avviare la modalità di ripristino oltre ai moduli del kernel nel ramdisk vendor_boot.
      • Il symlink in /init potrebbe esistere, ma è oscurato dal binario /init di prima fase 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 build controllano la modalità di creazione delle immagini init_boot, boot, recovery e vendor_boot. Il valore di una variabile booleana della scheda deve essere la stringa true o essere vuoto (valore predefinito).

  • TARGET_NO_KERNEL. Questa variabile indica se la build 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 si utilizza GKI, questa variabile è vuota e le risorse di ripristino devono essere spostate in vendor_boot.

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

    Questo è l'interruttore 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 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 sono create per vendor_boot.

    • Se impostato su true, se BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

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

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

    • Quando è vuoto, se BOARD_RECOVERY_AS_ROOT:

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

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

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

  • 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 init_boot.img viene generato 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 Avviare il dispositivo senza partizione di ripristino Avvia il dispositivo con la partizione di ripristino A/B Avvia il dispositivo con una 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 impostare PRODUCT_BUILD_RECOVERY_IMAGE su true o vuoto. Per questi dispositivi, se BOARD_RECOVERYIMAGE_PARTITION_SIZE è impostato, viene creata un'immagine recovery.

Abilita vbmeta concatenato per l'avvio

vbmeta concatenato deve essere attivato 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

System-as-root non è supportato per i dispositivi che utilizzano GKI. Su questi dispositivi, BOARD_BUILD_SYSTEM_ROOT_IMAGE deve essere vuoto. System-as-root non è supportato anche per i dispositivi che utilizzano partizioni dinamiche.

Configurazioni del prodotto

I dispositivi che utilizzano il ramdisk generico devono installare un elenco di file che possono essere installati nel 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 makefile di installare accidentalmente altri file nel ramdisk (sposta questi file in vendor_ramdisk invece).

Configura dispositivi

Le istruzioni di configurazione variano in base ai dispositivi lanciati con Android 13, a quelli con upgrade ad Android 12 e a quelli lanciati con Android 12. Android 13, la configurazione è simile a quella di Android 12

  • Dispositivi che eseguono l'upgrade ad Android 12:

    • Può preservare il valore di BOARD_USES_RECOVERY_AS_BOOT. In questo caso, utilizzano configurazioni precedenti e le nuove variabili di build 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 è mostrata nella Figura 4.

    • Può 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 è quella mostrata nella Figura 1 e l'opzione di configurazione del dispositivo è l'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.

  • 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 crea solo GKI (e non vendor_boot o recovery), non è una destinazione completa. Per le configurazioni di build aosp_arm64, consulta generic_arm64.

Opzione 1: nessuna partizione di ripristino dedicata

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

Impostare i valori di 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 collegamento simbolico da /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 collegamento simbolico /init viene sovrascritto. Quando il dispositivo si avvia in modalità di ripristino, è necessario il binario /system/bin/init per supportare l'inizializzazione 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 tutti i file fstab installati nel ramdisk generico in vendor_ramdisk. Per un esempio, consulta questa modifica.

Installare moduli

Puoi installare moduli specifici per il dispositivo per 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 in /first_stage_ramdisk. Questo modulo deve essere disponibile dopo che init passa alla radice in /first_stage_ramdisk, ma prima che init passi alla radice in /system. Per alcuni esempi, vedi Checksum dei metadati e Compressione A/B virtuale.

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

Console del primo turno

Poiché la console di primo livello viene avviata prima che init passi alla radice in /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 makefile del dispositivo eredita da questo file, non è necessario installare esplicitamente la variante recovery.

Per installare esplicitamente i moduli di ripristino, utilizza il seguente comando.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

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

Per aggiungere i moduli necessari per la console di primo livello (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.

Checksum 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/first_stage_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 in vendor_ramdisk. Il dispositivo deve 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:

  • Ramdisk build.prop si sposta in /second_stage_resources in modo che la seconda fase init possa leggere il timestamp di compilazione dell'avvio.

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

Rendere disponibile e2fsck

I makefile 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 makefile del prodotto installano $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. In fase di runtime, la prima fase init passa alla radice /first_stage_ramdisk, quindi esegue /system/bin/e2fsck.

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

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

AB_OTA_PARTITIONS += recovery

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

  • File fstab specifici per il dispositivo

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

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

Impostare i valori di 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 collegamento 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 collegamento simbolico /init viene sovrascritto. Quando il dispositivo si avvia in modalità di ripristino, è necessario il binario /system/bin/init per supportare l'inizializzazione della seconda fase.

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

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

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

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

Spostare i file fstab

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

Installare moduli

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

Console del primo turno

Per installare la variante vendor_ramdisk dei moduli, utilizza il seguente comando:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

Per aggiungere i moduli necessari per la console di prima fase (ad esempio adbd), attiva 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 ramdisk vendor_boot non viene caricato in modalità di ripristino, il dispositivo può facoltativamente installare anche adbd.recovery.

Checksum 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 per vendor_ramdisk. Il dispositivo deve 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. Il vendor_boot + ramdisk generico è 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 avvio normale.

Quando si avvia la modalità di recupero, il processo di avvio cambia. Il ramdisk di ripristino + vendor_boot + 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, quindi esegue le seguenti operazioni:

    1. Trasferisce il ramdisk di ripristino + vendor_boot + generico a /. (Se l'OEM duplica i moduli 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 ramdisk su /, quindi esegue /init dal ramdisk generico.

  3. L'inizializzazione della prima fase inizia, quindi esegue le seguenti operazioni:

    1. Imposta IsRecoveryMode() == true e ForceNormalBoot() == false.
    2. Carica i moduli 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 della seconda fase da /system/bin/init dal ramdisk recovery.

Rendere disponibile e2fsck

I makefile 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 makefile del prodotto installano $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. In fase di runtime, 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 suffisso di slot. Questi dispositivi includono:

  • dispositivi non A/B;
  • Dispositivi A/B e Virtual A/B, la cui partizione di ripristino non è aggiornabile. È una cosa insolita.

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

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

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

  • L'immagine del kernel
  • L'immagine DTBO
  • Moduli kernel in lib/modules
  • Inizializzazione di prima fase come link simbolico /init -> /system/bin/init
  • Binario init di secondo stadio /system/bin/init
  • File fstab specifici per il dispositivo
  • Tutte le altre risorse di ripristino, incluso il binario recovery

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

Impostare i valori di 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 collegamento simbolico /init -> /system/bin/init e init_second_stage.recovery in /system/bin/init. Quando il dispositivo si avvia in modalità di ripristino, è necessario il binario /system/bin/init per supportare l'inizializzazione della prima e della seconda fase.

Quando il dispositivo si avvia in recovery, i contenuti dei ramdisk recovery sono i seguenti:

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

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

  • /init (da ramdisk, creato da init_first_stage)

Spostare i file fstab

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

Installare moduli

Puoi installare moduli specifici per il dispositivo per vendor_ramdisk e recovery ramdisk (salta questo passaggio se non hai moduli specifici per il dispositivo da installare). init non cambia la root. La variante vendor_ramdisk dei moduli viene installata nella radice di vendor_ramdisk. La variante recovery dei moduli viene installata nella radice del ramdisk recovery. Per esempi di installazione di moduli su vendor_ramdisk e recovery ramdisk, consulta Console di prima fase e Checksum dei metadati.

Console del primo turno

Per installare la variante vendor_ramdisk dei moduli, utilizza il seguente comando:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

Per aggiungere i moduli necessari per la console di prima fase (ad esempio adbd), attiva 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 \

Checksum 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 supportare i checksum dei metadati durante il montaggio della prima fase nel 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. Il vendor_boot + ramdisk generico è 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 avvio normale.

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

  1. Il bootloader si avvia, quindi esegue le seguenti operazioni:

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

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

  3. L'inizializzazione della prima fase inizia, quindi esegue le seguenti operazioni:

    1. Imposta IsRecoveryMode() == true e ForceNormalBoot() == false.
    2. Carica i moduli 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 della seconda fase da /system/bin/init dal ramdisk recovery.

Timestamp delle immagini di avvio

Il seguente codice è un esempio di file di timestamp delle immagini 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, al ramdisk generico viene aggiunto un file system/etc/ramdisk/build.prop. Questo file contiene le informazioni sul timestamp della build.

  • In fase di runtime, la prima fase init copia i file dal ramdisk a tmpfs prima di liberare il ramdisk, in modo che la seconda fase init possa leggere questo file per impostare le proprietà del timestamp dell'immagine boot.