Generische Boot-Partition

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

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

Bei der Aktualisierung von Geräten, die weiterhin Android 12 oder ältere Kernel-Versionen verwenden, bleibt die generische Ramdisk dort, wo sie war, ohne dass ein neues init_boot Image erforderlich ist.

Um eine generische Ramdisk zu erstellen, verschieben Sie herstellerspezifische Ressourcen aus der Ramdisk, sodass die generische Ramdisk nur init der ersten Stufe und eine Eigenschaftendatei enthält, die Zeitstempelinformationen enthält.

Auf Geräten, die:

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

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

Die Architektur

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

Start mit Android 13, keine dedizierte Wiederherstellung

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

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

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

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

Abbildung 2. Geräte, die Android 13 starten oder auf Android 13 aktualisieren, mit GKI, dedizierter und A/B-Wiederherstellung

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

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

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

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

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

Starten oder Upgrade auf Android 12, keine dedizierte Wiederherstellung

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

Abbildung 4. Geräte, die Android 12 starten oder auf Android 12 aktualisieren, mit GKI, ohne dedizierte Wiederherstellung

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

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

Abbildung 5. Geräte, die Android 12 starten oder auf Android 12 aktualisieren, mit GKI, dedizierter und A/B-Wiederherstellung

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

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

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

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

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

Upgrade auf Android 12, Wiederherstellung als Boot (Wiederherstellung als Ramdisk)

Gerät starten/aktualisieren, kein GKI, Wiederherstellung beim Booten

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

Upgrade auf Android 12, dedizierte Wiederherstellung (dedizierte Ramdisk)

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

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

Inhalte der Boot-Images

Die Android-Boot-Images enthalten Folgendes.

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

    • Header-Version V4
    • Generisches Ramdisk-Image

  • Generisches boot -Image

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

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

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

  • recovery

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

Generische Ramdisk-Image-Inhalte

Die generische Ramdisk enthält die folgenden Komponenten.

  • init
  • system/etc/ramdisk/build.prop hinzugefügt
  • ro. PRODUCT .bootimg.* build Requisiten
  • Leere Verzeichnisse für Mountpunkte: 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 die Zeichenfolge true sein oder leer sein (was die Standardeinstellung ist).

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

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

  • BOARD_USES_GENERIC_KERNEL_IMAGE . Diese Variable gibt an, dass das Board GKI verwendet. Diese Variable hat keinen Einfluss auf Sysprops oder PRODUCT_PACKAGES .

    Dies ist der GKI-Switch auf Platinenebene. Alle unten aufgeführten Variablen werden durch diese Variable eingeschränkt.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . Diese Variable steuert, ob Ramdisk-Recovery-Ressourcen nach vendor_boot erstellt werden.

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

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

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

    • Wenn auf true gesetzt, wenn BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

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

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

    • Wenn leer, wenn BOARD_RECOVERY_AS_ROOT :

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

      • Ist diese Option nicht festgelegt, werden GSI AVB-Schlüssel in $ANDROID_PRODUCT_OUT/ramdisk/avb erstellt.

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

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

    • aosp_arm64 muss diese Variable auf true setzen.

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

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

Erlaubte Kombinationen

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

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

Aktivieren Sie verkettetes Vbmeta für den Start

Chained 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 finden Sie in dieser Änderung .

System-als-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 unterstützt, die dynamische Partitionen verwenden.

Produktkonfigurationen

Geräte, die die generische Ramdisk verwenden, müssen eine Liste der Dateien installieren, 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 außerdem, dass andere Makefiles versehentlich andere Dateien auf der Ramdisk installieren (verschieben Sie solche Dateien stattdessen nach vendor_ramdisk ).

Geräte einrichten

Die Einrichtungsanweisungen unterscheiden sich zwischen Geräten, die mit Android 13 starten, auf Android 12 aktualisieren und mit Android 12 starten. Die Einrichtung von Android 13 erfolgt ähnlich wie bei Android 12

  • Geräte, die auf Android 12 aktualisieren:

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

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

      • Setzen Sie BOARD_USES_RECOVERY_AS_BOOT auf leer. Die Architektur ist wie in Abbildung 4 dargestellt.

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

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

      • Verwenden Sie eine dedizierte recovery . Die Architektur ist wie in Abbildung 2a oder Abbildung 2b dargestellt und die Geräte-Setup-Option ist Option 2a oder Option 2b .

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

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

    • Verwenden Sie eine dedizierte recovery . Die Architektur ist wie in Abbildung 2a oder Abbildung 2b dargestellt und die Geräte-Setup-Option ist Option 2a oder Option 2b .

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

