OTA-Größe reduzieren

Auf dieser Seite werden die Änderungen beschrieben, die zu AOSP hinzugefügt wurden, um unnötige Dateiänderungen zwischen Builds zu reduzieren. Geräteimplementierungen, die ihre eigenen Build-Systeme unterhalten, können diese Informationen als Leitfaden verwenden. zur Reduzierung der Größe ihrer OTA-Updates.

Android-OTA-Updates enthalten gelegentlich geänderte Dateien, die keinen Codeänderungen entsprechen. Tatsächlich sind sie Systemartefakte. Dies kann vorkommen, wenn derselbe Code, aus verschiedenen Verzeichnissen oder auf verschiedenen Rechnern eine große Anzahl an geänderten Dateien. Solche überschüssigen Dateien erhöhen die Größe eines OTA-Patches und erschweren die Bestimmung welcher Code sich geändert hat.

Um den Inhalt eines OTA transparenter zu machen, umfasst der AOSP Build-Systemänderungen, um die Größe von OTA-Patches zu reduzieren. Unnötige Dateiänderungen zwischen Builds wurden vorgenommen entfernt und nur patch-bezogene Dateien sind in OTA-Updates enthalten. AOSP umfasst auch eine build diff-Tool, das allgemeine build-bezogene Funktionen herausfiltert. Änderungen an der Datei, um einen saubereren Build-Dateiunterschied bereitzustellen, und einen Tool zum Ordnen von Blockierungen, mit dem Sie die Blockierungen einheitlich sind.

Ein Build-System kann auf verschiedene Weise unnötig große Patches erstellen. Um dies zu vermeiden, Unter Android 8.0 und höher wurden neue Funktionen implementiert, um die Patchgröße für jedes Gerät zu reduzieren. Dateiunterschied Zu den Verbesserungen, die die Größe des OTA-Update-Pakets reduziert haben, gehören folgende Verbesserungen:

  • Die Nutzung von ZSTD, einem allgemeinen, verlustfreien Komprimierungsalgorithmus für vollständige Bilder auf anderen Geräten als A/B-Updates. ZSTD kann für höhere Komprimierungsverhältnisse durch Erhöhen des Komprimierungsgrads. Die Komprimierungsstufe wird während des OTA-Updates eingestellt Erstellungszeit und kann festgelegt werden, indem das -Flag --vabc_compression_param=zstd,$COMPRESSION_LEVEL
  • Die Größe des Komprimierungsfensters für das OTA-Update wird erhöht. Die maximale Größe des Komprimierungsfensters Sie können ihn festlegen, indem Sie den Build-Parameter in der Datei .mk eines Geräts anpassen. Dieses Variable ist auf PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 262144 <ph type="x-smartling-placeholder">
  • Verwendung der Puffin-Komprimierung, einem deterministischen Patching-Tool zum Deflate Streams, die die Komprimierungs- und Diff-Funktionen für die Generierung von A/B-OTA-Updates verarbeiten.
  • Änderungen an der Verwendung des Tools zur Deltagenerierung, z. B. die Art und Weise, bsdiff wird zur Komprimierung von Patches verwendet. Unter Android 9 und höher bsdiff-Tool den Komprimierungsalgorithmus auswählt, die besten Komprimierungsergebnisse für einen Patch.
  • Verbesserungen am update_engine führte zu einem geringeren Arbeitsspeicherverbrauch, wenn Patches für A/B-Geräteupdates angewendet werden.

In den folgenden Abschnitten werden verschiedene Probleme, die sich auf die Größe von OTA-Updates auswirken, und Beispiele für die Implementierung in AOSP.

Dateireihenfolge

Problem: Dateisysteme garantieren nicht die Reihenfolge der Dateien, wenn sie nach einer Liste von Dateien gefragt werden. in einem Verzeichnis gespeichert, auch wenn dies für denselben Bezahlvorgang in der Regel identisch ist. Tools wie ls sortiert die Ergebnisse standardmäßig, aber die Platzhalterfunktion für Befehle wie da find und make nicht sortiert werden. Bevor Sie diese Tools verwenden können, müssen Sie die Ausgaben.

Lösung: Wenn Sie Tools wie find und make mit der Platzhalterfunktion die Ausgabe dieser Befehle, bevor Sie . Bei Verwendung von $(wildcard) oder $(shell find) in Android.mk Dateien ebenfalls sortiert. Einige Tools, wie z. B. Java, sortieren Eingaben, sodass bevor Sie die Dateien sortieren, vergewissern Sie sich, dass das von Ihnen verwendete Tool dies nicht bereits getan hat.

