OTA-Pakete erstellen

Sie können die ota_from_target_files verwenden Tool in build/make/tools/releasetools zur Erstellung vollständiger und inkrementeller OTA-Pakete für Geräte mit A/B-Systemupdates oder Nicht-A/B-Systemupdates. Das Tool erfasst Die Datei target-files.zip, die vom Android-Build-System als Eingabe erstellt wurde.

Für Geräte mit Android 11 oder höher können Sie Ein OTA-Paket für mehrere Geräte mit unterschiedlichen SKUs Dazu müssen Sie Zielgeräte zur Verwendung von dynamischen Fingerabdrücken konfigurieren und die OTA-Metadaten so aktualisieren, dass sie das Gerät enthalten Name und Fingerabdruck in den Vor- und Nachbedingungseinträgen.

Unter Android 8.0 wurden dateibasierte OTA-Pakete für Nicht-A/B-Geräte eingestellt. Diese müssen verwenden Sie stattdessen blockbasierte OTA-Pakete. Bis blockbasierte OTA-Pakete oder Geräte mit Android 7.x oder niedriger generieren, die Option --block für den Parameter ota_from_target_files.

Vollständige Updates erstellen

Ein vollständiges Update ist ein OTA-Paket, das den gesamten endgültigen Zustand des Gerät (System-, Boot- und Wiederherstellungspartitionen). Solange das Gerät Empfang und Anwendung des Pakets kann das Paket den Build unabhängig vom aktuellen Gerätestatus. Beispiel: Befehle verwenden Release-Tools, um das target-files.zip-Archiv für die tardis Gerät.

. 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 folgenden Befehl aufrufen: vollständige oder inkrementelle Pakete 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 daraus resultierende Python- Die Binärdatei befindet sich im Verzeichnis out/.

ota_update.zip kann jetzt an Testgeräte gesendet werden (alles ist signiert) durch den Testschlüssel). Generieren und verwenden Sie für Nutzergeräte eigene private Schlüssel als wie unter Builds für die Veröffentlichung signieren beschrieben.

Inkrementelle Updates erstellen

Ein inkrementelles Update ist ein OTA-Paket, das Binär-Patches für Daten enthält. bereits auf dem Gerät installiert ist. Pakete mit inkrementellen Updates sind in der Regel kleiner da sie keine unveränderten Dateien enthalten müssen. Außerdem werden geänderte Dateien oft ihren vorherigen Versionen sehr ähnlich sind, muss das Paket nur eine Codierung der Unterschiede zwischen den beiden Dateien.

Sie können ein inkrementelles Update-Paket nur auf Geräten installieren, auf denen Quell-Build, 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 (das gewünschte from) sowie die target_files.zip-Datei des neuen Builds. Für Beispiel: Bei den folgenden Befehlen werden Release-Tools verwendet, um ein inkrementelles Update für das tardis-Gerät.

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 die inkrementelle Aktualisierung Paket (incremental_ota_update.zip) ist viel kleiner als das entsprechende vollständige Aktualisierung (ca. 1 MB statt 60 MB).

Inkrementelles Paket nur an Geräte verteilen, die genau gleich laufen vorherigen Build, 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 mit make dist erstellt, zum Flashen mit fastboot update erstellt) anstelle von die im Verzeichnis PRODUCT_OUT (mit make erstellt, die mit fastboot flashall) geblinkt. Versuch, das inkrementelle Paket zu installieren auf einem Gerät mit einem anderen Build führt zu einem Installationsfehler. Wenn der Parameter die Installation fehlschlägt, bleibt das Gerät im selben funktionsfähigen Zustand, d. h. die alte System); Das Paket prüft den vorherigen Status aller Dateien, die es aktualisiert. bevor Sie sie berühren, damit das Gerät nicht in einem halb aufgerüsteten Zustand verhängt wird.

Für eine optimale Nutzererfahrung sollten Sie für alle 3–4 Schritte ein vollständiges Update anbieten. Aktualisierungen. So bleiben Nutzer auf dem neuesten Stand und vermeiden lange Installation einer Abfolge inkrementeller Updates.

OTA-Pakete für mehrere SKUs erstellen

Android 11 oder höher unterstützt die Verwendung eines einzelnen OTA-Updates für mehrere Geräte mit unterschiedlichen Artikelnummern. Dazu müssen Sie die Zielgeräte, um dynamische Fingerabdrücke zu verwenden und die OTA-Metadaten zu aktualisieren (mithilfe von OTA-Tools), um den Gerätenamen und den Fingerabdruck in den Vor- und Nachahmungen anzugeben. Bedingungseinträge zu erstellen.

