Generische Bootpartition

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 auf den Markt kommen, wird die generische Ramdisk aus dem boot-Image entfernt und in ein separates init_boot-Image verschoben. Nach dieser Änderung enthält das boot-Image nur noch den GKI-Kernel.

Für das Aktualisieren von Geräten, auf denen weiterhin Android 12 oder ältere Kernelversionen verwendet werden, bleibt die generische Ramdisk an ihrem ursprünglichen Ort. Es ist kein neues init_boot-Image erforderlich.

Um eine generische Ramdisk zu erstellen, müssen Sie anbieterspezifische Ressourcen aus der Ramdisk entfernen, sodass die generische Ramdisk nur die erste Phase von init und eine Eigenschaftsdatei mit Zeitstempelinformationen enthält.

Auf Geräten, die

• Verwenden Sie keine dedizierte recovery-Partition. Alle Wiederherstellungs-Bits werden von der generischen Ramdisk zur vendor_boot-Ramdisk verschoben.

• Verwenden Sie eine dedizierte recovery-Partition. Es ist keine Änderung der recovery-Ramdisk erforderlich, da die recovery-Ramdisk in sich geschlossen ist.

Architektur

Die folgenden Diagramme veranschaulichen die Architektur für Geräte mit Android 12 und höher. Geräte, die mit Android 13 auf den Markt kommen, haben ein neues init_boot-Image mit der generischen Ramdisk. Geräte, die von Android 12 auf Android 13 aktualisiert werden, verwenden dieselbe Architektur wie unter Android 12.

Bei Markteinführung Android 13, keine dedizierte Wiederherstellung

Abbildung 1. Geräte, die mit GKI auf Android 13 eingeführt oder aktualisiert werden, haben keine dedizierte Recovery.

Markteinführung mit Android 13, dedizierte und A/B-Wiederherstellung (dedizierte Ramdisk)

Abbildung 2: Geräte, die mit Android 13 auf den Markt kommen oder auf Android 13 aktualisiert werden und GKI, dedizierte und A/B-Wiederherstellung nutzen.

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

Markteinführung mit Android 13, dedizierte und nicht A/B-Wiederherstellung (dedizierte Ramdisk)

Abbildung 3: Geräte, die mit Android 13 auf den Markt kommen oder auf Android 13 aktualisiert werden und GKI, dedizierte und Nicht-A/B-Wiederherstellung nutzen.

Sehen Sie sich dieses Bild an, wenn das Gerät eine Partition mit dem Namen recovery ohne Slot-Suffix hat.

Einführung oder Upgrade auf Android 12, keine dedizierte Wiederherstellung

Abbildung 4: Geräte, die mit GKI auf Android 12 eingeführt oder aktualisiert werden, haben keine dedizierte Recovery-Partition.

Einführung oder Upgrade auf Android 12, dedizierte und A/B-Wiederherstellung (dedizierte Ramdisk)

Abbildung 5: Geräte, die mit GKI, dedizierter und A/B-Wiederherstellung auf Android 12 eingeführt oder auf Android 12 aktualisiert werden.

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

Einführung oder Upgrade auf Android 12, dedizierte und nicht A/B-Wiederherstellung (dedizierte Ramdisk)

Abbildung 6. Geräte, die mit GKI, dedizierter und nicht A/B-Wiederherstellung auf den Markt kommen oder auf Android 12 aktualisiert werden.

Sehen Sie sich dieses Bild an, wenn das Gerät eine Partition mit dem Namen recovery ohne Slot-Suffix hat.

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

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

Upgrade auf Android 12, dedizierte Recovery (dedizierte Ramdisk)

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

Inhalte von Boot-Images

Die Android-Boot-Images enthalten Folgendes.

• init_boot Bild für Geräte mit Android 13 hinzugefügt

  • Header-Version V4
  • Allgemeines Ramdisk-Image