Beispiele: Viele Instanzen wurden im Core-Build-System mithilfe der Funktion integriertes all-*-files-under-Makro, das Folgendes beinhaltet: all-cpp-files-under (da mehrere Definitionen in anderen Makefiles verteilt waren). Weitere Informationen:

Build-Verzeichnis

Problem:Wenn Sie das Verzeichnis ändern, in dem die Elemente erstellt werden, kann das dazu führen, dass die Binärdateien unterschiedlich sind. Die meisten Pfade im Android-Build sind relative Pfade, sodass __FILE__ in C/C++ ist kein Problem. Mit den Debug-Symbolen wird jedoch Pfadname standardmäßig und der .note.gnu.build-id wird durch das Hashen der vorab entfernte Binärdatei, sodass sie sich ändert, wenn sich die Symbole zum Debuggen ändern.

Lösung:AOSP macht Debug-Pfade jetzt relativ. Weitere Informationen finden Sie im CL: https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02

Zeitstempel

Problem:Zeitstempel in der Build-Ausgabe führen zu unnötigen Dateiänderungen. Das passiert wahrscheinlich an folgenden Orten:

  • __DATE__/__TIME__/__TIMESTAMP__-Makros in C- oder C++-Code.
  • In ZIP-basierte Archive eingebettete Zeitstempel

Lösungen/Beispiele: Um Zeitstempel aus der Build-Ausgabe zu entfernen, verwenden Sie die Methode finden Sie weiter unten im __DATE__/__TIME__/__TIMESTAMP__ in C/C++. und Eingebettete Zeitstempel in Archiven:

__DATE__/__TIME__/__TIMESTAMP__ in C/C++

Diese Makros erzeugen immer unterschiedliche Ausgaben für verschiedene Builds und sollten daher nicht verwendet werden. Hier können Sie diese Makros mit folgenden Optionen entfernen:

<ph type="x-smartling-placeholder">

Eingebettete Zeitstempel in Archiven (ZIP, JAR)

In Android 7.0 wurde das Problem mit eingebetteten Zeitstempeln in ZIP-Archiven behoben, indem -X für alle Verwendungen des Befehls zip. Dadurch wurde die UID/GID der und den erweiterten Unix-Zeitstempel aus der ZIP-Datei.

Das neue Tool ziptime (in /platform/build/+/main/tools/ziptime/) setzt die normalen Zeitstempel in den ZIP-Headern zurück. Weitere Informationen finden Sie in der README-Datei.

Das signapk-Tool legt Zeitstempel für die APK-Dateien fest. Diese können je nach Zeitzone des Servers. Weitere Informationen finden Sie im CL. <ph type="x-smartling-placeholder"></ph> https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028

Das signapk-Tool legt Zeitstempel für die APK-Dateien fest. Diese können je nach Zeitzone des Servers. Weitere Informationen finden Sie im CL. https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.

Versionsstrings

Problem:An APK-Versionsstrings war oft das BUILD_NUMBER angehängt. ihre hartcodierten Versionen. Selbst wenn sich folglich nichts anderes in einem APK geändert hat, immer noch anders sein.

Lösung:Entfernen Sie die Build-Nummer aus dem APK-Versionsstring.

Beispiele:

Verifizierung der Integrität auf dem Gerät aktivieren

Wenn dm-verity aktiviert ist, übernehmen die OTA-Tools automatisch deine Versionskonfiguration und die On-Device-Zuverlässigkeitsberechnung zu aktivieren. Dadurch können Prüfungsblöcke unter Android berechnet werden und werden nicht als Rohbyte im OTA-Paket gespeichert. Verity-Blöcke können ca. 16 MB für eine 2-GB-Partition.

Allerdings kann die Computing-Zuverlässigkeit auf dem Gerät sehr lange dauern. Die Forward API Der Fehlerkorrekturcode kann sehr lange dauern. Auf Pixel-Geräten dauert dies in der Regel bis zu 10 Minuten. Auf Low-End-Geräten kann es länger dauern. Wenn Sie die On-Device-Version deaktivieren möchten und dm-verity dennoch aktivieren, können Sie dies tun, indem Sie --disable_fec_computation an das ota_from_target_files-Tool, wenn das Generieren eines OTA-Updates. Dieses Flag deaktiviert die On-Device-Berechnung der Version während OTA-Updates. Dadurch wird die OTA-Installationszeit verringert, aber die Größe des OTA-Pakets erhöht. Wenn Ihr Gerät nicht dm-verity aktiviert haben, hat das Übergeben dieses Flags keine Auswirkungen.

