Generische Bootpartition

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

Bei Geräten, die mit Android 13 ausgeliefert werden, wird das generische RAM-Disk aus dem boot-Image entfernt und in ein separates init_boot-Image verschoben. Durch diese Änderung verbleibt im boot-Image nur der GKI-Kernel.

Beim Upgrade von Geräten, auf denen weiterhin Android 12 oder ältere Kernelversionen verwendet werden, bleibt das generische RAM-Disk an seiner Position und es ist kein neues init_boot-Image erforderlich.

Wenn Sie ein generisches RAM-Disk erstellen möchten, verschieben Sie anbieterspezifische Ressourcen aus dem RAM-Disk, sodass es nur init der ersten Stufe und eine Property-Datei mit Zeitstempelinformationen enthält.

Auf Geräten, auf denen Folgendes zutrifft:

  • Verwenden Sie keine spezielle recovery-Partition. Alle Wiederherstellungs-Bits werden vom generischen Ramdisk in das vendor_boot-Ramdisk verschoben.

  • Verwenden Sie eine spezielle recovery-Partition. Es sind keine Änderungen am recovery-Ramdisk erforderlich, da es eigenständig ist.recovery

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 gebracht werden, haben ein neues init_boot-Image mit dem generischen RAM-Disk. Geräte, die von Android 12 auf Android 13 umgestellt werden, verwenden dieselbe Architektur wie unter Android 12.

Mit Android 13 ausgeliefert, keine spezielle Wiederherstellung

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

Abbildung 1. Geräte, die mit Android 13 ausgeliefert werden oder auf Android 13 umgestellt werden, mit GKI, keine spezielle Wiederherstellung

Markteinführung mit Android 13, spezielle und A/B-Wiederherstellung (eigenes RAM-Disk)

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

Abbildung 2. Geräte, die mit Android 13 ausgeliefert werden oder auf Android 13 umgestellt werden, mit GKI, spezieller und A/B-Wiederherstellung

Diese Abbildung gilt, wenn das Gerät die Partitionen recovery_a und recovery_b hat.

Markteinführung mit Android 13, spezielle und nicht A/B-Wiederherstellung (eigenes RAM-Disk)

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

Abbildung 3 Geräte, die mit Android 13 ausgeliefert werden oder auf Android 13 umgestellt werden, mit GKI, spezieller und nicht A/B-Wiederherstellung

Diese Abbildung gilt, wenn das Gerät eine Partition mit dem Namen recovery ohne Slot-Suffix hat.

Starten oder Upgrade auf Android 12, keine spezielle Wiederherstellung

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

Abbildung 4: Geräte, die auf Android 12 auf den Markt gebracht oder darauf aktualisiert werden, mit GKI, keine dedizierte Wiederherstellung.

Starten oder Upgrade auf Android 12, spezielle und A/B-Wiederherstellung (eigenes RAM-Disk)

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

Abbildung 5: Geräte, die mit Android 12 ausgeliefert werden oder auf Android 12 umgestellt werden, mit GKI, spezieller und A/B-Wiederherstellung

Diese Abbildung gilt, wenn das Gerät die Partitionen recovery_a und recovery_b hat.

Starten oder Upgrade auf Android 12, spezielle und nicht A/B-Wiederherstellung (eigenes RAM-Disk)

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

Abbildung 6 Geräte, die auf Android 12 auf den Markt gebracht oder darauf aktualisiert werden, mit Google-KI, zweckbestimmter und Nicht-A/B-Wiederherstellung.

In dieser Abbildung sehen Sie, wenn das Gerät eine Partition mit dem Namen recovery ohne Slotsuffix hat.

Upgrade auf Android 12, recovery-as-boot (recovery-as-ramdisk)

Gerät starten/upgraden, keine GKI, Wiederherstellung als Boot

Abbildung 7. Geräte, die auf Android 12 aktualisiert werden, ohne GKI und Wiederherstellung als Bootmodus.

Upgrade auf Android 12, spezielle Wiederherstellung (eigenes RAM-Disk)

Gerät starten/upgraden, keine GKI, spezielle Wiederherstellung

Abbildung 8. Geräte, die auf Android 12 umgestellt werden, keine GKI, spezielle Wiederherstellung