• Allgemeines boot-Bild

  • Header-Version V3 oder V4
    • Eine boot_signature für die GKI-boot.img-Zertifizierung (nur Version 4). Das zertifizierte GKI boot.img ist nicht für den verifizierten Bootmodus signiert. OEMs müssen das vorgefertigte boot.img weiterhin mit einem gerätespezifischen AVB-Schlüssel signieren.
    • Allgemein cmdline (GENERIC_KERNEL_CMDLINE)
    • GKI-Kernel
  • Allgemeines Ramdisk-Image
    • Nur in boot-Bildern von Android 12 und niedriger enthalten

• vendor_boot-Image (weitere Informationen finden Sie unter Vendor-Boot-Partitionen)

  • vendor_boot header
    • Gerätespezifische cmdline (BOARD_KERNEL_CMDLINE)
  • vendor_boot ramdisk-Image
    • lib/modules
    • Ressourcen zur Wiederherstellung (falls keine dedizierte Wiederherstellung)
  • dtb Bild

• recovery Bild

  • Header-Version V2
    • Gerätespezifische cmdline für die Wiederherstellung, falls erforderlich
    • Bei einer Wiederherstellungspartition, die keine A/B-Partition ist, muss der Inhalt des Headers eigenständig sein. Weitere Informationen finden Sie unter Wiederherstellungsimages. Beispiel:
    • cmdline wird nicht mit boot und vendor_boot cmdline verkettet.
    • Der Header gibt bei Bedarf das Recovery-DTBO an.
    • Bei der A/B-Wiederherstellungspartition können Inhalte aus boot und vendor_boot verkettet oder abgeleitet werden. Beispiel:
    • cmdline wird mit boot und vendor_boot cmdline verkettet.
    • DTBO kann aus dem vendor_boot-Header abgeleitet werden.
  • recovery ramdisk-Image
    • Ressourcen zur Wiederherstellung
    • Bei einer Wiederherstellungspartition, die keine A/B-Partition ist, muss der Inhalt der Ramdisk eigenständig sein. Weitere Informationen finden Sie unter Wiederherstellungsimages. Beispiel:
    • lib/modules muss alle Kernel-Module enthalten, die zum Starten des Wiederherstellungsmodus erforderlich sind.
    • Die Recovery-Ramdisk muss init enthalten.
    • Bei der A/B-Wiederherstellungspartition wird die Wiederherstellungs-Ramdisk der generischen und der vendor_boot-Ramdisk vorangestellt. Sie muss also nicht eigenständig sein. Beispiel:
    • lib/modules darf nur zusätzliche Kernelmodule enthalten, die für den Start des Wiederherstellungsmodus erforderlich sind, zusätzlich zu den Kernelmodulen im vendor_boot-Ramdisk.
    • Der Symlink unter /init ist möglicherweise vorhanden, wird aber von der Binärdatei /init der ersten Phase im Boot-Image überschattet.

Allgemeine Inhalte des Ramdisk-Images

Die generische Ramdisk enthält die folgenden Komponenten.

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

Boot-Image-Integration

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

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

• BOARD_USES_RECOVERY_AS_BOOT: Diese Variable gibt an, ob auf dem Gerät das recovery-Bild als boot-Bild verwendet wird. Bei Verwendung von GKI ist diese Variable leer und Wiederherstellungsressourcen sollten in vendor_boot verschoben werden.

• BOARD_USES_GENERIC_KERNEL_IMAGE: Diese Variable gibt an, dass das Board GKI verwendet. Diese Variable hat keine Auswirkungen auf System-Properties oder PRODUCT_PACKAGES.

  Dies ist der GKI-Switch auf Board-Ebene. Alle folgenden Variablen sind durch diese Variable eingeschränkt.

• BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT: Diese Variable steuert, ob Ramdisk-Wiederherstellungsressourcen für vendor_boot erstellt werden.

  • Wenn dieser Parameter auf true gesetzt ist, werden Wiederherstellungsressourcen nur für vendor-ramdisk/ und nicht für recovery/root/ erstellt.

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

• BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT: Mit dieser Variablen wird gesteuert, ob GSI-AVB-Schlüssel für vendor_boot erstellt werden.

  • Wenn true festgelegt ist und BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

    • Wenn diese Option festgelegt ist, werden GSI AVB-Schlüssel für $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb erstellt.

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

  • Wenn leer, gilt Folgendes:BOARD_RECOVERY_AS_ROOT

    • Wenn diese Option festgelegt ist, werden GSI AVB-Schlüssel für $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb erstellt.

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

• BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE: Diese Variable steuert, ob das recovery-Bild einen Kernel enthält. Bei Geräten, die mit Android 12 auf den Markt kommen und die A/B-Partition recovery verwenden, muss diese Variable auf true festgelegt werden. Geräte, die mit Android 12 auf den Markt kommen und keine A/B-Geräte sind, müssen diese Variable auf false setzen, damit das Wiederherstellungsimage in sich geschlossen ist.

• BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES: Mit dieser Variablen wird gesteuert, ob $OUT/boot*.img in IMAGES/ unter Zieldateien kopiert wird.

  • aosp_arm64 muss diese Variable auf true festlegen.

  • Auf anderen Geräten muss diese Variable leer bleiben.

• BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE: Mit dieser Variablen wird gesteuert, ob init_boot.img generiert wird, und die Größe festgelegt. Wenn diese Option festgelegt ist, wird die generische RAM-Disk dem init_boot.img anstelle von boot.img hinzugefügt. Außerdem müssen die BOARD_AVB_INIT_BOOT*-Variablen für verkettete vbmeta festgelegt werden.

Zulässige Kombinationen

Bei Geräten mit einer dedizierten recovery-Partition kann PRODUCT_BUILD_RECOVERY_IMAGE auf true oder leer gesetzt werden. Wenn für diese Geräte BOARD_RECOVERYIMAGE_PARTITION_SIZE festgelegt ist, wird ein recovery-Image erstellt.

Verkettete vbmeta für den Bootvorgang aktivieren

Verkettete vbmeta muss für die Images boot und init_boot aktiviert sein. 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

Hier finden Sie ein Beispiel für eine solche Änderung.

System-as-root

„System-as-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-as-root“ wird auch nicht für Geräte mit dynamischen Partitionen unterstützt.

Produktkonfigurationen

Auf Geräten, die die generische Ramdisk verwenden, muss eine Liste von Dateien installiert werden, die auf der Ramdisk installiert werden dürfen. Geben Sie dazu Folgendes in device.mk 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 RAM-Disk installieren. Verschieben Sie solche Dateien stattdessen nach vendor_ramdisk.

Geräte einrichten

Die Einrichtungsanleitung unterscheidet sich je nachdem, ob das Gerät mit Android 13 eingeführt wurde, auf Android 12 aktualisiert wurde oder mit Android 12 eingeführt wurde. Android 13-Geräte werden ähnlich wie Android 12-Geräte eingerichtet.

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

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

    • Wenn BOARD_USES_RECOVERY_AS_BOOT auf true gesetzt ist, sieht die Architektur wie in Abbildung 3 dargestellt aus.

    • Legen Sie BOARD_USES_RECOVERY_AS_BOOT auf „leer“ fest. Die Architektur ist wie in Abbildung 4 dargestellt.

  • Sie können BOARD_USES_RECOVERY_AS_BOOT auf leer setzen. In diesem Fall werden neue Konfigurationen verwendet. Wenn solche Geräte:

    • Verwenden Sie keine dedizierte recovery-Partition. Die Architektur ist wie in Abbildung 1 dargestellt und die Gerätekonfigurationsoption ist Option 1.

    • Verwenden Sie eine dedizierte recovery-Partition. Die Architektur ist wie in Abbildung 2a oder Abbildung 2b dargestellt und die Option für die Geräteeinrichtung ist Option 2a oder Option 2b.

