Dynamische Partitionen implementieren

Die dynamische Partitionierung wird mithilfe des dm-linear Device Mapper implementiert. im Linux-Kernel. Die Partition super enthält Metadaten mit den Namen und Blockbereichen jeder dynamischen Partition innerhalb von super. Während init der ersten Phase Metadaten werden geparst und validiert und virtuelle Blockgeräte werden erstellt, um jede dynamische Partition darstellt.

Beim Anwenden eines OTA werden automatisch dynamische Partitionen erstellt, in der Größe angepasst oder gelöscht werden. Für A/B-Geräte gibt es zwei Kopien und die Änderungen werden nur auf die Kopie angewendet, Zielslot.

Da dynamische Partitionen im Userspace implementiert sind, benötigen Partitionen vom Bootloader können nicht dynamisch gemacht werden. Beispiel: boot, dtbo und vbmeta werden vom Bootloader gelesen. müssen also als physische Partitionen bleiben.

Jede dynamische Partition kann einer Aktualisierungsgruppe angehören. Diese Gruppen begrenzen den maximalen Speicherplatz, den Partitionen in dieser Gruppe belegen können. system und vendor können beispielsweise zu einer Gruppe, die die Gesamtgröße von system und vendor.

Dynamische Partitionen auf neuen Geräten implementieren

In diesem Abschnitt wird beschrieben, wie Sie dynamische Partitionen auf neuen Geräten implementieren. die mit Android 10 und höher eingeführt wird. Zum Aktualisieren siehe Upgrade von Android-Geräten durchführen Geräte.

Partitionsänderungen

Für Geräte, die mit Android 10 auf den Markt gebracht werden, erstelle eine Partition namens super. Das super Partition verarbeitet A/B-Slots intern, sodass A/B-Geräte separate super_a- und super_b-Partitionen. Alle schreibgeschützten AOSP-Partitionen, die nicht vom Bootloader verwendet werden, müssen dynamisch sein und muss aus der GUID-Partitionstabelle (GPT) entfernt werden. Anbieterspezifische Partitionen müssen nicht dynamisch sein und können in den GPTs enthalten.

<ph type="x-smartling-placeholder">

Fügen Sie zum Schätzen der Größe von super die Größen der die aus dem GPT gelöscht werden. Bei A/B-Geräten sollte die Größe beider Anzeigenflächen enthalten. Abbildung 1: Beispiel für eine Partitionstabelle vor und nach der Konvertierung in ein dynamisches Format Partitionen.

<ph type="x-smartling-placeholder">
</ph> Layout der Partitionstabelle <ph type="x-smartling-placeholder">
</ph> Abbildung 1: Neues Layout für physische Partitionstabellen, wenn In dynamische Partitionen konvertieren

Folgende dynamische Partitionen werden unterstützt:

  • System
  • Vendor
  • Produkt
  • System-Erw.
  • ODM

Bei Geräten, die mit Android 10 auf den Markt gebracht werden, gilt die Kernel-Befehlszeilenoption androidboot.super_partition muss leer sein, damit der Befehl „sysprop“ ro.boot.super_partition ist leer.

Partitionsausrichtung

Das Device Mapper-Modul funktioniert möglicherweise weniger effizient, Die Partition „super“ ist nicht richtig ausgerichtet. Die Partition super MUSS an der minimalen E/A-Auslastung ausgerichtet sein Anfragegröße gemäß der Blockebene. Standardmäßig enthält der Parameter Build-System erstellen (über lpmake, das den super-Partitions-Image), wird von einer 1-MiB-Ausrichtung ausgegangen für jede dynamische Partition ausreicht. Zulieferunternehmen sollten jedoch Prüfen Sie, ob die Partition super richtig ausgerichtet ist.

Sie können die Mindestanfragegröße eines Blockgeräts bestimmen, indem Sie sysfs wird geprüft. Beispiel: 

# ls -l /dev/block/by-name/super
lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17
# cat /sys/block/sda/queue/minimum_io_size
786432

Sie können die Ausrichtung der Partition super in einem auf ähnliche Weise: 

