Generische Boot-Partition

In Android 12 enthält das generische boot Image, das als Generic Kernel Image (GKI) bezeichnet wird, die generische Ramdisk und den GKI-Kernel.

Bei Geräten, die mit Android 13 gestartet werden, wird die generische Ramdisk aus dem boot Image entfernt und in einem separaten init_boot -Image platziert. Diese Änderung belässt das boot Image nur noch mit dem GKI-Kernel.

Für Upgrades von Geräten, die weiterhin Android 12 oder ältere Kernelversionen verwenden, bleibt die generische Ramdisk dort, wo sie war, ohne dass ein neues init_boot -Image erforderlich ist.

Um eine generische Ramdisk zu erstellen, verschieben Sie herstellerspezifische Ressourcen so aus der Ramdisk, dass die generische Ramdisk nur die Initialisierung der ersten init und eine Eigenschaftsdatei mit Zeitstempelinformationen enthält.

Auf Geräten, die:

  • Verwenden Sie keine dedizierte recovery , alle Wiederherstellungsbits werden von der generischen Ramdisk auf die vendor_boot Ramdisk verschoben.

  • Verwenden Sie eine dedizierte recovery , es ist keine Änderung an der recovery -Ramdisk erforderlich, da die recovery -Ramdisk eigenständig ist.

Die Architektur

Die folgenden Diagramme veranschaulichen die Architektur für Geräte mit Android 12 und höher. Geräte, die mit Android 13 gestartet werden, verfügen über ein neues init_boot -Image, das die generische Ramdisk enthält. Geräte, die von Android 12 auf Android 13 aktualisieren, verwenden dieselbe Architektur wie bei Android 12.

Mit Android 13 starten, keine dedizierte Wiederherstellung

Gerät starten/aktualisieren, GKI, keine dedizierte Wiederherstellung

Abbildung 1. Geräte starten oder aktualisieren auf Android 13, mit GKI, keine dedizierte Wiederherstellung

Starten Sie mit Android 13, dediziert und A/B-Wiederherstellung (dedizierte Ramdisk)

Gerät starten/aktualisieren, GKI, dediziert und A/B-Wiederherstellung

Abbildung 2. Geräte, die auf Android 13 gestartet oder aktualisiert werden, mit GKI, dediziert und A/B-Wiederherstellung

Sehen Sie sich diese Abbildung an, wenn das Gerät über die Partitionen recovery_a und recovery_b verfügt.

Start mit Android 13, dedizierte und Nicht-A/B-Wiederherstellung (dedizierte Ramdisk)

Gerät starten/aktualisieren, GKI, dedizierte und Nicht-A/B-Wiederherstellung

Abbildung 3. Geräte, die auf Android 13 gestartet oder aktualisiert werden, mit GKI, dedizierter und Nicht-A/B-Wiederherstellung

Sehen Sie sich diese Abbildung an, wenn das Gerät über eine Partition mit dem Namen recovery ohne Slot-Suffix verfügt.

Starten oder aktualisieren Sie auf Android 12, keine dedizierte Wiederherstellung

Gerät starten/aktualisieren, GKI, keine dedizierte Wiederherstellung

Abbildung 4. Geräte, die mit GKI gestartet oder auf Android 12 aktualisiert werden, ohne dedizierte Wiederherstellung

Starten oder aktualisieren Sie auf Android 12, dediziert und A/B-Wiederherstellung (dedizierte Ramdisk)

Gerät starten/aktualisieren, GKI, dediziert und A/B-Wiederherstellung

Abbildung 5. Geräte, die auf Android 12 gestartet oder aktualisiert werden, mit GKI, dediziert und A/B-Wiederherstellung

Sehen Sie sich diese Abbildung an, wenn das Gerät über die Partitionen recovery_a und recovery_b verfügt.

Starten oder aktualisieren Sie auf Android 12, dedizierte und Nicht-A/B-Wiederherstellung (dedizierte Ramdisk)

Gerät starten/aktualisieren, GKI, dedizierte und Nicht-A/B-Wiederherstellung

Abbildung 6. Geräte, die auf Android 12 gestartet oder aktualisiert werden, mit GKI, dedizierter und Nicht-A/B-Wiederherstellung

