Erstellen von OTA-Paketen

Sie können das in build/make/tools/releasetools ota_from_target_files Tool ota_from_target_files verwenden, um vollständige und inkrementelle OTA-Pakete für Geräte zu erstellen, die A/B-Systemaktualisierungen oder Nicht-A/B-Systemaktualisierungen verwenden . Das Tool verwendet die vom Android-Buildsystem erstellte Datei target-files.zip 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 die Zielgeräte für die Verwendung dynamischer Fingerabdrücke konfiguriert und die OTA-Metadaten aktualisiert werden , um den Gerätenamen und den Fingerabdruck in die Vor- und Nachbedingungseinträge aufzunehmen.

Android 8.0 veraltete dateibasierte OTA-Pakete für Nicht-A/B-Geräte, die stattdessen blockbasierte OTA-Pakete verwenden müssen . Um blockbasierte OTA-Pakete oder Geräte mit Android 7.x oder niedriger zu generieren, ü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. Beispielsweise verwenden die folgenden Befehle Release-Tools, um das Archiv target-files.zip für das tardis -Gerät 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 die ota_from_target_files auch als Python-Binärdatei 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 die resultierende Python-Binärdatei befindet sich im Verzeichnis out/ .

ota_update.zip ist jetzt bereit, an Testgeräte gesendet zu werden (alles ist mit dem Testschlüssel signiert). Generieren und verwenden Sie für Benutzergeräte Ihre eigenen privaten Schlüssel, wie unter Signieren von Builds zur Veröffentlichung beschrieben.

Erstellen inkrementeller Updates

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 normalerweise kleiner, da sie keine unveränderten Dateien enthalten müssen. Da geänderte Dateien ihren vorherigen Versionen oft sehr ähnlich sind, muss das Paket außerdem nur eine Codierung der Unterschiede zwischen den beiden Dateien enthalten.

Sie können ein inkrementelles Updatepaket nur auf Geräten installieren, die über den Quellbuild verfügen, der beim Erstellen des Pakets verwendet wurde. Um ein inkrementelles Update zu erstellen, benötigen Sie die Datei target_files.zip “ aus dem vorherigen Build ( von dem Sie aktualisieren möchten) sowie die Datei target_files.zip “ aus dem neuen Build. Beispielsweise verwenden die folgenden Befehle Release-Tools, 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 Update-Paket ( 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, die genau denselben vorherigen Build ausführen, der als Ausgangspunkt des inkrementellen Pakets verwendet wurde. Sie müssen die Images in PREVIOUS-tardis-target_files.zip oder PREVIOUS-tardis-img.zip (beide erstellt mit make dist , um mit fastboot update geflasht zu werden) flashen, anstatt die im Verzeichnis PRODUCT_OUT (erstellt mit make , was wird mit fastboot flashall ). Der Versuch, das inkrementelle Paket auf einem Gerät mit einem anderen Build zu installieren, führt zu einem Installationsfehler. Wenn die Installation fehlschlägt, bleibt das Gerät im selben Betriebszustand (das alte System wird ausgeführt); Das Paket überprüft den vorherigen Zustand aller Dateien, die es aktualisiert, bevor es sie berührt, sodass das Gerät nicht in einem halb aktualisierten Zustand gestrandet ist.

Bieten Sie für die beste Benutzererfahrung alle 3–4 inkrementellen Updates ein vollständiges Update an. Dies hilft Benutzern, auf die neueste Version zuzugreifen und eine lange Installationssequenz inkrementeller Updates zu vermeiden.

Erstellen von OTA-Paketen für mehrere SKUs

Android 11 oder höher unterstützt die Verwendung eines einzigen OTA-Pakets für mehrere Geräte mit unterschiedlichen SKUs. Dazu müssen die Zielgeräte für die Verwendung dynamischer Fingerabdrücke konfiguriert und die OTA-Metadaten (unter Verwendung von OTA-Tools) aktualisiert werden, um den Gerätenamen und den Fingerabdruck in die Vor- und Nachbedingungseinträge aufzunehmen.

Über SKUs

Das Format einer SKU ist eine Variation kombinierter Build-Parameterwerte 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 SKU verwenden und gleichzeitig ein einzelnes Image für diese SKUs verwenden. Die folgende SKU hat beispielsweise mehrere Variationen:

SKU = <product><device><modifierA><modifierB><modifierC>
  • modifierA ist die Gerätestufe (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 dann den endgültigen Produktnamen und den Gerätefingerabdruck zur Laufzeit ab, nachdem das Gerät hochgefahren ist. Dieser Prozess vereinfacht den Plattformentwicklungsprozess und ermöglicht es Geräten mit geringfügigen Anpassungen, aber unterschiedlichen Produktnamen, gemeinsame Bilder (wie tardis und tardispro ) zu teilen.

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 auf dem Gerät ausgeführten Bilder (und Bytes) verwendet. Um einen dynamischen Fingerabdruck zu erstellen, verwenden Sie die dynamische Logik in der build.prop -Datei des Geräts, um den Wert der Bootloader-Variablen beim Gerätestart abzurufen, und verwenden Sie dann diese Daten, um einen dynamischen Fingerabdruck für dieses Gerät zu erstellen.

Um beispielsweise dynamische Fingerabdrücke für tardis und tardispro Geräte zu verwenden, 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 die Werte für Gerätename, Fingerabdruck und ro.build.fingerprint basierend auf dem Wert der Bootloader-Eigenschaft ro.boot.product.hardware.sku (die schreibgeschützt ist) dynamisch fest.

Metadaten des OTA-Pakets 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 tardis -Gerät abzielt.

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 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 pre- und post- Felder werden von den folgenden entsprechenden Build-Eigenschaften abgeleitet.

  • Der Wert pre-device Eigenschaft ro.product.device abgeleitet.
  • Die pre-build-incremental und post-build-incremental Werte werden von der Build-Eigenschaft ro.build.version.incremental abgeleitet.
  • Die pre-build und post-build Werte werden von der Build-Eigenschaft 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, um den Gerätenamen und den Fingerabdruck in die pre- und post- (unter Verwendung des Pipe-Zeichens | 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.* Eigenschaften enthält. Wird verwendet, um die möglichen Fingerabdrücke zur Laufzeit zu berechnen, wenn einige ro.product.* -Eigenschaften von der import-Anweisung überschrieben werden. Die Datei erwartet eine Eigenschaft pro Zeile, wobei jede Zeile das folgende Format hat: prop_name=value1,value2 .

Wenn die Eigenschaft beispielsweise ro.boot.product.hardware.sku=std,pro lautet, sehen die OTA-Metadaten für tardis und tardispro Geräte wie unten gezeigt 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 Referenzimplementierung . Diese Änderungsliste analysiert die import -Anweisungen in der build.prop -Datei bedingt, wodurch Eigenschaftsüberschreibungen erkannt und in den endgültigen OTA-Metadaten widergespiegelt werden können.