In Android 10 ist das Stammdateisystem nicht mehr in ramdisk.img enthalten, sondern wird stattdessen in system.img zusammengeführt. Das bedeutet, dass system.img immer so erstellt wird, als wäre BOARD_BUILD_SYSTEM_ROOT_IMAGE festgelegt. Geräte, die mit Android 10 auf den Markt gebracht werden:
- Verwenden Sie ein Partitionslayout vom Typ „System als Root“ (wird vom Build automatisch erzwungen, ohne Optionen zum Ändern des Verhaltens).
- Es muss ein RAM-Disk verwendet werden, was für dm-linear erforderlich ist.
BOARD_BUILD_SYSTEM_ROOT_IMAGEmuss auffalsegesetzt sein. Diese Einstellung wird nur verwendet, um zwischen Geräten mit und ohne Ramdisk zu unterscheiden, diesystem.imgstattdessen direkt bereitstellen.
Die Bedeutung einer System-as-Root-Konfiguration unterscheidet sich zwischen Android 9 und Android 10. In einer System-as-Root-Konfiguration von Android 9 ist BOARD_BUILD_SYSTEM_ROOT_IMAGE auf true festgelegt. Dadurch wird beim Build das Root-Dateisystem in system.img zusammengeführt und system.img als Root-Dateisystem (rootfs) bereitgestellt. Diese Konfiguration ist für Geräte, die mit Android 9 ausgeliefert werden, erforderlich, für Geräte, die auf Android 9 umgestellt werden, und für Geräte mit niedrigeren Android-Versionen jedoch optional. Bei einer System-as-Root-Konfiguration von Android 10 werden $TARGET_SYSTEM_OUT und $TARGET_ROOT_OUT im Build immer zu system.img zusammengeführt. Diese Konfiguration ist das Standardverhalten für alle Geräte mit Android 10.
Android 10 enthält weitere Änderungen zur Unterstützung von dynamischen Partitionen, einem Partitionssystem im Userspace, mit dem Partitionen über Over-the-air-Updates (OTA) erstellt, die Größe geändert oder Partitionen gelöscht werden können. Aufgrund dieser Änderung kann der Linux-Kernel die logische Systempartition auf Geräten mit Android 10 nicht mehr bereitstellen. Dieser Vorgang wird daher von der ersten Phase der Init-Datei ausgeführt.
In den folgenden Abschnitten werden die Anforderungen für „System als Root“ für reine System-OTAs beschrieben. Außerdem erhalten Sie eine Anleitung zum Aktualisieren von Geräten für die Verwendung von „System als Root“ (einschließlich Änderungen am Partitionslayout und dm-verity-Kernelanforderungen). Weitere Informationen zu den Änderungen an Ramdisk finden Sie unter Ramdisk-Partitionen.
Nur System-OTAs
Nur-System-OTAs, mit denen Android-Releases system.img und product.img aktualisieren können, ohne andere Partitionen zu ändern, erfordern ein Partitionslayout mit System als Root. Alle Geräte mit Android 10 müssen ein Partitionslayout vom Typ „System als Root“ verwenden, um nur systembezogene OTAs zu ermöglichen.
- A/B-Geräte, die die
system-Partition als Root-Dateisystem bereitstellen, verwenden bereits „System als Root“ und erfordern keine Änderungen zur Unterstützung von System-OTAs. - Nicht-A/B-Geräte, die die
system-Partition unter/systembereitstellen, müssen auf ein Partitionslayout mit System als Root aktualisiert werden, um System-OTAs zu unterstützen.
Weitere Informationen zu A/B- und Nicht-A/B-Geräten finden Sie unter Nahtlose A/B-Systemupdates.
Anbieter-Overlay verwenden (kleiner als AOSP 14)
Mit dem Anbieter-Overlay können Sie Änderungen an der vendor-Partition beim Starten des Geräts vornehmen. Ein Anbieter-Overlay ist eine Gruppe von Anbietermodulen in der product-Partition, die beim Starten des Geräts auf die vendor-Partition überlagert werden. Dabei werden die vorhandenen Module ersetzt und ergänzt.
Beim Starten des Geräts führt der init-Prozess die Bereitstellung der ersten Stufe durch und liest die Standardeigenschaften. Anschließend wird /product/vendor_overlay/<target_vendor_version> durchsucht und jedes Unterverzeichnis wird im entsprechenden vendor-Partitionsverzeichnis bereitgestellt, wenn die folgenden Bedingungen erfüllt sind:
/vendor/<overlay_dir>ist vorhanden./product/vendor_overlay/<target_vendor_version>/<overlay_dir>hat denselben Dateikontext wie/vendor/<overlay_dir>.initdarf im Dateikontext von/vendor/<overlay_dir>bereitgestellt werden.
Anbieter-Overlay implementieren
Installieren Sie Anbieter-Overlay-Dateien in /product/vendor_overlay/<target_vendor_version>. Diese Dateien werden beim Starten des Geräts über die vendor-Partition gelegt. Dabei werden Dateien mit demselben Namen ersetzt und neue Dateien hinzugefügt. Über das Anbieter-Overlay können keine Dateien aus der vendor-Partition entfernt werden.
Anbieter-Overlay-Dateien müssen denselben Dateikontext haben wie die Zieldateien, die sie in der vendor-Partition ersetzen. Standardmäßig haben die Dateien im Verzeichnis /product/vendor_overlay/<target_vendor_version> den Kontext vendor_file. Wenn es Abweichungen beim Dateikontext zwischen den Overlay-Dateien des Anbieters und den Dateien gibt, die sie ersetzen, geben Sie dies in der gerätespezifischen SEPolicy an. Der Dateikontext wird auf Verzeichnisebene festgelegt. Wenn der Dateikontext eines Anbieter-Overlay-Verzeichnisses nicht mit dem Zielverzeichnis übereinstimmt und der richtige Dateikontext nicht in der gerätespezifischen SEPolicy angegeben ist, wird das Anbieter-Overlay-Verzeichnis nicht auf das Zielverzeichnis angewendet.
Wenn Sie das Anbieter-Overlay verwenden möchten, muss der Kernel OverlayFS aktivieren, indem er CONFIG_OVERLAY_FS=y festlegt. Außerdem muss der Kernel aus dem Common Kernel 4.4 oder höher zusammengeführt oder mit "overlayfs:
override_creds=off option bypass creator_cred" gepatcht werden.
Beispiel für die Implementierung eines Anbieter-Overlays
In diesem Verfahren wird die Implementierung eines Anbieter-Overlays für die Verzeichnisse /vendor/lib/*, /vendor/etc/* und /vendor/app/* veranschaulicht.
-
Vordefinierte Anbieterdateien in
device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/hinzufügen:device/google/device/vendor_overlay/28/lib/libfoo.so device/google/device/vendor_overlay/28/lib/libbar.so device/google/device/vendor_overlay/28/etc/baz.xml device/google/device/vendor_overlay/28/app/qux.apk
-
Installieren Sie die vorkonfigurierten Anbieterdateien unter
product/vendor_overlayindevice/google/device/device.mk:PRODUCT_COPY_FILES += \ $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)
-
Definieren Sie Dateikontexte, wenn die Zieldateien der
vendor-Partition andere Kontexte alsvendor_filehaben. Da/vendor/lib/*den Kontextvendor_fileverwendet, ist dieses Verzeichnis in diesem Beispiel nicht enthalten.Fügen Sie
device/google/device-sepolicy/private/file_contextsFolgendes hinzu:/(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)? u:object_r:vendor_configs_file:s0 /(product|system/product)/vendor_overlay/[0-9]+/app(/.*)? u:object_r:vendor_app_file:s0
-
Dem
init-Prozess erlauben, das Anbieter-Overlay in anderen Dateikontexten alsvendor_filebereitzustellen Da derinit-Prozess bereits die Berechtigung zum Bereitstellen imvendor_file-Kontext hat, wird in diesem Beispiel keine Richtlinie fürvendor_filedefiniert.Fügen Sie
device/google/device-sepolicy/public/init.teFolgendes hinzu:allow init vendor_configs_file:dir mounton; allow init vendor_app_file:dir mounton;
Anbieter-Overlay prüfen
Um die Overlay-Konfiguration des Anbieters zu validieren, fügen Sie Dateien in /product/vendor_overlay/<target_vendor_version>/<overlay_dir> hinzu und prüfen Sie, ob die Dateien in /vendor/<overlay_dir> überlagert werden.
Für userdebug-Builds gibt es ein Testmodul für Atest:
$ atest -v fs_mgr_vendor_overlay_test
Auf „system-as-root“ aktualisieren
Wenn Sie nicht A/B-Geräte auf „System als Root“ umstellen möchten, müssen Sie das Partitionierungsschema für boot.img und system.img aktualisieren, dm-verity einrichten und alle Boot-Abhängigkeiten in den gerätespezifischen Stammordnern entfernen.
Partitionen aktualisieren
Anders als bei A/B-Geräten, bei denen /boot als Wiederherstellungspartition verwendet wird, muss auf Nicht-A/B-Geräten die /recovery-Partition getrennt bleiben, da sie keine Fallback-Slot-Partition haben (z. B. von boot_a nach boot_b). Wenn /recovery auf einem Nicht-A/B-Gerät entfernt und dem A/B-Schema ähnlich gemacht wird, kann der Wiederherstellungsmodus bei einem fehlgeschlagenen Update der /boot-Partition beschädigt werden. Aus diesem Grund muss die Partition /recovery auf Nicht-A/B-Geräten eine separate Partition von /boot sein. Das bedeutet, dass das Wiederherstellungs-Image weiterhin verzögert aktualisiert wird, genau wie auf Geräten mit Android 8.1.0 oder niedriger.
In der folgenden Tabelle sind die Unterschiede bei der Imagepartition für Geräte ohne A/B-Partition vor und nach Android 9 aufgeführt.
| Bild | Ramdisk (vor Version 9) | System-as-root (nach 9) |
|---|---|---|
boot.img |
Enthält einen Kernel und eine ramdisk.img:
ramdisk.img
-/
- init.rc
- init
- etc -> /system/etc
- system/ (mount point)
- vendor/ (mount point)
- odm/ (mount point)
... |
Enthält nur einen normalen Boot-Kernel. |
recovery.img |
Enthält einen Wiederherstellungskernel und eine Wiederherstellungsramdisk.img. |
|
system.img |
Enthält Folgendes:
system.img
-/
- bin/
- etc
- vendor -> /vendor
- ... |
Enthält die zusammengeführten Inhalte des ursprünglichen system.img und ramdisk.img:
system.img
-/
- init.rc
- init
- etc -> /system/etc
- system/
- bin/
- etc/
- vendor -> /vendor
- ...
- vendor/ (mount point)
- odm/ (mount point)
... |
Die Partitionen selbst ändern sich nicht. Sowohl für ramdisk als auch für system-as-root wird das folgende Partitionsschema verwendet:
/boot/system/system/recovery/vendorusw.
dm-verity einrichten
Bei „system-as-root“ muss der Kernel system.img unter / (Bereitstellungspunkt) mit dm-verity bereitstellen. AOSP unterstützt die folgenden dm-verity-Implementierungen für system.img.
vboot 1.0
Für vboot 1.0 muss der Kernel Android-spezifische Metadaten auf /system parsen und dann in dm-verity-Parameter konvertieren, um dm-verity einzurichten. Dazu sind diese Kernel-Patches erforderlich.
Das folgende Beispiel zeigt dm-verity-bezogene Einstellungen für „system-as-root“ in der Kernel-Befehlszeile:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="system none ro,0 1 android-verity /dev/sda34" veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f
vboot 2.0
Für vboot 2.0 (AVB) muss der Bootloader external/avb/libavb einbinden. Dieser liest dann den Hashtree-Beschreibungsblock für /system aus, wandelt ihn in dm-verity-Parameter um und übergibt die Parameter schließlich über die Kernel-Befehlszeile an den Kernel. Hashtree-Deskriptoren von /system können sich auf /vbmeta oder auf /system selbst befinden.
Für vboot 2.0 sind die folgenden Kernel-Patches erforderlich:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
- kernel 4.4 patches, kernel 4.9 patches usw.
Das folgende Beispiel zeigt dm-verity-bezogene Einstellungen für „system-as-root“ in der Kernel-Befehlszeile:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="1 vroot none ro 1,0 5159992 verity 1 PARTUUID=00000016-0000-0000-0000-000000000000 PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999 sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2 8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption ignore_zero_blocks use_fec_from_device PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks 650080 fec_start 650080"
Gerätespezifische Stammordner verwenden
Bei „System als Root“ werden alle gerätespezifischen Stammordner, die mit BOARD_ROOT_EXTRA_FOLDERS hinzugefügt wurden, gelöscht, nachdem das generische System-Image (GSI) auf das Gerät geflasht wurde (und bevor die Vendor Test Suite-Tests ausgeführt werden). Der gesamte Inhalt des Stammverzeichnisses wurde durch das GSI von „System als Root“ ersetzt. Wenn diese Ordner entfernt werden, kann das Gerät möglicherweise nicht mehr gestartet werden, wenn eine Abhängigkeit von den gerätespezifischen Stammordnern besteht (z. B. wenn sie als Bereitstellungspunkte verwendet werden).
Verwenden Sie BOARD_ROOT_EXTRA_FOLDERS nicht, um gerätespezifische Stammordner hinzuzufügen, um dieses Problem zu vermeiden. Wenn Sie gerätespezifische Befestigungspunkte angeben müssen, verwenden Sie /mnt/vendor/<mount point> (in diesen Änderungslisten hinzugefügt). Diese anbieterspezifischen Bereitstellungspunkte können sowohl im Gerätebaum fstab (für die Bereitstellung der ersten Stufe) als auch in der Datei /vendor/etc/fstab.{ro.hardware} direkt angegeben werden, ohne dass eine zusätzliche Einrichtung erforderlich ist, da sie von fs_mgr automatisch unter /mnt/vendor/* erstellt werden.