Inhalt 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 gebracht werden

    • Überschriftenversion V4
    • Generisches Ramdisk-Image

  • Generisches boot-Bild

    • Header-Version V3 oder V4
      • Ein 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 die vordefinierte boot.img weiterhin mit einem gerätespezifischen AVB-Schlüssel signieren.
      • Allgemein cmdline (GENERIC_KERNEL_CMDLINE)
      • GKI-Kernel
    • Generisches Ramdisk-Image
      • Nur in boot-Images von Android 12 und niedriger enthalten

  • vendor_boot-Image (weitere Informationen finden Sie unter Bootpartitionen des Anbieters)

    • vendor_boot-Header
      • Gerätespezifische cmdline (BOARD_KERNEL_CMDLINE)
    • vendor_boot Ramdisk-Image
      • lib/modules
      • Wiederherstellungsressourcen (wenn keine dedizierten Wiederherstellung vorhanden ist)
    • Bild mit dtb

  • Bild mit recovery

    • Header-Version V2
      • Gerätespezifische cmdline für die Wiederherstellung, falls erforderlich
      • Bei einer nicht A/B-Wiederherstellungspartition muss der Inhalt des Headers eigenständig sein. Weitere Informationen finden Sie unter Wiederherstellungs-Images. Beispiel:
      • cmdline ist nicht mit boot und vendor_boot cmdline verkettet.
      • Im Header wird ggf. die DTBO für die Wiederherstellung angegeben.
      • Bei der A/B-Wiederherstellungspartition können Inhalte aus boot und vendor_boot zusammengeführt oder abgeleitet werden. Beispiel:
      • cmdline ist mit boot und vendor_boot cmdline verknüpft.
      • DTBO kann aus dem vendor_boot-Header abgeleitet werden.
    • recovery Ramdisk-Image
      • Ressourcen zur Wiederherstellung
      • Bei einer nicht A/B-Wiederherstellungspartition muss der Inhalt des RAM-Disks eigenständig sein. Weitere Informationen finden Sie unter Wiederherstellungs-Images. Beispiel:
      • lib/modules muss alle Kernelmodule enthalten, die für den Boot-Wiederherstellungsmodus erforderlich sind
      • Das Wiederherstellungs-Ramdisk muss init enthalten.
      • Bei der A/B-Wiederherstellungspartition wird das Wiederherstellungs-Ramdisk dem generischen und vendor_boot-Ramdisk vorangestellt. Es muss also nicht eigenständig sein. Beispiel:
      • lib/modules enthält möglicherweise nur zusätzliche Kernelmodule, die zum Starten 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 /init-Binärdatei der ersten Phase im Boot-Image überschattet.

Inhalt eines generischen RAM-Disk-Images

Das generische RAM-Disk 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/
    • Leere Verzeichnisse für Bereitstellungspunkte wurden dupliziert: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

Integration des Boot-Images

Mit Build-Flags wird festgelegt, wie init_boot-, boot-, recovery- und vendor_boot-Images erstellt werden. Der Wert einer booleschen Boardvariablen muss der String true sein oder leer sein (Standardeinstellung).

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

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

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

    Dies ist der GKI-Schalter auf Boardebene. Alle folgenden Variablen sind durch diese Variable eingeschränkt.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT: Diese Variable steuert, ob Ressourcen für die Wiederherstellung von RAM-Disks für vendor_boot erstellt werden.

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

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

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

    • Wenn true festgelegt ist, gilt für BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT Folgendes:

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

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

    • Wenn leer, falls BOARD_RECOVERY_AS_ROOT:

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

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

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE: Diese Variable gibt an, ob das recovery-Bild einen Kernel enthält. Auf Geräten, die mit Android 12 gestartet werden und die A/B-Partition recovery verwenden, muss diese Variable auf true festgelegt werden. Bei Geräten, die mit Android 12 ausgeliefert werden und kein A/B-System verwenden, muss diese Variable auf false festgelegt werden, damit das Wiederherstellungs-Image in sich geschlossen ist.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES: Diese Variable steuert, ob $OUT/boot*.img in Zieldateien in IMAGES/ kopiert wird.

    • aosp_arm64 muss diese Variable auf true festlegen.

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

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE: Diese Variable steuert, ob init_boot.img generiert wird, und legt die Größe fest. Wenn diese Option festgelegt ist, wird das generische RAM-Disk 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 starten Gerät mit nicht A/B-Wiederherstellungspartition starten 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 no 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

Bei Geräten mit einer speziellen 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 Start aktivieren

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

Ein Beispiel hierfür ist diese Änderung.

System-as-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 mit dynamischen Partitionen unterstützt.

Produktkonfigurationen

Auf Geräten, die das generisch verwendete RAM-Disk verwenden, muss eine Liste der Dateien installiert werden, die im RAM-Disk installiert werden dürfen. Geben Sie dazu in device.mk Folgendes an:

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