Sehen Sie sich diese Abbildung an, wenn das Gerät über eine Partition mit dem Namen recovery ohne Slot-Suffix verfügt.

Upgrade auf Android 12, Recovery-as-Boot (Recovery-as-Ramdisk)

Gerät starten/aktualisieren, kein GKI, Recovery-as-Boot

Abbildung 7. Geräte, die auf Android 12 aktualisiert werden, kein GKI, Recovery-as-Boot

Upgrade auf Android 12, dedizierte Wiederherstellung (dedizierte Ramdisk)

Gerät starten/aktualisieren, kein GKI, dedizierte Wiederherstellung

Abbildung 8. Geräte, die auf Android 12 aktualisiert werden, kein GKI, dedizierte Wiederherstellung

Inhalt der Boot-Images

Die Android-Boot-Images enthalten Folgendes.

  • init_boot -Image für Geräte hinzugefügt, die mit Android 13 gestartet werden

    • Header-Version V4
    • Generisches Ramdisk-Image

  • Generisches boot Image

    • Header-Version V3 oder V4
      • Eine boot_signature für die GKI boot.img-Zertifizierung (nur v4). Das zertifizierte GKI boot.img ist nicht für den verifizierten Start signiert. OEMs müssen das vorgefertigte boot.img mit einem gerätespezifischen AVB -Schlüssel signieren.
      • Generische cmdline ( GENERIC_KERNEL_CMDLINE )
      • GKI-Kernel
    • Generisches Ramdisk-Image
      • Nur in boot Images von Android 12 und früher enthalten

  • vendor_boot -Image (für Details siehe Vendor-Boot-Partitionen )

    • vendor_boot Header
      • cmdline ( BOARD_KERNEL_CMDLINE )
    • vendor_boot Ramdisk-Image
      • lib/modules
      • Wiederherstellungsressourcen (falls keine dedizierte Wiederherstellung)
    • dtb -Bild

  • recovery

    • Header-Version V2
      • cmdline für die Wiederherstellung, falls erforderlich
      • Für Nicht-A/B-Wiederherstellungspartitionen muss der Inhalt des Headers eigenständig sein; siehe Wiederherstellungs-Images . Zum Beispiel:
      • cmdline ist nicht mit boot und vendor_boot cmdline .
      • Header gibt ggf. Wiederherstellungs-DTBO an.
      • Für A/B-Wiederherstellungspartitionen können Inhalte verkettet oder von boot und vendor_boot . Zum Beispiel:
      • cmdline wird mit boot und vendor_boot cmdline .
      • DTBO kann aus dem vendor_boot Header abgeleitet werden.
    • recovery -Ramdisk-Image
      • Wiederherstellungsressourcen
      • Für Nicht-A/B-Wiederherstellungspartitionen muss der Inhalt der Ramdisk eigenständig sein; siehe Wiederherstellungs-Images . Zum Beispiel:
      • lib/modules muss alle Kernelmodule enthalten, die zum Starten des Wiederherstellungsmodus erforderlich sind
      • Die Wiederherstellungs-Ramdisk muss init enthalten.
      • Für die A/B-Wiederherstellungspartition wird die Wiederherstellungs-Ramdisk der generischen und der vendor_boot Ramdisk vorangestellt, daher muss sie nicht eigenständig sein. Zum Beispiel:
      • lib/modules enthält möglicherweise nur zusätzliche Kernelmodule, die zum Booten des Wiederherstellungsmodus erforderlich sind, neben den Kernelmodulen in der vendor_boot .
      • Der symbolische Link unter /init ist möglicherweise vorhanden, wird jedoch von der /init -Binärdatei der ersten Stufe im Boot-Image überschattet.

Generische Ramdisk-Image-Inhalte

Die generische Ramdisk enthält die folgenden Komponenten.

  • init
  • system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build Requisiten
  • Leere Verzeichnisse für Einhängepunkte: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/
  • first_stage_ramdisk/
    • Doppelte leere Verzeichnisse für Einhängepunkte: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/

Boot-Image-Integration