# cat /sys/block/sda/sda17/alignment_offset

Der Ausrichtungsversatz MUSS 0 sein.

Änderungen an der Gerätekonfiguration

Um die dynamische Partitionierung zu aktivieren, fügen Sie das folgende Flag in device.mk: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Änderungen der Board-Konfiguration

Sie müssen die Größe der Partition super festlegen: 

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

Auf A/B-Geräten gibt das Build-System einen Fehler aus, wenn die Gesamtgröße aller dynamischen Partitions-Images machen mehr als die Hälfte von super aus der Partitionsgröße.

Sie können die Liste der dynamischen Partitionen so konfigurieren. Für die Updategruppen verwendet werden, BOARD_SUPER_PARTITION_GROUPS. Jeder Gruppenname hat dann eine BOARD_group_SIZE und BOARD_group_PARTITION_LIST. Bei A/B-Geräten sollte die maximale Größe einer Gruppe nur ein Slot, da die Gruppennamen intern ein Slot-Suffix haben.

Hier siehst du ein Beispielgerät, auf dem alle Partitionen in einer Gruppe zusammengefasst werden mit dem Namen example_dynamic_partitions: 

BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product

Hier ist ein Beispielgerät, über das System- und Produktdienste group_foo und vendor, product und odm in group_bar: 

BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar
BOARD_GROUP_FOO_SIZE := 4831838208
BOARD_GROUP_FOO_PARTITION_LIST := system product_services
BOARD_GROUP_BAR_SIZE := 1610612736
BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm
<ph type="x-smartling-placeholder"> <ph type="x-smartling-placeholder">
  • Für Virtual A/B Launch-Geräte muss die Summe der Maximalgrößen aller Gruppen Maximal:
    BOARD_SUPER_PARTITION_SIZE: Aufwand
    Siehe Virtual A/B implementieren.
  • Für A/B-Launch-Geräte muss die Summe der Maximalgrößen aller Gruppen sein:
    BOARD_SUPER_PARTITION_SIZE / 2 – Aufwand
  • Für Nicht-A/B-Geräte und nachgerüstete A/B-Geräte wird die Summe der muss die Größe aller Gruppen:
    BOARD_SUPER_PARTITION_SIZE – Aufwand
  • Zum Zeitpunkt der Erstellung ist die Summe der Größen der Images jeder Partition in einer Aktualisierungsgruppe darf die maximale Größe der Gruppe nicht überschreiten.
  • Bei der Berechnung ist Gemeinkosten erforderlich, um Metadaten zu berücksichtigen. Ausrichtungen usw. Ein angemessener Aufwand ist 4 MiB, aber Sie je nach Bedarf des Geräts einen größeren Overhead einplanen.

Größe dynamischer Partitionen

Vor dynamischen Partitionen wurden Partitionsgrößen sicherzustellen, dass sie genügend Platz für zukünftige Updates haben. Die tatsächliche Größe unverändert übernommen und die meisten schreibgeschützten Partitionen Speicherplatz in ihrem Dateisystem. In dynamischen Partitionen ist dieser kostenlose Speicherplatz ist unbrauchbar und könnte zum Vergrößern von Partitionen während eines OTA-Speichers verwendet werden. Es ist wichtig, dass Partitionen keinen Speicherplatz verschwenden einer minimalen Größe zugewiesen werden.

Bei schreibgeschützten ext4-Images weist das Build-System Die Mindestgröße, wenn keine hartcodierte Partitionsgröße angegeben ist. Die in das Image passt, sodass das Dateisystem so wenig ungenutzten Speicherplatzes möglichst ungenutzt lassen. So wird sichergestellt, dass das Gerät der für OTAs verwendet werden kann.

Außerdem können ext4-Bilder weiter komprimiert werden, indem Block- der Deduplizierung. Verwenden Sie die folgende Konfiguration, um dies zu aktivieren: 

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Wenn die automatische Zuweisung einer Partitions-Mindestgröße nicht gewünscht ist, gibt es zwei Möglichkeiten, die Partitionsgröße zu steuern. Sie können eine des freien Speicherplatzes mit der BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE, oder Sie können angeben, BOARD_partitionIMAGE_PARTITION_SIZE zum Erzwingen einer bestimmten Größe festlegen können. Keines von diesen wird empfohlen, sofern dies nicht unbedingt erforderlich ist.

