Partizione di avvio generica

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

Per i dispositivi avviati 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 con solo il kernel GKI.

Per l'aggiornamento dei dispositivi che continuano a utilizzare Android 12 o versioni precedenti del kernel, il ramdisk generico rimane dov'era senza la necessità di una nuova immagine init_boot .

Per creare un ramdisk generico, spostare le risorse specifiche del fornitore fuori dal ramdisk in modo che il ramdisk generico contenga solo init della prima fase e un file delle proprietà che contiene 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 .

  • Utilizzare una partizione recovery dedicata, non è necessaria alcuna modifica nel ramdisk recovery poiché il ramdisk recovery è autonomo.

Architettura

I seguenti diagrammi illustrano l'architettura per i dispositivi con Android 12 e versioni successive. L'avvio del dispositivo con Android 13 ha una nuova immagine init_boot contenente il ramdisk generico. I dispositivi che eseguono l'aggiornamento da Android 12 ad Android 13 utilizzano la stessa architettura di Android 12.

Avvia con Android 13, nessuna recovery dedicata

Dispositivo di avvio/aggiornamento, GKI, nessun ripristino dedicato

Figura 1. Dispositivi che si avviano o eseguono l'aggiornamento ad Android 13, con GKI, senza ripristino dedicato

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

Dispositivo di avvio/aggiornamento, GKI, ripristino dedicato e A/B

Figura 2. Dispositivi che si avviano o eseguono l'aggiornamento ad Android 13, con GKI, dedicato e ripristino A/B

Fare riferimento a questa figura se il dispositivo dispone di partizioni recovery_a e recovery_b .

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

Dispositivo di avvio/aggiornamento, GKI, ripristino dedicato e non A/B

Figura 3. Dispositivi che si avviano o eseguono l'aggiornamento ad Android 13, con GKI, ripristino dedicato e non A/B

Fare riferimento a questa figura se il dispositivo dispone di una partizione denominata recovery senza suffisso slot.

Avvia o esegui l'aggiornamento ad Android 12, senza ripristino dedicato

Dispositivo di avvio/aggiornamento, GKI, nessun ripristino dedicato

Figura 4. Dispositivi che si avviano o eseguono l'aggiornamento ad Android 12, con GKI, senza ripristino dedicato

Avvia o aggiorna ad Android 12, ripristino dedicato e A/B (ramdisk dedicato)

Dispositivo di avvio/aggiornamento, GKI, ripristino dedicato e A/B

Figura 5. Dispositivi in ​​fase di avvio o aggiornamento ad Android 12, con GKI, dedicato e ripristino A/B

Fare riferimento a questa figura se il dispositivo dispone di partizioni recovery_a e recovery_b .

Avvia o aggiorna ad Android 12, ripristino dedicato e non A/B (ramdisk dedicato)

Dispositivo di avvio/aggiornamento, GKI, ripristino dedicato e non A/B

Figura 6. Dispositivi che si avviano o eseguono l'aggiornamento ad Android 12, con GKI, ripristino dedicato e non A/B

Fare riferimento a questa figura se il dispositivo dispone di una partizione denominata recovery senza suffisso slot.

Aggiornamento ad Android 12, ripristino come avvio (ripristino come ramdisk)

Dispositivo di avvio/aggiornamento, senza GKI, ripristino all'avvio

Figura 7. Dispositivi che eseguono l'aggiornamento ad Android 12, senza GKI, ripristino all'avvio

Aggiornamento ad Android 12, ripristino dedicato (ramdisk dedicato)

Dispositivo di avvio/aggiornamento, senza GKI, ripristino dedicato

Figura 8. Dispositivi che eseguono l'aggiornamento ad Android 12, senza GKI, ripristino dedicato

Contenuto delle immagini di avvio

