Cette page a été traduite par l'API Cloud Translation.

Créer des packages OTA

Vous pouvez utiliser le ota_from_target_files fourni dans build/make/tools/releasetools pour créer des applications complètes et incrémentielles Packages OTA pour les appareils qui utilisent des mises à jour du système A/B ou mises à jour système non-A/B. L'outil prend le Fichier target-files.zip produit en entrée par le système de compilation Android.

Pour les appareils équipés d'Android 11 ou version ultérieure, vous pouvez compiler un package OTA pour plusieurs appareils avec différents SKU. Pour ce faire, configurer les appareils cibles de sorte qu'ils utilisent des empreintes dynamiques ; et mise à jour des métadonnées OTA pour inclure l'appareil. le nom et l'empreinte dans les entrées pre et postcondition.

Les packages OTA basés sur les fichiers sont obsolètes sous Android 8.0 pour les appareils non A/B, qui doivent Utilisez plutôt des packages OTA basés sur des blocs. À générer des packages OTA par bloc ou des appareils équipés d'Android 7.x ou version antérieure, transmettre l'option --block vers le paramètre ota_from_target_files.

Compiler les mises à jour complètes

Une mise à jour complète est un package OTA qui contient l'intégralité de l'état final (partitions système, de démarrage et de récupération). Tant que l'appareil est capable de réception et d'application du package, celui-ci peut installer quel que soit l'état actuel de l'appareil. Par exemple : utilisent les outils de publication pour créer l'archive target-files.zip pour le tardis appareil.

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

make dist crée un package OTA complet (dans $OUT). Le fichier .zip obtenu contient tout ce qui est nécessaire pour créer des packages OTA pour l'appareil tardis. Vous pouvez également compiler ota_from_target_files en tant que binaire Python et l'appeler pour des packages complets ou incrémentiels.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

Le chemin d'accès ota_from_target_files est configuré dans $PATH, et l'objet Python se trouve dans le répertoire out/.

ota_update.zip est maintenant prêt à être envoyé aux appareils de test (tout est signé) avec la clé de test). Pour les appareils des utilisateurs, générez et utilisez vos propres clés privées détaillé dans Signer les builds en vue de la publication.

Compiler des mises à jour incrémentielles

Une mise à jour incrémentielle est un package OTA qui contient des correctifs binaires sur les données. déjà sur l'appareil. Les packages avec mises à jour incrémentielles sont généralement plus petits car ils n'ont pas besoin d'inclure de fichiers non modifiés. De plus, comme les fichiers modifiés sont souvent très similaires à leurs versions précédentes, le package ne doit inclure un encodage des différences entre les deux fichiers.

Vous ne pouvez installer un package de mise à jour incrémentielle que sur les appareils dotés du la compilation source utilisée dans la construction du package. Pour créer une mise à jour incrémentielle, vous avez besoin du fichier target_files.zip de la compilation précédente (celle que vous souhaitez pour mettre à jour from), ainsi que le fichier target_files.zip à partir de la nouvelle compilation. Pour exemple, les commandes suivantes utilisent des outils de publication pour créer une mise à jour incrémentielle pour l'appareil tardis.

ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

Cette compilation est très semblable à la précédente, et la mise à jour incrémentielle le package (incremental_ota_update.zip) est bien plus petit que le package mise à jour complète (environ 1 Mo au lieu de 60 Mo).

Distribuez un package incrémentiel uniquement aux appareils qui exécutent exactement la même la compilation précédente utilisée comme point de départ du package incrémentiel. Vous devez flasher les images dans PREVIOUS-tardis-target_files.zip ou PREVIOUS-tardis-img.zip (tous deux créés avec make dist, à flasher avec fastboot update), au lieu de ceux du répertoire PRODUCT_OUT (créés avec make, qui seront flashé avec fastboot flashall). Tentative d'installation du package incrémentiel sur un appareil avec un autre build entraîne une erreur d'installation. Lorsque l'installation échoue, l'appareil reste dans le même état de fonctionnement (en exécutant système) ; le package vérifie l'état précédent de tous les fichiers qu'il met à jour avant de les toucher, afin que l’appareil ne soit pas coincé dans un état à moitié mis à niveau.

Pour une expérience utilisateur optimale, proposez une mise à jour complète tous les trois ou quatre mises à jour. Cela permet aux utilisateurs de rattraper leur retard sur la dernière version et d'éviter d'installation des mises à jour incrémentielles.

Créez des packages OTA pour plusieurs SKU.

Android 11 ou version ultérieure prend en charge l'utilisation d'une seule OTA pour plusieurs appareils avec différents SKU. Pour ce faire, vous devez configurer aux appareils cibles d'utiliser les empreintes dynamiques et de mettre à jour les métadonnées OTA (à l'aide des outils OTA) pour inclure le nom et l'empreinte de l'appareil avant et après Entrées de condition.

À propos des SKU