Option 1: Keine dedizierte Wiederherstellungspartition

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

Festlegen von BOARD-Werten

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 /init zu- /system/bin/init Symlink und init_second_stage.recovery unter /system/bin/init enthalten. Da jedoch die generische Ramdisk nach der vendor_boot Ramdisk verkettet ist, wird der symbolische Link /init überschrieben. Wenn das Gerät in die Wiederherstellung startet, wird die Binärdatei /system/bin/init benötigt, um Init der zweiten Stufe zu unterstützen. Der Inhalt von vendor_boot + generischen Ramdisks ist wie folgt:

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

Fstab-Dateien verschieben

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

Module installieren

Bei Bedarf können Sie gerätespezifische Module auf 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 auf /first_stage_ramdisk installiert wird. Dieses Modul sollte verfügbar sein, nachdem init Root zu /first_stage_ramdisk wechselt, aber bevor init Root zu /system wechselt. Beispiele finden Sie unter Metadatenprüfsummen und virtuelle A/B-Komprimierung .

  • Verwenden Sie die recovery des Moduls, wenn das Modul nach / installiert wird. Dieses Modul sollte verfügbar sein, bevor init root in /first_stage_ramdisk wechselt. Einzelheiten zur Installation von Modulen in / finden Sie unter Konsole der ersten Stufe .

Konsole der ersten Stufe

Da die First-Stage-Konsole startet, bevor init root in /first_stage_ramdisk wechselt, müssen Sie die recovery 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 erbt, müssen Sie die recovery nicht explizit installieren.

Um die Wiederherstellungsmodule explizit zu installieren, verwenden Sie Folgendes.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

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

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

PRODUCT_PACKAGES += adbd.recovery

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

Metadaten-Prüfsummen

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

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

Ein Beispiel finden Sie in dieser Änderungsliste .

Virtuelle A/B-Komprimierung

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

Änderungen am Bootvorgang

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

  • Ramdisk build.prop wird nach /second_stage_resources verschoben, sodass init der zweiten Stufe 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 vendor_boot Ramdisk nicht.

e2fsck verfügbar machen

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

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

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

Die Produkt-Makefiles installieren $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck . Zur Laufzeit wechselt der init der ersten Stufe als Root in /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 ; Das heißt, das Gerät verfügt über die Partitionen recovery_a und recovery_b partition . Zu diesen Geräten gehören A/B- und virtuelle A/B-Geräte, deren Wiederherstellungspartition aktualisierbar ist, mit der folgenden Konfiguration:

AB_OTA_PARTITIONS += recovery

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

  • Gerätespezifische fstab Dateien

  • lib/modules (enthält Kernelmodule des Herstellers)

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

Festlegen von BOARD-Werten

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

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

Die recovery Ramdisk kann einen symbolischen Link /init -> /system/bin/init und init_second_stage.recovery unter /system/bin/init enthalten. Da jedoch die Boot-Ramdisk nach der recovery Ramdisk verkettet ist, wird der symbolische Link /init überschrieben. Wenn das Gerät im Wiederherstellungsmodus startet, wird die Binärdatei /system/bin/init benötigt, um Init der zweiten Stufe zu unterstützen.

Wenn das Gerät in recovery startet, lautet der Inhalt von recovery + vendor_boot + generischen Ramdisks wie folgt:

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

Wenn das Gerät in Android startet, lautet der Inhalt von vendor_boot + generischen Ramdisks wie folgt:

  • /init (von der generischen Ramdisk, erstellt aus init_first_stage )

Fstab-Dateien verschieben

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

Module installieren

Bei Bedarf können Sie gerätespezifische Module auf vendor_ramdisk installieren (überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren möchten). Init wechselt den Root nicht. Die Modulvariante vendor_ramdisk wird im Stammverzeichnis von vendor_ramdisk installiert. Beispiele für die Installation von Modulen auf vendor_ramdisk finden Sie unter Konsole der ersten Stufe , Metadatenprüfsummen und virtuelle A/B-Komprimierung .

Konsole der ersten Stufe

Um die vendor_ramdisk Variante der Module zu installieren, verwenden Sie Folgendes:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Metadaten-Prüfsummen

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

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

Ein Beispiel finden Sie in dieser Änderungsliste .

Virtuelle A/B-Komprimierung

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

Änderungen am Bootvorgang

