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 einem separaten init_boot-Image platziert. Dadurch bleibt im boot-Image nur der GKI-Kernel übrig.

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 das generische RAM-Disk nur init der ersten Phase 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 zeigen 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. Auf Geräten, die von Android 12 auf Android 13 umgestellt werden, wird dieselbe Architektur verwendet wie bei 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, spezielle 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 mit Android 12 ausgeliefert werden oder auf Android 12 umgestellt werden, mit GKI, keine spezielle Wiederherstellung

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

Gerät starten/aktualisieren, GKI, spezielle 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 mit Android 12 ausgeliefert werden oder auf Android 12 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.

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 umgestellt werden, ohne GKI, Recovery-as-Boot

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

Gerät starten/aktualisieren, 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 kommen

    • Ü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 vorgefertigte boot.img weiterhin mit einem gerätespezifischen AVB-Schlüssel signieren.
      • Allgemein cmdline (GENERIC_KERNEL_CMDLINE)
      • GKI-Kernel
    • Generisches Ramdisk-Image
      • Nur in boot-Bildern von Android 12 und niedriger enthalten

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

    • vendor_boot-Header
      • Gerätespezifische cmdline (BOARD_KERNEL_CMDLINE)
    • vendor_boot Ramdisk-Image
      • lib/modules
      • Ressourcen zur Wiederherstellung (falls keine spezielle Wiederherstellung)
    • dtb Bild

  • recovery Bild

    • 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 verknüpft.cmdline
      • 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-Laufwerks eigenständig sein. Weitere Informationen finden Sie unter Wiederherstellungs-Images. Beispiel:
      • lib/modules muss alle Kernelmodule enthalten, die zum Starten des 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/
    • Duplizierte leere Verzeichnisse für Bereitstellungspunkte: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

Integration des Boot-Images

Build-Flags steuern, 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, setzen Sie BOARD_PREBUILT_BOOTIMAGE auf den Speicherort des vorkonfigurierten Boot-Images (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img).

  • BOARD_USES_RECOVERY_AS_BOOT: Diese Variable gibt an, ob das Gerät das recovery-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 hat keine Auswirkungen auf sysprops oder PRODUCT_PACKAGES.

    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 Ramdisk 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 auf BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT festgelegt ist:

      • Ist dies 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 BOARD_RECOVERY_AS_ROOT leer ist:

      • Ist dies 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. Bei 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

Für die boot- und init_boot-Images muss die verkettete vbmeta 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 diesen Geräten muss BOARD_BUILD_SYSTEM_ROOT_IMAGE leer sein. „System als Root“ wird auch nicht für Geräte unterstützt, die dynamische Partitionen verwenden.

Produktkonfigurationen

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 unter 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 werden alte Konfigurationen verwendet und neue Buildvariablen 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.

    • 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.

Da aosp_arm64 nur GKI und nicht vendor_boot oder die Wiederherstellung erstellt, ist es 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 unter / 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 \

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

Wenn Sie Module hinzufügen möchten, die für die Konsole der ersten Phase erforderlich sind (z. B. adbd), gehen Sie so vor:

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äte-Makefiles können von folgenden Elementen übernommen werden:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk, wenn das Gerät virtuelle A/B-Partitionen, 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. 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)

Das recovery-Ramdisk 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 aus init_second_stage.recovery und ausgeführt von /init)

Wenn das Gerät in Android gestartet wird, 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 den Stamm. 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 für die Konsole der ersten Phase erforderliche Module hinzufügen möchten (z. B. adbd), aktivieren Sie die vendor_ramdisk-Variante dieser Module, indem Sie die entsprechenden 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 das vendor_boot-Ramdisk im Wiederherstellungsmodus geladen wird, ist das Modul auch in recovery verfügbar. Wenn das vendor_boot-Ramdisk nicht im Wiederherstellungsmodus geladen wird, kann auf dem Gerät optional auch adbd.recovery installiert werden.

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 von virtual_ab_ota/compression.mk erben, wodurch die vendor_ramdisk-Variante von snapuserd installiert wird.

Ä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 den Vorgang als normalen Start.

Wenn Sie im Wiederherstellungsmodus starten, ändert sich der Bootvorgang. Die Wiederherstellung mit vendor_boot und einem generischen RAM-Disk ähnelt dem vorhandenen Wiederherstellungsprozess. Der Kernel wird jedoch aus dem boot-Image statt 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 die Wiederherstellungsdatei, vendor_boot und das generische RAM-Disk auf /. (Wenn der OEM Kernelmodule im Recovery-Ramdisk dupliziert, indem er sie zu BOARD_RECOVERY_KERNEL_MODULES hinzufügt, ist vendor_boot optional.)
    2. Führt den Kernel von der boot-Partition aus.

  2. Der Kernel bindet das RAM-Disk an / an und führt dann /init aus dem generischen RAM-Disk 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 Anbieter-Kernelmodule von /lib/modules.
    3. Ruft DoFirstStageMount() auf, überspringt aber das Bereitstellen, weil IsRecoveryMode() == true. Das Gerät gibt das Ramdisk nicht kostenlos (weil / gleich bleibt), ruft aber SetInitAvbVersionInRecovery() auf.
    4. Startet die zweite Phase der Init-Datei von /system/bin/init aus dem recovery-Ramdisk.

e2fsck verfügbar machen

Die Geräte-Makefiles können von folgenden Elementen übernommen werden:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk, wenn das Gerät virtuelle A/B-Partitionen, 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. Während der 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 recovery, d. h. das Gerät hat eine Partition namens recovery ohne Slot-Suffix. 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.)

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)

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 startet, hat das recovery-Ramdisk den folgenden Inhalt:

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

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

  • /init (aus 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 hierfür ist diese Ä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 den Stamm. 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 für die Konsole der ersten Phase erforderliche Module hinzufügen möchten (z. B. adbd), aktivieren Sie die vendor_ramdisk-Variante dieser Module, indem Sie die entsprechenden 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 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 \

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 den Vorgang 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 von der recovery-Partition aus.

  2. Der Kernel bindet das RAM-Disk an / und führt dann /init aus, einen Symlink zu /system/bin/init aus dem recovery-RAM-Disk.

  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 Anbieter-Kernelmodule von /lib/modules.
    3. Ruft DoFirstStageMount() auf, überspringt aber das Bereitstellen, weil IsRecoveryMode() == true. Das Gerät gibt das Ramdisk nicht kostenlos (weil / gleich bleibt), ruft aber SetInitAvbVersionInRecovery() auf.
    4. Startet die zweite Phase der Init-Datei von /system/bin/init aus dem recovery-Ramdisk.

Zeitstempel des 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 sie das RAM-Disk freigibt, damit die zweite Phase init diese Datei lesen kann, um die Zeitstempeleigenschaften des boot-Images festzulegen.