Réduire la taille de l'OTA

Cette page décrit les modifications ajoutées à AOSP pour réduire les modifications de fichiers inutiles entre les compilations. Les responsables de l'implémentation d'appareils qui gèrent leurs propres systèmes de compilation peuvent s'inspirer de ces informations. pour réduire la taille de leurs mises à jour Over The Air (OTA).

Les mises à jour OTA d'Android contiennent parfois des fichiers modifiés qui ne correspondent pas aux changements du code. Il s'agit en fait d'artefacts système de compilation. Cela peut se produire lorsque le même code, compilé à différents niveaux à partir de répertoires ou de machines différents produit un grand nombre de modifications . Ces fichiers en trop augmentent la taille d'un correctif OTA et rendent difficile son identification quel code a été modifié.

Pour rendre le contenu d'une OTA plus transparent, AOSP inclut des modifications du système de compilation conçues pour réduire la taille des correctifs OTA. Des modifications inutiles ont été apportées au fichier et seuls les fichiers liés aux correctifs sont contenus dans les mises à jour OTA. AOSP comprend également outil de comparaison de compilation, qui filtre les différences de compilation courantes les modifications de fichiers pour fournir une différence plus propre dans le fichier de compilation, outil de mappage de blocs, qui vous aide à conserver l'allocation de blocs cohérentes.

Un système de compilation peut créer des correctifs inutilement volumineux de plusieurs manières. Pour atténuer ce problème, dans Sur Android 8.0 et versions ultérieures, de nouvelles fonctionnalités ont été ajoutées afin de réduire la taille du correctif pour chaque diff. Voici les améliorations qui ont permis de réduire la taille des packages OTA-update:

  • Utilisation de Brotli, un algorithme de compression sans perte à usage générique pour des sur les mises à jour d'appareils non A/B. Vous pouvez personnaliser Brotli afin d'optimiser la compression. Pour les mises à jour plus importantes composées d'au moins deux blocs dans le système de fichiers (par exemple, system.img), les fabricants d'appareils ou les partenaires peuvent ajouter leurs propres et peut utiliser différents algorithmes de compression sur différents blocs de la même mise à jour.
  • Utilisation de la recompression Puffin, un outil d'application de correctifs déterministe pour le dégâtnement flux, qui gère les fonctions de compression et de différence pour la génération de mises à jour OTA A/B.
  • Modifications apportées à l'utilisation de l'outil de génération delta, telles que la manière dont bsdiff est utilisée pour compresser les correctifs. Sur Android 9 ou version ultérieure, L'outil bsdiff sélectionne l'algorithme de compression les meilleurs résultats de compression pour un correctif.
  • Améliorations apportées à la update_engine a entraîné une réduction de la consommation de mémoire lors de l'application de correctifs pour les mises à jour A/B des appareils.
  • Améliorations apportées à la division des fichiers ZIP volumineux pour les mises à jour OTA par bloc. Un mode dans imgdiff divise les fichiers APK surdimensionnés en fonction des noms d'entrée. Cela produit un correctif plus petit fractionnement linéaire des fichiers et utilisation de l'outil bsdiff pour les compresser.

Les sections suivantes traitent de différents problèmes qui affectent la taille des mises à jour OTA, leurs solutions, et des exemples d'implémentation dans AOSP.

Ordre des fichiers

Problème: les systèmes de fichiers ne garantissent pas l'ordre des fichiers lorsqu'une liste de fichiers dans un répertoire, bien que cela soit généralement le même pour le même paiement. Des outils tels que ls trie les résultats par défaut, mais la fonction de caractère générique utilisée par les commandes telles que que find et make ne sont pas triées. Avant d'utiliser ces outils, vous devez trier les sorties.

Solution: lorsque vous utilisez des outils tels que find et make avec la fonction de caractère générique, triez le résultat de ces commandes avant d'utiliser de l'IA générative. Lorsque vous utilisez $(wildcard) ou $(shell find) dans Android.mk fichiers, triez-les également. Certains outils, comme Java, trient les entrées, Avant de trier les fichiers, vérifiez que l'outil que vous utilisez ne l'a pas déjà fait.