Build-Flags steuern, wie init_boot -, boot -, recovery - und vendor_boot werden. Der Wert einer booleschen Board-Variablen muss der String true oder leer sein (was die Voreinstellung ist).

  • TARGET_NO_KERNEL . Diese Variable gibt an, ob der Build ein vorgefertigtes Boot-Image verwendet. Wenn diese Variable auf true gesetzt ist, setzen BOARD_PREBUILT_BOOTIMAGE auf den Speicherort des vorgefertigten Boot-Images ( BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img )

  • BOARD_USES_RECOVERY_AS_BOOT . Diese Variable gibt an, ob das Gerät das recovery als boot verwendet. Bei Verwendung von GKI ist diese Variable leer, und Wiederherstellungsressourcen sollten nach vendor_boot .

  • BOARD_USES_GENERIC_KERNEL_IMAGE . Diese Variable gibt an, dass das Board GKI verwendet. Diese Variable wirkt sich nicht auf Sysprops oder PRODUCT_PACKAGES .

    Dies ist der GKI-Switch auf Board-Ebene; alle unten aufgeführten Variablen werden durch diese Variable eingeschränkt.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . Diese Variable steuert, ob Ramdisk-Ressourcen für die Wiederherstellung von vendor_boot werden.

    • Wenn diese Einstellung auf true gesetzt ist, werden Wiederherstellungsressourcen nur auf der vendor-ramdisk/ und nicht auf recovery/root/ .

    • Wenn sie leer sind, werden Wiederherstellungsressourcen nur für recovery/root/ erstellt und nicht für vendor-ramdisk/ .

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT . Diese Variable steuert, ob GSI-AVB-Schlüssel für vendor_boot werden.

    • Wenn auf true gesetzt, wenn BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

      • gesetzt ist, werden GSI-AVB-Schlüssel in $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb .

      • Wenn nicht festgelegt, werden GSI-AVB-Schlüssel in $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb .

    • Wenn leer, wenn BOARD_RECOVERY_AS_ROOT :

      • gesetzt ist, werden GSI-AVB-Schlüssel in $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb .

      • Wenn nicht festgelegt, werden GSI-AVB-Schlüssel in $ANDROID_PRODUCT_OUT/ramdisk/avb .

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE . Diese Variable steuert, ob das recovery einen Kernel enthält oder nicht. Geräte, die mit Android 12 starten und die A/B- recovery verwenden, müssen diese Variable auf true setzen. Geräte, die mit Android 12 gestartet werden und Nicht-A/B verwenden, müssen diese Variable auf false “ setzen, damit das Wiederherstellungsabbild in sich geschlossen bleibt.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES . Diese Variable steuert, ob $OUT/boot*.img nach IMAGES/ unter den Zieldateien kopiert wird.

    • aosp_arm64 muss diese Variable auf true setzen.

    • Andere Geräte müssen diese Variable leer lassen.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE . Diese Variable steuert, ob init_boot.img generiert wird und legt die Größe fest. Wenn festgelegt, wird die generische Ramdisk zu init_boot.img anstelle von boot.img und erfordert, dass die BOARD_AVB_INIT_BOOT* für verkettete vbmeta festgelegt werden

Erlaubte Kombinationen

Komponente oder Variable Aktualisieren des Geräts ohne recovery Aktualisieren des Geräts mit der recovery Starten Sie das Gerät ohne recovery Starten Sie das Gerät mit der A/B- recovery Starten Sie das Gerät mit einer Nicht-A/B- recovery aosp_arm64
Enthält boot Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl
Enthält init_boot (Android 13) nein nein nein Jawohl Jawohl Jawohl
Enthält vendor_boot Optional Optional Jawohl Jawohl Jawohl nein
Enthält recovery nein Jawohl nein Jawohl Jawohl nein
BOARD_USES_RECOVERY_AS_BOOT true leer leer leer leer leer
BOARD_USES_GENERIC_KERNEL_IMAGE leer leer true true true true
PRODUCT_BUILD_RECOVERY_IMAGE leer true oder leer leer true oder leer true oder leer leer
BOARD_RECOVERYIMAGE_PARTITION_SIZE leer > 0 leer > 0 > 0 leer
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT leer leer true leer leer leer
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT leer leer true true true leer
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE leer leer leer true leer leer
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES leer leer leer leer leer true

