OTA-Pakete erstellen

Mit dem ota_from_target_files Tool 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 verwendet die Datei target-files.zip, die vom Android-Build-System erstellt wurde, als Eingabe.

Auf Geräten mit Android 11 oder höher können Sie ein OTA-Paket für mehrere Geräte mit unterschiedlichen Artikelnummern erstellen. Dazu müssen Sie die Zielgeräte so konfigurieren, dass sie dynamische Fingerabdrücke verwenden, und die OTA-Metadaten so aktualisieren, dass der Gerätename und der Fingerabdruck in den Einträgen für die Vor- und Nachbedingungen enthalten sind.

In 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 für 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 Endzustand des Geräts enthält (System-, Boot- und Wiederherstellungspartitionen). Solange das Gerät das Paket empfangen und anwenden kann, kann das Paket den Build unabhängig vom aktuellen Zustand des Geräts installieren. Die folgenden Befehle verwenden beispielsweise Release-Tools, um das Archiv target-files.zip für das Gerät tardis zu erstellen.

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

Mit make dist wird ein vollständiges OTA-Paket in $OUT erstellt. Die resultierende .zip-Datei enthält alles, was zum Erstellen von OTA-Paketen für das Gerät tardis erforderlich ist. Sie können ota_from_target_files auch als Python-Binärdatei erstellen und damit vollständige oder inkrementelle Pakete 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 die resultierende Python-Binärdatei 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 generieren und verwenden Sie Ihre eigenen privaten Schlüssel, wie unter Builds für die Veröffentlichung signieren beschrieben.

Inkrementelle Updates erstellen

Ein inkrementelles Update ist ein OTA-Paket, das binäre 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 sind wie ihre vorherigen Versionen, muss das Paket nur eine Codierung der Unterschiede zwischen den beiden Dateien enthalten.

Sie können ein inkrementelles Updatepaket nur auf Geräten installieren, die den Quell-Build verwenden, der zum Erstellen des Pakets verwendet wurde. Um ein inkrementelles Update zu erstellen, benötigen Sie die Datei target_files.zip aus dem vorherigen Build (aus dem Sie aktualisieren möchten) sowie die Datei target_files.zip aus dem neuen Build. Die folgenden Befehle verwenden beispielsweise Release-Tools, um ein inkrementelles Update für das Gerät tardis zu erstellen.

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

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

Verteilen Sie ein inkrementelles Paket nur an 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 flashen (beide mit make dist erstellt und mit fastboot update geflasht), anstelle der Images im Verzeichnis PRODUCT_OUT (mit make erstellt und mit fastboot flashall geflasht). Wenn Sie versuchen, das inkrementelle Paket auf einem Gerät mit einem anderen Build zu installieren, tritt ein Installationsfehler auf. Wenn die Installation fehlschlägt, bleibt das Gerät im selben Arbeitszustand (mit dem alten System). Das Paket überprüft den vorherigen Zustand aller Dateien, die es aktualisiert, bevor es sie ändert. So wird verhindert, dass das Gerät in einem halb aktualisierten Zustand verbleibt.

Für eine optimale Nutzererfahrung sollten Sie alle drei bis vier inkrementellen Updates ein vollständiges Update anbieten. So können Nutzer auf die neueste Version umsteigen und eine lange Installationssequenz inkrementeller Updates vermeiden.

OTA-Pakete für mehrere Artikelnummern erstellen

Android 11 oder höher unterstützt die Verwendung eines einzelnen OTA-Pakets für mehrere Geräte mit unterschiedlichen Artikelnummern. Dazu müssen Sie die Zielgeräte so konfigurieren, dass sie dynamische Fingerabdrücke verwenden, und die OTA-Metadaten (mit OTA-Tools) so aktualisieren, dass der Gerätename und der Fingerabdruck in den Einträgen für die Vor- und Nachbedingungen enthalten sind.

Artikelnummern

Das Format einer Artikelnummer ist eine Kombination aus Build Parameter-Werten und in der Regel eine nicht deklarierte Teilmenge der aktuellen build_fingerprint-Parameter. OEMs können eine beliebige Kombination von CDD-genehmigten Build-Parametern für eine Artikelnummer verwenden und gleichzeitig ein einzelnes Image für diese Artikelnummern 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. Funkgerät)
• 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 Artikelnummern und leiten dann den endgültigen Produktnamen und den Gerätefingerabdruck zur Laufzeit nach dem Start des Geräts ab. Dieser Prozess vereinfacht die Plattformentwicklung, sodass Geräte mit geringfügigen Anpassungen, aber unterschiedlichen Produktnamen gemeinsame Images verwenden können (z. B. tardis und tardispro).

Dynamische Fingerabdrücke verwenden

Ein Fingerabdruck ist eine definierte Verkettung von Build Parametern wie ro.product.brand, ro.product.name, und ro.product.device. Der Fingerabdruck eines Geräts wird vom Fingerabdruck der Systempartition abgeleitet und als eindeutige Kennung der Images (und Bytes) verwendet, die auf dem Gerät ausgeführt werden. Um einen dynamischen Fingerabdruck zu erstellen, verwenden Sie dynamische Logik in der Datei build.prop des Geräts, um den Wert von Bootloader-Variablen beim Start 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 die Geräte tardis und tardispro verwenden möchten, aktualisieren Sie die folgenden Dateien wie unten gezeigt.

• Aktualisieren Sie die Datei odm/etc/build_std.prop so, dass sie die folgende Zeile enthält.

  ro.odm.product.device=tardis
  

• Aktualisieren Sie die Datei odm/etc/build_pro.prop so, dass sie die folgende Zeile enthält.

  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
  

Diese Zeilen legen den Gerätenamen, den Fingerabdruck und die Werte für ro.build.fingerprint dynamisch basierend auf dem Wert der Bootloader-Property ro.boot.product.hardware.sku fest (die schreibgeschützt ist).

OTA-Paketmetadaten aktualisieren

Ein OTA-Paket enthält eine Metadatendatei (META-INF/com/android/metadata), die das Paket beschreibt, einschließlich der Vor- und Nachbedingungen 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 Zustand, den ein Gerät haben muss, bevor das OTA-Paket installiert werden kann. Die post-build-incremental und post-build Werte definieren den Zustand, den ein Gerät nach der Installation des OTA-Pakets haben soll. Die Werte der Felder pre- und post- werden aus den folgenden entsprechenden Build-Properties abgeleitet.

• Der Wert pre-device wird aus der Build-Property ro.product.device abgeleitet.
• Die Werte pre-build-incremental und post-build-incremental werden aus der Build-Property ro.build.version.incremental abgeleitet.
• Die Werte pre-build und post-build werden aus der Build-Property 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 zum Erstellen des dynamischen Fingerabdrucks des Geräts verwendet werden. Die Daten werden dann verwendet, um die OTA-Metadaten so zu aktualisieren, dass der Gerätename und der Fingerabdruck in den pre- und post--Bedingungen enthalten sind (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.*-Properties enthält. Wird verwendet, um die möglichen Laufzeitfingerabdrücke zu berechnen, wenn einige ro.product.*-Properties durch die Importanweisung überschrieben werden. Die Datei erwartet eine Property pro Zeile, 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:

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 finden Sie in der Referenz implementierung. Diese Änderung analysiert die import-Anweisungen in der Datei build.prop bedingt, sodass Property-Überschreibungen erkannt und in den endgültigen OTA-Metadaten berücksichtigt werden können.