Beispiel: 

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Dadurch wird erzwungen, dass das Dateisystem in product.img 50 MiB ungenutzter Speicherplatz

<ph type="x-smartling-placeholder">

System-as-root-Änderungen

Geräte, die mit Android 10 auf den Markt gebracht werden, dürfen verwenden Sie „system-as-root“.

Geräte mit dynamischen Partitionen (unabhängig davon, ob sie mit oder Nachrüstung auf den Markt gebracht werden) dynamischen Partitionen) darf „system-as-root“ nicht verwendet werden. Der Linux-Kernel kann nicht da sie die Partition super interpretieren. system selbst. system wird jetzt bereitgestellt von init der ersten Phase, die sich auf der Ramdisk befindet.

Legen Sie BOARD_BUILD_SYSTEM_ROOT_IMAGE nicht fest. In Android 10, die Das Flag BOARD_BUILD_SYSTEM_ROOT_IMAGE wird nur für folgende Aktionen verwendet: unterscheiden, ob das System vom Kernel oder vom init der ersten Phase in Ramdisk.

BOARD_BUILD_SYSTEM_ROOT_IMAGE wird auf true festgelegt verursacht einen Build-Fehler, wenn PRODUCT_USE_DYNAMIC_PARTITIONS ist auch true.

Wenn BOARD_USES_RECOVERY_AS_BOOT auf „true“ gesetzt ist, Das Wiederherstellungs-Image wird als boot.img erstellt und enthält die ramdisk. Bisher hat der Bootloader den Kernel skip_initramfs verwendet. Befehlszeilenparameter, um zu entscheiden, in welchem Modus gestartet werden soll. Für Bei Android 10-Geräten DARF der Bootloader NICHT den skip_initramfs an die Kernel-Befehlszeile. Stattdessen wird Bootloader sollte androidboot.force_normal_boot=1 übergeben, um die Wiederherstellung zu überspringen und das normale Android-Gerät starten. Geräte, die mit Android 12 auf den Markt gebracht werden oder höher muss bootconfig verwenden, um androidboot.force_normal_boot=1 zu übergeben.

AVB-Konfigurationsänderungen

<ph type="x-smartling-placeholder">

Wenn Sie Android Verifizierter Bootmodus 2.0, wenn das Gerät keine verkettete Partition verwendet Beschreibungen, ist keine Änderung erforderlich. Bei Verwendung von verketteten Eine der überprüften Partitionen ist dynamisch. sind Änderungen notwendig.

Hier ist eine Beispielkonfiguration für ein Gerät, das vbmeta für system und vendor Partitionen. 

BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1

Bei dieser Konfiguration erwartet der Bootloader, eine vbmeta zu finden. in der Fußzeile am Ende der system und vendor Partitionen. Da diese Partitionen nicht mehr für den Bootloader sichtbar (sie befinden sich in super), zwei Änderungen erforderlich sind.

  • vbmeta_system und vbmeta_vendor hinzufügen in die Partitionstabelle des Geräts ein. Fügen Sie für A/B-Geräte vbmeta_system_a, vbmeta_system_b, vbmeta_vendor_a und vbmeta_vendor_b. Wenn eine oder mehrere dieser Partitionen hinzufügen, als Partition vbmeta ein.
  • Benennen Sie die Konfigurations-Flags um, indem Sie VBMETA_ und geben Sie an, auf welche Partitionen die Verkettung erweitert wird: 
    BOARD_AVB_VBMETA_SYSTEM := system
BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VBMETA_VENDOR := vendor
BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1

Ein Gerät kann eine, beide oder keine dieser Partitionen verwenden. Änderungen die nur bei Verkettungen mit einer logischen Partition benötigt werden.

Änderungen am AVB-Bootloader

