Partizione di avvio generica

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

Per i dispositivi che verranno lanciati con Android 13, le norme ramdisk viene rimosso dall'immagine boot e posizionato in un elemento init_boot separato dell'immagine. Questa modifica lascia l'immagine boot con solo con il kernel GKI.

Per l'upgrade dei dispositivi che continuano a usare Android 12 o versioni precedenti del kernel, il ramdisk generico rimane dove si trovava nessun requisito per una nuova immagine init_boot.

Per creare un ramdisk generico, sposta le risorse specifiche del fornitore fuori dal ramdisk in modo che il ramdisk generico contenga solo la prima fase init e una proprietà contenente informazioni sul timestamp.

Sui dispositivi che:

  • Non utilizzare una partizione recovery dedicata, tutti i bit di ripristino si spostano da un ramdisk generico a vendor_boot ramdisk.

  • Usa una partizione recovery dedicata, nessuna modifica al ramdisk recovery perché il ramdisk recovery è indipendente.

Architettura

I seguenti diagrammi illustrano l'architettura per i dispositivi che eseguono Android 12 e successive. Il dispositivo lanciato con Android 13 ha una nuova Immagine init_boot contenente il ramdisk generico. Upgrade di dispositivi da Android 12 ad Android 13 usano la stessa architettura che hanno fatto con Android 12.

Avvia con Android 13, senza recupero dedicato

Avvia/esegui l'upgrade del dispositivo, GKI, nessun dispositivo di recupero dedicato

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

Lancio di Android 13, recupero A/B e dedicato (ramdisk dedicato)

Avvia/esegui l'upgrade del dispositivo, GKI, dedicato e ripristino A/B

Figura 2. Dispositivi che verranno introdotti o eseguono l'upgrade ad Android 13, con GKI, recupero A/B e dedicato.

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

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

Avvia/esegui l'upgrade del dispositivo, GKI, recupero dedicato e non A/B

Figura 3. Dispositivi che verranno introdotti o eseguono l'upgrade ad Android 13, con GKI, recupero dedicato e non A/B.

Fai riferimento a questa figura se il dispositivo ha una partizione denominata recovery senza un suffisso dell'area annuncio.

Avvia o esegui l'upgrade ad Android 12, senza recupero dedicato

Avvia/esegui l'upgrade del dispositivo, GKI, nessun dispositivo di recupero dedicato

Figura 4. Dispositivi che vengono lanciati o eseguono l'upgrade ad Android 12, con GKI, senza recupero dedicato.

Lanciare o eseguire l'upgrade ad Android 12, dedicato e ripristino A/B (ramdisk dedicato)

Avvia/esegui l'upgrade del dispositivo, GKI, dedicato e ripristino A/B

Figura 5. Dispositivi che verranno introdotti o eseguono l'upgrade ad Android 12, con GKI, recupero A/B e dedicato.

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

Avviare o eseguire l'upgrade ad Android 12, con ripristino dedicato e non A/B (ramdisk dedicato)

Avvia/esegui l'upgrade del dispositivo, GKI, recupero dedicato e non A/B

Figura 6. Dispositivi che vengono lanciati o eseguono l'upgrade ad Android 12, con GKI, recupero dedicato e non A/B.

Fai riferimento a questa figura se il dispositivo ha una partizione denominata recovery senza un suffisso dell'area annuncio.

Esegui l'upgrade ad Android 12 con ripristino come avvio (ripristino come ramdisk)

Avviare/eseguire l'upgrade del dispositivo, nessun GKI, ripristino all'avvio

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

Esegui l'upgrade ad Android 12, recupero dedicato (ramdisk dedicato)

Avvio/upgrade del dispositivo, nessun GKI, recupero dedicato

Figura 8. Dispositivi con aggiornamento ad Android 12, nessun GKI, ripristino dedicato.

Contenuti delle immagini di avvio

