Unterstützung für Android 10 dynamische Partitionen, eine Partitionierung im Nutzerbereich System, das während OTA-Updates (Over The Air) Partitionen erstellen, in der Größe anpassen und zerstören kann.
Auf dieser Seite wird beschrieben, wie OTA-Clients die Größe dynamischer Partitionen während eines Updates für A/B-Geräte ändern, die ohne Unterstützung für dynamische Partitionen eingeführt wurden, und wie OTA-Clients auf Android 10 umstellen.
Hintergrund
Bei der Aktualisierung eines A/B-Geräts zur Unterstützung dynamischer Partitionen wird die GUID-Partitionstabelle (GPT) auf dem Gerät beibehalten. Es gibt also keine super
-Partition auf dem Gerät. Metadaten werden gespeichert unter
system_a
und system_b
, aber dieser kann
durch Ändern von BOARD_SUPER_PARTITION_METADATA_DEVICE
angepasst.
Auf jedem der blockorientierten Geräte gibt es zwei Metadaten-Slots. Nur eine
in jedem Blockgerät verwendet wird. Beispiel: Metadaten 0 bei
system_a
und Metadaten 1 unter system_b
den Partitionen an den A- bzw. B-Slots entsprechen. Bei
egal, welcher Slot aktualisiert wird.
Auf dieser Seite werden die Metadatenslots als „Metadaten S“ (Quelle) und „Metadaten T“ (Ziel) bezeichnet. In ähnlicher Weise wird auf Partitionen verwiesen,
als system_s
, vendor_t
usw.
Weitere Informationen zu Buildsystemkonfigurationen finden Sie unter Geräte aktualisieren.
Weitere Informationen dazu, wie Partitionen zu Aktualisierungsgruppen gehören, finden Sie unter Board-Konfigurationsänderungen für neue Geräte.
Hier ein Beispiel für Metadaten auf einem Gerät:
- Physisches Blockgerät
system_a
- Metadaten 0
- Gruppe
foo_a
- Logische (dynamische) Partition
system_a
- Logische (dynamische) Partition
product_services_a
- Andere Partitionen von Foo aktualisiert
- Logische (dynamische) Partition
- Gruppe
bar_a
- Logische (dynamische) Partition
vendor_a
- Logische (dynamische) Partition
product_a
- Andere Partitionen aktualisiert durch Bar
- Logische (dynamische) Partition
- Gruppe
- Metadaten 1 (nicht verwendet)
- Metadaten 0
- Physisches Blockgerät
system_b
- Metadaten 0 (nicht verwendet)
- Metadaten 1
- Gruppe foo_b
- Logische (dynamische) Partition
system_b
- Logische (dynamische) Partition
product_services_b
- Andere Partitionen von Foo aktualisiert
- Logische (dynamische) Partition
- Gruppe bar_b
- Logische (dynamische) Partition
vendor_b
- Logische (dynamische) Partition
product_b
- Andere Partitionen, die von Bar aktualisiert wurden
- Logische (dynamische) Partition
- Gruppe foo_b
Sie können das lpdump
-Tool unter
system/extras/partition_tools
zum Dump der Metadaten auf
auf deinem Gerät. Beispiel:
lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b
Update nachrüsten
Auf Geräten mit Android 9 oder niedriger unterstützt der OTA-Client auf dem Gerät nicht die Zuordnung dynamischer Partitionen vor dem Update. Es werden zusätzliche Patches erstellt, damit die Zuordnung direkt auf die vorhandenen physischen Partitionen angewendet werden kann.
Der OTA-Generator erstellt die endgültige super.img
-Datei, die den Inhalt aller dynamischen Partitionen enthält, und teilt das Image dann in mehrere Images auf, die den Größen der physischen Blockgeräte entsprechen, die dem System, dem Anbieter usw. entsprechen. Diese Bilder haben den Namen
super_system.img
, super_vendor.img
usw.
Der OTA-Client wendet diese Images auf die physischen Partitionen an,
als die Images für die logischen (dynamischen) Partitionen anzuwenden.
Da der OTA-Client nicht weiß, wie dynamische Partitionen zugeordnet werden, werden alle Schritte nach der Installation für diese Partitionen beim Generieren des Update-Pakets automatisch deaktiviert. Weitere Informationen finden Sie unter Konfiguration nach der Installation.
Der Aktualisierungsablauf ist derselbe wie bei Android 9.
Vor dem Update:
ro.boot.dynamic_partitions= ro.boot.dynamic_partitions_retrofit=
Nach dem Update:
ro.boot.dynamic_partitions=true ro.boot.dynamic_partitions_retrofit=true
Zukünftige Updates nach der Nachrüstung
Nach dem Nachrüstupdate wird der OTA-Client für die Verwendung mit dynamischen Partitionen aktualisiert. Die Extents für Quellpartitionen erstrecken sich niemals über physische Zielpartitionen.
Aktualisierung mit einem regulären Update-Paket
- Initialisieren Sie die
super
-Partitionsmetadaten.-
Neue Metadaten M aus Metadaten S (Quellmetadaten) konstruieren.
Wenn Metadaten S beispielsweise [
system_s
,vendor_s
,product_s
] als Block verwendet das neue Metadaten-M [system_t
,vendor_t
,product_t
] als Block Geräte. Alle Gruppen und Partitionen werden in M verworfen. -
Fügen Sie im Aktualisierungsmanifest im Feld
dynamic_partition_metadata
Zielgruppen und Partitionen hinzu. Die Größe der einzelnen Partitionen finden Sie unternew_partition_info
. - Schreibe M in das Metadaten-Feld T.
- Ordnen Sie die hinzugefügten Partitionen im Device Mapper als beschreibbar zu.
-
Neue Metadaten M aus Metadaten S (Quellmetadaten) konstruieren.
Wenn Metadaten S beispielsweise [
- Wenden Sie das Update auf die Blockgeräte an.
- Ordnen Sie bei Bedarf die Quellpartitionen im Device Mapper zu schreibgeschützt sein. Dies ist für das Sideloading erforderlich, da die Quellpartitionen vor dem Update nicht zugeordnet werden.
- Vollständige oder Delta-Updates auf alle Blockgeräte im Ziel-Steckplatz anwenden
- Sie müssen die Partitionen bereitstellen, um das Skript nach der Installation auszuführen, und sie dann wieder trennen.
- Heben Sie die Zuordnung der Zielpartitionen auf.
Aktualisierungsablauf mit einem Retrofit-Aktualisierungspaket
Wenn das Update-Paket für die Nachrüstung auf einem Gerät angewendet wird, auf dem bereits dynamische Partitionen aktiviert sind, wendet der OTA-Client die geteilte super.img
-Datei direkt auf Blockgeräte an. Der Aktualisierungsvorgang ähnelt dem einer Nachrüstung. Weitere Informationen finden Sie unter
Update zurückstellen
.
Nehmen wir beispielsweise Folgendes an:
- Steckplatz A ist der aktive Steckplatz.
-
system_a
enthält die aktiven Metadaten in Steckplatz 0. -
system_a
,vendor_a
undproduct_a
werden als Blockgeräte verwendet.
Wenn der OTA-Client ein Update-Paket für die Nachrüstung empfängt, wird super_system.img
auf physischen system_b
, super_vendor.img
auf physischen vendor_b
und super_product.img
auf physischen product_b
angewendet.
Das physische Blockgerät system_b
enthält die richtigen Metadaten, um die logischen Laufwerke system_b
, vendor_b
und product_b
beim Starten zuzuordnen.
Aktualisierungspakete generieren
Inkrementelle OTA-Datei
Beim Generieren inkrementeller OTAs für Nachrüstgeräte hängen die Updates davon ab, ob PRODUCT_USE_DYNAMIC_PARTITIONS
und PRODUCT_RETROFIT_DYNAMIC_PARTITIONS
im Basisbuild definiert sind.
-
Wenn die Variablen im Basis-Build nicht definiert sind, handelt es sich um ein Nachrüst-Update. Das Update-Paket enthält die Aufteilung.
super.img
und deaktiviert den Schritt nach der Installation. - Wenn die Variablen im Basis-Build definiert sind, entspricht dies einem normalen Update mit dynamischen Partitionen. Das Update-Paket enthält die Images für logische (dynamische) Partitionen. Die nach der Installation aktiviert werden.
Vollständiges Onlinereisebüro
Für Nachrüstgeräte werden zwei vollständige OTA-Pakete generiert.
-
$(PRODUCT)-ota-retrofit-$(TAG).zip
enthält immer Aufteilen vonsuper.img
und Deaktivierung des Schritts nach der Installation für die Nachrüstung.-
Sie wird mit einem zusätzlichen Argument generiert.
--retrofit_dynamic_partitions
in denota_from_target_files
-Script. - Es kann auf alle Builds angewendet werden.
-
Sie wird mit einem zusätzlichen Argument generiert.
-
$(PRODUCT)-ota-$(TAG).zip
enthält logische Bilder für zukünftige Updates.- Nur auf Builds mit dynamischen Partitionen anwenden aktiviert. Weitere Informationen zur Durchsetzung dieser Richtlinie finden Sie unten.
Nicht rückwirkende Aktualisierung bei alten Builds ablehnen
Wenden Sie das reguläre vollständige OTA-Paket nur auf Builds mit aktivierten dynamischen Partitionen an. Wenn der OTA-Server konfiguriert ist fehlerhaft ist, und überträgt diese Pakete auf Geräte mit Android 9 oder und Geräte starten nicht. Der OTA-Client unter Android 9 und niedriger kann keinen Unterschied zwischen einem Retrofit-OTA-Paket und einem regulären vollständigen OTA-Paket erkennen. Daher lehnt der Client das vollständige Paket nicht ab.
Um zu verhindern, dass das Gerät das vollständige OTA-Paket akzeptiert, kannst du erfordern einen Schritt nach der Installation, um das vorhandene Gerät zu prüfen. Konfiguration. Beispiel:
device/device_name/dynamic_partitions/check_dynamic_partitions
#!/system/bin/sh DP_PROPERTY_NAME="ro.boot.dynamic_partitions" DP_RETROFIT_PROPERTY_NAME="ro.boot.dynamic_partitions_retrofit" DP_PROPERTY=$(getprop ${DP_PROPERTY_NAME}) DP_RETROFIT_PROPERTY=$(getprop ${DP_RETROFIT_PROPERTY_NAME}) if [ "${DP_PROPERTY}" != "true" ] || [ "${DP_RETROFIT_PROPERTY}" != "true" ] ; then echo "Error: applied non-retrofit update on build without dynamic" \ "partitions." echo "${DP_PROPERTY_NAME}=${DP_PROPERTY}" echo "${DP_RETROFIT_PROPERTY_NAME}=${DP_RETROFIT_PROPERTY}" exit 1 fi
device/device_name/dynamic_partitions/Android.mk
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE:= check_dynamic_partitions LOCAL_MODULE_TAGS := optional LOCAL_MODULE_CLASS := EXECUTABLES LOCAL_SRC_FILES := check_dynamic_partitions LOCAL_PRODUCT_MODULE := true include $(BUILD_PREBUILT)
device/device_name/device.mk
PRODUCT_PACKAGES += check_dynamic_partitions # OPTIONAL=false so that the error in check_dynamic_partitions will be # propagated to OTA client. AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_product=true \ POSTINSTALL_PATH_product=bin/check_dynamic_partitions \ FILESYSTEM_TYPE_product=ext4 \ POSTINSTALL_OPTIONAL_product=false \
Wenn das reguläre OTA-Paket auf einem Gerät ohne dynamische
Partitionen aktiviert sind, wird der OTA-Client ausgeführt.
check_dynamic_partitions
als Schritt nach der Installation und
lehnt das Update ab.