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 Buildeigenschaftro.product.device
abgeleitet. - Die
pre-build-incremental
undpost-build-incremental
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-
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 einigero.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.