Le immagini di avvio di Android contengono quanto segue.

  • init_boot immagine aggiunta per i dispositivi che verranno lanciati con Android 13

    • Versione intestazione V4
    • Immagine ramdisk generica

  • Immagine boot generica

    • Versione intestazione V3 oppure Versione 4
      • Un boot_signature per la certificazione boot.img GKI (solo v4). La La GKI boot.img certificata non è firmata per l'avvio verificato. Gli OEM devono comunque firma l'elemento boot.img predefinito con un nome utente Durata di visualizzazione media chiave.
      • Generico cmdline (GENERIC_KERNEL_CMDLINE)
      • Kernel GKI
    • Immagine ramdisk generica
      • Incluso solo in boot immagini da Android 12 e precedenti

  • Immagine vendor_boot (per dettagli, consulta Avvio fornitore partizioni)

    • Intestazione vendor_boot
      • cmdline (BOARD_KERNEL_CMDLINE) specifici per dispositivo
    • Immagine ramdisk vendor_boot
      • lib/modules
      • Risorse di recupero (se non è disponibile un recupero dedicato)
    • Immagine dtb

  • Immagine recovery

    • Versione intestazione V2
        .
      • cmdline specifico del dispositivo per il ripristino, se necessario
      • Per la partizione di ripristino non A/B, i contenuti dell'intestazione devono essere autonomo; vedi Immagini di recupero. Ad esempio:
      • cmdline non è concatenato a boot e vendor_boot cmdline.
      • L'intestazione specifica il DTBO di recupero, se necessario.
      • Per la partizione di recupero A/B, i contenuti possono essere concatenati o dedotti di boot e vendor_boot. Ad esempio:
      • cmdline è concatenato a boot e vendor_boot cmdline.
      • Il valore DTBO può essere dedotto dall'intestazione vendor_boot.
    • Immagine ramdisk recovery
      • Risorse di recupero
      • Per la partizione di ripristino non A/B, il contenuto del ramdisk deve essere autonomo; vedi Immagini di recupero. Ad esempio:
      • lib/modules deve contenere tutti i moduli kernel necessari per l'avvio Recovery mode
      • Il ramdisk di ripristino deve contenere init.
      • Per la partizione di ripristino A/B, il ramdisk di ripristino è anteposto alla sezione generico e vendor_boot ramdisk, quindi non deve essere indipendenti. Ad esempio:
      • lib/modules potrebbe contenere solo moduli kernel aggiuntivi necessari per avvia la modalità di ripristino oltre ai moduli kernel in vendor_boot ramdisk.
      • Il collegamento simbolico in /init potrebbe esistere, ma è oscurato dal il file binario /init di prima fase nell'immagine di avvio.

Contenuti di immagini ramdisk generiche

Il ramdisk generico contiene i seguenti componenti.

  • init
  • system/etc/ramdisk/build.prop
  • ro.PRODUCT.bootimg.* build oggetti
  • Directory vuote per i punti di montaggio: debug_ramdisk/, mnt/, dev/, sys/, proc/ metadata/
  • first_stage_ramdisk/
    • Directory vuote duplicate per i punti di montaggio: debug_ramdisk/, mnt/, dev/, sys/, proc/ e metadata/

Integrazione dell'immagine di avvio

