OTA-Pakete erstellen

Mit dem Tool ota_from_target_files in build/make/tools/releasetools können Sie vollständige und inkrementelle OTA-Pakete für Geräte erstellen, die A/B-Systemupdates oder Nicht-A/B-Systemupdates verwenden. Das Tool nimmt die vom Android-Buildsystem erstellte target-files.zip-Datei als Eingabe.

Für Geräte mit Android 11 oder höher können Sie ein OTA-Paket für mehrere Geräte mit unterschiedlichen SKUs erstellen. Dazu müssen Sie die Zielgeräte so konfigurieren, dass dynamische Fingerabdrücke verwendet werden, und die OTA-Metadaten aktualisieren, um den Gerätenamen und den Fingerabdruck in die Einträge für die Vor- und Nachbedingungen aufzunehmen.

Unter Android 8.0 wurden dateibasierte OTA-Pakete für Nicht-A/B-Geräte eingestellt. Stattdessen müssen blockbasierte OTA-Pakete verwendet werden. Wenn Sie blockbasierte OTA-Pakete oder Geräte mit Android 7.x oder niedriger generieren möchten, übergeben Sie die Option --block an den Parameter ota_from_target_files.

Vollständige Updates erstellen

Ein vollständiges Update ist ein OTA-Paket, das den gesamten Endstatus des Geräts (System-, Boot- und Wiederherstellungspartitionen) enthält. Solange das Gerät das Paket empfangen und anwenden kann, kann das Paket das Build unabhängig vom aktuellen Status des Geräts installieren. Die folgenden Befehle verwenden beispielsweise Release-Tools, um das target-files.zip-Archiv für das Gerät tardis zu erstellen.

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

make dist erstellt ein vollständiges OTA-Paket (in $OUT). Die resultierende .zip-Datei enthält alles, was zum Erstellen von OTA-Paketen für das tardis-Gerät erforderlich ist. Sie können das ota_from_target_files auch als Python-Binärprogramm erstellen und aufrufen, um entweder vollständige oder inkrementelle Pakete zu erstellen.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

Der Pfad ota_from_target_files wird in $PATH eingerichtet und das resultierende Python-Binary befindet sich im Verzeichnis out/.

ota_update.zip kann jetzt an Testgeräte gesendet werden (alles ist mit dem Testschlüssel signiert). Für Nutzergeräte müssen Sie eigene private Schlüssel generieren und verwenden, wie unter Builds für die Veröffentlichung signieren beschrieben.

Inkrementelle Updates erstellen

Ein inkrementelles Update ist ein OTA-Paket, das Binär-Patches für Daten enthält, die sich bereits auf dem Gerät befinden. Pakete mit inkrementellen Updates sind in der Regel kleiner, da sie keine unveränderten Dateien enthalten müssen. Da sich geänderte Dateien oft sehr ähnlich wie ihre vorherigen Versionen verhalten, muss das Paket nur eine Codierung der Unterschiede zwischen den beiden Dateien enthalten.

Sie können ein Paket mit inkrementellen Updates nur auf Geräten installieren, auf denen der Quell-Build vorhanden ist, der beim Erstellen des Pakets verwendet wurde. Zum Erstellen eines inkrementellen Updates benötigen Sie die target_files.zip-Datei aus dem vorherigen Build (die Datei, aus der Sie aktualisieren möchten) sowie die target_files.zip-Datei aus dem neuen Build. Bei den folgenden Befehlen werden beispielsweise Release-Tools verwendet, um ein inkrementelles Update für das tardis-Gerät zu erstellen.

ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

Dieser Build ist dem vorherigen Build sehr ähnlich und das inkrementelle Updatepaket (incremental_ota_update.zip) ist viel kleiner als das entsprechende vollständige Update (etwa 1 MB statt 60 MB).

Verteilen Sie ein inkrementelles Paket nur auf Geräte, auf denen genau derselbe vorherige Build ausgeführt wird, der als Ausgangspunkt für das inkrementelle Paket verwendet wurde. Sie müssen die Images in PREVIOUS-tardis-target_files.zip oder PREVIOUS-tardis-img.zip (beide mit make dist erstellt, mit fastboot update geflasht werden) und nicht die im Verzeichnis PRODUCT_OUT (mit make erstellt, mit fastboot flashall geflasht werden) flashen. Wenn Sie versuchen, das inkrementelle Paket mit einer anderen Build-Version auf einem Gerät zu installieren, führt dies zu einem Installationsfehler. Wenn die Installation fehlschlägt, bleibt das Gerät im selben funktionsfähigen Zustand (das alte System wird ausgeführt). Das Paket überprüft den vorherigen Status aller Dateien, die es aktualisiert, bevor es berührt wird, damit das Gerät nicht in einem halben Upgrade-Zustand verhängt wird.

Für eine optimale Nutzererfahrung sollten Sie alle drei bis vier inkrementellen Updates ein vollständiges Update anbieten. Dies hilft Nutzern, auf dem neuesten Stand zu bleiben und eine lange Installationssequenz inkrementeller Updates zu vermeiden.

OTA-Pakete für mehrere SKUs erstellen

Android 11 oder höher unterstützt die Verwendung eines einzigen OTA-Pakets für mehrere Geräte mit unterschiedlichen SKUs. Dazu müssen Sie die Zielgeräte so konfigurieren, dass dynamische Fingerabdrücke verwendet werden, und die OTA-Metadaten mithilfe von OTA-Tools aktualisieren, um den Gerätenamen und den Fingerabdruck in die Einträge für die Vor- und Nachbedingung aufzunehmen.

SKUs

