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 ramdiskvendor_boot
.Utilizzare una partizione
recovery
dedicata, non è necessaria alcuna modifica nel ramdiskrecovery
poiché il ramdiskrecovery
è 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
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)
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)
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
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)
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)
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)
Figura 7. Dispositivi che eseguono l'aggiornamento ad Android 12, senza GKI, ripristino all'avvio
Aggiornamento ad Android 12, ripristino dedicato (ramdisk 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). Ilboot.img
GKI certificato non è firmato per l'avvio verificato. Gli OEM devono comunque firmare ilboot.img
predefinito con una chiave AVB specifica del dispositivo. -
cmdline
generica (GENERIC_KERNEL_CMDLINE
) - kernel GKI
- Una
- Immagine ramdisk generica
- Incluso solo nelle immagini
boot
di Android 12 e versioni precedenti
- Incluso solo nelle immagini
- Versione testata 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 non è presente alcun ripristino dedicato)
-
- immagine
dtb
- intestazione
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 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
.
- Riga di
- 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 ramdiskvendor_boot
. - Il collegamento simbolico a
/init
può esistere, ma è messo in ombra dal binario/init
di prima fase nell'immagine di avvio.
- Versione intestazione V2
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/
- Directory vuote duplicate per i punti di montaggio:
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 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'immaginerecovery
come immagineboot
. 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 influisce sui 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 create suvendor_boot
.Se impostato su
true
, le risorse di ripristino vengono create solo suvendor-ramdisk/
e non surecovery/root/
.Quando sono vuote, le risorse di ripristino vengono create 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 create pervendor_boot
.Se impostato su
true
, seBOARD_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'immaginerecovery
contiene o meno un kernel. I dispositivi che si avviano con Android 12 e utilizzano la partizionerecovery
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/
nei 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 se viene generatoinit_boot.img
e imposta la dimensione. Quando impostato, il ramdisk generico viene aggiunto ainit_boot.img
anzichéboot.img
e richiede l'impostazione delle variabiliBOARD_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
sutrue
, 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
Binari Init 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 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 dainit_first_stage
) -
/system/bin/init
(davendor_ramdisk
, creato dainit_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 cheinit
ha cambiato root in/first_stage_ramdisk
ma prima cheinit
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 cheinit
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 cheinit
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 dispositivolib/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
Binari Init e collegamenti simbolici
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 dainit_first_stage
) -
/system/bin/init
(dal ramdiskrecovery
, creato 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, creato dainit_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.
Il Bootloader si avvia, quindi esegue le seguenti operazioni:
- Inserisce recovery+
vendor_boot
+ramdisk generico in/
. (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
boot
.
- Inserisce recovery+
Il kernel monta il ramdisk su
/
quindi esegue/init
dal ramdisk generico.Viene avviata la prima fase init, quindi esegue quanto segue:
- 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 di init da
/system/bin/init
dal ramdiskrecovery
.
- 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
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
Binari Init e collegamenti simbolici
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 ramdiskrecovery
) -
/system/bin/init
(dal ramdiskrecovery
, creato 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, creato dainit_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.
Il Bootloader si avvia, quindi esegue le seguenti operazioni:
- Inserisce il ramdisk di ripristino in
/
. - Esegue il kernel dalla partizione
recovery
.
- Inserisce il ramdisk di ripristino in
Il kernel monta il ramdisk su
/
quindi esegue/init
, che è un collegamento simbolico a/system/bin/init
dal ramdiskrecovery
.Viene avviata la prima fase init, quindi esegue quanto segue:
- 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 di init da
/system/bin/init
dal ramdiskrecovery
.
- Imposta
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 atmpfs
prima di liberare il ramdisk in modo cheinit
della seconda fase possa leggere questo file per impostare le proprietà del timestamp dell'immagineboot
.