I flag di build controllano il modo in cui init_boot, boot, recovery e vendor_boot vengono create le immagini. Il valore di una variabile board booleana deve essere la stringa true o essere vuoto (impostazione predefinita).

  • TARGET_NO_KERNEL. Questa variabile indica se la build utilizza un avvio predefinito dell'immagine. Se questa variabile è impostata su true, imposta BOARD_PREBUILT_BOOTIMAGE alla posizione dell'immagine di avvio predefinita (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img)

  • BOARD_USES_RECOVERY_AS_BOOT. Questa variabile indica se il dispositivo utilizza l'immagine recovery come immagine boot. Quando si utilizza GKI, questa variabile le risorse vuote e di recupero devono essere spostate in vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE. Questa variabile indica che la lavagna utilizza GKI. Questa variabile non influisce su sysprops o PRODUCT_PACKAGES.

    È lo switch GKI a livello di consiglio. tutte le seguenti variabili vengono limitato da questa variabile.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. Questa variabile controlla se le risorse di recupero ramdisk sono create per vendor_boot.

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

    • Se sono vuote, le risorse di recupero vengono create solo per recovery/root/ e non realizzati per vendor-ramdisk/.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. Questa variabile controlla se GSI I tasti AVB sono progettati per vendor_boot.

    • Se impostato su true, se BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • Se impostata, le chiavi GSI AVB sono progettate per: $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.

      • Se non viene configurato, le chiavi AVB GSI sono progettate per $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

    • Se vuoto, se BOARD_RECOVERY_AS_ROOT:

      • Se impostata, le chiavi GSI AVB sono progettate per: $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.

      • Se non viene configurato, le chiavi AVB GSI sono progettate per $ANDROID_PRODUCT_OUT/ramdisk/avb.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. Questa variabile controlla se L'immagine recovery contiene o meno un kernel. I dispositivi vengono lanciati con Android 12 e utilizzando la partizione A/B recovery deve essere impostata questa su true. Dispositivi con Android 12 lanciati e se usi un componente non A/B devi impostare questa variabile su false per mantenere l'immagine di ripristino indipendente.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. Questa variabile controlla se $OUT/boot*.img copiato in IMAGES/ nei file di destinazione.

    • aosp_arm64 deve impostare questa variabile su true.

    • Gli altri dispositivi devono lasciare vuota questa variabile.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. Questa variabile controlla se Viene generato il parametro init_boot.img e imposta le dimensioni. Se impostato, il ramdisk generico viene aggiunto a init_boot.img anziché a boot.img e richiede BOARD_AVB_INIT_BOOT* variabili da impostare vbmeta concatenato.

Combinazioni consentite

Componente o variabile Esegui l'upgrade del dispositivo senza partizione di ripristino Esegui l'upgrade del dispositivo con la partizione di ripristino Avvia il dispositivo senza partizione di ripristino Avvia il dispositivo con la partizione di recupero A/B Avvia il dispositivo con la partizione di ripristino non A/B aosp_arm64
Contiene boot sì sì sì sì sì sì
Contiene init_boot (Android 13) no no sì sì sì sì
Contiene vendor_boot facoltativo facoltativo sì sì sì no
Contiene recovery no sì no sì sì no
BOARD_USES_RECOVERY_AS_BOOT true vuoto vuoto vuoto vuoto vuoto
BOARD_USES_GENERIC_KERNEL_IMAGE vuoto vuoto true true true true
PRODUCT_BUILD_RECOVERY_IMAGE vuoto true o vuoto vuoto true o vuoto true o vuoto vuoto
BOARD_RECOVERYIMAGE_PARTITION_SIZE vuoto > 0 vuoto > 0 > 0 vuoto
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT vuoto vuoto true vuoto vuoto vuoto
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT vuoto vuoto true true true vuoto
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE vuoto vuoto vuoto true vuoto vuoto
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES vuoto vuoto vuoto vuoto vuoto true

È possibile impostare dispositivi con una partizione recovery dedicata Da PRODUCT_BUILD_RECOVERY_IMAGE a true o vuoto. Per questi dispositivi, se BOARD_RECOVERYIMAGE_PARTITION_SIZE impostata, viene creata un'immagine recovery.

Attiva vbmeta concatenato per l'avvio

La libreria vbmeta concatenata deve essere abilitata per le immagini boot e init_boot. Specifica le seguenti:

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, fai riferimento a questo modifica.

System as-root