Die generic_ramdisk.mk-Datei verhindert außerdem, dass andere Makefiles versehentlich andere Dateien im RAM-Dateisystem 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 ausgeliefert wird, auf Android 12 aktualisiert wird oder mit Android 12 ausgeliefert wird. Android 13 werden ähnlich wie bei Android 12 eingerichtet.

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

    • Der Wert von BOARD_USES_RECOVERY_AS_BOOT kann beibehalten werden. In diesem Fall 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 so aus wie in Abbildung 3.

      • Wenn Sie BOARD_USES_RECOVERY_AS_BOOT auf „leer“ setzen, sieht die Architektur so aus wie in Abbildung 4.

    • BOARD_USES_RECOVERY_AS_BOOT kann leer sein. In diesem Fall werden neue Konfigurationen verwendet. Bei solchen Geräten gilt Folgendes:

      • Verwenden Sie keine spezielle recovery-Partition. Die Architektur entspricht Abbildung 1 und die Option für die Geräteeinrichtung ist Option 1.

      • Es wird eine spezielle recovery-Partition verwendet, die Architektur entspricht Abbildung 2a oder Abbildung 2b und die Option für die Geräteeinrichtung ist Option 2a oder Option 2b.

  • Bei Geräten, die mit Android 12 ausgeliefert werden, muss BOARD_USES_RECOVERY_AS_BOOT auf „Leeres Feld“ gesetzt und neue Konfigurationen verwendet werden. Wenn solche Geräte:

    • Verwenden Sie keine spezielle recovery-Partition. Die Architektur entspricht Abbildung 1 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 Wiederherstellung erstellt, ist dies kein vollständiges Ziel. Informationen zu aosp_arm64-Buildkonfigurationen finden Sie unter generic_arm64.

Option 1: Keine spezielle Wiederherstellungspartition

Geräte ohne recovery-Partition enthalten das generische boot-Image in der boot-Partition. Das vendor_boot-Ramdisk enthält alle Wiederherstellungsressourcen, einschließlich lib/modules (mit Kernelmodulen des Anbieters). Auf solchen Geräten wird die Produktkonfiguration von generic_ramdisk.mk übernommen.

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

Das vendor_boot-Ramdisk kann einen Symlink von /init nach /system/bin/init und init_second_stage.recovery unter /system/bin/init enthalten. Da das generische RAM-Disk jedoch nach dem vendor_boot-RAM-Disk konkateniert wird, wird der /init-Symlink überschrieben. Wenn das Gerät in den Wiederherstellungsmodus startet, ist das /system/bin/init-Binärprogramm erforderlich, um die zweite Phase der Initialisierung zu unterstützen. Der Inhalt von vendor_boot + generischen RAM-Disks sieht so aus:

  • /init (aus generischen RAM-Disk, erstellt aus init_first_stage)
  • /system/bin/init (von vendor_ramdisk, basierend auf init_second_stage.recovery)

fstab-Dateien verschieben

Verschieben Sie alle fstab-Dateien, die im generischen RAM-Disk installiert wurden, nach vendor_ramdisk. Ein Beispiel hierfür ist diese Änderung.

Module installieren

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

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

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

Konsole der ersten Phase

Da die Konsole der ersten Phase gestartet wird, bevor init den Root-Nutzer zu /first_stage_ramdisk wechselt, müssen Sie die recovery-Variante der Module installieren. Standardmäßig werden beide Modulvarianten unter build/make/target/product/base_vendor.mk installiert. Wenn das Geräte-Makefile also von dieser Datei erbt, müssen Sie die recovery-Variante nicht explizit installieren.

Wenn Sie die Wiederherstellungsmodule explizit installieren möchten, verwenden Sie Folgendes:

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

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

So fügen Sie Module hinzu, die für die Konsole der ersten Phase erforderlich sind (z. B. adbd):

PRODUCT_PACKAGES += adbd.recovery

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

Metadaten-Prüfsummen

Zur Unterstützung von Metadaten-Prüfsummen während der ersten Bereitstellungsphase wird auf Geräten, die GKI nicht unterstützen, die Ramdisk-Variante der folgenden Module installiert. Wenn Sie GKI unterstützen möchten, verschieben Sie die Module zu $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

Für die Unterstützung der virtuellen A/B-Komprimierung muss snapuserd unter 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 mit folgender Ausnahme nicht:

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

Da Ressourcen vom generischen Ramdisk zum vendor_boot-Ramdisk verschoben werden, ändert sich das Ergebnis der Zusammenführung des generischen Ramdisks mit dem vendor_boot-Ramdisk nicht.

e2fsck verfügbar machen

Die Gerätemakefiles können von folgenden Elementen übernommen werden:

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

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