Wenn libavb im Bootloader eingebettet ist, enthalten die folgenden Patches:

Wenn Sie verkettete Partitionen verwenden, fügen Sie einen zusätzlichen Patch hinzu:

  • 49936b4c0109411fdd38bd4ba3a32a01c40439a9 – "libavb: Unterstützung für Vbmeta-BLOBs am Anfang der Partition." <ph type="x-smartling-placeholder">

Änderungen an der Kernel-Befehlszeile

Der neue Parameter androidboot.boot_devices muss hinzugefügt werden an die Kernel-Befehlszeile. Dies wird von init verwendet, um Symlinks vom Typ „/dev/block/by-name“ aktivieren. Es sollte die Gerätepfadkomponente zum zugrunde liegenden by-name-Symlink, der von ueventd, also: /dev/block/platform/device-path/by-name/partition-name. Bei Geräten, die mit Android 12 oder höher auf den Markt gebracht werden, muss bootconfig, um androidboot.boot_devices an init zu übergeben.

Wenn z. B. die Superpartition nach Name symlink lautet /dev/block/platform/soc/100000.ufshc/by-name/super, können Sie den Befehlszeilenparameter in der Datei BoardConfig.mk folgt: 

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
Sie können den Parameter bootconfig in der Datei BoardConfig.mk so hinzufügen: 
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

fstab-Änderungen

Die Gerätestruktur und die Overlays der Gerätestruktur dürfen fstab nicht enthalten Einträge. Verwenden Sie eine fstab-Datei, die Teil der Ramdisk sein wird.

Für logische Partitionen müssen Änderungen an der fstab-Datei vorgenommen werden:

  • Das Flags-Feld „fs_mgr“ muss das Flag logical enthalten und das Flag first_stage_mount, das im Android 10, was angibt, dass eine Partition in der ersten Phase bereitgestellt werden.
  • Eine Partition kann avb=vbmeta partition name als fs_mgr-Flag und dann die angegebene vbmeta Partition wird durch die erste Phase init initialisiert, bevor und versucht, Geräte bereitzustellen.
  • Das Feld dev muss den Partitionsnamen enthalten.

Durch die folgenden fstab-Einträge werden System, Anbieter und Produkt als logisch festgelegt wie oben beschrieben. 

#<dev>  <mnt_point> <type>  <mnt_flags options> <fs_mgr_flags>
system   /system     ext4    ro,barrier=1        wait,slotselect,avb=vbmeta,logical,first_stage_mount
vendor   /vendor     ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount
product  /product    ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount
<ph type="x-smartling-placeholder">

Kopieren Sie die fstab-Datei in die Ramdisk der ersten Phase.

SELinux-Änderungen

Das Superpartitions-Blockgerät muss mit dem Label gekennzeichnet sein super_block_device Wenn z. B. die Superpartition nach Name symlink lautet /dev/block/platform/soc/100000.ufshc/by-name/super, fügen Sie die folgende Zeile zu file_contexts hinzu: 

/dev/block/platform/soc/10000\.ufshc/by-name/super   u:object_r:super_block_device:s0

Fastbootd

Der Bootloader (oder ein Flash-Tool ohne Userspace) versteht die dynamische Partitionen, sodass sie nicht geflasht werden können. Um dieses Problem zu beheben, muss eine User-Space-Implementierung des Fastboot-Protokolls mit der Bezeichnung Fastbootd.

Weitere Informationen zum Implementieren von Fastbootd findest du unter Moving Fastboot to User Space.

ADB Remount

Für Entwickler, die eng- oder UserDebug-Builds verwenden, adb remount äußerst nützlich für eine schnelle Iteration. Dynamische Partitionen stellen eine Problem für adb remount, da kein kostenloser Speicherplatz mehr verfügbar ist Platz in jedem Dateisystem. Um dieses Problem zu beheben, können Geräte Overlayfs. Solange innerhalb der Super Partition kostenloser Platz ist, adb remount erstellt automatisch eine temporäre dynamische und verwendet Overlayfs für Schreibvorgänge. Die temporäre Partition namens scratch. Verwenden Sie diesen Namen daher nicht für andere Partitionen.