Exemples:De nombreuses instances ont été corrigées dans le système de compilation principal à l'aide de l' all-*-files-under intégrée, qui inclut all-cpp-files-under (car plusieurs définitions ont été réparties dans d'autres fichiers makefile). Pour en savoir plus, consultez les ressources suivantes:

Répertoire de compilation

Problème:la modification du répertoire dans lequel les éléments sont compilés peut entraîner l'erreur les binaires soient différents. La plupart des chemins d'accès dans le build Android sont des chemins relatifs. __FILE__ en C/C++ n'est pas un problème. Toutefois, les symboles de débogage encodent l'intégralité pathname par défaut, et le .note.gnu.build-id est généré en hachant le binaire pré-effacé, qui change donc si les symboles de débogage changent.

Solution:AOSP rend désormais les chemins de débogage relatifs. Pour en savoir plus, consultez CL: https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02.

Codes temporels

Problème:les horodatages dans le résultat de la compilation entraînent des modifications inutiles dans les fichiers. Ce problème est susceptible de se produire dans les pays suivants:

  • __DATE__/__TIME__/__TIMESTAMP__ en code C ou C++.
  • Codes temporels intégrés aux archives ZIP.

Solutions/Exemples:Pour supprimer des horodatages dans la sortie de compilation, utilisez la méthode les instructions fournies ci-dessous dans __DATE__/__TIME__/__TIMESTAMP__ en C/C++. et Horodatages intégrés dans les archives :

__DATE__/__TIME__/__TIMESTAMP__ en C/C++

Ces macros produisent toujours des sorties différentes selon les builds. Par conséquent, nous vous déconseillons de les utiliser. Ici, plusieurs options permettent de les supprimer:

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

Codes temporels intégrés dans les archives (ZIP, JAR)

Android 7.0 a résolu le problème des horodatages intégrés dans les archives zip en ajoutant -X à toutes les utilisations de la commande zip. Cette opération a supprimé l'UID/GID du et le code temporel Unix étendu du fichier zip.

Un nouvel outil, ziptime (situé dans /platform/build/+/main/tools/ziptime/) réinitialise les codes temporels normaux dans les en-têtes ZIP. Pour en savoir plus, consultez les Fichier README.

L'outil signapk définit les codes temporels des fichiers APK qui peuvent varier en fonction le fuseau horaire du serveur. Pour en savoir plus, consultez la https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.

Chaînes de version

Problème:BUILD_NUMBER était souvent ajouté aux chaînes des versions d'APK à leurs versions codées en dur. Même si rien d'autre n'a changé dans un APK, l'APK serait différente.

Solution:supprimez le numéro de build de la chaîne de version de l'APK.

Exemples:

Activer le calcul de vérification sur l'appareil

Si dm-verity est activé sur votre appareil, les outils OTA récupèrent automatiquement votre configuration de vérification et activer le calcul de vérification sur l'appareil. Cela permet de calculer les blocs de vérification sur Android au lieu d'être stockés sous forme d'octets bruts dans votre package OTA. Les blocs de vérification peuvent utiliser environ 16 Mo pour une partition de 2 Go.

Toutefois, le calcul de la vérification sur l'appareil peut prendre beaucoup de temps. Plus précisément, la fonction La correction des erreurs peut prendre beaucoup de temps. Sur les appareils Pixel, minutes. Sur les appareils bas de gamme, cela peut prendre plus de temps. Si vous souhaitez désactiver la vérification sur l'appareil les calculs tout en activant dm-verity, vous pouvez le faire en transmettant --disable_fec_computation à l'outil ota_from_target_files lorsque la génération d'une mise à jour OTA. Cet indicateur désactive le calcul de vérification sur l'appareil lors des mises à jour OTA. Cela réduit le temps d'installation de l'OTA, mais augmente la taille du package OTA. Si votre appareil ne si dm-verity est activé, la transmission de cet indicateur n'a aucun effet.

Outils de compilation cohérents

Problème:les outils qui génèrent les fichiers installés doivent être cohérents (une doivent toujours produire la même sortie).

Solutions/Exemples:des modifications ont été nécessaires dans les outils de compilation suivants:

Utiliser l'outil Build Diff

Dans les cas où il est impossible d'éliminer les modifications de fichiers liées à la compilation, AOSP inclut un de compilation des différences, target_files_diff.py à utiliser pour comparer deux packages de fichiers. Cet outil effectue une différence récursive entre deux à l'exclusion des modifications courantes apportées aux fichiers liées à la compilation, telles que

  • Modifications attendues dans la sortie de compilation (par exemple, en raison d'un changement de numéro de compilation).
  • Modifications dues à des problèmes connus dans le système de compilation actuel.

Pour utiliser l'outil Build diff, exécutez la commande suivante:

target_files_diff.py dir1 dir2

dir1 et dir2 sont des répertoires de base contenant la cible extraite. pour chaque compilation.

Maintenir la cohérence de l'allocation des blocs

Pour un fichier donné, bien que son contenu reste le même entre deux compilations, les blocs réels qui contiennent les données ont peut-être changé. Le programme de mise à jour doit donc effectuer pour déplacer les blocs pour une mise à jour OTA.

Dans une mise à jour OTA virtuelle A/B, des E/S inutiles peuvent augmenter considérablement l'espace de stockage nécessaire. pour stocker l'instantané de copie en écriture. Dans une mise à jour OTA non A/B, déplacer les blocs pour La mise à jour OTA contribue à augmenter la durée des mises à jour, car les E/S sont plus nombreuses en raison des déplacements de blocs.

Pour résoudre ce problème, Google a étendu l'outil make_ext4fs dans Android 7.0 à en gardant l'allocation de blocs cohérente entre les compilations. L'outil make_ext4fs accepte Un indicateur -d base_fs facultatif qui tente d'allouer des fichiers aux mêmes blocs lors de la génération d'une image ext4. Vous pouvez extraire les fichiers de mappage de blocs (tels que les fichiers de mappage base_fs) à partir des fichiers cibles d'une compilation précédente .zip. Pour chaque ext4, il y a un fichier .map dans Répertoire IMAGES (par exemple, IMAGES/system.map correspond au répertoire la partition system). Ces fichiers base_fs peuvent ensuite être enregistrés et spécifié via PRODUCT_<partition>_BASE_FS_PATH, comme dans cet exemple: 

  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

Bien que cela n'aide pas à réduire la taille globale du package OTA, cela améliore la mise à jour OTA. en réduisant le nombre d'E/S. Pour les mises à jour A/B virtuelles, il réduit considérablement d'espace de stockage nécessaire pour appliquer la mise à jour OTA.

Éviter de mettre à jour des applications

En plus de réduire les différences de compilation, vous pouvez réduire la taille des mises à jour OTA en excluant les mises à jour pour les applications mises à jour via les plates-formes de téléchargement d'applications. Les APK comprennent souvent une partie importante différentes partitions d'un appareil. Y compris les dernières versions des applications mises à jour par application les magasins d'une mise à jour OTA peuvent avoir un impact important sur les packages OTA et fournir peu d'utilisateurs avantageuse. Lorsque les utilisateurs reçoivent un package OTA, il est possible qu'ils disposent déjà de la mise à jour de l'application. une version encore plus récente, reçue directement des plates-formes de téléchargement d'applications.