• Bei Geräten, die mit Android 12 eingeführt werden, muss BOARD_USES_RECOVERY_AS_BOOT leer sein und es müssen neue Konfigurationen verwendet werden. Wenn solche Geräte:

  • Verwenden Sie keine dedizierte recovery-Partition. Die Architektur ist wie in Abbildung 1 dargestellt und die Option für die Geräteeinrichtung ist Option 1.

  • Verwenden Sie eine dedizierte recovery-Partition. Die Architektur ist wie in Abbildung 2a oder Abbildung 2b dargestellt und die Option für die Geräteeinrichtung ist Option 2a oder Option 2b.

Da aosp_arm64 nur GKI (und nicht vendor_boot oder Recovery) erstellt, 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-Partition enthalten das generische boot-Image in der boot-Partition. Die vendor_boot-Ramdisk enthält alle Wiederherstellungsressourcen, einschließlich lib/modules (mit Vendor-Kernelmodulen). Auf solchen Geräten wird die Produktkonfiguration von generic_ramdisk.mk abgeleitet.

BOARD-Werte festlegen

Legen Sie die folgenden Werte fest:

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

Init-Binärdateien und ‑Symlinks

Die vendor_boot-Ramdisk kann einen Symlink von /init nach /system/bin/init und init_second_stage.recovery unter /system/bin/init enthalten. Da die generische Ramdisk jedoch nach der vendor_boot-Ramdisk verkettet wird, wird der /init-Symlink überschrieben. Wenn das Gerät im Wiederherstellungsmodus gestartet wird, ist die Binärdatei /system/bin/init für die Unterstützung der zweiten Initialisierungsphase erforderlich. Der Inhalt von vendor_boot + generischen Ramdisks sieht so aus:

