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

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
      • Gruppe bar_a
        • Logische (dynamische) Partition vendor_a
        • Logische (dynamische) Partition product_a
        • Andere von Bar aktualisierte Partitionen
    • Metadaten 1 (nicht verwendet)
  • 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
      • Gruppe bar_b
        • Logische (dynamische) Partition vendor_b
        • Logische (dynamische) Partition product_b
        • Andere von Bar aktualisierte Partitionen

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

  1. Initialisieren Sie die Metadaten der super .
    1. 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.
    2. Fügen Sie Zielgruppen und Partitionen entsprechend dem Feld dynamic_partition_metadata im Update-Manifest hinzu. Die Größe jeder Partition finden Sie in new_partition_info .
    3. Schreiben Sie M in Metadaten T.
    4. Ordnen Sie die hinzugefügten Partitionen im Device Mapper als beschreibbar zu.
  2. Wenden Sie das Update auf den Blockgeräten an.
    1. 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.
    2. Wenden Sie ein vollständiges oder Delta-Update auf alle Blockgeräte im Zielsteckplatz an.
    3. Hängen Sie die Partitionen ein, um das Nachinstallationsskript auszuführen, und heben Sie dann die Bereitstellung der Partitionen auf.
  3. 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 und product_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 Split super.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 Skript ota_from_target_files generiert.
    • Es kann auf alle Builds angewendet werden.
  • $(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.