Generische Bootpartition

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

Für Geräte, die mit Android 13 auf den Markt gebracht wurden, wird die allgemeine ramdisk wird aus dem boot-Image entfernt und in einem separaten init_boot platziert Bild. Durch diese Änderung bleibt im Bild boot nur das Bild GKI-Kernel.

Für Upgradegeräte, auf denen weiterhin Android 12 verwendet wird oder älteren Kernel-Versionen bleibt die generische Ramdisk keine Anforderung für ein neues init_boot-Image.

Um eine generische Ramdisk zu erstellen, verschieben Sie anbieterspezifische Ressourcen aus der Ramdisk sodass die generische ramdisk nur die init der ersten Phase und ein Attribut enthält die Zeitstempelinformationen enthält.

Auf Geräten, die:

  • Verwenden Sie keine dedizierte Partition recovery, da alle Wiederherstellungsbits aus der Generic ramdisk zu vendor_boot ramdisk.

  • Dedizierte recovery-Partition verwenden, ohne Änderung der recovery-RAMdisk ist erforderlich, da die Ramdisk von recovery eigenständig ist.

Architektur

Die folgenden Diagramme veranschaulichen die Architektur für Geräte mit Android. 12 und höher. Geräte, die mit Android 13 auf den Markt gebracht werden, haben eine neue init_boot-Image mit der generischen Ramdisk. Geräte, die von Android 12 auf Android aktualisiert werden 13 nutzen dieselbe Architektur wie bei Android 12

Einführung mit Android 13, keine dedizierte Wiederherstellung

Einführung/Upgrade für Gerät, Google-KI, keine dedizierte Wiederherstellung

Abbildung 1: Geräte, die auf Android 13 auf den Markt gebracht oder darauf aktualisiert werden, mit GKI, ohne gesonderte Wiederherstellung.

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

Einführung/Upgrade für Gerät, Google-KI, zweckbestimmte und A/B-Wiederherstellung

Abbildung 2: Geräte, die auf Android 13 auf den Markt gebracht oder darauf aktualisiert werden, mit Google-KI, zweckbestimmten Funktionen und A/B-Wiederherstellung.

In dieser Abbildung sehen Sie, wenn das Gerät die Partitionen recovery_a und recovery_b hat.

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

Einführung/Upgrade für Gerät, Google-KI, dedizierte und Nicht-A/B-Wiederherstellung

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

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

Einführung oder Upgrade auf Android 12 (keine dedizierte Wiederherstellung)

Einführung/Upgrade für Gerät, Google-KI, keine dedizierte Wiederherstellung

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

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

Einführung/Upgrade für Gerät, Google-KI, zweckbestimmte und A/B-Wiederherstellung

Abbildung 5: Geräte, die auf Android 12 auf den Markt gebracht oder darauf aktualisiert werden, mit Google Workspace for Education, zweckbestimmter Funktionen und A/B-Wiederherstellung.

In dieser Abbildung sehen Sie, wenn das Gerät die Partitionen recovery_a und recovery_b hat.

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

Einführung/Upgrade für Gerät, Google-KI, dedizierte 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.

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

Upgrade auf Android 12, Recovery-as-Boot (recovery-as-ramdisk)

Starten/Upgrade des Geräts, 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, dedizierte Wiederherstellung (dedizierte RAMdisk)

Starten/Upgrade des Geräts, keine Google-KI, dedizierte Wiederherstellung

Abbildung 8: Geräte, die auf Android 12 aktualisiert werden, keine Google-KI, dedizierte Wiederherstellung.