Das Format einer Artikelnummer ist eine Variation kombinierter Werte für Build-Parameter und ist normalerweise eine nicht deklarierte Teilmenge der aktuellen build_fingerprint-Parameter. OEMs können eine beliebige Kombination von vom CDD genehmigten Build-Parametern für eine SKU verwenden und gleichzeitig ein einzelnes Image für diese SKUs verwenden. Die folgende Artikelnummer hat beispielsweise mehrere Varianten:

SKU = <product><device><modifierA><modifierB><modifierC>
  • modifierA ist die Geräteebene (z. B. Pro, Premium oder Plus)
  • modifierB ist die Hardwarevariante (z. B. Radio).
  • modifierC ist die Region, die allgemein (z. B. NA, EMEA oder CHN) oder länder- oder sprachspezifisch (z. B. JPN, ENG oder CHN) sein kann.

Viele OEMs verwenden ein einzelnes Image für mehrere SKUs und leiten den endgültigen Produktnamen und den Gerätefingerabdruck dann zur Laufzeit nach dem Starten des Geräts ab. Dieser Prozess vereinfacht die Plattformentwicklung, da Geräte mit geringfügigen Anpassungen, aber unterschiedlichen Produktnamen gemeinsame Bilder verwenden können (z. B. tardis und tardispro).

Dynamische Fingerabdrücke verwenden

Ein Fingerabdruck ist eine definierte Konkatenierung von Build-Parametern wie ro.product.brand, ro.product.name und ro.product.device. Der Fingerabdruck eines Geräts wird aus dem Fingerabdruck der Systempartition abgeleitet und dient als eindeutige Kennung der Images (und Bytes), die auf dem Gerät ausgeführt werden. Verwenden Sie zum Erstellen eines dynamischen Fingerabdrucks eine dynamische Logik in der Datei build.prop des Geräts, um den Wert der Bootloader-Variablen beim Booten des Geräts abzurufen. Verwenden Sie diese Daten dann, um einen dynamischen Fingerabdruck für dieses Gerät zu erstellen.

Wenn Sie beispielsweise dynamische Fingerabdrücke für tardis- und tardispro-Geräte verwenden möchten, aktualisieren Sie die folgenden Dateien wie unten gezeigt.

  • Aktualisieren Sie die Datei odm/etc/build_std.prop mit der folgenden Zeile.

    ro.odm.product.device=tardis

  • Aktualisieren Sie die Datei odm/etc/build_pro.prop mit der folgenden Zeile.

    ro.odm.product.device=tardispro

  • Aktualisieren Sie die Datei odm/etc/build.prop so, dass sie die folgenden Zeilen enthält.

    ro.odm.product.device=tardis
import /odm/etc/build_${ro.boot.product.hardware.sku}.prop

In diesen Zeilen werden der Gerätename, der Fingerabdruck und die ro.build.fingerprint-Werte dynamisch auf Grundlage des Werts der Bootloader-Eigenschaft ro.boot.product.hardware.sku (schreibgeschützt) festgelegt.

Metadaten für OTA-Pakete aktualisieren

Ein OTA-Paket enthält eine Metadatendatei (META-INF/com/android/metadata), die das Paket beschreibt, einschließlich der Vor- und Nachbedingung des OTA-Pakets. Der folgende Code ist beispielsweise die Metadatendatei für ein OTA-Paket, das auf das Gerät tardis ausgerichtet ist.

post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis

Die Werte pre-device, pre-build-incremental und pre-build definieren den Status, den ein Gerät haben muss, bevor das OTA-Paket installiert werden kann. Die Werte post-build-incremental und post-build definieren den Zustand, in dem sich ein Gerät nach der Installation des OTA-Pakets befinden soll. Die Werte der Felder pre- und post- werden aus den folgenden entsprechenden Build-Properties abgeleitet.

  • Der Wert für pre-device wird aus dem Build-Attribut ro.product.device abgeleitet.
  • Die Werte pre-build-incremental und post-build-incremental werden vom Build-Attribut ro.build.version.incremental abgeleitet.
  • Die Werte pre-build und post-build werden aus dem Attribut ro.build.fingerprint abgeleitet.

Auf Geräten mit Android 11 oder höher können Sie das Flag --boot_variable_file in OTA-Tools verwenden, um einen Pfad zu einer Datei anzugeben, die die Werte der Laufzeitvariablen enthält, die beim Erstellen des dynamischen Fingerabdrucks des Geräts verwendet werden. Die Daten werden dann verwendet, um die OTA-Metadaten zu aktualisieren und den Gerätenamen und den Fingerabdruck in die Bedingungen pre- und post- aufzunehmen (mit dem Pipe-Zeichen | als Trennzeichen). Das Flag --boot_variable_file hat die folgende Syntax und Beschreibung.

  • Syntax: --boot_variable_file <path>
  • Beschreibung: Gibt einen Pfad zu einer Datei an, die die möglichen Werte von ro.boot.*-Attributen enthält. Wird verwendet, um die möglichen Laufzeit-Fingerabdrücke zu berechnen, wenn einige ro.product.*-Properties durch die Importanweisung überschrieben werden. In der Datei wird ein Attribut pro Zeile erwartet, wobei jede Zeile das folgende Format hat: prop_name=value1,value2.

Wenn die Property beispielsweise ro.boot.product.hardware.sku=std,pro ist, sehen die OTA-Metadaten für tardis- und tardispro-Geräte so aus, wie unten dargestellt.

post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro

Informationen zur Unterstützung dieser Funktion auf Geräten mit Android 10 findest du in der Referenzimplementierung. In dieser Änderungsliste werden die import-Anweisungen in der build.prop-Datei bedingt analysiert. So können Attributüberschreibungen erkannt und in den endgültigen OTA-Metadaten berücksichtigt werden.