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.
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.
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
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
undvbmeta_vendor
hinzufügen in die Partitionstabelle des Geräts ein. Fügen Sie für A/B-Gerätevbmeta_system_a
,vbmeta_system_b
,vbmeta_vendor_a
undvbmeta_vendor_b
. Wenn eine oder mehrere dieser Partitionen hinzufügen, als Partitionvbmeta
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:
- 818cf56740775446285466eda984acedd4baeac0 – "libavb: Partitions-GUIDs nur abfragen, wenn die cmdline benötigt wird .“
- 5abd6bc2578968d24406d834471adfd995a0c2e9 – "Allow system partition to be missing" (Systempartition darf nicht vorhanden sein)
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 – "Fix AvbSlotVerifyData->cmdline may be NULL"
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.ufshcSie 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 Flagfirst_stage_mount
, das im Android 10, was angibt, dass eine Partition in der ersten Phase bereitgestellt werden. -
Eine Partition kann
avb=vbmeta partition name
alsfs_mgr
-Flag und dann die angegebenevbmeta
Partition wird durch die erste Phaseinit
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 inBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Dies ist die Liste der Größen vorhandener physischer Partitionen auf dem Gerät. Dies ist normalerweiseBOARD_partitionIMAGE_PARTITION_SIZE
in vorhandenem Board Konfigurationen.- Festlegung vorhandener
BOARD_partitionIMAGE_PARTITION_SIZE
für alle aufheben Partitionen inBOARD_SUPER_PARTITION_BLOCK_DEVICES
. BOARD_SUPER_PARTITION_SIZE
auf die Summe von festlegenBOARD_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 aufsystem
BOARD_SUPER_PARTITION_GROUPS
festlegen,BOARD_group_SIZE
undBOARD_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}