System-as-root non è supportato per i dispositivi che utilizzano GKI. Attivato questo tipo di dispositivi, il campo BOARD_BUILD_SYSTEM_ROOT_IMAGE deve essere vuoto. System as-root non è inoltre supportato per i dispositivi che utilizzano partizioni dinamiche.

Configurazioni del prodotto

I dispositivi che usano il ramdisk generico devono installare un elenco di file che può essere installata sul ramdisk. A tale scopo, 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 eliminare accidentalmente installazione di altri file sul ramdisk (sposta questi file in vendor_ramdisk ).

Configura dispositivi

Le istruzioni di configurazione variano a seconda del dispositivo che viene lanciato con Android 13, con l'upgrade ad Android 12 e lancio con Android 12. Android 13 ha una configurazione simile a quella di Android 12

  • Dispositivi aggiornati ad Android 12:

    • Può conservare il valore di BOARD_USES_RECOVERY_AS_BOOT. Se lo fa, se utilizzano configurazioni legacy e le nuove variabili di build devono essere vuote. Se tale dispositivi:

      • Imposta BOARD_USES_RECOVERY_AS_BOOT su true, l'architettura è come mostrato nella Figura 3.

      • Imposta BOARD_USES_RECOVERY_AS_BOOT su vuoto, l'architettura è come mostrato Figura 4.

    • È possibile impostare BOARD_USES_RECOVERY_AS_BOOT come vuoto. Se lo fa, userà nuove configurazioni. Se tali dispositivi:

      • Non utilizzare una partizione recovery dedicata, l'architettura è quella mostrata nella Figura 1, mentre l'opzione di configurazione del dispositivo è Opzione 1

      • Utilizza una partizione recovery dedicata, l'architettura è quella mostrata in Figura 2a o Figura 2b e configurazione del dispositivo è Opzione 2a o Opzione 2b.

  • I dispositivi che vengono lanciati con Android 12 devono impostare BOARD_USES_RECOVERY_AS_BOOT per svuotare e utilizzare nuove configurazioni. Se tale dispositivi:

    • Non utilizzare una partizione recovery dedicata, l'architettura è quella mostrata in Figura 1 e l'opzione di configurazione del dispositivo è Opzione 1.

    • Utilizza una partizione recovery dedicata, l'architettura è quella mostrata in Figura 2a o Figura 2b e configurazione del dispositivo è Opzione 2a o Opzione 2b.

Poiché aosp_arm64 crea solo GKI (e non vendor_boot o ripristino), non è un obiettivo completo. Per le aosp_arm64configurazioni build, fai riferimento a generic_arm64.

Opzione 1: nessuna partizione di ripristino dedicata

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

Imposta valori BOARD

Imposta i valori seguenti:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Il ramdisk vendor_boot può contenere un collegamento simbolico da /init a /system/bin/init, e init_second_stage.recovery alle ore /system/bin/init. Tuttavia, poiché ramdisk generico è concatenato dopo il ramdisk vendor_boot, /init il link simbolico viene sovrascritto. Quando il dispositivo avvia il ripristino, Il file binario /system/bin/init è necessario per supportare l'init della seconda fase. I contenuti di vendor_boot + ramdisk generici sono i seguenti:

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

Spostare file fstab

Sposta tutti i file fstab installati sul ramdisk generico in vendor_ramdisk. Per un esempio, fai riferimento a questo modifica.

Installa moduli

Puoi installare moduli specifici per dispositivo in vendor_ramdisk (salta questo passaggio se non hai moduli specifici del dispositivo da installare).

  • Utilizza la variante vendor_ramdisk del modulo quando il modulo viene installato in /first_stage_ramdisk. Questo modulo dovrebbe essere disponibile dopo il giorno init sposta la directory root in /first_stage_ramdisk ma prima che init esegua il trasferimento /system. Ad esempio, vedi Checksum dei metadati e Compressione A/B virtuale.

  • Utilizza la variante recovery del modulo quando il modulo viene installato in /. Questo modulo dovrebbe essere disponibile prima che init esegua il passaggio alla directory principale /first_stage_ramdisk. Per maggiori dettagli sull'installazione dei moduli in /, consulta la sezione Prima nella console dello stage.