Le immagini di avvio Android contengono quanto segue.

  • Immagine init_boot aggiunta per i dispositivi che si avviano con Android 13

    • Versione intestazione V4
    • Immagine ramdisk generica

  • Immagine boot generica

    • Versione testata V3 o V4
      • Una boot_signature per la certificazione GKI boot.img (solo v4). Il boot.img GKI certificato non è firmato per l'avvio verificato. Gli OEM devono comunque firmare il boot.img predefinito con una chiave AVB specifica del dispositivo.
      • cmdline generica ( GENERIC_KERNEL_CMDLINE )
      • kernel GKI
    • Immagine ramdisk generica
      • Incluso solo nelle immagini boot di Android 12 e versioni precedenti

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

    • intestazione vendor_boot
      • cmdline specifica del dispositivo ( BOARD_KERNEL_CMDLINE )
    • immagine ramdisk vendor_boot
      • lib/modules
      • Risorse di ripristino (se non è presente alcun ripristino dedicato)
    • immagine dtb

  • immagine recovery

    • Versione intestazione V2
      • Riga di cmdline specifica del dispositivo per il ripristino, se necessario
      • Per la partizione di ripristino non A/B, il contenuto dell'intestazione deve essere autonomo; vedere Immagini di ripristino . Per 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 . Per esempio:
      • cmdline è concatenato a boot e vendor_boot cmdline .
      • DTBO può essere dedotto dall'intestazione vendor_boot .
    • immagine del ramdisk recovery
      • Risorse di recupero
      • Per la partizione di ripristino non A/B, il contenuto del ramdisk deve essere autonomo; vedere Immagini di ripristino . Per esempio:
      • lib/modules deve contenere tutti i moduli del kernel richiesti per avviare la modalità di ripristino
      • 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 è necessario che sia autonomo. Per esempio:
      • lib/modules può contenere solo moduli kernel aggiuntivi richiesti per avviare la modalità di ripristino oltre ai moduli kernel nel ramdisk vendor_boot .
      • Il collegamento simbolico a /init può esistere, ma è messo in ombra dal binario /init di prima fase nell'immagine di avvio.

Contenuto dell'immagine ramdisk generica

Il ramdisk generico contiene i seguenti componenti.

  • init
  • Aggiunto system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build oggetti di scena
  • 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 il modo in cui vengono create le immagini init_boot , boot , recovery e vendor_boot . Il valore di una variabile booleana della scheda deve essere la stringa true o essere vuoto (che è l'impostazione predefinita).

  • 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 sui sysprops o PRODUCT_PACKAGES .

    Questo è lo switch GKI a livello di scheda; tutte le variabili elencate di seguito sono limitate da questa variabile.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . Questa variabile controlla se le risorse di ripristino del ramdisk sono create su vendor_boot .

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

    • Quando sono vuote, le risorse di ripristino vengono create solo su recovery/root/ e non su 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 :

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

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

    • Quando vuoto, se BOARD_RECOVERY_AS_ROOT :

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

      • Se non viene impostato, le chiavi GSI AVB vengono create su $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 che si avviano con Android 12 e utilizzano la partizione recovery A/B devono impostare questa variabile su true . I dispositivi che si avviano con Android 12 e 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 viene generato init_boot.img e imposta la dimensione. Quando impostato, il ramdisk generico viene aggiunto a init_boot.img anziché boot.img e richiede l'impostazione delle variabili BOARD_AVB_INIT_BOOT* per vbmeta concatenato

Combinazioni consentite

Componente o variabile Aggiornamento del dispositivo senza partizione recovery Aggiornamento del dispositivo con partizione recovery Avvia il dispositivo senza partizione recovery Avvia il dispositivo con partizione recovery A/B Avvia il dispositivo con partizione recovery 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 opzionale opzionale 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 è impostato BOARD_RECOVERYIMAGE_PARTITION_SIZE , viene creata un'immagine recovery .

Abilita vbmeta concatenato per l'avvio

vbmeta concatenato deve essere abilitato per le immagini boot e init_boot . Specificare 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, fare riferimento a questa modifica .

Sistema come root

System-as-root non è supportato per i dispositivi che utilizzano GKI. Su tali dispositivi, BOARD_BUILD_SYSTEM_ROOT_IMAGE deve essere vuoto. Inoltre, System-as-root non è supportato 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 sul ramdisk. Per fare ciò, 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 sul ramdisk (spostare invece tali file su vendor_ramdisk ).

Configurazione dei dispositivi

Le istruzioni di configurazione differiscono tra i dispositivi che si avviano con Android 13, che eseguono l'aggiornamento ad Android 12 e che si avviano con Android 12. Android 13, sono configurati in modo simile a come erano con Android 12

  • Dispositivi che si aggiornano ad Android 12:

    • Può preservare il valore di BOARD_USES_RECOVERY_AS_BOOT . Se lo fanno, stanno utilizzando configurazioni legacy e le nuove variabili di build devono essere vuote. Se tali dispositivi:

      • Impostare BOARD_USES_RECOVERY_AS_BOOT su true , l'architettura è quella mostrata nella Figura 3 .

      • Impostare BOARD_USES_RECOVERY_AS_BOOT su vuoto, l'architettura è come mostrata nella Figura 4 .

    • È possibile impostare BOARD_USES_RECOVERY_AS_BOOT su vuoto. Se lo fanno, stanno utilizzando 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 .

      • Utilizzare 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 avviati con Android 12 devono impostare BOARD_USES_RECOVERY_AS_BOOT su vuoto e utilizzare 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 .

    • Utilizzare 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 compila solo GKI (e non vendor_boot o recovery), non è un obiettivo completo. Per le configurazioni di build aosp_arm64 , fare riferimento a 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 ripristino, inclusi lib/modules (con i moduli del kernel del fornitore). Su tali dispositivi, la configurazione del prodotto eredita da generic_ramdisk.mk .

Impostazione dei 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 collegamento simbolico da /init a /system/bin/init e init_second_stage.recovery a /system/bin/init . Tuttavia, poiché il ramdisk generico è concatenato dopo il ramdisk vendor_boot , il collegamento simbolico /init viene sovrascritto. Quando il dispositivo si avvia in modalità di ripristino, è necessario il file binario /system/bin/init per supportare la seconda fase di inizializzazione. 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 )

