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 anpassen. die ohne Unterstützung dynamischer Partitionen gestartet wurde, und wie OTA-Clients ein Upgrade auf Android 10 durchführen.
Hintergrund
Während der Aktualisierung eines A/B-Geräts, um dynamische Partitionen zu unterstützen,
Die GUID-Partitionstabelle (GPT) auf dem Gerät wird beibehalten,
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 Blockgeräte gibt es zwei Metadatenbereiche. Nur eine
in jedem Blockgerät
verwendet werden. Beispiel: Metadaten 0 bei
system_a
und Metadaten 1 unter system_b
den Partitionen an den A- und B-Slots entsprechen. Bei
egal, welcher Slot aktualisiert wird.
Auf dieser Seite werden die Metadaten-Flächen als „Metadaten S“ bezeichnet.
(Quelle) und Metadaten T (Ziel). In ähnlicher Weise wird auf Partitionen verwiesen,
als system_s
, vendor_t
usw.
Weitere Informationen zu Build-Systemkonfigurationen finden Sie unter Upgrade für Geräte ausführen.
Weitere Informationen dazu, wie Partitionen zu update Gruppen finden Sie unter Brett Konfigurationsänderungen für neue Geräte.
Hier ein Beispiel für Metadaten auf einem Gerät:
- Physisches Blockgerät
system_a
<ph type="x-smartling-placeholder">- </ph>
- Metadaten 0
<ph type="x-smartling-placeholder">
- </ph>
- Gruppe
foo_a
<ph type="x-smartling-placeholder">- </ph>
- Logische (dynamische) Partition
system_a
- Logische (dynamische) Partition
product_services_a
- Andere Partitionen von Foo aktualisiert
- Logische (dynamische) Partition
- Gruppe
bar_a
<ph type="x-smartling-placeholder">- </ph>
- 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
<ph type="x-smartling-placeholder">
- Physisches Blockgerät
system_b
<ph type="x-smartling-placeholder">- </ph>
- Metadaten 0 (nicht verwendet)
- Metadaten 1
<ph type="x-smartling-placeholder">
- </ph>
- Gruppe foo_b
<ph type="x-smartling-placeholder">
- </ph>
- Logische (dynamische) Partition
system_b
- Logische (dynamische) Partition
product_services_b
- Andere Partitionen von Foo aktualisiert
- Logische (dynamische) Partition
- Gruppe bar_b
<ph type="x-smartling-placeholder">
- </ph>
- Logische (dynamische) Partition
vendor_b
- Logische (dynamische) Partition
product_b
- Andere Partitionen aktualisiert durch Bar
- Logische (dynamische) Partition
- Gruppe foo_b
<ph type="x-smartling-placeholder">
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 und niedriger: der OTA-Client auf dem Gerät unterstützt die Zuordnung dynamischer Partitionen vor der Aktualisierung nicht. Eine Es werden zusätzliche Patches erstellt, sodass die Zuordnung angewendet werden kann. direkt mit den vorhandenen physischen Partitionen.
Der OTA-Generator erstellt die endgültige super.img
-Datei, die
enthält den Inhalt aller dynamischen Partitionen und teilt dann das Image
in mehrere Bilder aufgeteilt, die den Größen der physischen Blockgeräte entsprechen
System, 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.
Da der OTA-Client nicht weiß, wie dynamische Partitionen zugeordnet werden, Alle Schritte nach der Installation werden für diese Partitionen automatisch deaktiviert wenn das Update-Paket generiert wird. Weitere Informationen finden Sie unter Nach der Installation konfigurieren .
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 der Nachrüstungsaktualisierung wird der OTA-Client aktualisiert, damit er mit dynamische Partitionen. Die Erweiterungen für Quellpartitionen erstrecken sich niemals für physische Zielpartitionen.
Ablauf mit einem regulären Updatepaket aktualisieren
- Initialisieren Sie die Metadaten der Partition
super
.-
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 Zielgruppen und Partitionen gemäß
Feld „
dynamic_partition_metadata
“ beim Update Manifests. Die Größe jeder Partition finden Sie innew_partition_info
- Schreiben Sie M in Metadaten 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 den blockierten Geräten an.
- Ordnen Sie bei Bedarf die Quellpartitionen im Device Mapper zu schreibgeschützt sein. Dies ist für das Sideloading erforderlich, Quellpartitionen wurden vor der Aktualisierung nicht zugeordnet.
- Wenden Sie ein vollständiges oder Delta-Update auf alle blockorientierten Geräte an der Zielslot.
- Stellen Sie die Partitionen bereit, um das Skript nach der Installation auszuführen. trennen Sie die Partitionen.
- Heben Sie die Zuordnung der Zielpartitionen auf.
Ablauf mit einem Retrofit-Updatepaket aktualisieren
Wenn das Retrofit-Update-Paket auf ein Gerät angewendet wird, das bereits
dynamische Partitionen aktiviert, der OTA-Client wendet die Aufteilung
super.img
-Datei direkt auf blockorientierten Geräten. Das Update
einer Nachrüstungsaktualisierung ähnelt. Weitere Informationen finden Sie unter
Update zurückstellen
.
Nehmen wir zum Beispiel Folgendes an:
- Anzeigenfläche A ist die aktive Anzeigenfläche.
-
system_a
enthält die aktiven Metadaten in Slot 0. -
system_a
,vendor_a
undproduct_a
werden als blockorientierte Geräte verwendet.
Wenn der OTA-Client ein Nachrüst-Update-Paket erhält, wird es angewendet.
super_system.img
am system_b
,
super_vendor.img
auf physischer vendor_b
und
super_product.img
am product_b
.
Das physische Blockgerät „system_b
“ enthält das richtige
Metadaten zum Zuordnen des logischen system_b
,
vendor_b
und product_b
beim Booten.
Aktualisierungspakete generieren
Inkrementelles OTA
Bei der Generierung inkrementeller OTAs für Nachrüstgeräte werden die Updates
hängt davon ab, ob der Basis-Build definiert
PRODUCT_USE_DYNAMIC_PARTITIONS
und
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS
.
-
Wenn der Basis-Build die Variablen nicht definiert, ist dies ein
der Nachrüstung aktualisiert. Das Update-Paket enthält die Aufteilung.
super.img
und deaktiviert den Schritt nach der Installation. - Wenn der Basis-Build die Variablen definiert, entspricht dies einem Aktualisierung 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 Images für Benachrichtigungen zu erhalten.- Nur auf Builds mit dynamischen Partitionen anwenden aktiviert. Weitere Informationen zur Erzwingung finden Sie weiter unten.
Nicht rückwirkende Aktualisierung bei alten Builds ablehnen
Reguläres vollständiges OTA-Paket nur auf Builds anwenden mit dynamische Partitionen aktiviert. Wenn der OTA-Server konfiguriert ist fehlerhaft ist, und überträgt diese Pakete an Geräte mit Android 9 oder und Geräte starten nicht. Der OTA-Client unter Android 9 und kann keinen Unterschied zwischen einem nachrüstbaren OTA-Paket und einem reguläres, vollständiges OTA-Paket, damit der Client das vollständige Paket nicht ablehnt.
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.