Weitere Informationen zum Aktivieren von „overlayfs“ finden Sie unter overlayfs README-Datei in AOSP.

Android-Geräte aktualisieren

Wenn du ein Gerät auf Android 10 aktualisierst und dynamische Partitionen in das OTA-Paket aufnehmen möchten, die integrierte Partitionstabelle ändern. Eine zusätzliche Konfiguration ist erforderlich.

Änderungen an der Gerätekonfiguration

Fügen Sie die folgenden Flags hinzu, um die dynamische Partitionierung nachzurüsten device.mk: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Änderungen der Board-Konfiguration

Sie müssen die folgenden Board-Variablen festlegen:

  • Liste der verwendeten blockierten Geräte für BOARD_SUPER_PARTITION_BLOCK_DEVICES festlegen um Dimensionen dynamischer Partitionen zu speichern. Dies ist die Liste der vorhandenen physischen auf dem Gerät.
  • BOARD_SUPER_PARTITION_partition_DEVICE_SIZE auf die Größen festlegen der einzelnen blockorientierten Geräte in BOARD_SUPER_PARTITION_BLOCK_DEVICES. Dies ist die Liste der Größen vorhandener physischer Partitionen auf dem Gerät. Dies ist normalerweise BOARD_partitionIMAGE_PARTITION_SIZE in vorhandenem Board Konfigurationen.
  • Festlegung vorhandener BOARD_partitionIMAGE_PARTITION_SIZE für alle aufheben Partitionen in BOARD_SUPER_PARTITION_BLOCK_DEVICES.
  • BOARD_SUPER_PARTITION_SIZE auf die Summe von festlegen BOARD_SUPER_PARTITION_partition_DEVICE_SIZE.
  • Setzen Sie BOARD_SUPER_PARTITION_METADATA_DEVICE auf das zu blockierende Gerät, dynamische Partitionsmetadaten gespeichert werden. Dies muss einer der folgenden Werte sein: BOARD_SUPER_PARTITION_BLOCK_DEVICES Normalerweise ist diese auf system
  • BOARD_SUPER_PARTITION_GROUPS festlegen, BOARD_group_SIZE und BOARD_group_PARTITION_LIST. Weitere Informationen finden Sie unter Änderungen an der Board-Konfiguration auf neuen Geräten .

Beispiel: Wenn das Gerät bereits System- und Anbieterpartitionen hat und Sie die zu dynamischen Partitionen hinzufügen und während des Updates eine neue Produktpartition hinzufügen, legen Sie diese Boardkonfiguration fest: 

BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor
BOARD_SUPER_PARTITION_METADATA_DEVICE := system

# Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE.
BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes>

# Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes>

# This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

# Configuration for dynamic partitions. For example:
BOARD_SUPER_PARTITION_GROUPS := group_foo
BOARD_GROUP_FOO_SIZE := <size-in-bytes>
BOARD_GROUP_FOO_PARTITION_LIST := system vendor product

SELinux-Änderungen

Die Superpartitions-Blockgeräte müssen mit dem Attribut gekennzeichnet sein super_block_device_type Wenn das Gerät z. B. bereits system- und vendor-Partitionen möchten Sie diese als Block verwenden. verwendet werden, um Bereiche dynamischer Partitionen zu speichern, und ihre Symlinks mit Namen sind als system_block_device: 

/dev/block/platform/soc/10000\.ufshc/by-name/system   u:object_r:system_block_device:s0
/dev/block/platform/soc/10000\.ufshc/by-name/vendor   u:object_r:system_block_device:s0

Fügen Sie dann die folgende Zeile in device.te ein: 

typeattribute system_block_device super_block_device_type;

Informationen zu anderen Konfigurationen finden Sie unter Implementieren dynamische Partitionen auf neuen Geräten

Weitere Informationen zu Nachrüstungsaktualisierungen finden Sie unter OTA für A/B-Geräte ohne dynamisches Partitionen.

Fabrikbilder