Geräte mit einer dedizierten recovery können PRODUCT_BUILD_RECOVERY_IMAGE auf „ true “ oder „leer“ setzen. Wenn BOARD_RECOVERYIMAGE_PARTITION_SIZE für diese Geräte festgelegt ist, wird ein recovery erstellt.

Verkettetes vbmeta zum Booten aktivieren

Chained vbmeta muss für die boot und init_boot Images aktiviert werden. Geben Sie Folgendes an:

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

Ein Beispiel finden Sie in dieser Änderung .

System als Root

System-als-Root wird für Geräte, die GKI verwenden, nicht unterstützt. Auf solchen Geräten muss BOARD_BUILD_SYSTEM_ROOT_IMAGE leer sein. System-als-Root wird auch nicht für Geräte unterstützt, die dynamische Partitionen verwenden.

Produktkonfigurationen

Geräte, die die generische Ramdisk verwenden, müssen eine Liste von Dateien installieren, die auf der Ramdisk installiert werden dürfen. Geben Sie dazu in device.mk Folgendes an:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

Die Datei generic_ramdisk.mk verhindert auch, dass andere Makefiles versehentlich andere Dateien auf der Ramdisk installieren (verschieben Sie solche Dateien stattdessen nach vendor_ramdisk ).

Geräte einrichten

Die Einrichtungsanweisungen unterscheiden sich zwischen Geräten, die mit Android 13 gestartet, auf Android 12 aktualisiert und mit Android 12 gestartet werden. Android 13 wird ähnlich eingerichtet wie mit Android 12

  • Geräte, die auf Android 12 aktualisiert werden:

    • Kann den Wert von BOARD_USES_RECOVERY_AS_BOOT . Wenn sie dies tun, verwenden sie Legacy-Konfigurationen und neue Build-Variablen müssen leer sein. Wenn solche Geräte:

      • Setzen BOARD_USES_RECOVERY_AS_BOOT auf „ true “, die Architektur ist wie in Abbildung 3 dargestellt.

      • Setzen BOARD_USES_RECOVERY_AS_BOOT auf leer, die Architektur ist wie in Abbildung 4 dargestellt.

    • Kann BOARD_USES_RECOVERY_AS_BOOT auf leer setzen. Wenn sie dies tun, verwenden sie neue Konfigurationen. Wenn solche Geräte:

  • Geräte, die mit Android 12 gestartet werden, müssen BOARD_USES_RECOVERY_AS_BOOT auf leer setzen und neue Konfigurationen verwenden. Wenn solche Geräte:

Da aosp_arm64 nur GKI erstellt (und nicht vendor_boot oder recovery), ist es kein vollständiges Ziel. Informationen zu aosp_arm64 Build-Konfigurationen finden Sie unter generic_arm64 .

Option 1: Keine dedizierte Wiederherstellungspartition

Geräte ohne recovery enthalten das generische boot Image in der boot Partition. Die vendor_boot Ramdisk enthält alle Wiederherstellungsressourcen, einschließlich lib/modules (mit Vendor-Kernel-Modulen). Auf solchen Geräten erbt die Produktkonfiguration von generic_ramdisk.mk .

Einstellen von BOARD-Werten

Stellen Sie die folgenden Werte ein:

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

Die vendor_boot Ramdisk kann einen /init to /system/bin/init Symlink und init_second_stage.recovery unter /system/bin/init enthalten. Da jedoch die generische Ramdisk nach der vendor_boot Ramdisk verkettet wird, wird der /init -Symlink überschrieben. Wenn das Gerät in die Wiederherstellung bootet, wird die /system/bin/init -Binärdatei benötigt, um Second Stage Init zu unterstützen. Der Inhalt von vendor_boot + generischen Ramdisks ist wie folgt:

  • /init (von generischer Ramdisk, gebaut aus init_first_stage )
  • /system/bin/init (von vendor_ramdisk , erstellt aus init_second_stage.recovery )

Fstab-Dateien verschieben

Verschieben Sie alle fstab -Dateien, die auf der generischen Ramdisk installiert wurden, nach vendor_ramdisk . Ein Beispiel finden Sie in dieser Änderung .

Module installieren