• /init (von generischer Ramdisk, erstellt 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 in der generischen Ramdisk installiert wurden, nach vendor_ramdisk. Hier finden Sie ein Beispiel für eine solche Änderung.

Module installieren

Sie können gerätespezifische Module in vendor_ramdisk installieren. Überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren möchten.

• Verwenden Sie die vendor_ramdisk-Variante des Moduls, wenn das Modul in /first_stage_ramdisk installiert wird. Dieses Modul sollte verfügbar sein, nachdem init den Root in /first_stage_ramdisk ändert, aber bevor init den Root in /system ändert. Beispiele finden Sie unter Metadaten-Prüfsummen und Virtuelle A/B-Kompression.

• Verwenden Sie die recovery-Variante des Moduls, wenn das Modul in / installiert wird. Dieses Modul sollte verfügbar sein, bevor init den Root in /first_stage_ramdisk ändert. Weitere Informationen zum Installieren von Modulen in / finden Sie unter Erste Phase der Konsole.

Konsole für die erste Stufe

Da die Konsole der ersten Phase vor dem Wechsel des Root-Verzeichnisses von init zu /first_stage_ramdisk startet, müssen Sie die recovery-Variante der Module installieren. Standardmäßig werden beide Modulvarianten in build/make/target/product/base_vendor.mk installiert. Wenn das Geräte-Makefile also von dieser Datei abgeleitet wird, müssen Sie die recovery-Variante nicht explizit installieren.

Verwenden Sie den folgenden Befehl, um die Wiederherstellungsmodule explizit zu installieren.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

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

Verwenden Sie Folgendes, um Module hinzuzufügen, die für die Console der ersten Phase erforderlich sind (z. B. adbd).

PRODUCT_PACKAGES += adbd.recovery

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

Metadaten-Prüfsummen

Zur Unterstützung von Metadaten-Prüfsummen während der Mount-Phase 1 werden auf Geräten, die GKI nicht unterstützen, die Ramdisk-Varianten der folgenden Module installiert. 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.

Virtual A/B-Komprimierung

Zur Unterstützung der Virtual A/B-Komprimierung muss snapuserd in vendor_ramdisk installiert sein. Das Gerät sollte von virtual_ab_ota/compression.mk erben, wodurch die vendor_ramdisk-Variante von snapuserd installiert wird.

Änderungen am Bootvorgang

Das Booten in den Wiederherstellungsmodus oder in Android ändert sich nicht, mit folgender Ausnahme:

• Die Ramdisk build.prop wird in /second_stage_resources verschoben, damit die zweite Phase init den Build-Zeitstempel des Bootvorgangs lesen kann.

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

e2fsck verfügbar machen

Die Makefiles für Geräte können Folgendes übernehmen:

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

• virtual_ab_ota/compression.mk, wenn das Gerät die 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 erste Phase init den Root-Pfad zu /first_stage_ramdisk und führt dann /system/bin/e2fsck aus.

Option 2a: Dedizierte und A/B-Wiederherstellungspartition

Verwenden Sie diese Option für Geräte mit A/B-recovery-Partitionen, d. h. das Gerät hat eine recovery_a und eine recovery_b partition. Dazu gehören A/B- und Virtual A/B-Geräte, deren Wiederherstellungspartition aktualisiert werden kann, mit der folgenden Konfiguration:

AB_OTA_PARTITIONS += recovery

Die vendor_boot-Ramdisk enthält die Anbieter-Bits der Ramdisk und die Anbieter-Kernelmodule, einschließlich der folgenden:

• Gerätespezifische fstab-Dateien

• lib/modules (einschließlich Kernelmodule des Anbieters)

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

BOARD-Werte festlegen

Legen Sie die folgenden Werte für Geräte mit A/B-Partition 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

Init-Binärdateien und ‑Symlinks

Die recovery-Ramdisk kann einen /init -> /system/bin/init-Symlink und init_second_stage.recovery unter /system/bin/init enthalten. Da die Boot-Ramdisk jedoch nach der recovery-Ramdisk verkettet wird, wird der /init-Symlink überschrieben. Wenn das Gerät im Wiederherstellungsmodus gestartet wird, ist die /system/bin/init-Binärdatei für die Initialisierung der zweiten Phase erforderlich.

Wenn das Gerät in recovery bootet, sind die Inhalte von recovery + vendor_boot + generische Ramdisks wie folgt:

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

Wenn das Gerät in Android hochfährt, enthält vendor_boot + generische Ramdisks Folgendes:

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

fstab-Dateien verschieben

Verschieben Sie alle fstab-Dateien, die in der generischen Ramdisk installiert wurden, in den vendor_ramdisk. Hier finden Sie ein Beispiel für eine solche Änderung.

Module installieren

Optional können Sie gerätespezifische Module in vendor_ramdisk installieren. Überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren möchten. Init wechselt nicht zum Root-Verzeichnis. Die vendor_ramdisk-Variante von Modulen wird im Stammverzeichnis von vendor_ramdisk installiert. Beispiele für die Installation von Modulen in vendor_ramdisk finden Sie unter First-Stage-Konsole, Metadaten-Prüfsummen und Virtuelle A/B-Komprimierung.

Konsole für die erste Stufe

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

So wird sichergestellt, dass linker, sh und toybox in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin installiert werden, was dann in /system/bin unter vendor_ramdisk installiert wird.

Wenn Sie Module hinzufügen möchten, die für die Console in der ersten Phase erforderlich sind (z. B. adbd), aktivieren Sie die vendor_ramdisk-Variante dieser Module, indem Sie entsprechende Patches in AOSP hochladen. Verwenden Sie dann Folgendes:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Metadaten-Prüfsummen

Zur Unterstützung von Metadaten-Prüfsummen während der Mount-Phase 1 werden auf Geräten, die GKI nicht unterstützen, die Ramdisk-Varianten der folgenden Module installiert. 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.

Virtual A/B-Komprimierung

Zur Unterstützung der Virtual A/B-Komprimierung muss snapuserd in vendor_ramdisk installiert sein. Das Gerät sollte von virtual_ab_ota/compression.mk erben, wodurch die vendor_ramdisk-Variante von snapuserd installiert wird.

Änderungen am Bootvorgang

Beim Booten in Android ändert sich der Bootvorgang nicht. Die vendor_boot + generische Ramdisk ähnelt dem vorhandenen Bootvorgang, mit der Ausnahme, dass fstab aus vendor_boot geladen wird. Da system/bin/recovery nicht vorhanden ist, behandelt first_stage_init den Vorgang als normalen Start.

Beim Starten im Wiederherstellungsmodus ändert sich der Startvorgang. Die Wiederherstellung + vendor_boot + generische Ramdisk ähnelt dem vorhandenen Wiederherstellungsprozess, aber der Kernel wird aus dem boot-Image anstelle des recovery-Images geladen. Der Bootvorgang für den Wiederherstellungsmodus läuft so ab:

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

   1. Überträgt „recovery“ + vendor_boot + generisches Ramdisk-Image an /. Wenn der OEM Kernelmodule in der Recovery-RAM-Disk dupliziert, indem er sie zu BOARD_RECOVERY_KERNEL_MODULES hinzufügt, ist vendor_boot optional.
   2. Führt den Kernel von der Partition boot aus.

2. Der Kernel hängt die Ramdisk in / ein und führt dann /init aus der generischen Ramdisk aus.

3. Die Initialisierung der ersten Phase wird gestartet und führt dann Folgendes aus:

   1. Legt IsRecoveryMode() == true und ForceNormalBoot() == false fest.
   2. Lädt Anbieter-Kernelmodule aus /lib/modules.
   3. Ruft DoFirstStageMount() auf, überspringt aber die Bereitstellung, weil IsRecoveryMode() == true. Das Gerät gibt die Ramdisk nicht kostenlos (da / immer noch gleich ist), ruft aber SetInitAvbVersionInRecovery() auf.
   4. Die Initialisierung der zweiten Phase wird ab /system/bin/init von der recovery-Ramdisk gestartet.

e2fsck verfügbar machen

Die Makefiles für Geräte können Folgendes übernehmen:

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

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

Die Produkt-Makefiles installieren $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. Zur Laufzeit wird in der ersten Phase init der Befehl /system/bin/e2fsck ausgeführt.

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

Verwenden Sie diese Option für Geräte mit einer Nicht-A/B-recovery-Partition. Das bedeutet, dass das Gerät eine Partition mit dem Namen recovery ohne Slot-Suffix hat. Dazu gehören:

• Nicht-A/B-Geräte
• A/B- und virtuelle A/B-Geräte, deren Wiederherstellungspartition nicht aktualisiert werden kann. Das ist ungewöhnlich.

Die vendor_boot-Ramdisk enthält die Anbieter-Bits der Ramdisk und die Anbieter-Kernelmodule, einschließlich der folgenden:

• Gerätespezifische fstab-Dateien
• lib/modules (einschließlich Kernelmodule des Anbieters)

Das recovery-Bild muss in sich geschlossen sein. Es muss alle erforderlichen Ressourcen zum Starten des Wiederherstellungsmodus enthalten, darunter:

• Das Kernel-Image
• Das DTBO-Image
• Kernelmodule in lib/modules
• Init-Datei der ersten Phase als Symlink /init -> /system/bin/init
• Binärdatei für die Initialisierung der zweiten Phase /system/bin/init
• Gerätespezifische fstab-Dateien
• Alle anderen Wiederherstellungsressourcen, einschließlich des recovery-Binärprogramms

Auf solchen Geräten wird die Produktkonfiguration von generic_ramdisk.mk abgeleitet.

BOARD-Werte festlegen

Legen Sie die folgenden Werte für Geräte ohne A/B-Partitionen 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

Init-Binärdateien und ‑Symlinks

Die recovery-Ramdisk muss einen /init -> /system/bin/init-Symlink und init_second_stage.recovery unter /system/bin/init enthalten. Wenn das Gerät im Wiederherstellungsmodus gestartet wird, ist die /system/bin/init-Binärdatei erforderlich, um die Initialisierung der ersten und zweiten Phase zu unterstützen.

Wenn das Gerät in recovery bootet, sind die Inhalte der recovery-Ramdisks wie folgt:

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

Wenn das Gerät in Android hochfährt, enthält vendor_boot + generische Ramdisks Folgendes:

• /init (von Ramdisk, erstellt aus init_first_stage)

fstab-Dateien verschieben

Verschieben Sie alle fstab-Dateien, die in der generischen Ramdisk installiert wurden, in die Ramdisk vendor_ramdisk und recovery. Hier finden Sie ein Beispiel für eine solche Änderung.

Module installieren

Sie können gerätespezifische Module in der vendor_ramdisk- und recovery-Ramdisk installieren. Überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren möchten. init wechselt nicht zum Root-Verzeichnis. Die vendor_ramdisk-Variante von Modulen wird im Stammverzeichnis von vendor_ramdisk installiert. Die recovery-Variante von Modulen wird im Stammverzeichnis der recovery-Ramdisk installiert. Beispiele für die Installation von Modulen in der vendor_ramdisk- und recovery-Ramdisk finden Sie unter First-Stage-Konsole und Metadaten-Prüfsummen.

Konsole für die erste Stufe

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

So wird sichergestellt, dass linker, sh und toybox in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin installiert werden, was dann in /system/bin unter vendor_ramdisk installiert wird.

Wenn Sie Module hinzufügen möchten, die für die Console in der ersten Phase erforderlich sind (z. B. adbd), aktivieren Sie die vendor_ramdisk-Variante dieser Module, indem Sie entsprechende Patches in AOSP hochladen. Verwenden Sie dann Folgendes:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Wenn Sie die recovery-Variante der Module installieren möchten, ersetzen Sie vendor_ramdisk durch recovery:

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

Metadaten-Prüfsummen

Zur Unterstützung von Metadaten-Prüfsummen während der Mount-Phase 1 werden auf Geräten, die GKI nicht unterstützen, die Ramdisk-Varianten der folgenden Module installiert. 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 \

Wenn Sie Metadaten-Prüfsummen während der ersten Phase der Bereitstellung in der Wiederherstellung unterstützen möchten, aktivieren Sie die Wiederherstellungsvariante dieser Module und installieren Sie sie ebenfalls.

Änderungen am Bootvorgang

Beim Booten in Android ändert sich der Bootvorgang nicht. Die vendor_boot + generische Ramdisk ähnelt dem vorhandenen Bootvorgang, mit der Ausnahme, dass fstab aus vendor_boot geladen wird. Da system/bin/recovery nicht vorhanden ist, behandelt first_stage_init den Vorgang als normalen Start.

Beim Booten in den Wiederherstellungsmodus ändert sich der Bootvorgang nicht. Die Recovery-Ramdisk wird auf dieselbe Weise geladen wie beim vorhandenen Recovery-Prozess. Der Kernel wird aus dem recovery-Image geladen. Der Bootvorgang für den Wiederherstellungsmodus läuft so ab:

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

   1. Überträgt die Recovery-Ramdisk per Push zu /.
   2. Führt den Kernel von der Partition recovery aus.

2. Der Kernel stellt die Ramdisk in / bereit und führt dann /init aus. Das ist ein symbolischer Link zu /system/bin/init aus der recovery-Ramdisk.

3. Die Initialisierung der ersten Phase wird gestartet und führt dann Folgendes aus:

   1. Legt IsRecoveryMode() == true und ForceNormalBoot() == false fest.
   2. Lädt Anbieter-Kernelmodule aus /lib/modules.
   3. Ruft DoFirstStageMount() auf, überspringt aber die Bereitstellung, weil IsRecoveryMode() == true. Das Gerät gibt die Ramdisk nicht kostenlos (da / immer noch gleich ist), ruft aber SetInitAvbVersionInRecovery() auf.
   4. Die Initialisierung der zweiten Phase wird ab /system/bin/init von der recovery-Ramdisk gestartet.

Zeitstempel für Boot-Images

Der folgende Code ist ein Beispiel für eine boot-Datei mit Bildzeitstempeln:

####################################
# 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 zum Build.

• Zur Laufzeit kopiert die erste Phase init Dateien von der RAM-Disk nach tmpfs, bevor die RAM-Disk freigegeben wird, damit die zweite Phase init diese Datei lesen kann, um die Zeitstempel-Properties des boot-Images festzulegen.