Console della prima fase

Poiché la console della prima fase viene avviata prima che init esegua il trasferimento root /first_stage_ramdisk, devi installare la variante recovery dei moduli. Per impostazione predefinita, entrambe le varianti del modulo sono installate build/make/target/product/base_vendor.mk, quindi se il makefile del dispositivo eredita da questo file non devi installare esplicitamente la variante recovery.

Per installare esplicitamente i moduli di ripristino, utilizza quanto segue.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Ciò garantisce che linker, sh e toybox installino $ANDROID_PRODUCT_OUT/recovery/root/system/bin, che verrà quindi installato in /system/bin in vendor_ramdisk.

Per aggiungere i moduli necessari per la console della prima fase (ad esempio, adbd), utilizza seguire.

PRODUCT_PACKAGES += adbd.recovery

Ciò garantisce che i moduli specificati vengano installati $ANDROID_PRODUCT_OUT/recovery/root/system/bin, che verrà installato in /system/bin in vendor_ramdisk.

Checksum dei metadati

Per supportare i metadati checksum durante il montaggio della prima fase, i dispositivi che non supportano GKI installano il ramdisk la variante dei seguenti moduli. Per aggiungere il supporto per GKI, sposta i moduli in $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin:

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

Per un esempio, fai riferimento a questo elenco modifiche.

Compressione A/B virtuale

Per supportare la compressione A/B virtuale, è necessario installare snapuserd in vendor_ramdisk. Il dispositivo deve ereditare virtual_ab_ota/compression.mk, che installa la variante vendor_ramdisk di snapuserd.

Modifiche al processo di avvio

La procedura di avvio del ripristino o di Android non cambia, seguente eccezione:

  • Ramdisk build.prop passa a /second_stage_resources, quindi la seconda fase init può leggere il timestamp della build di avvio.

Poiché le risorse passano da un ramdisk generico a un ramdisk vendor_boot, il risultato della concatenazione di ramdisk generico in vendor_boot ramdisk non cambia.

Rendi disponibile e2fsck

I makefile del dispositivo possono ereditare da:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk se il dispositivo supporta A/B ma non compressione.

  • virtual_ab_ota/compression.mk se il dispositivo supporta A/B virtuale compressione.

I makefile del prodotto da installare $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. Alle ore runtime, la prima fase init esegue il passaggio alla directory principale in /first_stage_ramdisk, quindi esegue /system/bin/e2fsck.

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

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

AB_OTA_PARTITIONS += recovery

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

  • File fstab specifici per il dispositivo

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

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

Imposta valori BOARD

Imposta i seguenti valori per i dispositivi con partizione A/B recovery:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Il ramdisk recovery può contenere un link simbolico /init -> /system/bin/init e init_second_stage.recovery alle /system/bin/init. Tuttavia, poiché l'avvio ramdisk è concatenato dopo il ramdisk recovery, il link simbolico /init sovrascritto. Quando il dispositivo si avvia in Recovery mode, /system/bin/init il file binario è necessario per supportare l'init della seconda fase.

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

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

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

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

Spostare file fstab

Sposta tutti i file fstab installati sul ramdisk generico nell' vendor_ramdisk. Per un esempio, fai riferimento a questo modifica.

Installa moduli

Facoltativamente, puoi installare moduli specifici per dispositivo in vendor_ramdisk (salta questo passaggio se non hai moduli specifici del dispositivo da installare). Init non passa alla directory radice. La variante vendor_ramdisk dei moduli viene installata nel radice di vendor_ramdisk. Per esempi sull'installazione di moduli in vendor_ramdisk, consulta Console prima fase, Metadati checksum e A/B virtuali compressa.

