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 avendor_boot
ramdisk.Utilizzare una partizione di
recovery
dedicata, non è necessaria alcuna modifica al ramdisk direcovery
poiché il ramdisk direcovery
è 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
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)
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)
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
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)
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)
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)
Figura 7. Aggiornamento dei dispositivi ad Android 12, nessuna GKI, ripristino all'avvio
Upgrade ad Android 12, recovery dedicata (ramdisk 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 GKIboot.img
non è firmato per l'avvio verificato. Gli OEM devono comunque firmare il fileboot.img
predefinito con una chiave AVB specifica per il dispositivo. -
cmdline
generica (GENERIC_KERNEL_CMDLINE
) - kernel GKI
- Una
- Immagine generica del ramdisk
- Incluso solo nelle immagini di
boot
di Android 12 e precedenti
- Incluso solo nelle immagini di
- Versione intestazione V3 o V4
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
- intestazione
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 aboot
evendor_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
evendor_boot
. Per esempio: -
cmdline
è concatenato aboot
evendor_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 invendor_boot
ramdisk. - Il collegamento simbolico in
/init
può esistere, ma è oscurato dal binario/init
di primo stadio nell'immagine di avvio.
- Testata versione V2
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/
- Directory vuote duplicate per i punti di montaggio:
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 sutrue
, impostaBOARD_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 direcovery
come immagine diboot
. Quando si utilizza GKI, questa variabile è vuota e le risorse di ripristino devono essere spostate invendor_boot
.BOARD_USES_GENERIC_KERNEL_IMAGE
. Questa variabile indica che la scheda utilizza GKI. Questa variabile non ha effetto su sysprops oPRODUCT_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 suvendor_boot
.Se impostato su
true
, le risorse di ripristino vengono compilate solo suvendor-ramdisk/
e non surecovery/root/
.Quando sono vuote, le risorse di ripristino vengono compilate solo su
recovery/root/
e non suvendor-ramdisk/
.
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT
. Questa variabile controlla se le chiavi GSI AVB sono costruite suvendor_boot
.Se impostato su
true
, seBOARD_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 direcovery
contiene un kernel o meno. I dispositivi che si avviano con Android 12 e utilizzano la partizione direcovery
A/B devono impostare questa variabile sutrue
. I dispositivi che si avviano con Android 12 e utilizzano non A/B devono impostare questa variabile sufalse
per mantenere l'immagine di ripristino autonoma.BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES
. Questa variabile controlla se$OUT/boot*.img
viene copiato inIMAGES/
sotto i file di destinazione.aosp_arm64
deve impostare questa variabile sutrue
.Gli altri dispositivi devono lasciare vuota questa variabile.
BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE
. Questa variabile controlla seinit_boot.img
viene generato e imposta la dimensione. Quando impostato, il ramdisk generico viene aggiunto ainit_boot.img
invece diboot.img
e richiede che le variabiliBOARD_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: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 dainit_first_stage
) -
/system/bin/init
(davendor_ramdisk
, compilato dainit_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 cheinit
passa a root in/first_stage_ramdisk
ma prima cheinit
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 cheinit
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 stadioinit
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 dispositivolib/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 dainit_first_stage
) -
/system/bin/init
(darecovery
ramdisk, compilato dainit_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 dainit_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
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/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 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:
- Spinge recovery +
vendor_boot
+ generico ramdisk su/
. (Se l'OEM duplica i moduli del kernel nel ramdisk di ripristino aggiungendoli aBOARD_RECOVERY_KERNEL_MODULES
),vendor_boot
è facoltativo.) - Esegue il kernel dalla partizione di
boot
.
- Spinge recovery +
Il kernel monta ramdisk su
/
quindi esegue/init
dal ramdisk generico.Inizia la prima fase init, quindi esegue le seguenti operazioni:
- Imposta
IsRecoveryMode() == true
eForceNormalBoot() == false
. - Carica i moduli del kernel del fornitore da
/lib/modules
. - Chiama
DoFirstStageMount()
ma salta il montaggio perchéIsRecoveryMode() == true
. (Il dispositivo non libera ramdisk (perché/
è sempre lo stesso) ma chiamaSetInitAvbVersionInRecovery()
.) - Avvia la seconda fase init da
/system/bin/init
dal ramdisk direcovery
.
- Imposta
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 direcovery
) -
/system/bin/init
(darecovery
ramdisk, compilato dainit_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 dainit_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
.
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
.
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
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/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, abilitare la variante di ripristino di questi moduli e installarli anche loro.
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 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:
- Spinge il ramdisk di ripristino su
/
. - Esegue il kernel dalla partizione di
recovery
.
- Spinge il ramdisk di ripristino su
Il kernel monta ramdisk su
/
quindi esegue/init
, che è un collegamento simbolico a/system/bin/init
dal ramdisk direcovery
.Inizia la prima fase init, quindi esegue le seguenti operazioni:
- Imposta
IsRecoveryMode() == true
eForceNormalBoot() == false
. - Carica i moduli del kernel del fornitore da
/lib/modules
. - Chiama
DoFirstStageMount()
ma salta il montaggio perchéIsRecoveryMode() == true
. (Il dispositivo non libera ramdisk (perché/
è sempre lo stesso) ma chiamaSetInitAvbVersionInRecovery()
.) - Avvia la seconda fase init da
/system/bin/init
dal ramdisk direcovery
.
- Imposta
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 atmpfs
prima di liberare il ramdisk in modo che la seconda faseinit
possa leggere questo file per impostare le proprietà del timestamp dell'immagine diboot
.