Vermeiden Sie bei Geräten, die mit Unterstützung für dynamische Partitionen gestartet werden, die Verwendung von Userspace fastboot zu Flash Factory Images, da das Starten im Userspace langsamer als andere Flash-Methoden.

Um dieses Problem zu beheben, erstellt make dist jetzt eine zusätzliche super.img-Bild, das direkt in den Superbereich geflasht werden kann -Partition an. Es bündelt automatisch den Inhalt logischer d. h. system.img, vendor.img usw., zusätzlich zu super Partitionsmetadaten. Dieses Image kann direkt in den super-Partition ohne zusätzliche Tools oder Fastbootd. Nach dem Build wird super.img im folgenden Verzeichnis platziert: ${ANDROID_PRODUCT_OUT}.

Für A/B-Geräte, die mit dynamischen Partitionen gestartet werden, super.img enthält Bilder im A-Slot. Nach dem Blinken der sollten Sie Slot A als bootfähig markieren, bevor Sie den .

Für Nachrüstgeräte stellt make dist eine Reihe von super_*.img Bilder, die direkt geflasht werden können, entsprechende physische Partitionen. Beispiel: make dist Builds super_system.img und super_vendor.img wenn das System BOARD_SUPER_PARTITION_BLOCK_DEVICES ist Zulieferunternehmen. Diese Bilder werden im OTA-Ordner unter target_files.zip

Abstimmung von Speichergeräten für Device Mapper

Die dynamische Partitionierung ermöglicht eine Reihe nicht deterministischer Device Mapper Objekte. Möglicherweise werden nicht alle wie erwartet instanziiert. Sie müssen daher alle Bereitstellungen erstellt und die Android-Attribute aller verknüpften Partitionen mit die zugrunde liegenden Speichergeräte.

Ein Mechanismus innerhalb von init verfolgt die Bereitstellungen asynchron aktualisiert die Android-Eigenschaften. Die dafür benötigte Zeit kann nicht garantiert werden. innerhalb eines bestimmten Zeitraums liegen. bis alle on property Trigger reagieren. Die Eigenschaften sind dev.mnt.blk.<partition>, wobei <partition> hat den Wert root, system, data oder vendor. Jede Property ist mit dem Name des Basisspeichergeräts, wie in diesen Beispielen gezeigt:

taimen:/ % getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [sda]
[dev.mnt.blk.firmware]: [sde]
[dev.mnt.blk.metadata]: [sde]
[dev.mnt.blk.persist]: [sda]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.vendor]: [dm-1]

blueline:/ $ getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [dm-4]
[dev.mnt.blk.metadata]: [sda]
[dev.mnt.blk.mnt.scratch]: [sda]
[dev.mnt.blk.mnt.vendor.persist]: [sdf]
[dev.mnt.blk.product]: [dm-2]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.system_ext]: [dm-3]
[dev.mnt.blk.vendor]: [dm-1]
[dev.mnt.blk.vendor.firmware_mnt]: [sda]

Mit der Sprache init.rc können die Android-Properties werden gemäß den Regeln erweitert und Speichergeräte können von der Plattform abgestimmt werden. mit Befehlen wie diesen:

write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128

Sobald die Befehlsverarbeitung in der zweiten Phase init beginnt, wird der Parameter epoll loop wird aktiv und die Werte werden aktualisiert. Sie können jedoch da Property-Trigger erst Ende init aktiv sind, können in den ersten Bootphasen nicht zur Verarbeitung von root verwendet werden. system oder vendor. Die Der Kernel-Standardwert read_ahead_kb ist ausreichend, bis der init.rc-Scripts können in early-fs überschrieben werden (wenn verschiedene Daemons und Einrichtungen starten. Daher empfiehlt Google, Sie die Funktion on property in Verbindung mit einem Über init.rc gesteuerte Property wie sys.read_ahead_kb, den zeitlichen Ablauf von Operationen abzuwickeln und Race-Bedingungen zu vermeiden, wie in diesen Beispiele:

on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on early-fs:
    setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048}

on property:sys.boot_completed=1
   setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}