Falls gewünscht, können Sie gerätespezifische Module auf der vendor_ramdisk “ installieren (überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren müssen).

  • Verwenden Sie die Variante vendor_ramdisk des Moduls, wenn das Modul auf /first_stage_ramdisk installiert wird. Dieses Modul sollte verfügbar sein, nachdem init root in /first_stage_ramdisk , aber bevor init root in /system umschaltet. Beispiele finden Sie unter Metadaten-Prüfsummen und virtuelle A/B-Komprimierung .

  • Verwenden Sie die recovery des Moduls, wenn das Modul in / installiert wird. Dieses Modul sollte verfügbar sein, bevor init root in /first_stage_ramdisk . Einzelheiten zum Installieren von Modulen nach / finden Sie unter First-Stage-Konsole .

Konsole der ersten Stufe

Da die Konsole der ersten Stufe gestartet wird, bevor init root in /first_stage_ramdisk , müssen Sie die recovery von Modulen installieren. Standardmäßig werden beide Modulvarianten in build/make/target/product/base_vendor.mk , wenn also das Geräte-Makefile von dieser Datei erbt, müssen Sie die recovery nicht explizit installieren.

Verwenden Sie Folgendes, um die Wiederherstellungsmodule explizit zu installieren.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Dadurch wird sichergestellt, dass der linker , sh und toybox in $ANDROID_PRODUCT_OUT/recovery/root/system/bin installiert werden, das dann in /system/bin unter der vendor_ramdisk installiert wird.

Um Module hinzuzufügen, die für die Konsole der ersten Stufe benötigt werden (z. B. adbd), verwenden Sie Folgendes.

PRODUCT_PACKAGES += adbd.recovery

Dadurch wird sichergestellt, dass die angegebenen Module in $ANDROID_PRODUCT_OUT/recovery/root/system/bin installiert werden, das dann in /system/bin unter dem vendor_ramdisk installiert wird.

Metadaten-Prüfsummen

Um Metadaten-Prüfsummen während der Bereitstellung in der ersten Phase zu unterstützen, installieren Geräte, die GKI nicht unterstützen, die Ramdisk-Variante der folgenden Module. Um Unterstützung für GKI hinzuzufügen, verschieben Sie die Module nach $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin :

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

Ein Beispiel finden Sie in dieser Änderungsliste .

Virtuelle A/B-Komprimierung

Um die virtuelle A/B-Komprimierung zu unterstützen, muss snapuserd auf vendor_ramdisk installiert werden. Das Gerät sollte von virtual_ab_ota/compression.mk erben, das die vendor_ramdisk Variante von snapuserd installiert.

Änderungen am Startvorgang

Der Prozess des Bootens in die Wiederherstellung oder in Android ändert sich nicht, mit der folgenden Ausnahme:

  • Ramdisk build.prop verschiebt sich in /second_stage_resources , damit Second Stage init den Build-Zeitstempel des Bootens lesen kann.

Da Ressourcen von der generischen Ramdisk zur vendor_boot werden, ändert sich das Ergebnis der Verkettung der generischen ramdisk mit der vendor_boot nicht.

e2fsck verfügbar machen

Die Geräte-Makefiles können erben von:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk , wenn das Gerät virtuelles A/B, aber keine Komprimierung unterstützt.

  • virtual_ab_ota/compression.mk , wenn das Gerät virtuelle A/B-Komprimierung unterstützt.

Die Produkt-Makefiles installieren $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck . Zur Laufzeit wechselt die init der ersten Stufe root in /first_stage_ramdisk und führt dann /system/bin/e2fsck .

Option 2a: Dedizierte und A/B-Wiederherstellungspartition

Verwenden Sie diese Option für Geräte mit A/B- recovery ; Das heißt, das Gerät hat eine recovery_a und eine recovery_b partition . Zu diesen Geräten gehören A/B- und virtuelle A/B-Geräte, deren Wiederherstellungspartition aktualisierbar ist, mit der folgenden Konfiguration:

AB_OTA_PARTITIONS += recovery

Die vendor_boot Ramdisk enthält die Vendor-Bits der Ramdisk- und Vendor-Kernel-Module, einschließlich der folgenden:

  • Gerätespezifische fstab -Dateien

  • lib/modules (enthält Hersteller-Kernel-Module)

