Questa pagina è stata tradotta dall'API Cloud Translation.

Partizione di avvio generica

In Android 12, l'immagine di 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 di boot e posizionato in un'immagine init_boot separata. Questa modifica lascia l'immagine di boot solo con il kernel GKI.

Per l'aggiornamento dei dispositivi che continuano a utilizzare Android 12 o versioni precedenti del kernel, il ramdisk generico rimane dove si trovava 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 l' init della prima fase e un file delle proprietà che contenga informazioni sul timestamp.

Su dispositivi che:

Non utilizzare una partizione di recovery dedicata, tutti i bit di ripristino si spostano dal ramdisk generico a vendor_boot ramdisk.
Utilizzare una partizione di recovery dedicata, non è necessaria alcuna modifica al ramdisk di recovery poiché il ramdisk di recovery è autonomo.

Architettura

I diagrammi seguenti 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, nessun ripristino dedicato

Avvia/aggiorna dispositivo, GKI, nessun ripristino dedicato

Figura 1. Dispositivi in fase di avvio o aggiornamento ad Android 13, con GKI, nessun ripristino dedicato

Avvia con Android 13, dedicato e A/B recovery (ramdisk dedicato)

Avvia/aggiorna dispositivo, GKI, dedicato e ripristino A/B

Figura 2. Dispositivi in fase di avvio o 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 .

Avvia con Android 13, recovery dedicata e non A/B (ramdisk dedicato)

Avvia/aggiorna dispositivo, GKI, recovery dedicata e non A/B

Figura 3. Dispositivi in fase di avvio o 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 un suffisso di slot.

Avvia o aggiorna ad Android 12, nessun ripristino dedicato

Avvia/aggiorna dispositivo, GKI, nessun ripristino dedicato

Figura 4. Dispositivi in fase di avvio o aggiornamento ad Android 12, con GKI, nessun ripristino dedicato

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

Avvia/aggiorna dispositivo, GKI, dedicato e ripristino A/B

Figura 5. Dispositivi che si avviano o si aggiornano 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, recovery dedicata e non A/B (ramdisk dedicato)

Avvia/aggiorna dispositivo, GKI, recovery dedicata e non A/B

Figura 6. Dispositivi in fase di avvio o 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 un suffisso di slot.

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

Avvia/aggiorna il dispositivo, nessuna GKI, ripristino all'avvio

Figura 7. Aggiornamento dei dispositivi ad Android 12, nessuna GKI, ripristino all'avvio

Upgrade ad Android 12, recovery dedicata (ramdisk dedicato)

Avvia/aggiorna il dispositivo, nessuna GKI, ripristino dedicato

Figura 8. Aggiornamento dei dispositivi ad Android 12, nessuna GKI, ripristino dedicato

Contenuto delle immagini di avvio

Le immagini di avvio di Android contengono quanto segue.

immagine init_boot aggiunta per dispositivi che si avviano con Android 13
- Testata versione V4
- Immagine generica del ramdisk
Immagine di boot generica
- Versione intestazione V3 o V4
  - Una boot_signature per la certificazione GKI boot.img (solo v4). Il certificato GKI boot.img non è firmato per l'avvio verificato. Gli OEM devono comunque firmare il file boot.img predefinito con una chiave AVB specifica per il dispositivo.
  - cmdline generica ( GENERIC_KERNEL_CMDLINE )
  - kernel GKI
- Immagine generica del ramdisk
  - Incluso solo nelle immagini di boot di Android 12 e 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 nessun ripristino dedicato)
- immagine dtb
immagine di recovery
- Testata versione V2
  - 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 disco ram di 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 necessari per avviare la modalità di ripristino
  - Il ramdisk di ripristino deve contenere init .
  - Per la partizione di ripristino A/B, il ramdisk di ripristino è anteposto al ramdisk generico e vendor_boot , quindi 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 in vendor_boot ramdisk.
  - Il collegamento simbolico in /init può esistere, ma è oscurato dal binario /init di primo stadio nell'immagine di avvio.

