Diese Seite wurde von der Cloud Translation API übersetzt.

Erstellen Sie OTA-Pakete

Sie können das in build/make/tools/releasetools bereitgestellte 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-Build-System 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 .

Erstellen Sie vollständige Updates

Ein vollständiges Update ist ein OTA-Paket, das den gesamten Endzustand des Geräts (System-, Start- und Wiederherstellungspartitionen) enthält. Solange das Gerät das Paket empfangen und anwenden kann, kann das Paket den Build unabhängig vom aktuellen Status des Geräts installieren. Die folgenden Befehle verwenden beispielsweise 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 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 nun 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 „Builds für die Veröffentlichung signieren“ beschrieben.

Erstellen Sie inkrementelle 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 außerdem häufig ihren Vorgängerversionen sehr ähnlich sind, muss das Paket lediglich eine Kodierung der Unterschiede zwischen den beiden Dateien enthalten.

Sie können ein inkrementelles Update-Paket nur auf Geräten installieren, auf denen der Quell-Build zum Erstellen des Pakets verwendet wurde. Um ein inkrementelles Update zu erstellen, benötigen Sie die Datei target_files.zip aus dem vorherigen Build (dem, von dem aus 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 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, auf denen genau derselbe vorherige Build ausgeführt wird, der als Ausgangspunkt des inkrementellen Pakets verwendet wurde. Sie müssen die Bilder in PREVIOUS-tardis-target_files.zip oder PREVIOUS-tardis-img.zip (beide erstellt mit make dist , um mit fastboot update geflasht zu werden) flashen, anstelle der Bilder im PRODUCT_OUT Verzeichnis (erstellt mit make , die wird mit fastboot flashall geflasht). 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 gleichen Betriebszustand (das alte System wird ausgeführt). Das Paket überprüft den vorherigen Status aller von ihm aktualisierten Dateien, bevor es sie berührt, sodass das Gerät nicht in einem halb aktualisierten Zustand festsitzt.

Um die beste Benutzererfahrung zu erzielen, bieten Sie alle drei bis vier inkrementellen Updates ein vollständiges Update an. Dies hilft Benutzern, auf dem neuesten Stand zu bleiben und eine lange Installationssequenz inkrementeller Updates zu vermeiden.

Erstellen Sie OTA-Pakete 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 (mithilfe von OTA-Tools) aktualisiert werden, um den Gerätenamen und den Fingerabdruck in die Einträge vor und nach der Bedingung aufzunehmen.

Über SKUs

Das Format einer SKU ist eine Variation kombinierter Build-Parameterwerte und typischerweise 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ä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 dann den endgültigen Produktnamen und den Gerätefingerabdruck zur Laufzeit nach dem Hochfahren des Geräts ab. Dieser Prozess vereinfacht den Plattformentwicklungsprozess und ermöglicht es Geräten mit geringfügigen Anpassungen, aber unterschiedlichen Produktnamen, gemeinsame Bilder zu teilen (z. B. tardis und tardispro ).

Verwenden Sie dynamische Fingerabdrücke

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 dynamische Logik in der Datei build.prop des Geräts, um den Wert der Bootloader-Variablen beim Gerätestart abzurufen, und verwenden Sie diese Daten dann, 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 den Gerätenamen, den Fingerabdruck und die Werte ro.build.fingerprint dynamisch fest, basierend auf dem Wert der Bootloader-Eigenschaft ro.boot.product.hardware.sku (die schreibgeschützt ist).

Aktualisieren Sie die Metadaten des OTA-Pakets

Ein OTA-Paket enthält eine Metadatendatei ( META-INF/com/android/metadata ), die das Paket beschreibt, einschließlich der Vorbedingung 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 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 voraussichtlich haben wird. Die Werte der pre- und post- werden von den folgenden entsprechenden Build-Eigenschaften abgeleitet.

Der Wert pre-device wird von der Buildeigenschaft ro.product.device abgeleitet.
Die pre-build-incremental und post-build-incremental 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- aufzunehmen (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 der ro.boot.* Eigenschaften enthält. Wird zur Berechnung der möglichen Laufzeit-Fingerabdrücke verwendet, wenn einige ro.product.* Eigenschaften durch die Importanweisung ü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, sind die OTA-Metadaten für tardis und tardispro Geräte 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 Funktionalität auf Geräten mit Android 10 finden Sie in der Referenzimplementierung . Diese Änderungsliste analysiert bedingt die import in der Datei build.prop , wodurch Eigenschaftsüberschreibungen erkannt und in den endgültigen OTA-Metadaten widergespiegelt werden können.