Inhalt des 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

    • Header version V4
    • Allgemeines Ramdisk-Image

  • Allgemeines Bild für boot

    • Header-Version V3 oder Version 4 <ph type="x-smartling-placeholder">
        </ph>
      • Ein boot_signature für die GKI-Boot.img-Zertifizierung (nur Version 4). Die Die zertifizierte GKI boot.img ist nicht für den bestätigten Bootmodus signiert. OEMs müssen immer noch die vordefinierte boot.img mit einem gerätespezifischen AVB .
      • Allgemein cmdline (GENERIC_KERNEL_CMDLINE)
      • GKI-Kernel
    • Allgemeines Ramdisk-Image <ph type="x-smartling-placeholder">
        </ph>
      • Nur in boot Bildern von Android 12 enthalten und früher

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

    • vendor_boot-Header <ph type="x-smartling-placeholder">
        </ph>
      • Gerätespezifisches cmdline (BOARD_KERNEL_CMDLINE)
    • vendor_boot RAMdisk-Image <ph type="x-smartling-placeholder">
        </ph>
      • lib/modules
      • Wiederherstellungsressourcen (wenn keine dedizierten Wiederherstellung vorhanden ist)
    • Bild mit dtb

  • Bild mit recovery

    • Header-Version V2 <ph type="x-smartling-placeholder">
        </ph>
      • Gerätespezifisches cmdline für Wiederherstellung, falls erforderlich
      • Bei einer Nicht-A/B-Wiederherstellungspartition muss der Inhalt des Headers eigenständig; Siehe Wiederherstellungs-Images Beispiel:
      • cmdline ist nicht mit boot und vendor_boot cmdline verkettet.
      • Der Header gibt bei Bedarf den DTBO für die Wiederherstellung an.
      • Bei A/B-Wiederherstellungspartitionen können Inhalte verkettet oder abgeleitet werden. von boot und vendor_boot. Beispiel:
      • cmdline ist mit boot und vendor_boot cmdline verkettet.
      • DTBO kann aus dem vendor_boot-Header abgeleitet werden.
    • recovery RAMdisk-Image <ph type="x-smartling-placeholder">
        </ph>
      • Ressourcen für die Wiederherstellung
      • Bei einer Nicht-A/B-Wiederherstellungspartition muss der Inhalt der Ramdisk eigenständig; Siehe Wiederherstellungs-Images Beispiel:
      • lib/modules muss alle für das Booten erforderlichen Kernelmodule enthalten Wiederherstellungsmodus
      • Die Wiederherstellungs-RAMdisk muss init enthalten.
      • Bei A/B-Wiederherstellungspartitionen wird die Wiederherstellungs-RAMdisk dem generische und vendor_boot-ramdisk. Daher muss es nicht als eigenständiges Gerät. Beispiel:
      • lib/modules enthält möglicherweise nur zusätzliche Kernelmodule, die für Bootwiederherstellungsmodus (außer Kernelmodule) in vendor_boot-RAMdisk.
      • Der Symlink unter /init ist möglicherweise vorhanden, wird aber vom die /init-Binärdatei der ersten Phase im Boot-Image.

Allgemeiner Inhalt von Ramdisk-Images

Die generische ramdisk enthält die folgenden Komponenten.

  • init
  • system/etc/ramdisk/build.prop
  • ro.PRODUCT.bootimg.* build Elemente
  • 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/

Boot-Image-Einbindung

Build-Flags steuern, wie init_boot, boot, recovery und vendor_boot erstellt werden. Der Wert einer booleschen Variablen für die Karte muss der String sein true oder leer sein (Standardeinstellung).

  • TARGET_NO_KERNEL Diese Variable gibt an, ob der Build einen vordefinierten Bootmodus verwendet Bild. Wenn diese Variable auf true gesetzt ist, legen Sie BOARD_PREBUILT_BOOTIMAGE fest. zum Speicherort des vordefinierten 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. 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. Diese Variable wirkt sich nicht auf Sysprops oder PRODUCT_PACKAGES

    Das ist der GKI-Switch auf Board-Ebene. sind alle folgenden Variablen die durch diese Variable eingeschränkt ist.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT Diese Variable steuert, Ramdisk-Wiederherstellungsressourcen sind auf vendor_boot aufgebaut.

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

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

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

    • Wenn true festgelegt, und BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • GSI-AVB-Tasten sind so aufgebaut, dass sie $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb

      • Ist die Richtlinie nicht konfiguriert, können die GSI-AVB-Tasten $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb

    • Wenn leer, falls BOARD_RECOVERY_AS_ROOT:

      • GSI-AVB-Tasten sind so aufgebaut, dass sie $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb

      • Ist die Richtlinie nicht konfiguriert, können die GSI-AVB-Tasten $ANDROID_PRODUCT_OUT/ramdisk/avb

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE Diese Variable steuert, Das recovery-Image enthält einen Kernel oder nicht. Geräte, die mit Android auf den Markt gebracht werden 12 und bei Verwendung der A/B-Partition recovery muss dies festgelegt werden in true. Geräte, die mit Android 12 auf den Markt gebracht werden Bei Nicht-A/B-Verbindungen muss diese Variable auf false gesetzt werden, damit das Wiederherstellungsabbild erhalten bleibt. als eigenständiges Produkt.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES Diese Variable steuert, $OUT/boot*.img wird in die Datei IMAGES/ unter den Zieldateien kopiert.

    • aosp_arm64 muss diese Variable auf true setzen.

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

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE Diese Variable steuert, init_boot.img wird generiert und legt die Größe fest. Wenn festgelegt, wird die generische ramdisk wird dem init_boot.img statt boot.img hinzugefügt und erfordert den BOARD_AVB_INIT_BOOT* Variablen für chained vbmeta aus.

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) 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 &gt; 0 Leer &gt; 0 &gt; 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-Partition können Folgendes festlegen: PRODUCT_BUILD_RECOVERY_IMAGE in true oder leer. Für diese Geräte gilt Folgendes: 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. Definieren Folgendes:

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 diesem ändern.