Die recovery -Ramdisk enthält alle Wiederherstellungsressourcen. Auf solchen Geräten erbt die Produktkonfiguration von generic_ramdisk.mk .

Einstellen von BOARD-Werten

Legen Sie die folgenden Werte für Geräte mit A/B- recovery fest:

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

Die recovery -Ramdisk kann einen symbolischen Link /init -> /system/bin/init und init_second_stage.recovery unter /system/bin/init . Da die Boot-Ramdisk jedoch nach der recovery -Ramdisk verkettet wird, wird der /init -Symlink überschrieben. Wenn das Gerät in den Wiederherstellungsmodus bootet, wird die /system/bin/init -Binärdatei benötigt, um Second Stage Init zu unterstützen.

Wenn das Gerät in die recovery bootet, sieht der Inhalt von recovery + vendor_boot + generische Ramdisks wie folgt aus:

  • /init (von Ramdisk, erstellt aus init_first_stage )
  • /system/bin/init (von recovery Ramdisk, erstellt aus init_second_stage.recovery und ausgeführt von /init )

Wenn das Gerät in Android bootet, sieht der Inhalt von vendor_boot + generische Ramdisks wie folgt aus:

  • /init (von generischer Ramdisk, gebaut aus init_first_stage )

Fstab-Dateien verschieben

Verschieben Sie alle fstab -Dateien, die auf der generischen Ramdisk installiert wurden, in die vendor_ramdisk . Ein Beispiel finden Sie in dieser Änderung .

Module installieren

Falls gewünscht, können Sie gerätespezifische Module auf der vendor_ramdisk “ installieren (überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren müssen). Init wechselt nicht root. Die vendor_ramdisk Variante von modulen wird im Stammverzeichnis von vendor_ramdisk installiert. Beispiele für die Installation von Modulen auf dem vendor_ramdisk finden Sie unter First-Stage-Konsole , Metadaten-Prüfsummen und Virtuelle A/B-Komprimierung .

Konsole der ersten Stufe

Verwenden Sie Folgendes, um die Variante vendor_ramdisk der Module zu installieren:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dadurch wird sichergestellt, dass der linker , sh und toybox in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin installiert werden, das dann in /system/bin unter dem vendor_ramdisk installiert wird.

Um Module hinzuzufügen, die für die Konsole der ersten Stufe benötigt werden (z. B. adbd), aktivieren Sie die Variante vendor_ramdisk dieser Module, indem Sie relevante Patches auf AOSP hochladen, und verwenden Sie dann Folgendes:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Dadurch wird sichergestellt, dass die angegebenen Module in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin installiert werden. Wenn die vendor_boot Ramdisk im Recovery-Modus geladen wird, ist das Modul auch im recovery -Modus verfügbar. Wenn die vendor_boot Ramdisk nicht im Wiederherstellungsmodus geladen ist, kann das Gerät optional auch adbd.recovery installieren.

Metadaten-Prüfsummen

Um Metadaten-Prüfsummen während der Bereitstellung in der ersten Phase zu unterstützen, installieren Geräte, die GKI nicht unterstützen, die Ramdisk-Variante der folgenden Module. Um Unterstützung für GKI hinzuzufügen, verschieben Sie die Module nach $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin :

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

Ein Beispiel finden Sie in dieser Änderungsliste .

Virtuelle A/B-Komprimierung

Um die virtuelle A/B-Komprimierung zu unterstützen, muss snapuserd auf vendor_ramdisk installiert werden. Das Gerät sollte von virtual_ab_ota/compression.mk erben, das die vendor_ramdisk Variante von snapuserd installiert.

Änderungen am Startvorgang

Beim Booten in Android ändert sich der Bootvorgang nicht. Die generische Ramdisk vendor_boot +" ähnelt dem vorhandenen Boot-Prozess, außer dass fstab von vendor_boot . Da system/bin/recovery nicht existiert, behandelt first_stage_init es wie einen normalen Bootvorgang.