Console della prima fase

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Ciò garantisce che linker, sh e toybox installino $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, che verrà quindi installato in /system/bin in vendor_ramdisk.

Per aggiungere i moduli necessari per la console della prima fase (ad esempio, adbd), abilita la variante vendor_ramdisk di questi moduli caricando le patch pertinenti AOSP, quindi utilizza il seguente comando

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Ciò garantisce che i moduli specificati vengano installati $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin. Se il ramdisk vendor_boot viene caricato in Recovery mode, 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 metadati checksum durante il montaggio della prima fase, i dispositivi che non supportano GKI installano il ramdisk la variante dei seguenti moduli. Per aggiungere il supporto per GKI, sposta i moduli in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

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

Per un esempio, fai riferimento a questo elenco modifiche.

Compressione A/B virtuale

Per supportare la compressione A/B virtuale, è necessario installare snapuserd in vendor_ramdisk. Il dispositivo deve ereditare virtual_ab_ota/compression.mk, che installa la variante vendor_ramdisk di snapuserd.

Modifiche al processo di avvio

Quando avvii Android, il processo di avvio non cambia. vendor_boot + ramdisk generico è simile al processo di avvio esistente, ad eccezione del fatto che fstab caricamenti da vendor_boot. Poiché system/bin/recovery non esiste, first_stage_init lo gestisce come un normale avvio.

