Erstellen von OTA-Paketen

Sie können die Verwendung ota_from_target_files Werkzeug in bereitgestellt build/make/tools/releasetools vollständige und inkrementelle OTA - Pakete für Geräte , die Verwendung zu bauen A / B System - Updates oder Nicht-A / B - System - Updates . Das Werkzeug nimmt die target-files.zip Datei durch das Android - Build - System als Eingabe erzeugt.

Bei Geräten mit Android 11 oder höher können Sie ein OTA-Paket für mehrere Geräte mit unterschiedlichen SKUs erstellen. Dabei erfordert die Zielgeräte zur Verwendung Konfigurieren von dynamischen Fingerabdrücke und die Aktualisierung der OTA - Metadaten den Gerätenamen und Fingerabdruck in den Vor- und Nachbedingung Einträge hinzu.

Android 8.0 veraltet dateibasierte OTA - Pakete für nicht-A / B - Geräte, die stattdessen verwenden müssen blockbasierten OTA - Pakete . Um blockbasierten OTA - Pakete oder Geräte mit Android 7.x oder senken, übergeben Sie die Erzeugung --block Option zum ota_from_target_files Parameter.

Vollständige Updates erstellen

Eine vollständige Aktualisierung ist ein OTA - Paket , das den gesamten Endzustand des Geräts (System-, Start- und Recovery - Partitionen) enthält. Solange das Gerät das Paket empfangen und anwenden kann, kann das Paket den Build unabhängig vom aktuellen Zustand des Geräts installieren. Verwenden Sie zum Beispiel die folgenden Befehle Entriegelungswerkzeuge die bauen 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 baut ein vollständiges OTA - Paket (in $OUT ). Die sich ergebende .zip - Datei enthält alle benötigten Komponenten OTA - Pakete für die konstruieren tardis Gerät. Sie können auch die bauen ota_from_target_files als Python Binär- und nennen es entweder vollständige oder inkrementelle Pakete zu bauen.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

Der ota_from_target_files Pfad wird in einzurichten $PATH und die resultierende Python - Binary befindet sich in der out/ Verzeichnis.

ota_update.zip ist nun bereit , um Testgeräte gesendet werden (alles wird mit dem Testschlüssel signiert). Für Anwender Geräte erzeugen und verwenden Sie Ihre eigenen privaten Schlüssel wie detailliert in Signing für Release - Builds .

Inkrementelle Updates erstellen

Eine inkrementelle Aktualisierung ist ein OTA - Paket , die binären Pflaster auf Daten , die bereits auf dem Gerät enthält. Pakete mit inkrementellen Updates sind normalerweise kleiner, da sie keine unveränderten Dateien enthalten müssen. Da geänderte Dateien ihren Vorgängerversionen oft sehr ähnlich sind, muss das Paket außerdem nur eine Kodierung der Unterschiede zwischen den beiden Dateien enthalten.