Beim Booten unter Android ändert sich der Bootvorgang nicht. Die generische Ramdisk vendor_boot ähnelt dem vorhandenen Boot-Prozess, mit der Ausnahme, dass fstab von vendor_boot geladen wird. Da system/bin/recovery nicht existiert, behandelt first_stage_init es wie einen normalen Start.

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

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

    1. Schiebt Wiederherstellung + vendor_boot + generische Ramdisk nach / . (Wenn der OEM Kernelmodule in der Wiederherstellungs-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 mountet die Ramdisk in / und führt dann /init von der generischen Ramdisk aus.

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

    1. Setzt IsRecoveryMode() == true und ForceNormalBoot() == false .
    2. Lädt Kernelmodule des Herstellers aus /lib/modules .
    3. Ruft DoFirstStageMount() auf, überspringt aber das Mounten, weil IsRecoveryMode() == true . (Das Gerät gibt keine Ramdisk frei (da / immer noch dasselbe ist), ruft aber SetInitAvbVersionInRecovery() auf.)
    4. Startet die Init-Initialisierung der zweiten Stufe von /system/bin/init aus recovery -Ramdisk.

e2fsck verfügbar machen

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

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

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

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

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

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

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

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

  • Gerätespezifische fstab Dateien
  • lib/modules (enthält Kernelmodule des Herstellers)

Das recovery muss eigenständig sein. Es muss alle erforderlichen Ressourcen zum Starten des Wiederherstellungsmodus enthalten, einschließlich:

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

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

Festlegen von BOARD-Werten

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

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

Die recovery Ramdisk muss einen symbolischen Link /init -> /system/bin/init und init_second_stage.recovery unter /system/bin/init enthalten. Wenn das Gerät im Wiederherstellungsmodus startet, ist die Binärdatei /system/bin/init erforderlich, um Init sowohl der ersten als auch der zweiten Stufe zu unterstützen.

Wenn das Gerät im recovery startet, ist der Inhalt der recovery Ramdisk wie folgt:

  • /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, lautet der Inhalt von vendor_boot + generischen Ramdisks wie folgt:

  • /init (von Ramdisk, erstellt aus init_first_stage )

Fstab-Dateien verschieben

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

Module installieren

Bei Bedarf können Sie gerätespezifische Module auf vendor_ramdisk und recovery Ramdisk installieren (überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren möchten). init wechselt den Root nicht. Die Modulvariante vendor_ramdisk wird im Stammverzeichnis von vendor_ramdisk installiert. Die recovery der Module wird im Stammverzeichnis der recovery Ramdisk installiert. Beispiele für die Installation von Modulen auf vendor_ramdisk und recovery Ramdisk finden Sie unter Konsole der ersten Stufe und Prüfsummen für Metadaten .

Konsole der ersten Stufe

Um die vendor_ramdisk Variante der Module zu installieren, verwenden Sie Folgendes:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

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

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

Metadaten-Prüfsummen

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

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

Um Metadaten-Prüfsummen während der ersten Bereitstellungsphase bei der Wiederherstellung zu unterstützen, aktivieren Sie die Wiederherstellungsvariante dieser Module und installieren Sie sie ebenfalls.

Änderungen am Bootvorgang

Beim Booten unter Android ändert sich der Bootvorgang nicht. Die generische Ramdisk vendor_boot ähnelt dem vorhandenen Boot-Prozess, mit der Ausnahme, dass fstab von vendor_boot geladen wird. Da system/bin/recovery nicht existiert, behandelt first_stage_init es wie einen normalen Start.

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

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

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

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

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

    1. Setzt IsRecoveryMode() == true und ForceNormalBoot() == false .
    2. Lädt Kernelmodule des Herstellers aus /lib/modules .
    3. Ruft DoFirstStageMount() auf, überspringt aber das Mounten, weil IsRecoveryMode() == true . (Das Gerät gibt keine Ramdisk frei (da / immer noch dasselbe ist), ruft aber SetInitAvbVersionInRecovery() auf.)
    4. Startet die Init-Initialisierung der zweiten Stufe von /system/bin/init aus recovery -Ramdisk.

Zeitstempel des Boot-Images

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

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

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

  • Zur Laufzeit kopiert die init der ersten Stufe Dateien von der Ramdisk nach tmpfs , bevor sie die Ramdisk freigibt, damit die init der zweiten Stufe diese Datei lesen kann, um die Zeitstempeleigenschaften boot Images festzulegen.