Beim Booten in den Wiederherstellungsmodus ändert sich der Bootvorgang. Die Wiederherstellung + vendor_boot + generische Ramdisk ähnelt dem bestehenden Wiederherstellungsprozess, aber der Kernel wird vom boot Image statt vom recovery -Image geladen. Der Startvorgang für den Wiederherstellungsmodus ist wie folgt.

  1. Der Bootloader startet und führt dann Folgendes aus:

    1. Schiebt Wiederherstellung + vendor_boot + generische Ramdisk nach / . (Wenn der OEM Kernel-Module in der Wiederherstellungs-Ramdisk dupliziert, indem er sie zu BOARD_RECOVERY_KERNEL_MODULES ), ist vendor_boot optional.)
    2. Führt den Kernel von der boot Partition aus.

  2. Der Kernel mountet die Ramdisk auf / und führt dann /init von der generischen Ramdisk aus.

  3. Init der ersten Stufe startet und führt dann Folgendes aus:

    1. Setzt IsRecoveryMode() == true und ForceNormalBoot() == false .
    2. Lädt Hersteller-Kernel-Module aus /lib/modules .
    3. DoFirstStageMount() auf, überspringt aber das Mounten, weil IsRecoveryMode() == true . (Das Gerät gibt die Ramdisk nicht frei (weil / immer noch dasselbe ist), ruft aber SetInitAvbVersionInRecovery() .)
    4. Startet Second Stage Init von /system/bin/init von recovery Ramdisk.

e2fsck verfügbar machen

Die Geräte-Makefiles können erben von:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk , wenn das Gerät virtuelles A/B, aber keine Komprimierung unterstützt.

  • virtual_ab_ota/compression.mk , wenn das Gerät virtuelle A/B-Komprimierung unterstützt.

Die Produkt-Makefiles installieren $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck . Zur Laufzeit führt die erste Stufe init /system/bin/e2fsck .

Option 2b: Dedizierte und Nicht-A/B-Wiederherstellungspartition

Verwenden Sie diese Option für Geräte mit einer Nicht-A/B- recovery ; Das heißt, das Gerät hat eine Partition mit dem Namen recovery ohne Slot-Suffix. Zu diesen Geräten gehören:

  • Nicht-A/B-Geräte;
  • A/B- und virtuelle A/B-Geräte, deren Wiederherstellungspartition nicht aktualisierbar ist. (Das ist ungewöhnlich.)

Die vendor_boot Ramdisk enthält die Vendor-Bits der Ramdisk- und Vendor-Kernel-Module, einschließlich der folgenden:

  • Gerätespezifische fstab -Dateien
  • lib/modules (enthält Hersteller-Kernel-Module)

Das recovery muss eigenständig sein. Es muss alle erforderlichen Ressourcen enthalten, um den Wiederherstellungsmodus zu starten, einschließlich:

  • Das Kernel-Image
  • Das DTBO-Bild
  • Kernelmodule in lib/modules
  • Init der ersten Stufe als Symlink /init -> /system/bin/init
  • Init-Binärdatei der zweiten Stufe /system/bin/init
  • Gerätespezifische fstab -Dateien
  • Alle anderen Wiederherstellungsressourcen, einschließlich der recovery -Binärdatei usw.
  • usw.

Auf solchen Geräten erbt die Produktkonfiguration von generic_ramdisk.mk .

Einstellen von BOARD-Werten

Legen Sie die folgenden Werte für Nicht-A/B-Geräte fest:

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

Die recovery -Ramdisk muss einen /init -> /system/bin/init Symlink und init_second_stage.recovery unter /system/bin/init . Wenn das Gerät in den Wiederherstellungsmodus bootet, wird die /system/bin/init -Binärdatei benötigt, um sowohl die Erst- als auch die Zweitstufeninitialisierung zu unterstützen.

Wenn das Gerät in die recovery bootet, sieht der Inhalt der recovery -Ramdisks wie folgt aus:

  • /init -> /system/bin/init (von der recovery -Ramdisk)
  • /system/bin/init (von recovery Ramdisk, erstellt aus init_second_stage.recovery und ausgeführt von /init )

Wenn das Gerät in Android bootet, sieht der Inhalt von vendor_boot + generische Ramdisks wie folgt aus:

  • /init (von Ramdisk, erstellt aus init_first_stage )

Fstab-Dateien verschieben

Verschieben Sie alle fstab -Dateien, die auf der generischen Ramdisk installiert wurden, auf die vendor_ramdisk und die recovery -Ramdisk. Ein Beispiel finden Sie in dieser Änderung .