Quando avvii in Recovery mode, il processo di avvio cambia. Il ripristino + vendor_boot + ramdisk generico è simile al processo di recupero esistente, ma il kernel viene caricato dall'immagine boot anziché dall'immagine recovery. La procedura di avvio per la modalità di ripristino è la seguente.

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

    1. Invia recupero + vendor_boot + ramdisk generico a /. (Se l'OEM duplica i moduli del kernel nel ramdisk di recupero aggiungendoli al BOARD_RECOVERY_KERNEL_MODULES), vendor_boot è facoltativo.)
    2. Esegue il kernel dalla partizione boot.

  2. Il kernel monta ramdisk su /, quindi esegue /init dal ramdisk generico.

  3. Viene avviata la prima fase, quindi esegue le seguenti operazioni:

    1. Imposta IsRecoveryMode() == true e ForceNormalBoot() == false.
    2. Carica i moduli kernel del fornitore da /lib/modules.
    3. Chiama il numero DoFirstStageMount(), ma il montaggio salta perché IsRecoveryMode() == true. Il dispositivo non libera ramdisk (perché / è sempre lo stesso), ma chiama SetInitAvbVersionInRecovery().
    4. Avvia l'init della seconda fase da /system/bin/init da recovery ramdisk.

Rendi disponibile e2fsck

I makefile del dispositivo possono ereditare da:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk se il dispositivo supporta A/B ma non compressione.

  • virtual_ab_ota/compression.mk se il dispositivo supporta A/B virtuale compressione.

I makefile del prodotto da installare $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. Alle ore il runtime, la prima fase init esegue /system/bin/e2fsck.

Opzione 2b: partizione di recupero dedicata e non A/B

Utilizza questa opzione per i dispositivi con una partizione recovery non A/B. cioè il dispositivo ha una partizione denominata recovery senza un suffisso slot. Dispositivi di questo tipo include:

  • dispositivi non A/B;
  • Dispositivi A/B e A/B virtuali, di cui la partizione di ripristino non è aggiornabili. (Si tratta di una situazione insolita).

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

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

L'immagine recovery deve essere indipendente. Deve contenere tutte le risorse necessarie per avviare la Recovery mode, tra cui:

  • L'immagine kernel
  • Immagine DTBO
  • Moduli del kernel in lib/modules
  • Init di prima fase come collegamento simbolico /init -> /system/bin/init
  • Programma binario di inizializzazione di seconda fase /system/bin/init
  • File fstab specifici per il dispositivo
  • Tutte le altre risorse di recupero, incluso il file binario recovery

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

Imposta valori BOARD

Imposta i seguenti valori per i dispositivi non A/B:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Il ramdisk recovery deve contenere un link simbolico /init -> /system/bin/init e init_second_stage.recovery alle /system/bin/init. Quando il dispositivo si avvia Recovery mode, il file binario /system/bin/init è necessario per supportare inizialmente e l'init della seconda fase.

Quando il dispositivo si avvia in recovery, i contenuti dei ramdisk di recovery vengono come segue:

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

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

  • /init (da ramdisk, creato da init_first_stage)

Spostare file fstab

Sposta tutti i file fstab installati sul ramdisk generico nell' ramdisk vendor_ramdisk e recovery. Per un esempio, fai riferimento a questo modifica.

Installa moduli

Puoi installare moduli specifici per dispositivo in vendor_ramdisk e ramdisk recovery (ignora questo passaggio se non hai moduli specifici del dispositivo da installare). init non passa alla directory radice. La variante vendor_ramdisk dei moduli viene installata nel radice di vendor_ramdisk. La variante recovery dei moduli viene installata nel radice di recovery ramdisk. Per esempi sull'installazione di moduli in vendor_ramdisk e recovery ramdisk, se Console della prima fase e metadati checksum.

Console della prima fase

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Ciò garantisce che linker, sh e toybox installino $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, che verrà quindi installato in /system/bin in vendor_ramdisk.

Per aggiungere i moduli necessari per la console della prima fase (ad esempio, adbd), abilita la variante vendor_ramdisk di questi moduli caricando le patch pertinenti AOSP, quindi utilizza il seguente comando

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Per installare la variante recovery dei moduli, sostituisci vendor_ramdisk con recovery:

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

Checksum dei metadati

Per supportare i metadati checksum durante il montaggio della prima fase, i dispositivi che non supportano GKI installano il ramdisk la variante dei seguenti moduli. Per aggiungere il supporto per GKI, sposta i moduli in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

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

Per supportare i checksum dei metadati durante il montaggio della prima fase nel ripristino, abilita la variante di ripristino di questi moduli e installarli.

Modifiche al processo di avvio

Quando avvii Android, il processo di avvio non cambia. vendor_boot + ramdisk generico è simile al processo di avvio esistente, ad eccezione del fatto che fstab caricamenti da vendor_boot. Poiché system/bin/recovery non esiste, first_stage_init lo gestisce come un normale avvio.

Quando avvii in Recovery mode, il processo di avvio non cambia. La ripresa ramdisk viene caricato nello stesso modo del processo di ripristino esistente. Il kernel viene caricato dall'immagine recovery. La di avvio per la modalità di ripristino è la seguente.

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

    1. Esegue il push del ramdisk di recupero a /.
    2. Esegue il kernel dalla partizione recovery.

  2. Il kernel monta il ramdisk su /, quindi esegue /init, che è un collegamento simbolico a /system/bin/init dal ramdisk recovery.

  3. Viene avviata la prima fase, quindi esegue le seguenti operazioni:

    1. Imposta IsRecoveryMode() == true e ForceNormalBoot() == false.
    2. Carica i moduli kernel del fornitore da /lib/modules.
    3. Chiama il numero DoFirstStageMount(), ma il montaggio salta perché IsRecoveryMode() == true. Il dispositivo non libera ramdisk (perché / è sempre lo stesso), ma chiama SetInitAvbVersionInRecovery().
    4. Avvia l'init della seconda fase da /system/bin/init da recovery ramdisk.

Timestamp dell'immagine di avvio

Il seguente codice è un file timestamp immagine 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 creazione, un file system/etc/ramdisk/build.prop viene aggiunto alla richiesta ramdisk. Questo file contiene informazioni sul timestamp della build.

  • In fase di runtime, prima fase init copie file da ramdisk a tmpfs prima di liberare il ramdisk in modo che fase init può leggere questo file per impostare boot le proprietà del timestamp dell'immagine.