Contenuto dell'immagine ramdisk generico

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 come vengono create le immagini init_boot , boot , recovery e vendor_boot . Il valore di una variabile board booleana deve essere la stringa true o essere vuota (che è l'impostazione predefinita).

TARGET_NO_KERNEL . Questa variabile indica se la build utilizza un'immagine di avvio precompilata. 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 di recovery come immagine di 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 ha effetto su 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 compilate su vendor_boot .
- Se impostato su true , le risorse di ripristino vengono compilate solo su vendor-ramdisk/ e non su recovery/root/ .
- Quando sono vuote, le risorse di ripristino vengono compilate 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 costruite su vendor_boot .
- Se impostato su true , se BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :
  - È impostato, le chiavi GSI AVB sono costruite su $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb .
  - Non è impostato, le chiavi GSI AVB sono compilate in $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb .
- Quando è vuoto, se BOARD_RECOVERY_AS_ROOT :
  - È impostato, le chiavi GSI AVB sono costruite su $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb .
  - Non è impostato, le chiavi GSI AVB sono costruite in $ANDROID_PRODUCT_OUT/ramdisk/avb .
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE . Questa variabile controlla se l'immagine di recovery contiene un kernel o meno. I dispositivi che si avviano con Android 12 e utilizzano la partizione di 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/ sotto i 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 imposta la dimensione. Quando impostato, il ramdisk generico viene aggiunto a init_boot.img invece di boot.img e richiede che le variabili BOARD_AVB_INIT_BOOT* siano impostate per vbmeta concatenato

Combinazioni consentite

Componente o variabile	Aggiornamento del dispositivo senza partizione di `recovery`	Aggiornamento del dispositivo con partizione di `recovery`	Avvia il dispositivo senza partizione di `recovery`	Avvia il dispositivo con la partizione di `recovery` A/B	Avvia il dispositivo con una partizione di `recovery` non A/B	aosp_arm64
Contiene `boot`	sì	sì	sì	sì	sì	sì
Contiene `init_boot` (Android 13)	No	No	No	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 di recovery dedicata possono impostare PRODUCT_BUILD_RECOVERY_IMAGE su true o empty. Per questi dispositivi, se è impostato BOARD_RECOVERYIMAGE_PARTITION_SIZE , viene creata un'immagine di recovery .

Abilita vbmeta concatenato per l'avvio

La vbmeta concatenata deve essere abilitata per le immagini di 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 usano GKI. Su tali dispositivi, BOARD_BUILD_SYSTEM_ROOT_IMAGE deve essere vuoto. Anche System-as-root non è supportato per i dispositivi che usano 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 anche 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 avviati con Android 13, l'aggiornamento ad Android 12 e l'avvio con Android 12. Android 13, sono configurati in modo simile a come erano con Android 12

Aggiornamento dei dispositivi ad Android 12:
- Può preservare il valore di BOARD_USES_RECOVERY_AS_BOOT . In tal caso, utilizzano 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 è quella mostrata in Figura 4 .
- Può impostare BOARD_USES_RECOVERY_AS_BOOT su vuoto. Se lo fanno, stanno usando nuove configurazioni. Se tali dispositivi:
  - Non utilizzare una partizione di recovery dedicata, l'architettura è mostrata nella figura 1 e l'opzione di configurazione del dispositivo è l' opzione 1 .
  - Utilizzare una partizione di recovery dedicata, l'architettura è mostrata nella Figura 2a o nella Figura 2b e l'opzione di configurazione del dispositivo è l' Opzione 2a o l' Opzione 2b .
I dispositivi che si avviano con Android 12 devono impostare BOARD_USES_RECOVERY_AS_BOOT per svuotare e utilizzare nuove configurazioni. Se tali dispositivi:
- Non utilizzare una partizione di recovery dedicata, l'architettura è mostrata nella figura 1 e l'opzione di configurazione del dispositivo è l' opzione 1 .
- Utilizzare una partizione di recovery dedicata, l'architettura è mostrata nella Figura 2a o nella Figura 2b e l'opzione di configurazione del dispositivo è l' Opzione 2a o l' Opzione 2b .

Poiché aosp_arm64 solo GKI (e non vendor_boot o recovery), non è un obiettivo completo. Per le configurazioni di build di aosp_arm64 , fare riferimento a generic_arm64 .

Opzione 1: nessuna partizione di ripristino dedicata

I dispositivi senza una partizione di recovery contengono l'immagine di boot generica nella partizione di boot . Il ramdisk vendor_boot contiene tutte le risorse di ripristino, incluso 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

Impostare 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

Init binari e collegamenti simbolici

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 recovery, è necessario il file binario /system/bin/init per supportare la seconda fase init. I contenuti di vendor_boot + ramdisk generici sono i seguenti:

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

Spostamento di file fstab

Sposta tutti i file fstab che sono stati installati sul ramdisk generico in 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 passa a root in /first_stage_ramdisk ma prima che init passi a root in /system . Per esempi, consulta Checksum dei metadati e Compressione A/B virtuale .
Utilizzare la variante di recovery del modulo quando il modulo viene installato in / . Questo modulo dovrebbe essere disponibile prima che init passi a root in /first_stage_ramdisk . Per i dettagli sull'installazione dei moduli su / , vedere Console di prima fase .

Consolle del primo stadio

Poiché la console della prima fase viene avviata prima che init passi a root in /first_stage_ramdisk , è necessario installare la variante di 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 quel file non è necessario installare esplicitamente la variante di 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 installati su $ANDROID_PRODUCT_OUT/recovery/root/system/bin , che quindi venga 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 venga 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 moduli seguenti. 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, 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 recovery o in Android non cambia, con la seguente eccezione:

Ramdisk build.prop si sposta in /second_stage_resources in modo che il secondo stadio init possa leggere il timestamp di build di avvio.

Poiché le risorse si spostano da ramdisk generico a vendor_boot ramdisk, il risultato della concatenazione di ramdisk generico a vendor_boot ramdisk 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, la prima fase init passa a root in /first_stage_ramdisk quindi esegue /system/bin/e2fsck .

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

Utilizzare questa opzione per i dispositivi con partizioni di recovery A/B; ovvero, il dispositivo ha una recovery_b partition recovery_a e recovery_b . Tali dispositivi includono dispositivi A/B e Virtual A/B di cui è aggiornabile la partizione di ripristino, con la seguente configurazione:

AB_OTA_PARTITIONS += recovery

Il vendor_boot ramdisk 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 di recovery contiene tutte le risorse di ripristino. Su tali dispositivi, la configurazione del prodotto eredita da generic_ramdisk.mk .

Impostazione dei valori BOARD

Impostare i seguenti valori per i dispositivi con partizione di 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

Init binari e collegamenti simbolici

Il ramdisk di 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 di 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 init.

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 (da recovery ramdisk, compilato da init_second_stage.recovery ed eseguito da /init )

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

/init (da ramdisk generico, compilato da init_first_stage )

Spostamento di file fstab

Sposta tutti i file fstab che sono stati installati sul ramdisk generico in 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 vendor_ramdisk dei moduli viene installata nella radice di vendor_ramdisk . Per esempi sull'installazione di moduli su vendor_ramdisk , vedere Console di 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 installati su $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , che quindi venga installato su /system/bin sotto vendor_ramdisk .

Per aggiungere i moduli necessari per la console della 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 in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin . Se il ramdisk vendor_boot viene caricato in modalità di ripristino, il modulo è disponibile anche in modalità di recovery . Se il ramdisk vendor_boot non è caricato in modalità di ripristino, il dispositivo può opzionalmente installare anche adbd.recovery .

Checksum dei metadati

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

Bootloader si avvia, quindi esegue le seguenti operazioni:
1. Spinge recovery + vendor_boot + generico ramdisk su / . (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 di boot .
Il kernel monta ramdisk su / quindi esegue /init dal ramdisk generico.
Inizia la prima fase init, quindi esegue le seguenti operazioni:
1. Imposta IsRecoveryMode() == true e ForceNormalBoot() == false .
2. Carica i moduli del kernel del fornitore da /lib/modules .
3. Chiama DoFirstStageMount() ma salta il montaggio perché IsRecoveryMode() == true . (Il dispositivo non libera ramdisk (perché / è sempre lo stesso) ma chiama SetInitAvbVersionInRecovery() .)
4. Avvia la seconda fase init da /system/bin/init dal ramdisk di 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

Utilizzare questa opzione per i dispositivi con una partizione di recovery non A/B; ovvero, il dispositivo ha una partizione denominata recovery senza un suffisso di slot. Tali dispositivi includono:

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

Il vendor_boot ramdisk 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 di 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 init della seconda fase /system/bin/init
File fstab specifici del dispositivo
Tutte le altre risorse di ripristino, incluso il file binario di recovery , ecc.
eccetera.

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

Impostazione dei valori BOARD

Impostare 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

Init binari e collegamenti simbolici

Il ramdisk di 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 fase che la seconda fase init.

Quando il dispositivo si avvia in recovery , il contenuto dei dischi ram di recovery è il seguente:

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

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

/init (da ramdisk, compilato da init_first_stage )

Spostamento di file fstab

Sposta tutti i file fstab che sono stati installati sul ramdisk generico nel vendor_ramdisk e nel ramdisk di 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 vendor_ramdisk dei moduli viene installata nella radice di vendor_ramdisk . La variante di recovery dei moduli viene installata nella radice del ramdisk di recovery . Per esempi sull'installazione di moduli su vendor_ramdisk e recovery ramdisk, vedere Console di 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 installati su $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , che quindi venga installato su /system/bin sotto vendor_ramdisk .

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Per installare la variante di recovery dei moduli, sostituire vendor_ramdisk con recovery :

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

Checksum dei metadati

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, abilitare la variante di ripristino di questi moduli e installarli anche loro.

Modifiche al processo di avvio

Quando si avvia in modalità di ripristino, il processo di avvio non cambia. Il ramdisk di ripristino viene caricato allo stesso modo del processo di ripristino esistente. Il kernel viene caricato dall'immagine di recovery . Il processo di avvio per la modalità di ripristino è il seguente.

Bootloader si avvia, quindi esegue le seguenti operazioni:
1. Spinge il ramdisk di ripristino su / .
2. Esegue il kernel dalla partizione di recovery .
Il kernel monta ramdisk su / quindi esegue /init , che è un collegamento simbolico a /system/bin/init dal ramdisk di recovery .
Inizia la prima fase init, quindi esegue le seguenti operazioni:
1. Imposta IsRecoveryMode() == true e ForceNormalBoot() == false .
2. Carica i moduli del kernel del fornitore da /lib/modules .
3. Chiama DoFirstStageMount() ma salta il montaggio perché IsRecoveryMode() == true . (Il dispositivo non libera ramdisk (perché / è sempre lo stesso) ma chiama SetInitAvbVersionInRecovery() .)
4. Avvia la seconda fase init da /system/bin/init dal ramdisk di recovery .

Timestamp dell'immagine di avvio

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

####################################
# 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 system/etc/ramdisk/build.prop viene aggiunto al ramdisk generico. Questo file contiene informazioni sul timestamp della build.
In fase di esecuzione, 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 di boot .