In Android 10 ist das Root-Dateisystem nicht mehr in ramdisk.img
enthalten und wird stattdessen in system.img
zusammengeführt (d. h. system.img
wird immer so erstellt, als ob BOARD_BUILD_SYSTEM_ROOT_IMAGE
festgelegt wäre). Geräte, die mit Android 10 starten:
- Verwenden Sie ein System-als-Root-Partitionslayout (wird vom Build automatisch erzwungen, ohne Optionen zum Ändern des Verhaltens).
- Es muss eine Ramdisk verwendet werden, die für dm-linear erforderlich ist.
-
BOARD_BUILD_SYSTEM_ROOT_IMAGE
muss auffalse
gesetzt werden. Diese Einstellung dient nur zur Unterscheidung zwischen Geräten, die eine Ramdisk verwenden, und Geräten, die keine Ramdisk verwenden (und stattdessensystem.img
direkt mounten).
Die Bedeutung einer System-als-Root-Konfiguration unterscheidet sich zwischen Android 9 und Android 10. In einer Android 9-System-als-Root-Konfiguration ist BOARD_BUILD_SYSTEM_ROOT_IMAGE
auf true
gesetzt, was den Build dazu zwingt, das Root-Dateisystem dann in system.img
zusammenzuführen Mounten Sie system.img
als Root-Dateisystem (rootfs). Diese Konfiguration ist für Geräte, die mit Android 9 starten, obligatorisch , ist jedoch für Geräte, die auf Android 9 aktualisieren, und für Geräte, auf denen niedrigere Android-Versionen ausgeführt werden, optional . In einer Android 10-System-als-Root-Konfiguration führt der Build immer $TARGET_SYSTEM_OUT
und $TARGET_ROOT_OUT
in system.img
zusammen; Diese Konfiguration ist das Standardverhalten für alle Geräte mit Android 10.
Android 10 nimmt weitere Änderungen vor, um dynamische Partitionen zu unterstützen, ein Userspace-Partitionierungssystem, das OTA-Updates (Over-the-Air) zum Erstellen, Ändern der Größe oder Zerstören von Partitionen ermöglicht. Im Rahmen dieser Änderung kann der Linux-Kernel die logische Systempartition auf Geräten mit Android 10 nicht mehr mounten, sodass dieser Vorgang von der ersten Init-Stufe übernommen wird.
In den folgenden Abschnitten werden die System-als-Root-Anforderungen für Nur-System-OTAs beschrieben und Anleitungen zum Aktualisieren von Geräten für die Verwendung von System-als-Root bereitgestellt (einschließlich Änderungen am Partitionslayout und dm-verity-Kernelanforderungen). Einzelheiten zu Änderungen an der Ramdisk finden Sie unter Ramdisk-Partitionen .
Über systemspezifische OTAs
Nur-System-OTAs, die es Android-Versionen ermöglichen, system.img
und product.img
zu aktualisieren, ohne andere Partitionen zu ändern, erfordern ein System-als-Root-Partitionslayout. Alle Geräte mit Android 10 müssen ein System-als-Root-Partitionslayout verwenden, um reine System-OTAs zu ermöglichen.
- A/B-Geräte, die die
system
als Rootfs bereitstellen, verwenden bereits System-als-Root und erfordern keine Änderungen, um System-OTAs zu unterstützen. - Nicht-A/B-Geräte, die die
system
unter/system
bereitstellen, müssen aktualisiert werden, um ein System-als-Root-Partitionslayout zur Unterstützung von System-OTAs zu verwenden .
Einzelheiten zu A/B- und Nicht-A/B-Geräten finden Sie unter A/B (Seamless) System Updates .
Verwendung des Anbieter-Overlays
Mit der Herstellerüberlagerung können Sie Änderungen an der vendor
beim Gerätestart überlagern. Ein Anbieter-Overlay ist eine Reihe von Anbietermodulen in der product
, die beim Booten des Geräts auf der vendor
überlagert werden und die vorhandenen Module ersetzen und ergänzen.
Wenn das Gerät startet, schließt der init
Prozess die erste Mount-Phase ab und liest die Standardeigenschaften. Anschließend wird /product/vendor_overlay/<target_vendor_version>
durchsucht und jedes Unterverzeichnis im entsprechenden vendor
bereitgestellt, wenn die folgenden Bedingungen erfüllt sind:
-
/vendor/<overlay_dir>
existiert. -
/product/vendor_overlay/<target_vendor_version>/<overlay_dir>
hat den gleichen Dateikontext wie/vendor/<overlay_dir>
. -
init
darf im Dateikontext von/vendor/<overlay_dir>
mounten.
Implementierung eines Anbieter-Overlays
Installieren Sie Anbieter-Overlay-Dateien in /product/vendor_overlay/<target_vendor_version>
. Diese Dateien überlagern beim Booten des Geräts die vendor
, ersetzen Dateien mit demselben Namen und fügen alle neuen Dateien hinzu. Das Anbieter-Overlay kann keine Dateien von der vendor
entfernen.
Hersteller-Overlay-Dateien müssen denselben Dateikontext haben wie die Zieldateien, die sie in der vendor
ersetzen. Standardmäßig haben die Dateien im Verzeichnis /product/vendor_overlay/<target_vendor_version>
den Kontext vendor_file
. Wenn zwischen den Overlay-Dateien des Herstellers und den durch sie ersetzten Dateien Dateikontextkonflikte bestehen, geben Sie dies in der gerätespezifischen Separierungsrichtlinie 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 dieses Anbieter-Overlay-Verzeichnis nicht über das Zielverzeichnis gelegt.
Um das Hersteller-Overlay zu verwenden, muss der Kernel OverlayFS aktivieren, indem er CONFIG_OVERLAY_FS=y
festlegt. Außerdem muss der Kernel aus dem gemeinsamen 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
Dieses Verfahren veranschaulicht die Implementierung eines Anbieter-Overlays, das die Verzeichnisse /vendor/lib/*
, /vendor/etc/*
und /vendor/app/*
überlagert.
Fügen Sie vorgefertigte Herstellerdateien in
device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/
hinzu: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 vorgefertigten Herstellerdateien in „
product/vendor_overlay
indevice/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 Partitionsdateien
vendor
andere Kontexte alsvendor_file
haben. Da/vendor/lib/*
denvendor_file
Kontext verwendet, enthält dieses Beispiel dieses Verzeichnis nicht.Fügen Sie Folgendes zu
device/google/device-sepolicy/private/file_contexts
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
Ermöglichen Sie dem
init
Prozess, das Anbieter-Overlay in anderen Dateikontexten alsvendor_file
bereitzustellen. Da derinit
Prozess bereits über die Berechtigung zum Mounten imvendor_file
Kontext verfügt, wird in diesem Beispiel die Richtlinie fürvendor_file
nicht definiert.Fügen Sie Folgendes zu
device/google/device-sepolicy/public/init.te
hinzu:allow init vendor_configs_file:dir mounton; allow init vendor_app_file:dir mounton;
Validierung des Anbieter-Overlays
Um die Anbieter-Overlay-Konfiguration zu validieren, fügen Sie Dateien in /product/vendor_overlay/<target_vendor_version>/<overlay_dir>
hinzu und prüfen Sie, ob die Dateien den Dateien in /vendor/<overlay_dir>
überlagert sind.
Für userdebug
Builds gibt es ein Testmodul für Atest :
$ atest -v fs_mgr_vendor_overlay_test
Aktualisierung auf System-als-Root
Um Nicht-A/B-Geräte so zu aktualisieren, dass sie „System als Root“ verwenden, müssen Sie das Partitionierungsschema für boot.img
und system.img
aktualisieren, dm-verity einrichten und alle Boot-Abhängigkeiten von den gerätespezifischen Root-Ordnern entfernen.
Partitionen aktualisieren
Im Gegensatz zu A/B-Geräten, die /boot
als Wiederherstellungspartition verwenden, müssen Nicht-A/B-Geräte die /recovery
Partition separat halten, da sie nicht über die Fallback-Slot-Partition verfügen (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, könnte der Wiederherstellungsmodus während einer fehlgeschlagenen Aktualisierung der /boot
Partition unterbrochen werden. Aus diesem Grund muss die /recovery
Partition für Nicht-A/B-Geräte eine von /boot
getrennte Partition sein, was bedeutet, dass das Wiederherstellungsimage weiterhin verzögert aktualisiert wird (d. h. genauso wie bei Geräten mit Android). 8.1.0 oder niedriger).
In der folgenden Tabelle sind die Unterschiede bei der Bildpartition für Nicht-A/B-Geräte vor und nach Android 9 aufgeführt.
Bild | Ramdisk (vor 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 Wiederherstellungs ramdisk.img . | |
system.img | Enthält Folgendes: system.img -/ - bin/ - etc - vendor -> /vendor - ... | Enthält den zusammengeführten Inhalt der 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 Ramdisk als auch System-as-Root verwenden das folgende Partitionsschema:
-
/boot
-
/system
-
/system
-
/recovery
-
/vendor
usw.
dm-verity einrichten
Im System-als-Root-System muss der Kernel system.img
unter /
(Einhängepunkt) mit dm-verity mounten. 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
analysieren und dann in dm-verity-Parameter konvertieren, um dm-verity einzurichten (erfordert diese Kernel-Patches ). 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 integrieren, das dann den Hashtree-Deskriptor für /system
analysiert, ihn in dm-verity params konvertiert und die Parameter schließlich über die Kernel-Befehlszeile an den Kernel übergibt. (Hashtree-Deskriptoren von /system
können sich auf /vbmeta
oder auf /system
selbst befinden.)
vboot 2.0 erfordert die folgenden Kernel-Patches:
- 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"
Verwendung gerätespezifischer Stammordner
Bei System-as-Root sind alle mit BOARD_ROOT_EXTRA_FOLDERS
hinzugefügten gerätespezifischen Stammordner verschwunden, nachdem das generische Systemabbild (GSI) auf dem Gerät geflasht wurde (und bevor Vendor Test Suite- Tests ausgeführt werden), da der gesamte Inhalt des Stammverzeichnisses ersetzt wurde durch das System-as-Root-GSI. Das Entfernen dieser Ordner kann dazu führen, dass das Gerät nicht mehr bootfähig ist, wenn eine Abhängigkeit von den gerätespezifischen Stammordnern besteht (sie werden beispielsweise als Bereitstellungspunkte verwendet).
Um dieses Problem zu vermeiden, verwenden Sie BOARD_ROOT_EXTRA_FOLDERS
nicht, um gerätespezifische Stammordner hinzuzufügen. Wenn Sie gerätespezifische Mount-Punkte angeben müssen, verwenden Sie /mnt/vendor/<mount point>
(in diesen Änderungslisten hinzugefügt). Diese herstellerspezifischen Mount-Punkte können direkt sowohl im fstab
Gerätebaum (für die Mount-Phase der ersten Stufe) als auch in der Datei /vendor/etc/fstab.{ro.hardware}
ohne zusätzliche Einrichtung angegeben werden (da fs_mgr
sie unter /mnt/vendor/*
automatisch).