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
Eigenschaftro.product.device
abgeleitet. - Die
pre-build-incremental
undpost-build-incremental
Werte werden von der Build-Eigenschaftro.build.version.incremental
abgeleitet. - Die
pre-build
undpost-build
Werte werden von der Build-Eigenschaftro.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 einigero.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.