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 die Aktualisierung 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 init und eine Eigenschaftendatei mit Zeitstempelinformationen enthält.

Auf Geräten, die

  • Verwenden Sie keine dedizierte recovery-Partition. Alle Recovery-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

Gerät wird eingeführt/upgegradet, GKI, kein dedizierter Wiederherstellungsmodus

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

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

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

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)

Gerät starten/upgraden, GKI, dedizierte und nicht A/B-Wiederherstellung

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

Gerät wird eingeführt/upgegradet, GKI, kein dedizierter Wiederherstellungsmodus

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)

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

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)

Gerät starten/upgraden, GKI, dedizierte und nicht A/B-Wiederherstellung

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)

Gerät wird eingeführt/upgegradet, 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 wird eingeführt/upgegradet, kein GKI, dedizierte Wiederherstellung

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 hinzugefügt, die mit Android 13 auf den Markt kommen

    • 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). Der 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 Partitions)

    • vendor_boot header
      • Gerätespezifische cmdline (BOARD_KERNEL_CMDLINE)
    • vendor_boot ramdisk-Image
      • lib/modules
      • Wiederherstellungsressourcen (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.
      • Für die A/B-Wiederherstellungspartition können Inhalte verkettet oder aus boot und vendor_boot 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 für die 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 Kernelmodule 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 auf dem Board GKI verwendet wird. Diese Variable hat keine Auswirkungen auf Systemattribute 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 für 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 den Zieldateien in IMAGES/ 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 Ramdisk 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

Komponente oder Variable Gerät ohne Wiederherstellungspartition aktualisieren Gerät mit Wiederherstellungspartition aktualisieren Gerät ohne Wiederherstellungspartition starten Gerät mit A/B-Wiederherstellungspartition auf den Markt bringen Gerät mit einer Wiederherstellungspartition ohne A/B-Partitionierung auf den Markt bringen aosp_arm64
Enthält boot Ja ja ja ja ja Ja
Enthält init_boot (Android 13) no no Ja ja ja Ja
Enthält vendor_boot optional optional Ja ja Ja no
Enthält recovery no Ja Nein Ja Ja no
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

Auf 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 werden ähnlich wie bei Android 12 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 Sie BOARD_USES_RECOVERY_AS_BOOT auf true festlegen, 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 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.

  • Auf 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 Anbietermodulen). 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

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 RAM-Disk 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 Konsole für die erste Phase.

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, das dann unter vendor_ramdisk in /system/bin installiert wird.

Verwenden Sie Folgendes, um Module hinzuzufügen, die für die Console in 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

Um Metadaten-Prüfsummen während der Mount-Phase der ersten Stufe zu unterstützen, wird auf Geräten, die GKI nicht unterstützen, die Ramdisk-Variante 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

Der Prozess des Bootens in den Wiederherstellungsmodus oder in Android ändert sich nicht, mit der folgenden 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-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 Anbieterbits der Ramdisk und die Anbieterkernelmodule, 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

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 Unterstützung der zweiten Phase der Initialisierung erforderlich.

Wenn das Gerät in recovery bootet, sind die Inhalte von recovery + vendor_boot + generischen 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, sieht der Inhalt von vendor_boot + generischen Ramdisks so aus:

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

„fstab“-Dateien verschieben

Verschieben Sie alle fstab-Dateien, die in der generischen RAM-Disk 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, das dann unter vendor_ramdisk in /system/bin installiert wird.

Wenn Sie Module hinzufügen möchten, die für die Konsole 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

Um Metadaten-Prüfsummen während der Mount-Phase der ersten Stufe zu unterstützen, wird auf Geräten, die GKI nicht unterstützen, die Ramdisk-Variante 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, wird first_stage_init als normaler Start behandelt.

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 sieht so aus:

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

    1. Überträgt „recovery“ + vendor_boot + generisches Ramdisk-Image nach /. 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. Startet die Initialisierung der zweiten Phase ab /system/bin/init aus der recovery-Ramdisk.

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 Code /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:

  • Geräte, die keine A/B‑Geräte sind;
  • 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 Anbieterbits der Ramdisk und die Anbieterkernelmodule, 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 übernommen.

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

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 das /system/bin/init-Binärprogramm erforderlich, um die Initialisierung der ersten und zweiten Phase zu unterstützen.

Wenn das Gerät in recovery gebootet wird, 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, sieht der Inhalt von vendor_boot + generischen Ramdisks so aus:

  • /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-RAM-Disk installiert. Beispiele für die Installation von Modulen in vendor_ramdisk- und recovery-Ramdisk finden Sie unter Konsole der ersten Phase 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, das dann unter vendor_ramdisk in /system/bin installiert wird.

Wenn Sie Module hinzufügen möchten, die für die Konsole 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

Um Metadaten-Prüfsummen während der Mount-Phase der ersten Stufe zu unterstützen, wird auf Geräten, die GKI nicht unterstützen, die Ramdisk-Variante 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 Bereitstellung in der ersten Phase 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, wird first_stage_init als normaler Start behandelt.

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 RAM-Disk unter / bereit und führt dann /init aus. Das ist ein symbolischer Link zu /system/bin/init aus der recovery-RAM-Disk.

  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. Startet die Initialisierung der zweiten Phase ab /system/bin/init aus der recovery-Ramdisk.

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. So kann die zweite Phase init diese Datei lesen, um die Zeitstempel-Properties des boot-Images festzulegen.