Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

OTA-Aktualisierung für A/B-Geräte ohne dynamische Partitionen

Android 10 unterstützt dynamische Partitionen, ein Partitionssystem im Userspace, mit dem Partitionen während Over-the-air-Updates (OTA) erstellt, neu formatiert und gelöscht werden können.

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 unter system_a und system_b gespeichert. Das kann aber angepasst werden, indem BOARD_SUPER_PARTITION_METADATA_DEVICE geändert wird.

Auf jedem der blockorientierten Geräte gibt es zwei Metadaten-Slots. Pro Blockgerät wird nur ein Metadaten-Steckplatz verwendet. Beispiel: „Metadaten 0“ bei system_a und „Metadaten 1“ bei system_b entsprechen beispielsweise Partitionen in den Slots A und B. Bei der Laufzeit spielt es keine Rolle, welcher Steckplatz aktualisiert wird.

Auf dieser Seite werden die Metadatenslots als „Metadaten S“ (Quelle) und „Metadaten T“ (Ziel) bezeichnet. Partitionen werden ebenfalls als system_s, vendor_t usw. bezeichnet.

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.

Beispiele 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, die von Foo aktualisiert wurden
  - Gruppe bar_a
    - Logische (dynamische) Partition vendor_a
    - Logische (dynamische) Partition product_a
    - Andere Partitionen, die von Bar aktualisiert wurden
- Metadaten 1 (nicht verwendet)
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, die von Foo aktualisiert wurden
  - Gruppe „bar_b“
    - Logische (dynamische) Partition vendor_b
    - Logische (dynamische) Partition product_b
    - Andere Partitionen, die von Bar aktualisiert wurden

Mit dem lpdump-Tool unter system/extras/partition_tools können Sie die Metadaten auf Ihr Gerät übertragen. 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 heißen super_system.img, super_vendor.img usw. Der OTA-Client wendet diese Images auf die physischen Partitionen an, anstatt sie auf 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 Updateablauf ist mit dem von Android 9 identisch.

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

Kü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.
1. Neue Metadaten M aus Metadaten S (Quellmetadaten) erstellen. Wenn in den Metadaten S beispielsweise [system_s, vendor_s, product_s] als blockierte Geräte verwendet werden, werden in den neuen Metadaten M [system_t, vendor_t, product_t] als blockierte Geräte verwendet. Alle Gruppen und Partitionen werden in M verworfen.
2. Fügen Sie Zielgruppen und Partitionen gemäß dem Feld dynamic_partition_metadata im Aktualisierungsmanifest hinzu. Die Größe der einzelnen Partitionen finden Sie unter new_partition_info.
3. Schreibe M in das Metadaten-Feld T.
4. Ordnen Sie die hinzugefügten Partitionen im Geräte-Mapper als beschreibbar zu.
Wenden Sie das Update auf die Blockgeräte an.
1. Weisen Sie die Quellpartitionen bei Bedarf dem Geräte-Mapper als schreibgeschützt zu. Dies ist für das Sideloading erforderlich, da die Quellpartitionen vor dem Update nicht zugeordnet werden.
2. Vollständige oder Delta-Updates auf alle Blockgeräte im Ziel-Steckplatz anwenden
3. Sie müssen die Partitionen bereitstellen, um das Skript nach der Installation auszuführen, und sie dann wieder trennen.
Entfernen Sie die Zuordnung der Zielpartitionen.

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 Ablauf der Aktualisierung ähnelt dem einer Nachrüstung. Weitere Informationen finden Sie unter Update nachträglich einspielen.

Angenommen, Sie haben Folgendes festgelegt:

Steckplatz A ist der aktive Steckplatz.
system_a enthält die aktiven Metadaten in Steckplatz 0.
system_a, vendor_a und product_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.

Update-Pakete generieren

Inkrementelle OTA-Updates

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 geteilte Datei 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. Der Schritt nach der Installation kann aktiviert werden.

Vollständiges OTA

Für Nachrüstgeräte werden zwei vollständige OTA-Pakete generiert.

$(PRODUCT)-ota-retrofit-$(TAG).zip enthält immer den Split super.img und deaktiviert den Schritt nach der Installation für das Nachrüstupdate.
- Er wird mit einem zusätzlichen Argument --retrofit_dynamic_partitions für das ota_from_target_files-Script generiert.
- Sie kann auf alle Builds angewendet werden.
$(PRODUCT)-ota-$(TAG).zip enthält logische Bilder für zukünftige Updates.
- Diese Option gilt nur für Builds mit aktivierten dynamischen Partitionen. Weitere Informationen zur Durchsetzung dieser Richtlinie finden Sie unten.

Nicht nachrüstbares Update 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 sendet, können die Geräte nicht gestartet werden. 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.

Damit das Gerät das vollständige OTA-Paket nicht akzeptiert, können Sie einen Schritt nach der Installation zur Überprüfung der vorhandenen Gerätekonfiguration anfordern. 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 angewendet wird, ohne dass dynamische Partitionen aktiviert sind, führt der OTA-Client check_dynamic_partitions als Schritt nach der Installation aus und lehnt das Update ab.