Vous pouvez utiliser l'outil ota_from_target_files
fourni dans build/make/tools/releasetools
pour créer des packages OTA complets et incrémentiels pour les appareils qui utilisent des mises à jour système A/B ou des mises à jour système non-A/B . L'outil prend en entrée le fichier target-files.zip
produit par le système de build Android.
Pour les appareils exécutant Android 11 ou version ultérieure, vous pouvez créer un package OTA pour plusieurs appareils avec des SKU différents. Cela nécessite de configurer les appareils cibles pour utiliser des empreintes digitales dynamiques et de mettre à jour les métadonnées OTA pour inclure le nom de l'appareil et l'empreinte digitale dans les entrées de pré et postcondition.
Android 8.0 a rendu les packages OTA basés sur des fichiers obsolètes pour les appareils non A/B, qui doivent à la place utiliser des packages OTA basés sur des blocs . Pour générer des packages OTA basés sur des blocs ou des appareils exécutant Android 7.x ou une version antérieure, transmettez l'option --block
au paramètre ota_from_target_files
.
Créer des mises à jour complètes
Une mise à jour complète est un package OTA qui contient l'intégralité de l'état final du périphérique (partitions système, de démarrage et de récupération). Tant que l'appareil est capable de recevoir et d'appliquer le package, celui-ci peut installer la version quel que soit l'état actuel de l'appareil. Par exemple, les commandes suivantes utilisent des outils de publication pour créer l'archive target-files.zip
pour le périphérique tardis
.
. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output
make dist
construit un package OTA complet (dans $OUT
). Le fichier .zip
résultant contient tout le nécessaire pour créer des packages OTA pour le périphérique tardis
. Vous pouvez également créer ota_from_target_files
en tant que binaire python et l'appeler pour créer des packages complets ou incrémentiels.
ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip
Le chemin ota_from_target_files
est configuré dans $PATH
et le binaire python résultant 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 utilisateur, générez et utilisez vos propres clés privées comme détaillé dans Signature des versions pour la version .
Créer des mises à jour incrémentielles
Une mise à jour incrémentielle est un package OTA qui contient des correctifs binaires pour les données déjà présentes sur l'appareil. Les packages avec des mises à jour incrémentielles sont généralement plus petits car ils n'ont pas besoin d'inclure des fichiers inchangés. De plus, comme les fichiers modifiés sont souvent très similaires à leurs versions précédentes, le package doit uniquement inclure un encodage des différences entre les deux fichiers.
Vous pouvez installer un package de mise à jour incrémentielle uniquement sur les appareils sur lesquels la version source est utilisée lors de la construction du package. Pour créer une mise à jour incrémentielle, vous avez besoin du fichier target_files.zip
de la version précédente (celui à partir duquel vous souhaitez mettre à jour) ainsi que du fichier target_files.zip
de la nouvelle version. Par exemple, les commandes suivantes utilisent des outils de publication pour créer une mise à jour incrémentielle pour le périphérique tardis
.
ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip
Cette version est très similaire à la version précédente et le package de mise à jour incrémentielle ( incremental_ota_update.zip
) est beaucoup plus petit que la mise à jour complète correspondante (environ 1 Mo au lieu de 60 Mo).
Distribuez un package incrémentiel uniquement aux appareils qui exécutent exactement la même version 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 construits avec make dist
, à flasher avec fastboot update
), au lieu de celles du répertoire PRODUCT_OUT
(construit avec make
, qui sera flashé avec fastboot flashall
). Toute tentative d'installation du package incrémentiel sur un appareil avec une autre version entraîne une erreur d'installation. Lorsque l'installation échoue, l'appareil reste dans le même état de fonctionnement (exécutant l'ancien système) ; le package vérifie l'état précédent de tous les fichiers qu'il met à jour avant de les toucher, de sorte que l'appareil ne soit pas bloqué dans un état à moitié mis à niveau.
Pour une expérience utilisateur optimale, proposez une mise à jour complète toutes les 3 à 4 mises à jour incrémentielles. Cela aide les utilisateurs à se tenir au courant de la dernière version et à éviter une longue séquence d'installation de mises à jour incrémentielles.
Créez des packages OTA pour plusieurs SKU
Android 11 ou version ultérieure prend en charge l'utilisation d'un seul package OTA pour plusieurs appareils avec des SKU différents. Cela nécessite de configurer les appareils cibles pour utiliser des empreintes digitales dynamiques et de mettre à jour les métadonnées OTA (à l'aide des outils OTA) pour inclure le nom de l'appareil et l'empreinte digitale dans les entrées de condition préalable et postérieure.
À propos des SKU
Le format d'un SKU est une variation des valeurs combinées des paramètres de construction et constitue 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 construction approuvés par le CDD pour un SKU tout en utilisant également 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 (tel que Pro, Premium ou Plus) -
modifierB
est la variante matérielle (telle que la radio) -
modifierC
est la région, qui peut être générale (comme NA, EMEA ou CHN ) ou spécifique à un pays ou à une langue (comme JPN, ENG ou CHN)
De nombreux OEM utilisent une seule image pour plusieurs SKU, puis dérivent le nom final du produit et l'empreinte digitale 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, permettant aux appareils avec des personnalisations mineures mais des noms de produits différents de partager des images communes (telles que tardis
et tardispro
).
Utiliser des empreintes digitales dynamiques
Une empreinte digitale est une concaténation définie de paramètres de construction tels que ro.product.brand
, ro.product.name
et ro.product.device
. L'empreinte digitale d'un périphérique est dérivée de l'empreinte digitale de la partition système et est utilisée comme identifiant unique des images (et des octets) exécutées sur le périphérique. Pour créer une empreinte dynamique , utilisez la logique dynamique dans le fichier build.prop
du périphérique pour obtenir la valeur des variables du chargeur de démarrage au moment du démarrage du périphérique, puis utilisez ces données pour créer une empreinte dynamique pour ce périphérique.
Par exemple, pour utiliser des empreintes digitales dynamiques pour les appareils tardis
et tardispro
, mettez à jour 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 dynamiquement les valeurs du nom du périphérique, de l'empreinte digitale et ro.build.fingerprint
en fonction de la valeur de la propriété du chargeur de démarrage 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 précondition et la postcondition du package OTA. Par exemple, le code suivant est le fichier de métadonnées d'un package OTA ciblant le périphérique 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 l'état qu'un périphérique doit avoir avant que le package OTA puisse s'installer. Les valeurs post-build-incremental
et post-build
définissent l'état qu'un périphérique est censé avoir après l'installation du package OTA. Les valeurs des champs pre-
et post-
sont dérivées des propriétés de construction correspondantes suivantes.
- La valeur
pre-device
est dérivée de la propriété de constructionro.product.device
. - Les valeurs
pre-build-incremental
etpost-build-incremental
sont dérivées de la propriété de constructionro.build.version.incremental
. - Les valeurs
pre-build
etpost-build
sont dérivées de la propriété de constructionro.build.fingerprint
.
Sur les appareils exécutant 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 contenant les valeurs des variables d'exécution utilisées pour créer l'empreinte dynamique de l'appareil. Les données sont ensuite utilisées pour mettre à jour les métadonnées OTA afin d'inclure le nom de l'appareil et l'empreinte digitale dans les conditions pre-
et post-
(en utilisant le caractère barre verticale | comme délimiteur). L'indicateur --boot_variable_file
a la syntaxe et la description suivantes.
- Syntaxe :
--boot_variable_file <path>
- Description : Spécifie un chemin d'accès à un fichier contenant les valeurs possibles des propriétés
ro.boot.*
. Utilisé pour calculer les empreintes digitales d'exécution possibles lorsque certaines propriétésro.product.*
sont remplacées par l'instruction d'importation. Le fichier attend une propriété par ligne, chaque ligne ayant le format suivant :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 comme indiqué 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 exécutant Android 10, consultez l' implémentation de référence . Cette liste de modifications analyse conditionnellement les instructions import
dans le fichier build.prop
, ce qui permet de reconnaître et de refléter les remplacements de propriétés dans les métadonnées OTA finales.