Android 10 unterstützt dynamische Partitionen , ein Userspace-Partitionierungssystem, das bei Over-the-Air-Updates (OTA) Partitionen erstellen, in der Größe ändern 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 dynamischer Partitionen gestartet wurden, und wie OTA-Clients ein Upgrade auf Android 10 durchführen.
Hintergrund
Während einer Aktualisierung eines A/B-Geräts zur Unterstützung dynamischer Partitionen bleibt die GUID-Partitionstabelle (GPT) auf dem Gerät erhalten, sodass es keine super
auf dem Gerät gibt. Metadaten werden unter system_a
und system_b
gespeichert, dies kann jedoch durch Ändern BOARD_SUPER_PARTITION_METADATA_DEVICE
angepasst werden.
In jedem der Blockgeräte gibt es zwei Metadaten-Slots. Es wird nur ein Metadaten-Slot in jedem Blockgerät verwendet. Beispielsweise entsprechen Metadaten 0 bei system_a
und Metadaten 1 bei system_b
den Partitionen an den Steckplätzen A bzw. B. Zur Laufzeit spielt es keine Rolle, welcher Slot aktualisiert wird.
Auf dieser Seite werden die Metadaten-Slots als Metadata S (Quelle) und Metadata T (Ziel) bezeichnet. Ebenso werden Partitionen als system_s
, vendor_t
usw. bezeichnet.
Weitere Informationen zu Build-Systemkonfigurationen finden Sie unter Geräte aktualisieren .
Weitere Informationen darüber, wie Partitionen zu Update-Gruppen gehören, finden Sie unter Änderungen der Board-Konfiguration für neue Geräte.
Ein Beispiel für Metadaten auf einem Gerät ist:
- Physisches Blockgerät
system_a
- Metadaten 0
- Gruppe
foo_a
- Logisches (dynamisches)
system_a
- Logische (dynamische) Partition
product_services_a
- Andere von Foo aktualisierte Partitionen
- Logisches (dynamisches)
- Gruppe
bar_a
- Logische (dynamische) Partition
vendor_a
- Logische (dynamische) Partition
product_a
- Andere von Bar aktualisierte Partitionen
- Logische (dynamische) Partition
- Gruppe
- Metadaten 1 (nicht verwendet)
- Metadaten 0
- Physisches Blockgerät
system_b
- Metadaten 0 (nicht verwendet)
- Metadaten 1
- Gruppe foo_b
- Logisches (dynamisches)
system_b
- Logische (dynamische) Partition
product_services_b
- Andere von Foo aktualisierte Partitionen
- Logisches (dynamisches)
- Gruppe bar_b
- Logische (dynamische) Partition
vendor_b
- Logische (dynamische) Partition
product_b
- Andere von Bar aktualisierte Partitionen
- Logische (dynamische) Partition
- Gruppe foo_b
Sie können das Tool lpdump
unter system/extras/partition_tools
verwenden, um die Metadaten auf Ihrem Gerät zu sichern. Zum Beispiel:
lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b
Ein Update nachrüsten
Auf Geräten mit Android 9 und niedriger unterstützt der OTA-Client auf dem Gerät die Zuordnung dynamischer Partitionen vor dem Update nicht. Es wird ein zusätzlicher Satz Patches erstellt, sodass 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 entsprechend System, Anbieter usw. entsprechen. Diese Bilder heißen super_system.img
, super_vendor.img
usw. Der OTA-Client wendet diese Images auf die physischen Partitionen an, anstatt die Images für die logischen (dynamischen) Partitionen anzuwenden.
Da der OTA-Client nicht weiß, wie er dynamische Partitionen zuordnet, werden alle Schritte nach der Installation für diese Partitionen automatisch deaktiviert, wenn das Update-Paket generiert wird. Weitere Einzelheiten finden Sie unter Konfigurieren nach der Installation .
Der Update-Ablauf ist der gleiche wie in 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 Retrofit-Update wird der OTA-Client aktualisiert, um mit dynamischen Partitionen zu arbeiten. Die Bereiche für Quellpartitionen erstrecken sich niemals über physische Zielpartitionen.
Update-Ablauf mit einem regulären Update-Paket
- Initialisieren Sie die Metadaten der
super
.- Konstruieren Sie neue Metadaten M aus Metadaten S (Quellmetadaten). Wenn beispielsweise Metadaten S [
system_s
,vendor_s
,product_s
] als Blockgeräte verwenden, dann verwendet das neue Metadaten M [system_t
,vendor_t
,product_t
] als Blockgeräte. Alle Gruppen und Partitionen werden in M verworfen. - Fügen Sie Zielgruppen und Partitionen entsprechend dem Feld
dynamic_partition_metadata
im Update-Manifest hinzu. 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.
- Konstruieren Sie neue Metadaten M aus Metadaten S (Quellmetadaten). Wenn beispielsweise Metadaten S [
- Wenden Sie das Update auf den Blockgeräten an.
- Ordnen Sie bei Bedarf die Quellpartitionen im Geräte-Mapper als schreibgeschützt zu. Dies ist für das Querladen erforderlich, da die Quellpartitionen vor dem Update nicht zugeordnet werden.
- Wenden Sie ein vollständiges oder Delta-Update auf alle Blockgeräte im Zielsteckplatz an.
- Hängen Sie die Partitionen ein, um das Nachinstallationsskript auszuführen, und heben Sie dann die Bereitstellung der Partitionen auf.
- Heben Sie die Zuordnung der Zielpartitionen auf.
Update-Ablauf mit einem Retrofit-Update-Paket
Wenn das Retrofit-Update-Paket auf einem Gerät angewendet wird, das bereits dynamische Partitionen ermöglicht, wendet der OTA-Client die geteilte super.img
Datei direkt auf Blockgeräte an. Der Update-Ablauf ähnelt einem Retrofit-Update. Weitere Informationen finden Sie unter Nachrüsten eines Updates .
Gehen Sie beispielsweise von Folgendem aus:
- Steckplatz A ist der aktive Steckplatz.
-
system_a
enthält die aktiven Metadaten in Slot 0. -
system_a
,vendor_a
undproduct_a
werden als Blockgeräte verwendet.
Wenn der OTA-Client ein Retrofit-Update-Paket erhält, wendet er super_system.img
auf das physische system_b
, super_vendor.img
auf das physische vendor_b
und super_product.img
auf das physische product_b
an. Das physische Blockgerät system_b
enthält die richtigen Metadaten, um die logischen system_b
, vendor_b
und product_b
beim Booten abzubilden.
Generieren Sie Update-Pakete
Inkrementeller OTA
Beim Generieren inkrementeller OTAs für Nachrüstgeräte hängen die Aktualisierungen davon ab, ob der Basis-Build PRODUCT_USE_DYNAMIC_PARTITIONS
und PRODUCT_RETROFIT_DYNAMIC_PARTITIONS
definiert oder nicht.
- Wenn der Basis-Build die Variablen nicht definiert, handelt es sich um ein Retrofit-Update. Das Update-Paket enthält die geteilte
super.img
Datei und deaktiviert den Schritt nach der Installation. - Wenn der Basis-Build die Variablen definiert , entspricht dies einem typischen Update mit dynamischen Partitionen. Das Update-Paket enthält die Images für logische (dynamische) Partitionen. Der Post-Install-Schritt kann aktiviert werden.
Vollständiger OTA
Für Nachrüstgeräte werden zwei vollständige OTA-Pakete generiert.
-
$(PRODUCT)-ota-retrofit-$(TAG).zip
enthält immer Splitsuper.img
und deaktiviert den Post-Install-Schritt für die Nachrüstung von Updates.- Es wird mit einem zusätzlichen Argument
--retrofit_dynamic_partitions
zum Skriptota_from_target_files
generiert. - Es kann auf alle Builds angewendet werden.
- Es wird mit einem zusätzlichen Argument
-
$(PRODUCT)-ota-$(TAG).zip
enthält logische Bilder für zukünftige Updates.- Wenden Sie dies nur auf Builds mit aktivierten dynamischen Partitionen an. Weitere Informationen zur Durchsetzung finden Sie weiter unten.
Nicht nachrüstbare Updates für alte Builds ablehnen
Wenden Sie das reguläre vollständige OTA-Paket nur auf Builds mit aktivierten dynamischen Partitionen an. Wenn der OTA-Server falsch konfiguriert ist und diese Pakete an Geräte mit Android 9 oder niedriger weiterleitet, können die Geräte nicht gestartet werden. Der OTA-Client auf Android 9 und niedriger kann den Unterschied zwischen einem Retrofit-OTA-Paket und einem regulären vollständigen OTA-Paket nicht erkennen, sodass der Client das vollständige Paket nicht ablehnt.
Um zu verhindern, dass das Gerät das vollständige OTA-Paket akzeptiert, können Sie einen Schritt nach der Installation anfordern, um die vorhandene Gerätekonfiguration zu überprüfen. Zum 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 aktivierte dynamische Partitionen angewendet wird, führt der OTA-Client check_dynamic_partitions
als Nachinstallationsschritt aus und lehnt die Aktualisierung ab.