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 gestartet werden, 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 noch mit dem GKI-Kernel.
Für Upgrades von Geräten, die weiterhin Android 12 oder ältere Kernelversionen 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 so aus der Ramdisk, dass die generische Ramdisk nur die Initialisierung der ersten init
und eine Eigenschaftsdatei mit Zeitstempelinformationen enthält.
Auf Geräten, die:
Verwenden Sie keine dedizierte
recovery
, alle Wiederherstellungsbits werden von der generischen Ramdisk auf dievendor_boot
Ramdisk verschoben.Verwenden Sie eine dedizierte
recovery
, es ist keine Änderung an derrecovery
-Ramdisk erforderlich, da dierecovery
-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 aktualisieren, verwenden dieselbe Architektur wie bei Android 12.
Mit Android 13 starten, keine dedizierte Wiederherstellung
Abbildung 1. Geräte starten oder aktualisieren auf Android 13, mit GKI, keine dedizierte Wiederherstellung
Starten Sie mit Android 13, dediziert und A/B-Wiederherstellung (dedizierte Ramdisk)
Abbildung 2. Geräte, die auf Android 13 gestartet oder aktualisiert werden, mit GKI, dediziert 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, dedizierte und Nicht-A/B-Wiederherstellung (dedizierte Ramdisk)
Abbildung 3. Geräte, die auf Android 13 gestartet oder aktualisiert werden, 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 aktualisieren Sie auf Android 12, keine dedizierte Wiederherstellung
Abbildung 4. Geräte, die mit GKI gestartet oder auf Android 12 aktualisiert werden, ohne dedizierte Wiederherstellung
Starten oder aktualisieren Sie auf Android 12, dediziert und A/B-Wiederherstellung (dedizierte Ramdisk)
Abbildung 5. Geräte, die auf Android 12 gestartet oder aktualisiert werden, mit GKI, dediziert 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 aktualisieren Sie auf Android 12, dedizierte und Nicht-A/B-Wiederherstellung (dedizierte Ramdisk)
Abbildung 6. Geräte, die auf Android 12 gestartet oder aktualisiert werden, 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, Recovery-as-Boot (Recovery-as-Ramdisk)
Abbildung 7. Geräte, die auf Android 12 aktualisiert werden, kein GKI, Recovery-as-Boot
Upgrade auf Android 12, dedizierte Wiederherstellung (dedizierte Ramdisk)
Abbildung 8. Geräte, die auf Android 12 aktualisiert werden, kein GKI, dedizierte Wiederherstellung
Inhalt der Boot-Images
Die Android-Boot-Images enthalten Folgendes.
init_boot
-Image für Geräte hinzugefügt, die mit Android 13 gestartet werden- 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 v4). Das zertifizierte GKIboot.img
ist nicht für den verifizierten Start signiert. OEMs müssen das vorgefertigteboot.img
mit einem gerätespezifischen AVB -Schlüssel signieren. - Generische
cmdline
(GENERIC_KERNEL_CMDLINE
) - GKI-Kernel
- Eine
- Generisches Ramdisk-Image
- Nur in
boot
Images von Android 12 und früher enthalten
- Nur in
- Header-Version V3 oder V4
vendor_boot
-Image (für Details siehe Vendor-Boot-Partitionen )-
vendor_boot
Header-
cmdline
(BOARD_KERNEL_CMDLINE
)
-
-
vendor_boot
Ramdisk-Image-
lib/modules
- Wiederherstellungsressourcen (falls keine dedizierte Wiederherstellung)
-
-
dtb
-Bild
-
recovery
- Header-Version V2
-
cmdline
für die Wiederherstellung, falls erforderlich - Für Nicht-A/B-Wiederherstellungspartitionen muss der Inhalt des Headers eigenständig sein; siehe Wiederherstellungs-Images . Zum Beispiel:
-
cmdline
ist nicht mitboot
undvendor_boot
cmdline
. - Header gibt ggf. Wiederherstellungs-DTBO an.
- Für A/B-Wiederherstellungspartitionen können Inhalte verkettet oder von
boot
undvendor_boot
. Zum Beispiel: -
cmdline
wird mitboot
undvendor_boot
cmdline
. - DTBO kann aus dem
vendor_boot
Header abgeleitet werden.
-
-
recovery
-Ramdisk-Image- Wiederherstellungsressourcen
- Für Nicht-A/B-Wiederherstellungspartitionen muss der Inhalt der Ramdisk eigenständig sein; siehe Wiederherstellungs-Images . Zum Beispiel:
-
lib/modules
muss alle Kernelmodule enthalten, die zum Starten des Wiederherstellungsmodus erforderlich sind - Die Wiederherstellungs-Ramdisk muss
init
enthalten. - Für die A/B-Wiederherstellungspartition wird die Wiederherstellungs-Ramdisk der generischen und der
vendor_boot
Ramdisk vorangestellt, daher muss sie nicht eigenständig sein. Zum Beispiel: -
lib/modules
enthält möglicherweise nur zusätzliche Kernelmodule, die zum Booten des Wiederherstellungsmodus erforderlich sind, neben den Kernelmodulen in dervendor_boot
. - Der symbolische Link unter
/init
ist möglicherweise vorhanden, wird jedoch von der/init
-Binärdatei der ersten Stufe im Boot-Image überschattet.
- Header-Version V2
Generische Ramdisk-Image-Inhalte
Die generische Ramdisk enthält die folgenden Komponenten.
-
init
-
system/etc/ramdisk/build.prop
-
ro. PRODUCT .bootimg.* build
Requisiten - Leere Verzeichnisse für Einhängepunkte:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
-
first_stage_ramdisk/
- Doppelte leere Verzeichnisse für Einhängepunkte:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
- Doppelte leere Verzeichnisse für Einhängepunkte:
Boot-Image-Integration
Build-Flags steuern, wie init_boot
-, boot
-, recovery
- und vendor_boot
werden. Der Wert einer booleschen Board-Variablen muss der String true
oder leer sein (was die Voreinstellung ist).
TARGET_NO_KERNEL
. Diese Variable gibt an, ob der Build ein vorgefertigtes Boot-Image verwendet. Wenn diese Variable auftrue
gesetzt ist, setzenBOARD_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 dasrecovery
alsboot
verwendet. Bei Verwendung von GKI ist diese Variable leer, und Wiederherstellungsressourcen sollten nachvendor_boot
.BOARD_USES_GENERIC_KERNEL_IMAGE
. Diese Variable gibt an, dass das Board GKI verwendet. Diese Variable wirkt sich nicht auf Sysprops oderPRODUCT_PACKAGES
.Dies ist der GKI-Switch auf Board-Ebene; alle unten aufgeführten Variablen werden durch diese Variable eingeschränkt.
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
. Diese Variable steuert, ob Ramdisk-Ressourcen für die Wiederherstellung vonvendor_boot
werden.Wenn diese Einstellung auf
true
gesetzt ist, werden Wiederherstellungsressourcen nur auf dervendor-ramdisk/
und nicht aufrecovery/root/
.Wenn sie leer sind, werden Wiederherstellungsressourcen nur für
recovery/root/
erstellt und nicht fürvendor-ramdisk/
.
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT
. Diese Variable steuert, ob GSI-AVB-Schlüssel fürvendor_boot
werden.Wenn auf
true
gesetzt, wennBOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
:gesetzt ist, werden GSI-AVB-Schlüssel in
$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb
.Wenn nicht festgelegt, werden GSI-AVB-Schlüssel in
$ANDROID_PRODUCT_OUT/vendor-ramdisk/avb
.
Wenn leer, wenn
BOARD_RECOVERY_AS_ROOT
:gesetzt ist, werden GSI-AVB-Schlüssel in
$ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb
.Wenn nicht festgelegt, werden GSI-AVB-Schlüssel in
$ANDROID_PRODUCT_OUT/ramdisk/avb
.
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE
. Diese Variable steuert, ob dasrecovery
einen Kernel enthält oder nicht. Geräte, die mit Android 12 starten und die A/B-recovery
verwenden, müssen diese Variable auftrue
setzen. Geräte, die mit Android 12 gestartet werden und Nicht-A/B verwenden, müssen diese Variable auffalse
“ setzen, damit das Wiederherstellungsabbild in sich geschlossen bleibt.BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES
. Diese Variable steuert, ob$OUT/boot*.img
nachIMAGES/
unter den Zieldateien kopiert wird.aosp_arm64
muss diese Variable auftrue
setzen.Andere Geräte müssen diese Variable leer lassen.
BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE
. Diese Variable steuert, obinit_boot.img
generiert wird und legt die Größe fest. Wenn festgelegt, wird die generische Ramdisk zuinit_boot.img
anstelle vonboot.img
und erfordert, dass dieBOARD_AVB_INIT_BOOT*
für verkettete vbmeta festgelegt werden
Erlaubte Kombinationen
Komponente oder Variable | Aktualisieren des Geräts ohne recovery | Aktualisieren des Geräts mit der recovery | 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 | Jawohl | Jawohl | Jawohl | Jawohl | Jawohl | Jawohl |
Enthält init_boot (Android 13) | nein | nein | nein | Jawohl | Jawohl | Jawohl |
Enthält vendor_boot | Optional | Optional | Jawohl | Jawohl | Jawohl | nein |
Enthält recovery | nein | Jawohl | nein | Jawohl | Jawohl | 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 BOARD_RECOVERYIMAGE_PARTITION_SIZE
für diese Geräte festgelegt ist, wird ein recovery
erstellt.
Verkettetes vbmeta zum Booten aktivieren
Chained vbmeta muss für die boot
und init_boot
Images aktiviert werden. 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-als-Root wird für Geräte, die GKI verwenden, nicht unterstützt. Auf solchen Geräten muss BOARD_BUILD_SYSTEM_ROOT_IMAGE
leer sein. System-als-Root wird auch nicht für Geräte unterstützt, die dynamische Partitionen verwenden.
Produktkonfigurationen
Geräte, die die generische Ramdisk verwenden, müssen eine Liste von Dateien installieren, die auf der Ramdisk installiert werden dürfen. Geben Sie dazu in device.mk
Folgendes an:
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
Die Datei generic_ramdisk.mk
verhindert auch, dass andere Makefiles versehentlich andere Dateien auf der Ramdisk installieren (verschieben Sie solche Dateien stattdessen nach vendor_ramdisk
).
Geräte einrichten
Die Einrichtungsanweisungen unterscheiden sich zwischen Geräten, die mit Android 13 gestartet, auf Android 12 aktualisiert und mit Android 12 gestartet werden. Android 13 wird ähnlich eingerichtet wie mit Android 12
Geräte, die auf Android 12 aktualisiert werden:
Kann den Wert von
BOARD_USES_RECOVERY_AS_BOOT
. Wenn sie dies tun, verwenden sie Legacy-Konfigurationen und neue Build-Variablen müssen leer sein. Wenn solche Geräte:Setzen
BOARD_USES_RECOVERY_AS_BOOT
auf „true
“, die Architektur ist wie in Abbildung 3 dargestellt.Setzen
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 Einrichtungsoption für das Gerät ist Option 1 .Verwenden Sie eine dedizierte
recovery
, die Architektur ist wie in Abbildung 2a oder Abbildung 2b dargestellt und die Einrichtungsoption für das Gerät 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 Einrichtungsoption für das Gerät ist Option 1 .Verwenden Sie eine dedizierte
recovery
, die Architektur ist wie in Abbildung 2a oder Abbildung 2b dargestellt und die Einrichtungsoption für das Gerät 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 Vendor-Kernel-Modulen). Auf solchen Geräten erbt die Produktkonfiguration von generic_ramdisk.mk
.
Einstellen von BOARD-Werten
Stellen Sie die folgenden Werte ein:
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
Init-Binärdateien und Symlinks
Die vendor_boot
Ramdisk kann einen /init
to /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 wird, wird der /init
-Symlink überschrieben. Wenn das Gerät in die Wiederherstellung bootet, wird die /system/bin/init
-Binärdatei benötigt, um Second Stage Init zu unterstützen. Der Inhalt von vendor_boot
+ generischen Ramdisks ist wie folgt:
-
/init
(von generischer Ramdisk, gebaut ausinit_first_stage
) -
/system/bin/init
(vonvendor_ramdisk
, erstellt ausinit_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
Falls gewünscht, können Sie gerätespezifische Module auf der vendor_ramdisk
“ installieren (überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren müssen).
Verwenden Sie die Variante
vendor_ramdisk
des Moduls, wenn das Modul auf/first_stage_ramdisk
installiert wird. Dieses Modul sollte verfügbar sein, nachdeminit
root in/first_stage_ramdisk
, aber bevorinit
root in/system
umschaltet. Beispiele finden Sie unter Metadaten-Prüfsummen und virtuelle A/B-Komprimierung .Verwenden Sie die
recovery
des Moduls, wenn das Modul in/
installiert wird. Dieses Modul sollte verfügbar sein, bevorinit
root in/first_stage_ramdisk
. Einzelheiten zum Installieren von Modulen nach/
finden Sie unter First-Stage-Konsole .
Konsole der ersten Stufe
Da die Konsole der ersten Stufe gestartet wird, bevor init
root in /first_stage_ramdisk
, müssen Sie die recovery
von Modulen installieren. Standardmäßig werden beide Modulvarianten in build/make/target/product/base_vendor.mk
, wenn also das Geräte-Makefile von dieser Datei erbt, müssen Sie die recovery
nicht explizit installieren.
Verwenden Sie Folgendes, um die Wiederherstellungsmodule explizit zu installieren.
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 dem vendor_ramdisk
installiert wird.
Metadaten-Prüfsummen
Um Metadaten-Prüfsummen während der Bereitstellung in der ersten Phase 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 Startvorgang
Der Prozess des Bootens in die Wiederherstellung oder in Android ändert sich nicht, mit der folgenden Ausnahme:
- Ramdisk
build.prop
verschiebt sich in/second_stage_resources
, damit Second Stageinit
den Build-Zeitstempel des Bootens lesen kann.
Da Ressourcen von der generischen Ramdisk zur vendor_boot
werden, ändert sich das Ergebnis der Verkettung der generischen ramdisk mit der vendor_boot
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 die init
der ersten Stufe root in /first_stage_ramdisk
und führt dann /system/bin/e2fsck
.
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 hat eine recovery_a
und eine 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
-Dateienlib/modules
(enthält Hersteller-Kernel-Module)
Die recovery
-Ramdisk enthält alle Wiederherstellungsressourcen. Auf solchen Geräten erbt die Produktkonfiguration von generic_ramdisk.mk
.
Einstellen 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
Init-Binärdateien und Symlinks
Die recovery
-Ramdisk kann einen symbolischen Link /init -> /system/bin/init
und init_second_stage.recovery
unter /system/bin/init
. Da die Boot-Ramdisk jedoch nach der recovery
-Ramdisk verkettet wird, wird der /init
-Symlink überschrieben. Wenn das Gerät in den Wiederherstellungsmodus bootet, wird die /system/bin/init
-Binärdatei benötigt, um Second Stage Init zu unterstützen.
Wenn das Gerät in die recovery
bootet, sieht der Inhalt von recovery
+ vendor_boot
+ generische Ramdisks wie folgt aus:
-
/init
(von Ramdisk, erstellt ausinit_first_stage
) -
/system/bin/init
(vonrecovery
Ramdisk, erstellt ausinit_second_stage.recovery
und ausgeführt von/init
)
Wenn das Gerät in Android bootet, sieht der Inhalt von vendor_boot
+ generische Ramdisks wie folgt aus:
-
/init
(von generischer Ramdisk, gebaut ausinit_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
Falls gewünscht, können Sie gerätespezifische Module auf der vendor_ramdisk
“ installieren (überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren müssen). Init
wechselt nicht root. Die vendor_ramdisk
Variante von modulen wird im Stammverzeichnis von vendor_ramdisk
installiert. Beispiele für die Installation von Modulen auf dem vendor_ramdisk
finden Sie unter First-Stage-Konsole , Metadaten-Prüfsummen und Virtuelle A/B-Komprimierung .
Konsole der ersten Stufe
Verwenden Sie Folgendes, um die Variante vendor_ramdisk
der Module zu installieren:
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 dem 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 Variante vendor_ramdisk
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 in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
installiert werden. Wenn die vendor_boot
Ramdisk im Recovery-Modus geladen wird, ist das Modul auch im recovery
-Modus verfügbar. Wenn die vendor_boot
Ramdisk nicht im Wiederherstellungsmodus geladen ist, kann das Gerät optional auch adbd.recovery
installieren.
Metadaten-Prüfsummen
Um Metadaten-Prüfsummen während der Bereitstellung in der ersten Phase 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 Startvorgang
Beim Booten in Android ändert sich der Bootvorgang nicht. Die generische Ramdisk vendor_boot
+" ähnelt dem vorhandenen Boot-Prozess, außer dass fstab
von vendor_boot
. Da system/bin/recovery
nicht existiert, behandelt first_stage_init
es wie einen normalen Bootvorgang.
Beim Booten in den Wiederherstellungsmodus ändert sich der Bootvorgang. Die Wiederherstellung + vendor_boot
+ generische Ramdisk ähnelt dem bestehenden Wiederherstellungsprozess, aber der Kernel wird vom boot
Image statt vom recovery
-Image geladen. Der Startvorgang für den Wiederherstellungsmodus ist wie folgt.
Der Bootloader startet und führt dann Folgendes aus:
- Schiebt Wiederherstellung +
vendor_boot
+ generische Ramdisk nach/
. (Wenn der OEM Kernel-Module in der Wiederherstellungs-Ramdisk dupliziert, indem er sie zuBOARD_RECOVERY_KERNEL_MODULES
), istvendor_boot
optional.) - Führt den Kernel von der
boot
Partition aus.
- Schiebt Wiederherstellung +
Der Kernel mountet die Ramdisk auf
/
und führt dann/init
von der generischen Ramdisk aus.Init der ersten Stufe startet und führt dann Folgendes aus:
- Setzt
IsRecoveryMode() == true
undForceNormalBoot() == false
. - Lädt Hersteller-Kernel-Module aus
/lib/modules
. -
DoFirstStageMount()
auf, überspringt aber das Mounten, weilIsRecoveryMode() == true
. (Das Gerät gibt die Ramdisk nicht frei (weil/
immer noch dasselbe ist), ruft aberSetInitAvbVersionInRecovery()
.) - Startet Second Stage Init von
/system/bin/init
vonrecovery
Ramdisk.
- Setzt
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
.
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 hat eine Partition mit dem Namen recovery
ohne Slot-Suffix. Zu diesen Geräten gehören:
- Nicht-A/B-Geräte;
- A/B- und virtuelle A/B-Geräte, deren Wiederherstellungspartition nicht 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 Hersteller-Kernel-Module)
Das recovery
muss eigenständig sein. Es muss alle erforderlichen Ressourcen enthalten, um den Wiederherstellungsmodus zu starten, 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
-Binärdatei usw. - usw.
Auf solchen Geräten erbt die Produktkonfiguration von generic_ramdisk.mk
.
Einstellen 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
Init-Binärdateien und Symlinks
Die recovery
-Ramdisk muss einen /init -> /system/bin/init
Symlink und init_second_stage.recovery
unter /system/bin/init
. Wenn das Gerät in den Wiederherstellungsmodus bootet, wird die /system/bin/init
-Binärdatei benötigt, um sowohl die Erst- als auch die Zweitstufeninitialisierung zu unterstützen.
Wenn das Gerät in die recovery
bootet, sieht der Inhalt der recovery
-Ramdisks wie folgt aus:
-
/init -> /system/bin/init
(von derrecovery
-Ramdisk) -
/system/bin/init
(vonrecovery
Ramdisk, erstellt ausinit_second_stage.recovery
und ausgeführt von/init
)
Wenn das Gerät in Android bootet, sieht der Inhalt von vendor_boot
+ generische Ramdisks wie folgt aus:
-
/init
(von Ramdisk, erstellt ausinit_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
Falls gewünscht, können Sie gerätespezifische Module auf der vendor_ramdisk
und der recovery
-Ramdisk installieren (überspringen Sie diesen Schritt, wenn Sie keine gerätespezifischen Module installieren müssen). init
wechselt nicht root. Die vendor_ramdisk
Variante von modulen wird im Stammverzeichnis von vendor_ramdisk
installiert. Die recovery
von Modulen wird im Stammverzeichnis der recovery
-Ramdisk installiert. Beispiele für die Installation von Modulen auf der vendor_ramdisk
und der recovery
-Ramdisk finden Sie unter First-Stage-Konsole und Metadaten-Prüfsummen .
Konsole der ersten Stufe
Verwenden Sie Folgendes, um die Variante vendor_ramdisk
der Module zu installieren:
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 dem 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 Variante vendor_ramdisk
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 in $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
installiert werden.
Um die recovery
-Variante der Module zu installieren, ersetzen vendor_ramdisk
durch recovery
:
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
adbd.recovery \
Metadaten-Prüfsummen
Um Metadaten-Prüfsummen während der Bereitstellung in der ersten Phase 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 \
Aktivieren Sie die Wiederherstellungsvariante dieser Module und installieren Sie sie ebenfalls, um Metadaten-Prüfsummen während der ersten Phase des Mountens in der Wiederherstellung zu unterstützen.
Änderungen am Startvorgang
Beim Booten in Android ändert sich der Bootvorgang nicht. Die generische Ramdisk vendor_boot
+" ähnelt dem vorhandenen Boot-Prozess, außer dass fstab
von vendor_boot
. Da system/bin/recovery
nicht existiert, behandelt first_stage_init
es wie einen normalen Bootvorgang.
Beim Booten in den Wiederherstellungsmodus ändert sich der Bootvorgang nicht. Die Wiederherstellungs-Ramdisk wird auf die gleiche Weise wie der vorhandene Wiederherstellungsprozess geladen. Der Kernel wird aus dem recovery
geladen. Der Startvorgang für den Wiederherstellungsmodus ist wie folgt.
Der Bootloader startet und führt dann Folgendes aus:
- Verschiebt die Wiederherstellungs-Ramdisk nach
/
. - Führt den Kernel von der
recovery
aus.
- Verschiebt die Wiederherstellungs-Ramdisk nach
Der Kernel mountet die Ramdisk auf
/
und führt dann/init
aus, was ein symbolischer Link zu/system/bin/init
von derrecovery
-Ramdisk ist.Init der ersten Stufe startet und führt dann Folgendes aus:
- Setzt
IsRecoveryMode() == true
undForceNormalBoot() == false
. - Lädt Hersteller-Kernel-Module aus
/lib/modules
. -
DoFirstStageMount()
auf, überspringt aber das Mounten, weilIsRecoveryMode() == true
. (Das Gerät gibt die Ramdisk nicht frei (weil/
immer noch dasselbe ist), ruft aberSetInitAvbVersionInRecovery()
.) - Startet Second Stage Init von
/system/bin/init
vonrecovery
Ramdisk.
- Setzt
Boot-Image-Zeitstempel
Der folgende Code ist ein Beispiel für eine 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 Build-Zeit wird der generischen Ramdisk eine
system/etc/ramdisk/build.prop
-Datei hinzugefügt. Diese Datei enthält Zeitstempelinformationen des Builds.Zur Laufzeit kopiert die erste Stufe von
init
Dateien von der Ramdisk nachtmpfs
, bevor die Ramdisk freigegeben wird, sodass die zweite Stufe voninit
diese Datei lesen kann, um die Eigenschaften desboot
Image-Zeitstempels festzulegen.