Spostamento di file fstab

Spostare tutti i file fstab installati sul ramdisk generico su vendor_ramdisk . Per un esempio, fare riferimento a questa modifica .

Installazione dei moduli

Se lo desideri, puoi installare moduli specifici del dispositivo su vendor_ramdisk (salta questo passaggio se non hai moduli specifici del dispositivo da installare).

  • Utilizzare la variante vendor_ramdisk del modulo quando il modulo viene installato su /first_stage_ramdisk . Questo modulo dovrebbe essere disponibile dopo che init ha cambiato root in /first_stage_ramdisk ma prima che init abbia cambiato root in /system . Per esempi, consulta Checksum dei metadati e compressione A/B virtuale .

  • Utilizzare la variante recovery del modulo quando il modulo viene installato in / . Questo modulo dovrebbe essere disponibile prima che init diventi root in /first_stage_ramdisk . Per dettagli sull'installazione dei moduli su / , vedere Console della prima fase .

Consolle del primo stadio

Poiché la console di prima fase si avvia prima che init passi a root in /first_stage_ramdisk , è necessario 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 makefile del dispositivo eredita da quel file non è necessario installare esplicitamente la variante recovery .

Per installare in modo esplicito i moduli di ripristino, utilizzare quanto segue.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Ciò garantisce che linker , sh e toybox vengano installati su $ANDROID_PRODUCT_OUT/recovery/root/system/bin , che quindi verrà installato su /system/bin sotto vendor_ramdisk .

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

PRODUCT_PACKAGES += adbd.recovery

Ciò garantisce che i moduli specificati vengano installati su $ANDROID_PRODUCT_OUT/recovery/root/system/bin , che quindi verrà installato su /system/bin sotto 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 su $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin :

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

Per un esempio, fare riferimento a 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 al processo di avvio

Il processo di avvio in ripristino o in Android non cambia, con la seguente eccezione:

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

Poiché le risorse si spostano 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 esecuzione, l' init della prima fase passa da root a /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 recovery A/B; ovvero, il dispositivo ha una recovery_b partition recovery_a e recovery_b . Tali dispositivi includono dispositivi A/B e A/B virtuali la cui 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, inclusi i seguenti:

  • File fstab specifici del dispositivo

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

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

Impostazione dei 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 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 file binario /system/bin/init per supportare la seconda fase di inizializzazione.

Quando il dispositivo si avvia in recovery , il contenuto di recovery + vendor_boot + RamDisks generici è il seguente:

  • /init (da ramdisk, creato da init_first_stage )
  • /system/bin/init (dal 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 )

Spostamento di file fstab

Spostare tutti i file fstab installati sul ramdisk generico su vendor_ramdisk . Per un esempio, fare riferimento a questa modifica .

Installazione dei moduli

Se lo desideri, puoi installare moduli specifici del dispositivo su vendor_ramdisk (salta questo passaggio se non hai moduli specifici del dispositivo da installare). Init non cambia root. La variante dei moduli vendor_ramdisk viene installata nella root di vendor_ramdisk . Per esempi sull'installazione dei moduli su vendor_ramdisk , vedere Console della prima fase , Checksum dei metadati e Compressione A/B virtuale .

