Diese Seite wurde von der Cloud Translation API übersetzt.

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 verwendet die vom Android-Build-System erstellte Datei target-files.zip als Eingabe.

Für Geräte mit Android 11 oder höher kannst du ein OTA-Paket für mehrere Geräte mit unterschiedlichen SKUs erstellen. Dazu müssen Sie die Zielgeräte für die Verwendung von dynamischen Fingerabdrücken konfigurieren und die OTA-Metadaten aktualisieren, sodass der Gerätename und der Fingerabdruck in den Vor- und Nachbedingungseinträgen enthalten sind.

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

Vollständige Updates erstellen

Ein vollständiges Update ist ein OTA-Paket, das den gesamten endgültigen Zustand 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 Gerätestatus 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 Gerät tardis 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 ist 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). Generieren und verwenden Sie für Nutzergeräte eigene private Schlüssel, wie unter Builds für den Release 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 geänderte Dateien häufig ihren vorherigen Versionen ähneln, muss das Paket außerdem nur eine Codierung der Unterschiede zwischen den beiden Dateien enthalten.

Sie können ein inkrementelles Update-Paket nur auf Geräten installieren, auf denen der Quell-Build beim Erstellen des Pakets verwendet wurde. Für ein inkrementelles Update benötigen Sie die Datei target_files.zip aus dem vorherigen Build, d. h. den, von dem Sie aktualisieren möchten, sowie die Datei target_files.zip 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 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 mit make dist erstellt und mit fastboot update erstellt werden) flashen, nicht in den Images im Verzeichnis PRODUCT_OUT, das mit make erstellt wurde und mit fastboot flashall geflasht wird. 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 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 nach 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 einzelnen 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 so aktualisiert werden, dass der Gerätename und der Fingerabdruck den Vor- und Nachbedingungseinträgen hinzugefügt werden.

SKUs

Das Format einer Artikelnummer ist eine Variation kombinierter Build-Parameterwerte und ist normalerweise 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 SKU gibt es beispielsweise in mehreren 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 dann nach dem Hochfahren des Geräts den endgültigen Produktnamen und den Geräte-Fingerabdruck zur Laufzeit ab. Dieser Prozess vereinfacht den Plattformentwicklungsprozess, da Geräte mit geringfügigen Anpassungen, aber unterschiedlichen Produktnamen gemeinsame Images wie tardis und tardispro nutzen können.

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 Systempartitions-Fingerabdruck abgeleitet und als eindeutige Kennzeichnung für die auf dem Gerät ausgeführten Bilder (und Byte) verwendet. 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, müssen Sie die folgenden Dateien wie unten gezeigt aktualisieren.

Aktualisieren Sie die Datei odm/etc/build_std.prop, sodass sie die folgende Zeile enthält.
```
ro.odm.product.device=tardis
```
Aktualisieren Sie die Datei odm/etc/build_pro.prop, sodass sie die folgende Zeile enthält.
```
ro.odm.product.device=tardispro
```

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

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

Mit diesen Zeilen werden der Gerätename, der Fingerabdruck und die ro.build.fingerprint-Werte dynamisch anhand des Werts der schreibgeschützten Bootloader-Eigenschaft ro.boot.product.hardware.sku festgelegt.

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 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 Status, den ein Gerät nach der Installation des OTA-Pakets haben wird. Die Werte der Felder pre- und post- werden aus den folgenden entsprechenden Build-Attributen abgeleitet.

Der Wert pre-device wird vom 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 vom Build-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, um den Gerätenamen und den Fingerabdruck in die pre-- und post--Bedingungen aufzunehmen (unter Verwendung des senkrechten Strichs | 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 zum Berechnen der möglichen Laufzeit-Fingerabdrücke verwendet, wenn einige ro.product.*-Attribute von der Importanweisung überschrieben werden. In der Datei wird ein Attribut pro Zeile erwartet, wobei jede Zeile das folgende Format hat: prop_name=value1,value2.

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