Module installieren

Falls gewünscht, können Sie gerätespezifische Module auf der vendor_ramdisk und der recovery -Ramdisk installieren (überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren müssen). init wechselt nicht root. Die vendor_ramdisk Variante von modulen wird im Stammverzeichnis von vendor_ramdisk installiert. Die recovery von Modulen wird im Stammverzeichnis der recovery -Ramdisk installiert. Beispiele für die Installation von Modulen auf der vendor_ramdisk und der recovery -Ramdisk finden Sie unter First-Stage-Konsole und Metadaten-Prüfsummen .

Konsole der ersten Stufe

Verwenden Sie Folgendes, um die Variante vendor_ramdisk der Module zu installieren:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dadurch wird sichergestellt, dass der linker , sh und toybox in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin installiert werden, das dann in /system/bin unter dem vendor_ramdisk installiert wird.

Um Module hinzuzufügen, die für die Konsole der ersten Stufe benötigt werden (z. B. adbd), aktivieren Sie die Variante vendor_ramdisk dieser Module, indem Sie relevante Patches auf AOSP hochladen, und verwenden Sie dann Folgendes:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Dadurch wird sichergestellt, dass die angegebenen Module in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin installiert werden.

Um die recovery -Variante der Module zu installieren, ersetzen vendor_ramdisk durch recovery :

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

Metadaten-Prüfsummen

Um Metadaten-Prüfsummen während der Bereitstellung in der ersten Phase zu unterstützen, installieren Geräte, die GKI nicht unterstützen, die Ramdisk-Variante der folgenden Module. Um Unterstützung für GKI hinzuzufügen, verschieben Sie die Module nach $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin :

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

Aktivieren Sie die Wiederherstellungsvariante dieser Module und installieren Sie sie ebenfalls, um Metadaten-Prüfsummen während der ersten Phase des Mountens in der Wiederherstellung zu unterstützen.

Änderungen am Startvorgang

Beim Booten in Android ändert sich der Bootvorgang nicht. Die generische Ramdisk vendor_boot +" ähnelt dem vorhandenen Boot-Prozess, außer dass fstab von vendor_boot . Da system/bin/recovery nicht existiert, behandelt first_stage_init es wie einen normalen Bootvorgang.

Beim Booten in den Wiederherstellungsmodus ändert sich der Bootvorgang nicht. Die Wiederherstellungs-Ramdisk wird auf die gleiche Weise wie der vorhandene Wiederherstellungsprozess geladen. Der Kernel wird aus dem recovery geladen. Der Startvorgang für den Wiederherstellungsmodus ist wie folgt.

  1. Der Bootloader startet und führt dann Folgendes aus:

    1. Verschiebt die Wiederherstellungs-Ramdisk nach / .
    2. Führt den Kernel von der recovery aus.

  2. Der Kernel mountet die Ramdisk auf / und führt dann /init aus, was ein symbolischer Link zu /system/bin/init von der recovery -Ramdisk ist.

  3. Init der ersten Stufe startet und führt dann Folgendes aus:

    1. Setzt IsRecoveryMode() == true und ForceNormalBoot() == false .
    2. Lädt Hersteller-Kernel-Module aus /lib/modules .
    3. DoFirstStageMount() auf, überspringt aber das Mounten, weil IsRecoveryMode() == true . (Das Gerät gibt die Ramdisk nicht frei (weil / immer noch dasselbe ist), ruft aber SetInitAvbVersionInRecovery() .)
    4. Startet Second Stage Init von /system/bin/init von recovery Ramdisk.

Boot-Image-Zeitstempel

Der folgende Code ist ein Beispiel für eine boot Image-Zeitstempeldatei.

####################################
# 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

  • Zur Build-Zeit wird der generischen Ramdisk eine system/etc/ramdisk/build.prop -Datei hinzugefügt. Diese Datei enthält Zeitstempelinformationen des Builds.

  • Zur Laufzeit kopiert die erste Stufe von init Dateien von der Ramdisk nach tmpfs , bevor die Ramdisk freigegeben wird, sodass die zweite Stufe von init diese Datei lesen kann, um die Eigenschaften des boot Image-Zeitstempels festzulegen.