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

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Android 10 unterstützt dynamische Partitionen , ein Userspace-Partitionierungssystem, das während 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 auf Android 10 aktualisieren.

Hintergrund

Während einer Aktualisierung eines A/B-Geräts zur Unterstützung dynamischer Partitionen wird die GUID-Partitionstabelle (GPT) auf dem Gerät beibehalten, sodass auf dem Gerät keine super vorhanden ist. Metadaten werden unter system_a und system_b gespeichert, dies kann jedoch angepasst werden, indem BOARD_SUPER_PARTITION_METADATA_DEVICE .

In jedem der Blockgeräte gibt es zwei Metadaten-Slots. Es wird nur ein Metadaten-Slot in jedem Blockgerät verwendet. Zum Beispiel entsprechen Metadaten 0 bei system_a und Metadaten 1 bei system_b den Partitionen an den Slots A und B. Zur Laufzeit spielt es keine Rolle, welcher Slot aktualisiert wird.

Auf dieser Seite heißen die Metadaten-Slots Metadaten S (Quelle) und Metadaten T (Ziel). Auf ähnliche Weise werden Partitionen als system_s , vendor_t usw. bezeichnet.

Weitere Informationen zu Buildsystemkonfigurationen finden Sie unter Upgrade von Geräten .

Weitere Informationen darüber, wie Partitionen zu Aktualisierungsgruppen gehören , finden Sie unter Board-Konfigurationsänderungen für neue Geräte.

Ein Beispiel für Metadaten auf einem Gerät ist:

  • Physikalisches 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 von Bar aktualisierte Partitionen
    • Metadaten 1 (nicht verwendet)
  • Physikalisches 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 von Bar aktualisierte Partitionen

Sie können das lpdump Tool unter system/extras/partition_tools verwenden, um die Metadaten auf Ihrem Gerät auszugeben. Beispielsweise:

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. Ein zusätzlicher Patch-Satz wird 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, Anbieter usw. entsprechen. Diese Bilder heißen super_system.img , super_vendor.img und so weiter. 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 zuordnen soll, werden alle Schritte nach der Installation für diese Partitionen automatisch deaktiviert, wenn das Aktualisierungspaket generiert wird. Weitere Einzelheiten finden Sie unter Nachinstallation konfigurieren .

Der Update-Flow ist derselbe 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 Retrofit

Nach dem Retrofit-Update wird der OTA-Client aktualisiert, um mit dynamischen Partitionen zu arbeiten. Die Extents für Quellpartitionen erstrecken sich niemals über physische Zielpartitionen.

Aktualisieren Sie den Flow mit einem regulären Updatepaket

  1. Initialisieren Sie die Metadaten der super .
    1. Erstellen Sie neue Metadaten M aus Metadaten S (Quellmetadaten). Wenn beispielsweise Metadaten S [ system_s , vendor_s , product_s ] als Blockgeräte verwenden, dann verwenden die neuen 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 gemäß dem Feld dynamic_partition_metadata im Updatemanifest hinzu. Die Größe jeder Partition kann in new_partition_info gefunden werden.
    3. Schreiben Sie M in Metadaten T.
    4. Ordnen Sie die hinzugefügten Partitionen auf dem Device Mapper als beschreibbar zu.
  2. Wenden Sie das Update auf die Blockgeräte an.
    1. Ordnen Sie bei Bedarf die Quellpartitionen auf dem Device 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 am Zielsteckplatz an.
    3. Mounten Sie die Partitionen, um das Post-Installationsskript auszuführen, und unmounten Sie dann die Partitionen.
  3. Heben Sie die Zuordnung der Zielpartitionen auf.

Aktualisieren Sie den Ablauf mithilfe eines Retrofit-Update-Pakets

Wenn das Retrofit-Update-Paket auf ein Gerät angewendet wird, das bereits dynamische Partitionen aktiviert, wendet der OTA-Client die aufgeteilte super.img -Datei direkt auf Blockgeräten an. Der Aktualisierungsablauf ähnelt einem Retrofit-Update. Einzelheiten finden Sie unter Update nachrüsten.

Nehmen Sie zum Beispiel Folgendes an:

  • 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 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 zuzuordnen.

Generieren von Aktualisierungspaketen

Inkrementelles 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 Nachrüst-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 Aktualisierungspaket 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 die gesplittete super.img und deaktiviert den Post-Install-Schritt zum Nachrüsten des Updates.
    • Es wird mit einem zusätzlichen Argument --retrofit_dynamic_partitions zum Skript ota_from_target_files .
    • 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. Einzelheiten zur Durchsetzung finden Sie weiter unten.

Ablehnen von nicht nachrüstbaren Updates für alte Builds

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 auf Geräte mit Android 9 oder niedriger überträgt, können Geräte nicht gestartet werden. Der OTA-Client auf Android 9 und niedriger kann den Unterschied zwischen einem nachrüstbaren 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. Beispielsweise:

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 Schritt nach der Installation aus und lehnt das Update ab.