Consolle del primo stadio

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Ciò garantisce che linker , sh e toybox vengano installati su $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , che quindi verrà installato su /system/bin sotto vendor_ramdisk .

Per aggiungere i moduli necessari per la console di prima fase (ad esempio, adbd), abilitare la variante vendor_ramdisk di questi moduli caricando le patch pertinenti su AOSP, quindi utilizzare quanto segue,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Ciò garantisce che i moduli specificati vengano installati su $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin . Se il ramdisk vendor_boot viene caricato in modalità ripristino, il modulo è disponibile anche in recovery . Se il ramdisk vendor_boot non è 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 su $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin :

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

Per un esempio, fare riferimento a 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 al processo di avvio

Quando si avvia in Android, il processo di avvio non cambia. Il vendor_boot + Ramdisk generico è simile al processo 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 in modalità di ripristino, il processo di avvio cambia. Il processo di ripristino + vendor_boot + ramdisk generico è simile al processo di ripristino esistente, ma il kernel viene caricato dall'immagine boot anziché dall'immagine recovery . Il processo di avvio per la modalità di ripristino è il seguente.

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

    1. Inserisce 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 la prima fase init, quindi 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 ramdisk (perché / è sempre lo stesso) ma chiama SetInitAvbVersionInRecovery() .)
    4. Avvia la seconda fase di init 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 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 suffisso slot. Tali dispositivi includono:

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

Il ramdisk vendor_boot contiene i bit del fornitore del ramdisk e dei moduli del kernel del fornitore, inclusi i seguenti:

  • File fstab specifici del dispositivo
  • lib/modules (include 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
  • Init di prima fase come collegamento simbolico /init -> /system/bin/init
  • Binario di init di seconda fase /system/bin/init
  • File fstab specifici del dispositivo
  • Tutte le altre risorse di ripristino, incluso il file binario recovery , ecc.
  • eccetera.

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

Impostazione dei 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 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 file binario /system/bin/init per supportare sia la prima che la seconda fase di init.

Quando il dispositivo si avvia in recovery , il contenuto dei ramdisk recovery è il seguente:

  • /init -> /system/bin/init (dal ramdisk recovery )
  • /system/bin/init (dal 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 )

Spostamento di file fstab

Spostare tutti i file fstab installati sul ramdisk generico su vendor_ramdisk e sul ramdisk recovery . Per un esempio, fare riferimento a questa modifica .

Installazione dei moduli

Se lo desideri, puoi installare moduli specifici del dispositivo su vendor_ramdisk e recovery Ramdisk (salta questo passaggio se non hai moduli specifici del dispositivo da installare). init non cambia root. La variante dei moduli vendor_ramdisk viene installata nella root di vendor_ramdisk . La variante di recovery dei moduli viene installata nella root del ramdisk di recovery . Per esempi sull'installazione dei moduli su vendor_ramdisk e recovery Ramdisk, vedere Console della prima fase e checksum dei metadati .

Consolle del primo stadio

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Ciò garantisce che linker , sh e toybox vengano installati su $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , che quindi verrà installato su /system/bin sotto vendor_ramdisk .

Per aggiungere i moduli necessari per la console di prima fase (ad esempio, adbd), abilitare la variante vendor_ramdisk di questi moduli caricando le patch pertinenti su AOSP, quindi utilizzare quanto segue,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Ciò garantisce che i moduli specificati vengano installati su $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin .

Per installare la variante recovery dei moduli, sostituire 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 su $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 del ripristino, abilitare la variante di ripristino di questi moduli e installarli anch'essi.

Modifiche al processo di avvio

Quando si avvia in Android, il processo di avvio non cambia. Il vendor_boot + Ramdisk generico è simile al processo 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 in modalità di ripristino, il processo di avvio non cambia. Il ramdisk di ripristino viene caricato nello stesso modo del processo di ripristino esistente. Il kernel viene caricato dall'immagine recovery . Il processo di avvio per la modalità di ripristino è il seguente.

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

    1. Inserisce il ramdisk di ripristino in / .
    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 la prima fase init, quindi 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 ramdisk (perché / è sempre lo stesso) ma chiama SetInitAvbVersionInRecovery() .)
    4. Avvia la seconda fase di init da /system/bin/init dal ramdisk recovery .

Timestamp dell'immagine di avvio

Il codice seguente è un esempio di file 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

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

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