SKUs

Das Format einer Artikelnummer ist eine Variante des kombinierten Builds. 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, während für diese Artikelnummern auch ein einzelnes Bild verwenden. Die folgende SKU hat beispielsweise Mehrere 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 sein kann. (z. B. NA, EMEA oder CHN) oder länderspezifische oder sprachspezifische Elemente wie JPN, EN oder CHN)

Viele OEMs verwenden ein einziges Bild für mehrere SKUs und leiten dann das Endprodukt ab. Name und Fingerabdruck zur Laufzeit nach dem Hochfahren des Geräts. Dieser Prozess vereinfacht den Entwicklungsprozess der Plattform, indem Geräte mit kleineren Personalisierungen, aber unterschiedliche Produktnamen, um gemeinsame Bilder (z. B. tardis und tardispro).

Dynamische Fingerabdrücke verwenden

Ein Fingerabdruck ist eine definierte Verkettung von build Parameter wie ro.product.brand, ro.product.name und ro.product.device. Der Fingerabdruck eines Geräts wird vom Systempartitions-Fingerabdruck abgeleitet und als Eindeutige Kennung der Bilder (und Byte), die auf dem Gerät ausgeführt werden. So erstellen Sie ein dynamischen Fingerabdruck verwenden, verwenden Sie dynamische Logik in der build.prop-Datei des Geräts, um den Wert der Bootloader-Variablen beim Starten des Geräts abrufen und diese Daten einen dynamischen Fingerabdruck für dieses Gerät zu erstellen.

So können Sie beispielsweise dynamische Fingerabdrücke für tardis- und tardispro-Geräte verwenden: Aktualisieren Sie die folgenden Dateien wie unten gezeigt.

  • 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 Gerätename, Fingerabdruck und ro.build.fingerprint-Werte basierend auf dem Wert des ro.boot.product.hardware.sku-Bootloader-Attribut (schreibgeschützt).

Metadaten des OTA-Pakets aktualisieren

Ein OTA-Paket enthält eine Metadatendatei (META-INF/com/android/metadata), die beschreibt das Paket, einschließlich der Vor- und Nachbedingung des OTA-Updates. Paket. Der folgende Code ist beispielsweise die Metadatendatei für ein OTA-Paket. für 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 die den ein Gerät haben muss, damit das OTA-Paket installiert werden kann. Die Die Werte post-build-incremental und post-build definieren den Status eines Geräts die nach der Installation des OTA-Pakets voraussichtlich vorhanden sind. Die Werte von pre- und post--Felder 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 abgeleitet aus der Build-Eigenschaft ro.build.version.incremental.
  • Die Werte pre-build und post-build werden abgeleitet aus dem ro.build.fingerprint-Build-Property.

Auf Geräten mit Android 11 oder höher kannst du das Flag --boot_variable_file in OTA-Tools, um einen Pfad zu einer Datei anzugeben, die enthält die Werte der Laufzeitvariablen, die beim Erstellen der dynamischer Fingerabdruck. Die Daten werden dann verwendet, um die OTA-Metadaten Gerätename und Fingerabdruck in den Bedingungen pre- und post- (mithilfe der senkrechter Strich | als Trennzeichen). Das Flag --boot_variable_file enthält den Wert folgenden Syntax und Beschreibung.

  • Syntax: --boot_variable_file <path>
  • Beschreibung: Gibt den Pfad zu einer Datei an, die die möglichen Werte von ro.boot.*-Properties. Wird zum Berechnen der möglichen Laufzeit-Fingerabdrücke verwendet wenn einige ro.product.*-Attribute von der Importanweisung überschrieben werden. In der Datei wird eine Eigenschaft pro Zeile erwartet, wobei jede Zeile Folgendes enthält: Format: prop_name=value1,value2.

Wenn das Attribut beispielsweise ro.boot.product.hardware.sku=std,pro ist, OTA-Metadaten für tardis- und tardispro-Geräte finden Sie unten.

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 Referenz Implementierung. Diese Änderungsliste parst die import-Anweisungen in build.prop bedingt -Datei, mit der Eigenschaftsüberschreibungen erkannt und im die endgültigen OTA-Metadaten.