System-as-root

„System-as-root“ wird für Geräte mit GKI nicht unterstützt. An Für solche Geräte muss BOARD_BUILD_SYSTEM_ROOT_IMAGE leer sein. System-as-root wird auch nicht für Geräte mit dynamischen Partitionen unterstützt.

Produktkonfigurationen

Geräte, die die generische Ramdisk verwenden, müssen eine Liste der Dateien installieren, auf Ramdisk installiert werden darf. Geben Sie dazu Folgendes in device.mk:

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

Die Datei generic_ramdisk.mk verhindert auch das versehentliche Erstellen anderer Makefiles andere Dateien auf der Ramdisk installieren (verschieben Sie diese Dateien in vendor_ramdisk .

Geräte einrichten

Die Einrichtungsanleitungen unterscheiden sich bei den Geräten, die mit Android gestartet werden. 13, Upgrade auf Android 12 und Markteinführung mit Android 12. 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. Wenn sie dies tun, Sie verwenden alte Konfigurationen und neue Build-Variablen müssen leer sein. Wenn solche Geräte:

      • Legen Sie BOARD_USES_RECOVERY_AS_BOOT auf true fest. Die Architektur ist wie folgt: wie in Abbildung 3 dargestellt.

      • Setzen Sie BOARD_USES_RECOVERY_AS_BOOT auf leer. Die Architektur sieht so aus. Abbildung 4.

    • BOARD_USES_RECOVERY_AS_BOOT kann auf leer gesetzt werden. Wenn sie dies tun, verwenden sie neue Konfigurationen erstellen. Wenn solche Geräte:

      • Verwenden Sie keine dedizierte recovery-Partition, die Architektur ist so dargestellt in Abbildung 1 und die Geräteeinrichtungsoption ist Option 1.

      • Verwenden Sie eine dedizierte recovery-Partition. Die Architektur wird so dargestellt: Abbildung 2a oder Abbildung 2b und Einrichtung des Geräts Option ist Option 2a oder Option 2b.

  • Für Geräte, die mit Android 12 auf den Markt gebracht werden, muss Folgendes festgelegt werden: BOARD_USES_RECOVERY_AS_BOOT zum Leeren und Verwenden neuer Konfigurationen. Wenn eine solche Geräte:

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

    • Verwenden Sie eine dedizierte recovery-Partition. Die Architektur wird so dargestellt: Abbildung 2a oder Abbildung 2b und Einrichtung des Geräts Option ist Option 2a oder Option 2b.

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

Option 1: Keine dedizierte Wiederherstellungspartition

Geräte ohne Partition recovery enthalten das generische boot-Image im Partition boot. Die Ramdisk vendor_boot enthält alle Wiederherstellungsressourcen. einschließlich lib/modules (mit Kernel-Modulen des Anbieters). Auf solchen Geräten die Produktkonfiguration übernimmt von generic_ramdisk.mk

BOARD-Werte festlegen

Legen Sie die folgenden Werte fest:

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

Die Ramdisk vendor_boot kann einen Symlink von /init bis /system/bin/init enthalten. und init_second_stage.recovery um /system/bin/init. Da die Generic ramdisk wird nach der ramdisk vendor_boot verkettet, der y-/init Symlink wird überschrieben. Beim Neustart des Geräts für die Wiederherstellung Das /system/bin/init-Binärprogramm ist erforderlich, um die Initialisierung der zweiten Phase zu unterstützen. Inhalt von vendor_boot + generischen Ramdisks sehen so aus:

  • /init (aus generischer Ramdisk, erstellt mit init_first_stage)
  • /system/bin/init (ab vendor_ramdisk, erstellt aus init_second_stage.recovery)

fstab-Dateien verschieben

Verschieben Sie alle installierten fstab-Dateien auf die generische Ramdisk vendor_ramdisk. Ein Beispiel finden Sie in diesem ändern.

Module installieren

Du kannst gerätespezifische Module in vendor_ramdisk installieren (überspringen) diesen Schritt ausführen, wenn Sie keine gerätespezifischen Module installieren müssen.

  • Verwenden Sie die vendor_ramdisk-Variante des Moduls, wenn das Modul installiert wird in /first_stage_ramdisk. Dieses Modul sollte ab dem init verfügbar sein wechselt den Root in /first_stage_ramdisk, aber bevor init den Root-Modus wechselt zu /system 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-Modus wechselt /first_stage_ramdisk. Weitere Informationen zum Installieren von Modulen in / finden Sie unter Erste Staging-Konsole.

Konsole der ersten Phase

Weil die Konsole der ersten Phase startet, bevor init den Root-Zugriff wechselt in /first_stage_ramdisk, du musst die Modulvariante recovery installieren. Standardmäßig werden beide Modulvarianten build/make/target/product/base_vendor.mk, d. h., wenn das Geräte-Makefile aus dieser Datei müssen Sie die Variante recovery nicht explizit installieren.

Verwenden Sie folgenden Code, um die Wiederherstellungsmodule explizit zu installieren.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Dadurch wird sichergestellt, dass linker, sh und toybox $ANDROID_PRODUCT_OUT/recovery/root/system/bin, die dann auf /system/bin gemäß vendor_ramdisk.

Um Module hinzuzufügen, die für die Konsole der ersten Phase erforderlich sind (z. B. adbd), verwenden Sie den folgen.

PRODUCT_PACKAGES += adbd.recovery

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

Metadaten-Prüfsummen

Zur Unterstützung von Metadaten Prüfsummen Während der Bereitstellung in der ersten Phase wird die Ramdisk auf Geräten, die GKI nicht unterstützen, installiert. der folgenden Module. 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 diesem Änderungsliste.

Virtuelle A/B-Komprimierung

Zur Unterstützung der virtuellen A/B-Komprimierung muss snapuserd installiert werden, vendor_ramdisk. Die Einstellungen für das Gerät sollten virtual_ab_ota/compression.mk, Dadurch wird die vendor_ramdisk-Variante von snapuserd installiert.

Änderungen am Bootvorgang

Beim Starten der Wiederherstellung oder beim Starten von Android ändert sich nichts. folgende Ausnahme:

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

Da Ressourcen von „Generic ramdisk“ zu „vendor_boot ramdisk“ verschoben werden, führt das Ergebnis durch das Verketten von generischem ramdisk mit vendor_boot ramdisk ändert sich nichts.

e2fsck verfügbar machen

Die Makefiles des Geräts können Folgendes übernehmen:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk, wenn das Gerät virtuelle A/B-Tests, aber ohne Komprimierung.

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

Die Makefiles des Produkts werden installiert $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck Bei aktiviert, wechselt die erste Phase (init) in den Root-Modus in /first_stage_ramdisk und führt /system/bin/e2fsck aus.

Option 2a: Dedizierte Partition und A/B-Wiederherstellungspartition

Verwenden Sie diese Option für Geräte mit A/B-Partitionen recovery. also: Auf dem Gerät befinden sich recovery_a und recovery_b partition. Zu diesen Geräten gehören A/B- und virtuelle A/B-Geräte, deren Wiederherstellungspartition aktualisiert werden kann, mit folgende Konfiguration:

AB_OTA_PARTITIONS += recovery

Das Ramdisk-Paket vendor_boot enthält die Anbieterbits der Ramdisk und des Anbieters. Kernelmodule, einschließlich der folgenden:

  • Gerätespezifische fstab-Dateien

  • lib/modules (enthält Kernel-Module des Anbieters)

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

BOARD-Werte festlegen

Legen Sie für Geräte mit der 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

Die Ramdisk recovery kann einen /init -> /system/bin/init-Symlink enthalten und init_second_stage.recovery um /system/bin/init. Da der Startvorgang jedoch Ramdisk ist nach recovery-ramdisk verkettet, der Symlink /init ist überschrieben. Wenn das Gerät im Wiederherstellungsmodus gestartet wird, wird der /system/bin/init Binärcode ist erforderlich, um die Initialisierung der zweiten Phase zu unterstützen.

Wenn das Gerät in recovery startet, wird der Inhalt von recovery + vendor_boot + allgemeine RAM-Disks:

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

Wenn das Gerät in Android gestartet wird, werden die Inhalte von vendor_boot + generischer ramdisks:

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

fstab-Dateien verschieben

Verschieben Sie alle installierten fstab-Dateien auf die generische Ramdisk vendor_ramdisk. Ein Beispiel finden Sie in diesem ändern.

Module installieren

Optional können Sie gerätespezifische Module in vendor_ramdisk installieren (überspringen diesen Schritt ausführen, wenn Sie keine gerätespezifischen Module installieren müssen. Init wechselt nicht das Stammverzeichnis. Die Modulvariante vendor_ramdisk wird im Wurzel von vendor_ramdisk. Beispiele zum Installieren von Modulen, vendor_ramdisk, siehe Konsole der ersten Phase, Metadaten Prüfsummen und Virtual A/B Komprimierung.

Konsole der ersten Phase

So installieren Sie die Variante vendor_ramdisk der Module:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dadurch wird sichergestellt, dass linker, sh und toybox $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, die dann auf /system/bin gemäß vendor_ramdisk.

Um Module hinzuzufügen, die für die Konsole der ersten Phase erforderlich sind (z. B. adbd), aktivieren Sie der vendor_ramdisk-Variante dieser Module, indem Sie relevante Patches in AOSP und verwenden Sie Folgendes:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Metadaten-Prüfsummen

Zur Unterstützung von Metadaten Prüfsummen Während der Bereitstellung in der ersten Phase wird die Ramdisk auf Geräten, die GKI nicht unterstützen, installiert. der folgenden Module. 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 diesem Änderungsliste.

Virtuelle A/B-Komprimierung

Zur Unterstützung der virtuellen A/B-Komprimierung muss snapuserd installiert werden, vendor_ramdisk. Die Einstellungen für das Gerät sollten virtual_ab_ota/compression.mk, Dadurch wird die vendor_ramdisk-Variante von snapuserd installiert.

Änderungen am Bootvorgang

Beim Starten von Android ändert sich der Bootvorgang nicht. Die vendor_boot + „Generic ramdisk“ ähnelt dem vorhandenen Bootprozess, außer dass fstab wird von vendor_boot geladen. Da system/bin/recovery nicht vorhanden ist, first_stage_init behandelt das wie einen normalen Bootvorgang.

Beim Starten im Wiederherstellungsmodus ändert sich der Bootvorgang. Die Wiederherstellung + vendor_boot + allgemeine ramdisk ähnelt dem bestehenden Wiederherstellungsprozess, Der Kernel wird aus dem boot-Image und nicht aus dem recovery-Image geladen. Der Bootvorgang für den Wiederherstellungsmodus läuft so ab:

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

    1. Verschiebt die Wiederherstellung + vendor_boot + generisches RAMdisk auf /. (Wenn der OEM Dupliziert Kernelmodule in Wiederherstellungs-RAMdisk, indem sie zu BOARD_RECOVERY_KERNEL_MODULES), vendor_boot ist 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 init-Phase 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, weil IsRecoveryMode() == true. (Das Gerät gibt ramdisk nicht kostenlos, weil / bleibt unverändert, ruft jedoch SetInitAvbVersionInRecovery() auf.)
    4. Startet die Initialisierung der zweiten Phase mit /system/bin/init von recovery ramdisk.

e2fsck verfügbar machen

Die Makefiles des Geräts können Folgendes übernehmen:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk, wenn das Gerät virtuelle A/B-Tests, aber ohne Komprimierung.

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

Die Makefiles des Produkts werden installiert $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck Bei Laufzeit führt die erste Phase init den Befehl /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. also: Das Gerät hat eine Partition mit dem Namen recovery ohne Slot-Suffix. Solche Geräte umfassen:

  • Nicht-A/B-Geräte;
  • A/B- und virtuelle A/B-Geräte, von denen die Wiederherstellungspartition nicht ist aktualisierbar. (Dies ist ungewöhnlich.)

Das Ramdisk-Paket vendor_boot enthält die Anbieterbits der Ramdisk und des Anbieters. Kernelmodule, einschließlich der folgenden:

  • Gerätespezifische fstab-Dateien
  • lib/modules (enthält Kernel-Module des Anbieters)

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

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

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

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

Die RAM-Disk recovery muss einen /init -> /system/bin/init-Symlink enthalten. init_second_stage.recovery um /system/bin/init. Beim Starten des Geräts in Wiederherstellungsmodus ist, ist die Binärdatei /system/bin/init erforderlich, um zuerst beide zu unterstützen Stage- und Second-Stage-Init-Methode.

Wenn das Gerät in recovery gestartet wird, ist der Inhalt der recovery-RAMdisks wie folgt:

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

Wenn das Gerät in Android gestartet wird, werden die Inhalte von vendor_boot + generischer ramdisks:

  • /init (von Ramdisk, erstellt mit init_first_stage)

fstab-Dateien verschieben

Verschieben Sie alle installierten fstab-Dateien auf die generische Ramdisk vendor_ramdisk und recovery Ramdisk. Ein Beispiel finden Sie in diesem ändern.

Module installieren

Du kannst gerätespezifische Module in vendor_ramdisk und recovery Ramdisk (überspringen) diesen Schritt ausführen, wenn Sie keine gerätespezifischen Module installieren müssen. init wechselt nicht das Stammverzeichnis. Die Modulvariante vendor_ramdisk wird im Wurzel von vendor_ramdisk. Die Modulvariante recovery wird im Stamm von recovery Ramdisk. Beispiele zum Installieren von Modulen, vendor_ramdisk und recovery Ramdisk, se Konsole der ersten Phase und Metadaten Prüfsummen.

Konsole der ersten Phase

So installieren Sie die Variante vendor_ramdisk der Module:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dadurch wird sichergestellt, dass linker, sh und toybox $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, die dann auf /system/bin gemäß vendor_ramdisk.

Um Module hinzuzufügen, die für die Konsole der ersten Phase erforderlich sind (z. B. adbd), aktivieren Sie der vendor_ramdisk-Variante dieser Module, indem Sie relevante Patches in AOSP und verwenden Sie Folgendes:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Wenn du die Modulvariante recovery installieren möchtest, ersetze 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 Bereitstellung in der ersten Phase wird die Ramdisk auf Geräten, die GKI nicht unterstützen, installiert. der folgenden Module. Verschieben Sie die Module nach: $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

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

Damit Metadaten-Prüfsummen während der Bereitstellung in der ersten Phase der Wiederherstellung unterstützt werden, aktivieren Sie der Wiederherstellungsvariante dieser Module und installieren Sie sie ebenfalls.

Änderungen am Bootvorgang

Beim Starten von Android ändert sich der Bootvorgang nicht. Die vendor_boot + „Generic ramdisk“ ähnelt dem vorhandenen Bootprozess, außer dass fstab wird von vendor_boot geladen. Da system/bin/recovery nicht vorhanden ist, first_stage_init behandelt das wie einen normalen Bootvorgang.

Beim Starten im Wiederherstellungsmodus ändert sich der Bootvorgang nicht. Genesung ramdisk wird auf die gleiche Weise wie der vorhandene Wiederherstellungsprozess geladen. Der Kernel wird aus dem recovery-Image geladen. Die für den Wiederherstellungsmodus:

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

    1. Verschiebt die Wiederherstellungs-RAMdisk auf /.
    2. Führt den Kernel von der Partition recovery aus aus.

  2. Der Kernel stellt Ramdisk für / bereit und führt dann /init aus, einen Symlink zu /system/bin/init von der recovery-RAMdisk.

  3. Die erste init-Phase 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, weil IsRecoveryMode() == true. (Das Gerät gibt ramdisk nicht kostenlos, weil / bleibt unverändert, ruft jedoch SetInitAvbVersionInRecovery() auf.)
    4. Startet die Initialisierung der zweiten Phase mit /system/bin/init von recovery ramdisk.

Zeitstempel des Start-Images

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

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

  • Bei der Erstellung wird eine system/etc/ramdisk/build.prop-Datei zum allgemeinen ramdisk. Diese Datei enthält Zeitstempelinformationen des Builds.

  • Während der Laufzeit, erste Phase init Kopien von ramdisk in tmpfs hochladen, bevor die RAM-Disk freigegeben wird, Stufe init kann lesen mit dieser Datei, um boot-Eigenschaften für den Bildzeitstempel festzulegen.