Diese Seite wurde von der Cloud Translation API übersetzt.

Partitionslayout

In Android 10 ist das Root-Dateisystem nicht mehr in ramdisk.img enthalten und wird stattdessen mit system.img (d. h. system.img wird immer erstellt als wenn BOARD_BUILD_SYSTEM_ROOT_IMAGE festgelegt wurde). Geräte Markteinführung mit Android 10:

Verwenden Sie ein System-as-Root-Partitionslayout (automatisch erzwungen vom ohne Optionen zum Ändern des Verhaltens).
Muss eine ramdisk verwenden, die für dm-linear erforderlich ist.
BOARD_BUILD_SYSTEM_ROOT_IMAGE muss auf false festgelegt werden. Diese Einstellung wird nur verwendet, um zwischen Geräten zu unterscheiden, die eine Ramdisk verwenden und bei Geräten, die keine RAM-Disk nutzen (und stattdessen system.img direkt).

Die Bedeutung einer System-as-Root-Konfiguration ist bei Android 9 und Android 10 Auf einem System-as-root-System mit Android 9 Konfiguration ist BOARD_BUILD_SYSTEM_ROOT_IMAGE festgelegt auf true, wodurch der Build gezwungen wird, das Stammdateisystem system.img und stellen Sie dann system.img als Root-Datei bereit (rootfs). Diese Konfiguration ist für Geräte erforderlich Markteinführung mit Android 9, ist aber optional für Geräte mit Upgrade auf Android 9 und für Geräte mit älteren Android-Versionen Auf einem Android-Gerät 10-System-as-root-Konfiguration hat, wird der Build immer führt $TARGET_SYSTEM_OUT und $TARGET_ROOT_OUT zu system.img; Diese Konfiguration ist das Standardverhalten für alle Geräte mit Android 10.

Android 10 nimmt weitere Änderungen am Support vor dynamische Partitionen, ein Userspace-Partitionierungssystem, das OTA-Updates (Over The Air) ermöglicht, Sie können Partitionen erstellen, in der Größe anpassen oder löschen. Im Rahmen dieser Änderung wird das Der Kernel kann die logische Systempartition nicht mehr auf laufenden Geräten bereitstellen Android 10, sodass dieser Vorgang vom ersten Stage init an.

In den folgenden Abschnitten werden die System-as-root-Anforderungen für System-OTAs: Anleitung zum Aktualisieren von Geräten für die Verwendung von System-as-Root (einschließlich Änderungen des Partitionslayouts und dm-verity-Kernel-Anforderungen). Für Details zu den Änderungen an Ramdisk findest du unter Ramdisk Partitionen.

Informationen zu reinen System-OTAs

Systemspezifische OTAs, mit denen Android-Releases aktualisiert werden können system.img und product.img, ohne dass sich andere Werte ändern ein System-as-root-Layout. Alle Geräte mit Android 10 muss ein System-as-root-Partitionslayout reine System-OTAs aktivieren.

A/B-Geräten, die die Partition system als „rootfs“ bereitstellen, verwenden bereits System-as-root und erfordern keine Änderungen zur Unterstützung von System-OTAs.
Nicht-A/B-Geräte, die die Partition system bereitstellen /system, muss für die Verwendung aktualisiert werden ein System-as-root-Partitionslayout, 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 (<=AOSP 14)

Mit einem Anbieter-Overlay können Sie Änderungen am vendor einblenden beim Starten des Geräts. Ein Anbieter-Overlay ist eine Reihe von Die Partition product, die über vendor eingeblendet wird Partition beim Hochfahren des Geräts an. Ersetzen Sie dabei die bestehenden Module und erweitern Sie sie.

Beim Starten des Geräts schließt der init-Prozess den ersten Bereitstellung des Anzeigebereichs und liest die Standardeigenschaften. Dann sucht es /product/vendor_overlay/<target_vendor_version> und Halterungen jedes Unterverzeichnis im zugehörigen vendor-Partitionsverzeichnis, 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>.
init darf die Bereitstellung im Dateikontext von /vendor/<overlay_dir>.

Anbieter-Overlay implementieren

Anbieter-Overlay-Dateien installieren in /product/vendor_overlay/<target_vendor_version> Diese Dateien beim Hochfahren des Geräts die Partition vendor einblenden und so Dateien ersetzen und fügen neue Dateien hinzu. Über das Anbieter-Overlay können keine Dateien entfernt werden aus der Partition vendor.

Anbieter-Overlay-Dateien müssen denselben Dateikontext wie die Zieldateien haben werden sie in der Partition vendor ersetzt. Standardmäßig werden die Dateien im Verzeichnis /product/vendor_overlay/<target_vendor_version> vendor_file-Kontext haben. Bei nicht übereinstimmenden Dateikontexten zwischen Anbieter-Overlay-Dateien und den Dateien, die sie ersetzen, angeben, dass in der gerätespezifische sepolicy. Der Dateikontext wird auf Verzeichnisebene festgelegt. Wenn die Der Dateikontext eines Anbieter-Overlay-Verzeichnisses stimmt nicht mit dem Zielverzeichnis überein. und der richtige Dateikontext nicht in der gerätespezifischen sepolicy angegeben ist, dass das Anbieter-Overlay-Verzeichnis nicht mit dem Zielverzeichnis überlagert wird.

Zur Verwendung von Anbieter-Overlay muss der Kernel OverlayFS aktivieren, indem er Folgendes festlegt: CONFIG_OVERLAY_FS=y Außerdem muss der Kernel aus der gängiger Kernel 4.4 oder höher oder mit "overlayfs: override_creds=off option bypass creator_cred" gepatcht.