Sie können ein inkrementelles Updatepaket nur auf Geräten installieren, auf denen der Quellbuild zum Erstellen des Pakets verwendet wurde. Um ein inkrementelles Update zu bauen, müssen Sie die target_files.zip Datei aus dem vorherigen Build (die Sie aktualisieren möchten aus) sowie die target_files.zip Datei aus dem neuen Build. Zum Beispiel die folgenden Befehle Entriegelungswerkzeuge eine inkrementelle Aktualisierung für das bauen 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 sehr ähnlich zu dem vorherigen bauen, und das inkrementellen Aktualisierungspaket ( incremental_ota_update.zip ) ist viel kleiner als die entsprechende vollständige Aktualisierung (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 Bilder in Flash PREVIOUS-tardis-target_files.zip oder PREVIOUS-tardis-img.zip (beide mit eingebautem make dist , mit geflasht werden fastboot update - PRODUCT_OUT make fastboot update ), statt die , die unter dem PRODUCT_OUT Verzeichnis (mit eingebautem make , die wird mit geflasht werden 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 gleichen Arbeitszustand (mit dem alten System); Das Paket überprüft den vorherigen Zustand aller aktualisierten Dateien, bevor es sie berührt, damit das Gerät nicht in einem halb aktualisierten Zustand festsitzt.

Bieten Sie für ein optimales Benutzererlebnis alle 3-4 inkrementellen Updates ein vollständiges Update an. Dies hilft Benutzern, sich an die neueste Version zu halten 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 (mithilfe 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 der kombinierten build Parameterwerten und ist typischerweise eine nicht angemeldete Untermenge der aktuellen build_fingerprint Parameter. OEMs können eine beliebige Kombination von CDD-zugelassenen 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äte - Ebene (wie Pro, Premium, oder Plus)
  • modifierB ist die Hardware - Variation (wie Radio)
  • modifierC ist die Region, die allgemein sein kann (wie Na, EMEA oder CHN) oder landes- oder sprachspezifische (wie JPN, ENG, oder CHN)

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 gestartet wurde. Dieser Prozess vereinfacht den Plattform - Entwicklungsprozess, so dass Geräte mit kleineren Anpassungen , aber unterschiedlichen Produktnamen gemeinsame Bilder (wie teilen tardis und tardispro ).

Dynamische Fingerabdrücke verwenden

Ein Fingerabdruck ist ein definierter Verkettung von Build - ro.product.brand ro.product.name ro.product.device Parameter 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. Eine dynamischer Fingerabdruck, verwenden dynamische Logik in den Geräten erstellen build.prop Datei , um den Wert der Variablen Bootloader an Gerät Boote zu bekommen, dann diese Daten verwenden , um eine dynamische Fingerabdruck für das Gerät zu erstellen.

Zum Beispiel dynamische Fingerabdrücke verwenden tardis und tardispro Geräte, aktualisieren Sie die folgenden Dateien wie unten dargestellt.

  • Aktualisieren Sie die odm/etc/build_std.prop Datei die folgende Zeile enthalten.

    ro.odm.product.device=tardis
    
  • Aktualisieren Sie die odm/etc/build_pro.prop Datei die folgende Zeile enthalten.

    ro.odm.product.device=tardispro
    
  • Aktualisieren Sie die odm/etc/build.prop Datei die folgenden Zeilen enthalten.

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

Diese Linien eingestellt dynamisch die Gerätenamen, den Fingerabdruck und ro.build.fingerprint Werte basierend auf dem Wert der ro.boot.product.hardware.sku Bootloader - Eigenschaft (die schreibgeschützt).

Aktualisieren von OTA-Paket-Metadaten

Ein OTA - Paket enthält eine Metadaten - Datei ( META-INF/com/android/metadata ), die das Paket beschreibt, einschließlich der Vorbedingung und Nachbedingung des OTA - Pakets. Beispielsweise ist der folgende Code die Metadaten - Datei für ein OTA - Paket Targeting des tardis Geräts.

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

Das pre-device , pre-build-incremental und pre-build Werte , die den Zustand definieren , eine Einrichtung aufweisen müssen , bevor das Paket OTA kann installieren. Die post-build-incremental und post-build - Werte definieren , die den Zustand einer Vorrichtung erwartet wird , nachdem die OTA Paket installiert haben. Die Werte von pre- und post- Felder werden aus den folgenden entsprechenden Aufbaueigenschaften abgeleitet.

  • Der pre-device - Wert wird aus der abgeleiteten ro.product.device build - Eigenschaft.
  • Die pre-build-incremental und post-build-incremental Werte werden aus der abgeleiteten ro.build.version.incremental build - Eigenschaft.
  • Die pre-build - und post-build - Werte werden aus der abgeleiteten ro.build.fingerprint build - Eigenschaft.

Auf Geräten mit Android 11 oder höher, können Sie das verwenden --boot_variable_file Flag in OTA - Tools einen Pfad zu einer Datei angeben , die die Werte der Laufzeitvariablen bei der Erstellung des Geräts dynamischen Fingerabdruck verwendet wird, enthält. Die Daten werden dann verwendet , um die OTA - Metadaten zu aktualisieren , die Gerätenamen und die Fingerabdruck in einschließen pre- und post- Bedingungen (unter Verwendung des Pipezeichen | als Trennzeichen). Die --boot_variable_file Flag hat die folgende Syntax und Beschreibung.

  • Syntax: --boot_variable_file <path>
  • Beschreibung: Gibt einen Pfad zu einer Datei , die die möglichen Werte enthält ro.boot.* Eigenschaften. Verwendet , um die mögliche Laufzeit Fingerabdrücke zu berechnen , wenn einige ro.product.* Eigenschaften durch die Import - Anweisung außer Kraft gesetzt werden. Die Datei erwartet ein Objekt pro Zeile , in jeder Zeile das folgende Format hat: prop_name=value1,value2 .

Wenn zum Beispiel der Eigenschaft ro.boot.product.hardware.sku=std,pro , die OTA - Metadaten für tardis und tardispro Geräte wie unten gezeigt.

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

Um diese Funktionalität auf Geräte zu unterstützen mit Android 10 finden Sie in der Referenzimplementierung . Diese Änderungsliste parst bedingt die import - Anweisungen in der build.prop - Datei, die Eigenschaftsüberschreibungen kann in dem endgültigen OTA Metadaten erkannt und berücksichtigt werden.