$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck wird über die Makefiles des Produkts installiert. Während der Laufzeit wechselt die erste Phase init den Root 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 virtuelle A/B-Geräte, bei denen die Wiederherstellungspartition mit der folgenden Konfiguration aktualisiert werden kann:

AB_OTA_PARTITIONS += recovery

Das vendor_boot-Ramdisk enthält die Anbieterbits des Ramdisks und die Anbieterkernelmodule, darunter:

  • Gerätespezifische fstab-Dateien

  • lib/modules (einschließlich Kernelmodule von Anbietern)

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

BOARD-Werte festlegen

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

Das recovery-Ramdisk kann einen /init -> /system/bin/init-Symlink und init_second_stage.recovery unter /system/bin/init enthalten. Da das Boot-Ramdisk jedoch nach dem recovery-Ramdisk konkateniert wird, wird der /init-Symlink überschrieben. Wenn das Gerät im Wiederherstellungsmodus startet, ist das /system/bin/init-Binärprogramm erforderlich, um die zweite Phase der Initialisierung zu unterstützen.

Wenn das Gerät in recovery startet, sieht der Inhalt von recovery + vendor_boot + generischen RAM-Disks so aus:

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

Wenn das Gerät in Android startet, sieht der Inhalt von vendor_boot + generischen RAM-Disks so aus:

  • /init (aus generischen RAM-Disk, erstellt aus init_first_stage)

Fstab-Dateien verschieben

Verschieben Sie alle fstab-Dateien, die im generischen RAM-Disk installiert wurden, auf das vendor_ramdisk. Ein Beispiel hierfür ist diese Änderung.

Module installieren

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

Konsole der ersten Phase

So installieren Sie die vendor_ramdisk-Variante der Module:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

So werden linker, sh und toybox unter $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin installiert, das dann unter vendor_ramdisk auf /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 Variante vendor_ramdisk dieser Module. Laden Sie dazu relevante Patches in AOSP hoch 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 das vendor_boot-Ramdisk im Wiederherstellungsmodus geladen wird, ist das Modul auch in recovery verfügbar. Wenn die RAM-Disk vendor_boot 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 ersten Bereitstellungsphase wird auf Geräten, die GKI nicht unterstützen, die Ramdisk-Variante der folgenden Module installiert. Wenn Sie GKI unterstützen möchten, verschieben Sie die Module zu $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

Für die Unterstützung der virtuellen A/B-Komprimierung muss snapuserd unter vendor_ramdisk installiert sein. Das Gerät sollte die Einstellungen von virtual_ab_ota/compression.mk übernehmen, wodurch die vendor_ramdisk-Variante von snapuserd installiert wird.

Änderungen am Bootvorgang

Beim Starten in Android ändert sich der Bootvorgang nicht. vendor_boot und generisches Ramdisk ähnelt dem vorhandenen Bootprozess, 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.