Le format d'un SKU est une variante de la commande combinée paramètre et est généralement un sous-ensemble non déclaré des paramètres build_fingerprint actuels. Les OEM peuvent utiliser n'importe quelle combinaison de paramètres de compilation approuvés par le CDD pour un SKU, tout en également en utilisant une seule image pour ces SKU. Par exemple, le SKU suivant a plusieurs variantes:

SKU = <product><device><modifierA><modifierB><modifierC>

modifierA est le niveau de l'appareil (par exemple, Pro, Premium ou Plus)
modifierB est la variante matérielle (par exemple, radio)
modifierC est la région, qui peut être une valeur (par exemple, NA, EMEA ou CHN) ou selon un pays ou une langue spécifique (par exemple, JPN, AN ou CHN)

De nombreux OEM utilisent une seule image pour plusieurs SKU, puis extraient le produit final. et l'empreinte de l'appareil au moment de l'exécution, après le démarrage de l'appareil. Ce processus simplifie le processus de développement de la plate-forme en permettant aux appareils personnalisations, mais des noms de produits différents pour partager des images communes (comme tardis et tardispro).

Utiliser des empreintes dynamiques

Une empreinte est une concaténation définie de build paramètres tels que ro.product.brand, ro.product.name et ro.product.device. L'empreinte digitale d'un appareil est dérivée de l'empreinte de la partition système et est utilisée comme l'identifiant unique des images (et des octets) exécutées sur l'appareil. Pour créer un dynamique, utilisez la logique dynamique dans le fichier build.prop de l'appareil pour obtenir la valeur des variables du bootloader au moment du démarrage de l'appareil, puis utiliser ces données pour créer une empreinte dynamique pour cet appareil.

Par exemple, pour utiliser des empreintes dynamiques sur les appareils tardis et tardispro, modifiez les fichiers suivants comme indiqué ci-dessous.

Mettez à jour le fichier odm/etc/build_std.prop pour qu'il contienne la ligne suivante.
```
ro.odm.product.device=tardis
```
Mettez à jour le fichier odm/etc/build_pro.prop pour qu'il contienne la ligne suivante.
```
ro.odm.product.device=tardispro
```

Mettez à jour le fichier odm/etc/build.prop pour qu'il contienne les lignes suivantes.

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

Ces lignes définissent de façon dynamique le nom de l'appareil, son empreinte Valeurs ro.build.fingerprint en fonction de la valeur du Propriété du bootloader ro.boot.product.hardware.sku (qui est en lecture seule).

Mettre à jour les métadonnées du package OTA

Un package OTA contient un fichier de métadonnées (META-INF/com/android/metadata) qui décrit le package, y compris la condition préalable et l'état post-condition de l'OTA d'un package. Par exemple, le code suivant est le fichier de métadonnées d'un package OTA. ciblant l'appareil tardis.

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

Les valeurs pre-device, pre-build-incremental et pre-build définissent état que doit avoir un appareil pour que le package OTA puisse être installé. La Les valeurs post-build-incremental et post-build définissent l'état d'un appareil. après l'installation du package OTA. Les valeurs de pre- et Les champs post- sont dérivés des propriétés de compilation correspondantes suivantes.

La valeur pre-device est dérivée de la propriété de compilation ro.product.device.
Les valeurs pre-build-incremental et post-build-incremental sont dérivées à partir de la propriété de compilation ro.build.version.incremental.
Les valeurs pre-build et post-build sont issues de la ro.build.fingerprint.

Sur les appareils équipés d'Android 11 ou version ultérieure, vous pouvez utiliser l'indicateur --boot_variable_file dans les outils OTA pour spécifier un chemin d'accès à un fichier contient les valeurs des variables d'exécution utilisées pour créer le empreinte dynamique. Ces données sont ensuite utilisées pour mettre à jour les métadonnées OTA afin d'inclure le nom et l'empreinte de l'appareil dans les conditions pre- et post- (à l'aide de la méthode barre verticale | comme délimiteur). L'indicateur --boot_variable_file comporte les la syntaxe et la description suivantes.

Syntaxe : --boot_variable_file <path>
Description: spécifie le chemin d'accès à un fichier contenant les valeurs possibles de ro.boot.*. Permet de calculer les empreintes d'exécution possibles Lorsque certaines propriétés ro.product.* sont remplacées par l'instruction d'importation. Le fichier attend une propriété par ligne, chaque ligne contenant les éléments suivants : format: prop_name=value1,value2.

Par exemple, lorsque la propriété est ro.boot.product.hardware.sku=std,pro, Les métadonnées OTA pour les appareils tardis et tardispro sont présentées ci-dessous.

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

Pour prendre en charge cette fonctionnalité sur les appareils équipés d'Android 10, consultez la documentation de référence l'implémentation. Cette liste de modifications analyse de manière conditionnelle les instructions import dans le build.prop. , ce qui permet de reconnaître et de refléter les remplacements de propriété les métadonnées OTA finales.