Einheitliche Build-Tools

Problem:Tools, die installierte Dateien generieren, müssen einheitlich sein (eine bestimmte Eingabe immer dieselbe Ausgabe erzeugen).

Lösungen/Beispiele:An den folgenden Build-Tools waren Änderungen erforderlich:

Tool „Build diff“ verwenden

In Fällen, in denen es nicht möglich ist, build-bezogene Dateiänderungen zu eliminieren, enthält AOSP eine „build diff“-Tool, target_files_diff.py zum Vergleich von zwei Dateipaketen. Dieses Tool führt eine rekursive Differenz zwischen zwei Builds erstellt werden. Hiervon ausgenommen sind allgemeine Build-bezogene Dateiänderungen wie

  • Erwartete Änderungen in der Build-Ausgabe (z. B. aufgrund einer Änderung der Build-Nummer)
  • Änderungen aufgrund bekannter Probleme im aktuellen Build-System.

Führen Sie den folgenden Befehl aus, um das Tool „build diff“ zu verwenden:

target_files_diff.py dir1 dir2

dir1 und dir2 sind Basisverzeichnisse, die das extrahierte Ziel enthalten für jeden Build.

Blockierungen einheitlich zuweisen

Auch wenn der Inhalt einer bestimmten Datei bei zwei Builds gleich bleibt, werden die die die Daten enthalten, haben sich möglicherweise geändert. Der Updater muss daher unnötige E/A-Vorgänge ausführen. um die Blöcke für ein OTA-Update zu verschieben.

Bei einem Virtual A/B OTA-Update können unnötige E/A-Vorgänge den erforderlichen Speicherplatz erheblich erhöhen. um den Copy-on-Write-Snapshot zu speichern. Bei einem Nicht-A/B-OTA-Update wird das Verschieben der Blöcke für eine OTA-Updates tragen zur Aktualisierungszeit bei, da aufgrund von Blockverschiebungen mehr E/A-Vorgänge stattfinden.

Um dieses Problem zu beheben, hat Google in Android 7.0 das make_ext4fs-Tool für damit die Blockzuweisung über alle Builds hinweg konsistent ist. Das make_ext4fs-Tool akzeptiert Ein optionales -d base_fs-Flag, das versucht, Dateien denselben Blöcken zuzuweisen wenn ein ext4-Bild generiert wird. Sie können die Blockzuordnungsdateien (z. B. base_fs-Zuordnungsdateien) aus den Zieldateien eines vorherigen Builds ZIP-Datei. Für jede Partition ext4 befindet sich die Datei .map im IMAGES-Verzeichnis (z. B. entspricht IMAGES/system.map dem system). Diese base_fs Dateien können dann eingecheckt werden und wie in diesem Beispiel über PRODUCT_<partition>_BASE_FS_PATH angegeben: 

  PRODUCT_SYSTEM_BASE_FS_PATH := path/to/base_fs_files/base_system.map
  PRODUCT_SYSTEM_EXT_BASE_FS_PATH := path/to/base_fs_files/base_system_ext.map
  PRODUCT_VENDOR_BASE_FS_PATH := path/to/base_fs_files/base_vendor.map
  PRODUCT_PRODUCT_BASE_FS_PATH := path/to/base_fs_files/base_product.map
  PRODUCT_ODM_BASE_FS_PATH := path/to/base_fs_files/base_odm.map

Dies reduziert zwar nicht die Gesamtgröße des OTA-Pakets, verbessert aber die OTA-Aktualisierung. indem Sie den E/A-Aufwand reduzieren. Bei virtuellen A/B-Updates wird die wie viel Speicherplatz zum Anwenden des OTA-Speichers erforderlich ist.

App-Updates vermeiden

Sie können nicht nur Build-Unterschiede minimieren, sondern auch die Größe von OTA-Updates reduzieren, indem Sie Updates ausschließen. für Apps, die Updates über App-Shops erhalten. APKs machen häufig einen erheblichen Teil verschiedene Partitionen auf einem Gerät. Einschließlich der neuesten App-Versionen, die von der App aktualisiert werden bei einem OTA-Update große Auswirkungen auf die Größe des OTA-Pakets haben und profitieren. Wenn die Nutzer ein OTA-Paket erhalten haben, haben sie möglicherweise bereits die aktualisierte App oder eine noch neuere Version, die direkt aus den App-Shops bezogen wurde.