Wenn Sie im Wiederherstellungsmodus starten, ändert sich der Bootvorgang. Die Wiederherstellung + vendor_boot + generisches Ramdisk ähnelt dem vorhandenen Wiederherstellungsprozess, der Kernel wird jedoch aus dem boot-Image und nicht aus dem recovery-Image geladen. So starten Sie das Gerät im Wiederherstellungsmodus:

  1. Bootloader wird gestartet und führt dann folgende Schritte aus:

    1. Verschiebt die Wiederherstellung + vendor_boot + generisches RAMdisk auf /. (Wenn der OEM Kernelmodule im Wiederherstellungs-Ramdisk 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 aus.

  2. Der Kernel stellt Ramdisk für / bereit und führt dann /init aus der generischen Ramdisk aus.

  3. Die erste Phase von init wird gestartet und führt dann Folgendes aus:

    1. Legt IsRecoveryMode() == true und ForceNormalBoot() == false fest.
    2. Lädt Kernelmodule des Anbieters aus /lib/modules.
    3. Ruft DoFirstStageMount() auf, überspringt aber die Bereitstellung aus folgendem Grund: IsRecoveryMode() == true. Das Gerät gibt das Ramdisk nicht kostenlos (weil / unverändert ist), ruft aber SetInitAvbVersionInRecovery() auf.
    4. Startet die Initialisierung der zweiten Phase mit /system/bin/init von recovery ramdisk.

e2fsck verfügbar machen

Die Gerätemakefiles können von folgenden Elementen übernommen werden:

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

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

$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck wird über die Makefiles des Produkts installiert. Zur Laufzeit führt die erste Phase init /system/bin/e2fsck aus.

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

Verwenden Sie diese Option für Geräte mit einer Nicht-A/B-Partition vom Typ recovery, d. h., 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 aktualisiert werden kann. (Das ist ungewöhnlich.)

Das RAM-Disk vendor_boot enthält die Anbieter-Bits der Ramdisk und die Kernel-Module des Anbieters, darunter:

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

Das recovery-Image muss unabhängig sein. Sie muss alle erforderlichen Ressourcen zum Starten des Wiederherstellungsmodus enthalten, darunter:

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

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

BOARD-Werte festlegen

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

Das 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 startet, ist das /system/bin/init-Binärprogramm erforderlich, um sowohl die Erst- als auch die Zweitphase der Initialisierung zu unterstützen.

Wenn das Gerät in recovery gestartet wird, sieht der Inhalt der recovery-RAMdisks so aus:

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

Wenn das Gerät in Android startet, sieht der Inhalt von vendor_boot + generischen RAM-Disks so aus:

  • /init (von Ramdisk, erstellt von init_first_stage)

Fstab-Dateien verschieben

Verschieben Sie alle fstab-Dateien, die im generischen RAM-Disk installiert wurden, in die RAM-Disks vendor_ramdisk und recovery. Ein Beispiel finden Sie in dieser Änderung.

Module installieren

Sie können gerätespezifische Module in vendor_ramdisk und recovery Ramdisk installieren. Überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren müssen. init wechselt nicht das Stammverzeichnis. Die vendor_ramdisk-Variante der Module wird im Stammverzeichnis von vendor_ramdisk installiert. Die recovery-Variante der Module wird im Stammverzeichnis des recovery-Ramdisks installiert. Beispiele zum Installieren von Modulen im vendor_ramdisk- und recovery-Ramdisk finden Sie unter Erste-Phase-Konsole und Metadaten-Prüfsummen.

Konsole der ersten Phase

So installieren Sie die vendor_ramdisk-Variante der Module:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

So werden linker, sh und toybox unter $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin installiert, das dann unter vendor_ramdisk auf /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 Variante vendor_ramdisk dieser Module. Laden Sie dazu relevante Patches in AOSP hoch 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 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 Metadatenprüfsummen während der Bereitstellung in der ersten Phase installieren Geräte, die GKI nicht unterstützen, die Ramdisk-Variante der folgenden Module. Verschieben Sie die Module nach $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, um Unterstützung für GKI hinzuzufügen:

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 Starten in Android ändert sich der Bootvorgang nicht. vendor_boot + fstab ist dem vorhandenen Bootvorgang ähnlich, mit der Ausnahme, dass fstab von vendor_boot geladen wird. Da system/bin/recovery nicht existiert, behandelt first_stage_init es als normalen Start.

Wenn Sie im Wiederherstellungsmodus starten, ändert sich der Bootvorgang nicht. Das Wiederherstellungs-RAM-Laufwerk wird auf die gleiche Weise wie der vorhandene Wiederherstellungsprozess geladen. Der Kernel wird aus dem recovery-Image geladen. So starten Sie das Gerät im Wiederherstellungsmodus:

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

    1. Überträgt das Wiederherstellungs-RAM-Disk auf /.
    2. Führt den Kernel über die recovery-Partition aus.

  2. Der Kernel stellt Ramdisk auf / bereit und führt dann /init aus, bei dem es sich um einen Symlink zu /system/bin/init von der Ramdisk-recovery handelt.

  3. Die erste Phase init wird gestartet. Anschließend werden folgende Schritte ausgeführt:

    1. Legt IsRecoveryMode() == true und ForceNormalBoot() == false fest.
    2. Lädt Kernelmodule des Anbieters aus /lib/modules.
    3. Ruft DoFirstStageMount() auf, überspringt aber die Bereitstellung aus folgendem Grund: IsRecoveryMode() == true. Das Gerät gibt das Ramdisk nicht kostenlos (weil / unverändert ist), ruft aber SetInitAvbVersionInRecovery() auf.
    4. Startet die zweite Phase der Init-Datei von /system/bin/init aus dem recovery-Ramdisk.

Zeitstempel für Boot-Images

Der folgende Code ist ein Beispiel für eine boot-Zeitstempeldatei für Bilder:

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

  • Beim Build wird dem generischen RAM-Disk eine system/etc/ramdisk/build.prop-Datei hinzugefügt. Diese Datei enthält Zeitstempelinformationen zum Build.

  • Während der Laufzeit kopiert die erste Phase init Dateien aus dem RAM-Disk in tmpfs, bevor der RAM-Disk freigegeben wird, damit die zweite Phase init diese Datei lesen und die Zeitstempeleigenschaften des boot-Images festlegen kann.