Beispiel für die Implementierung eines Anbieter-Overlays

Dieses Verfahren zeigt die Implementierung eines Anbieter-Overlays, das die die Verzeichnisse /vendor/lib/*, /vendor/etc/* und /vendor/app/*

Vordefinierte Anbieterdateien hinzufügen device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/:

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 vordefinierten Anbieterdateien product/vendor_overlay Zoll device/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 vendor-Zielpartitionsdateien haben andere Kontexte als vendor_file. Weil /vendor/lib/* verwendet den Kontext vendor_file, dies Beispiel enthält dieses Verzeichnis nicht.

Folgendes hinzufügen zu device/google/device-sepolicy/private/file_contexts:
```
/(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
```
init-Prozess erlauben, das Anbieter-Overlay für eine Datei bereitzustellen Kontexte als vendor_file. Da die init Prozess hat bereits die Berechtigung zur Bereitstellung im Kontext vendor_file. In diesem Beispiel wird die Richtlinie für vendor_file nicht definiert.

Folgendes hinzufügen zu device/google/device-sepolicy/public/init.te:
```
allow init vendor_configs_file:dir mounton;
allow init vendor_app_file:dir mounton;
```

Anbieter-Overlay validieren

Fügen Sie Dateien hinzu, um die Konfiguration des Anbieter-Overlays zu validieren. /product/vendor_overlay/<target_vendor_version>/<overlay_dir> und prüfen Sie, ob die Dateien /vendor/<overlay_dir>.

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 für die Verwendung des Systems als Root aktualisieren möchten, müssen Sie die Partitionierungsschema für boot.img und system.img, festgelegt Richten Sie dm-verity ein und entfernen Sie alle Startabhängigkeiten des gerätespezifischen Stammverzeichnisses. Ordner.

Partitionen aktualisieren

Im Gegensatz zu A/B-Geräten, die /boot als recovery-Partition Nicht-A/B-Geräte müssen die Partition /recovery beibehalten. getrennt, da sie keine Fallback-Slot-Partition haben (z. B. von boot_a bis boot_b). Wenn /recovery gleich auf Nicht-A/B-Geräten entfernt und dem A/B-Schema ähnlich: Wiederherstellungsmodus könnte während einer fehlgeschlagenen Aktualisierung der Partition /boot nicht mehr funktionieren. Für Aus diesem Grund muss die Partition /recovery ein separate Partition von /boot für Nicht-A/B-Geräte, was bedeutet, dass das Wiederherstellungsabbild weiterhin verzögert aktualisiert wird (also wie bei Geräten mit Android 8.1.0 oder niedriger).

In der folgenden Tabelle sind die Unterschiede bei den Bildpartitionen für Nicht-A/B-Geräte aufgeführt vor und nach Android 9.

Bild	Ramdisk (vor 9)	System-as-root (nach 9)
`boot.img`	Enthält einen Kernel und ein `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 Wiederherstellungs-Kernel und einen Wiederherstellungs-Kernel `ramdisk.img`
`system.img`	Enthält Folgendes: system.img -/ - bin/ - etc - vendor -> /vendor - ...	Enthält den zusammengeführten Inhalt der ursprünglichen Datei `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 das folgende Partitionsschema:

/boot
/system
/system
/recovery
/vendor usw.

dm-verity einrichten

Im System-as-root muss der Kernel system.img unter dem / (Bereitstellungspunkt) mit dm-verity. AOSP unterstützt die folgende dm-verity Implementierungen für system.img.

vboot 1.0

Für vboot 1.0 muss der Kernel parsen Android-spezifisch metadata aktiviert /system, dann konvertieren in dm-verity-Parameter zum Einrichten von dm-verity (erfordert dieser Kernel-Patches). Das folgende Beispiel zeigt dm-verity-bezogene Einstellungen für „system-as-root“ in 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) enthält, muss der Bootloader external/avb/libavb, das dann die Hashtree-Deskriptor für /system, konvertiert es an dm-verity-Parameter und übergibt die Parameter schließlich an den über die Kernel-Befehlszeile. (Hashtree-Deskriptoren von /system) möglicherweise auf /vbmeta oder auf /system selbst.)

vboot 2.0 erfordert die folgenden Kernel-Patches:

Das folgende Beispiel zeigt dm-verity-bezogene Einstellungen für „system-as-root“ in 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

Mit System-as-root nach dem generischen System-Image (GSI) auf dem Gerät (und vor der Ausführung) angezeigt wird. Anbieter-Test-Suite), alle Gerätespezifische Stammordner, die mit BOARD_ROOT_EXTRA_FOLDERS hinzugefügt wurden weil der gesamte Inhalt des Stammverzeichnisses durch System-as-root-GSI. Das Entfernen dieser Ordner kann dazu führen, dass das Gerät werden nicht gestartet, wenn eine Abhängigkeit von den gerätespezifischen Stammordnern besteht. (Sie werden z. B. als Bereitstellungspunkte verwendet).

Um dieses Problem zu vermeiden, solltest du BOARD_ROOT_EXTRA_FOLDERS nicht für folgende Zwecke verwenden: gerätespezifische Stammordner hinzufügen Wenn Sie eine gerätespezifische Bereitstellung angeben müssen Punkte, verwenden Sie /mnt/vendor/<mount point> (in diesen Änderungslisten) erstellen. Diese anbieterspezifischen Bereitstellungspunkte können direkt in den beiden fstab-Gerätestrukturen angegeben (für die erste Phase mount) und die Datei /vendor/etc/fstab.{ro.hardware} ohne zusätzliche Einrichtung (da fs_mgr sie unter dem /mnt/vendor/* automatisch).