Règles de fuseau horaire

Android 10 abandonne le mécanisme de mise à jour des données de fuseau horaire basé sur APK (disponible dans Android 8.1 et Android 9) et le remplace par un mécanisme de mise à jour de module basé sur APEX . AOSP 8.1 à 13 incluent toujours le code de plate-forme nécessaire aux OEM pour activer les mises à jour basées sur l'APK, de sorte que les appareils mis à niveau vers Android 10 peuvent toujours recevoir les mises à jour des données de fuseau horaire fournies par les partenaires via l'APK. Cependant, le mécanisme de mise à jour APK ne doit pas être utilisé sur un appareil de production qui reçoit également des mises à jour de modules, car une mise à jour basée sur APK remplace une mise à jour basée sur APEX (c'est-à-dire qu'un appareil ayant reçu une mise à jour APK ignorerait les mises à jour basées sur APEX). ).

Mises à jour du fuseau horaire (Android 10+)

Le module de données de fuseau horaire pris en charge dans Android 10 et versions ultérieures met à jour l'heure d'été (DST) et les fuseaux horaires sur les appareils Android, standardisant les données qui peuvent changer fréquemment pour des raisons religieuses, politiques et géopolitiques.

Les mises à jour utilisent le processus suivant :

  1. L'IANA publie une mise à jour de la base de données des fuseaux horaires publie une mise à jour en réponse à la modification par un ou plusieurs gouvernements d'une règle de fuseau horaire dans leur pays.
  2. Google ou le partenaire Android prépare une mise à jour du module Time Zone Data (fichier APEX) contenant les fuseaux horaires mis à jour.
  3. L'appareil de l'utilisateur final télécharge la mise à jour, redémarre, puis applique les modifications, après quoi les données de fuseau horaire de l'appareil contiennent les nouvelles données de fuseau horaire de la mise à jour.

Pour plus de détails sur les modules, voir Composants du système modulaire .

Mises à jour du fuseau horaire (Android 8.1–9)

Remarque : La fonctionnalité du mécanisme de mise à jour des données de fuseau horaire basé sur l'APK a été complètement supprimée à partir d'Android 14 et est introuvable dans le code source. Les partenaires doivent migrer entièrement vers le module Time Zone Mainline.

Dans Android 8.1 et Android 9, les OEM peuvent utiliser un mécanisme basé sur l'APK pour transmettre les données mises à jour des règles de fuseau horaire aux appareils sans nécessiter de mise à jour du système. Ce mécanisme permet aux utilisateurs de recevoir des mises à jour en temps opportun (prolongant ainsi la durée de vie utile d'un appareil Android) et permet aux partenaires Android de tester les mises à jour de fuseau horaire indépendamment des mises à jour de l'image système.

L'équipe des bibliothèques principales d'Android fournit les fichiers de données nécessaires à la mise à jour des règles de fuseau horaire sur un appareil Android d'origine. Les OEM peuvent choisir d'utiliser ces fichiers de données lors de la création de mises à jour de fuseau horaire pour leurs appareils ou peuvent créer leurs propres fichiers de données s'ils préfèrent. Dans tous les cas, les OEM conservent le contrôle de l’assurance qualité/des tests, du calendrier et du lancement des mises à jour des règles de fuseau horaire pour leurs appareils pris en charge.

Code source et données du fuseau horaire Android

Tous les appareils Android d'origine, même ceux qui n'utilisent pas cette fonctionnalité, ont besoin de données de règles de fuseau horaire et doivent être livrés avec un ensemble par défaut de données de règles de fuseau horaire dans la partition /system . Ces données sont ensuite utilisées par le code des bibliothèques suivantes dans l'arborescence des sources Android :

  • Le code géré de libcore/ (par exemple, java.util.TimeZone ) utilise les fichiers tzdata et tzlookup.xml .
  • Le code de bibliothèque natif dans bionic/ (par exemple, pour mktime , les appels système localtime) utilise le fichier tzdata .
  • Le code de la bibliothèque ICU4J/ICU4C dans external/icu/ utilise le fichier icu .dat .

Ces bibliothèques assurent le suivi des fichiers de superposition pouvant être présents dans le répertoire /data/misc/zoneinfo/current . Les fichiers de superposition devraient contenir des données améliorées sur les règles de fuseau horaire, permettant ainsi la mise à jour des appareils sans modifier /system .

Les composants du système Android qui nécessitent des données de règle de fuseau horaire vérifient d'abord les emplacements suivants :

  • libcore/ et bionic/ code utilisent la copie /data des fichiers tzdata et tzlookup.xml .
  • Le code ICU4J/ICU4C utilise les fichiers dans /data et revient aux fichiers /system pour les données qui ne sont pas présentes (pour les formats, les chaînes localisées, etc.).

Fichiers de distribution

Les fichiers Distro .zip contiennent les fichiers de données nécessaires pour remplir le répertoire /data/misc/zoneinfo/current . Les fichiers de distribution contiennent également des métadonnées qui permettent aux appareils de détecter les problèmes de version.

Le format du fichier de distribution dépend de la version Android, car le contenu change avec la version ICU, les exigences de la plate-forme Android et d'autres modifications de la version. Android fournit des fichiers de distribution pour les versions Android prises en charge pour chaque mise à jour de l'IANA (en plus de la mise à jour des fichiers système de la plateforme). Pour maintenir leurs appareils à jour, les OEM peuvent utiliser ces fichiers de distribution ou créer les leurs à l'aide de l'arborescence des sources Android (qui contient les scripts et autres fichiers nécessaires pour générer les fichiers de distribution).

Composants de mise à jour du fuseau horaire

Une mise à jour des règles de fuseau horaire implique la transmission de fichiers de distribution vers un appareil et l'installation sécurisée des fichiers qu'ils contiennent. Le transfert et l'installation nécessitent les éléments suivants :

  • Fonctionnalité du service de plateforme ( timezone.RulesManagerService ), qui est désactivée par défaut. Les OEM doivent activer la fonctionnalité via la configuration. RulesManagerService s'exécute dans le processus du serveur système et organise les opérations de mise à jour du fuseau horaire en écrivant dans /data/misc/zoneinfo/staged . RulesManagerService peut également remplacer ou supprimer des opérations déjà effectuées.
  • TimeZoneUpdater , une application système non pouvant être mise à jour (alias l' application Updater ). Les OEM doivent inclure cette application dans l’image système des appareils utilisant cette fonctionnalité.
  • OEM TimeZoneData , une application système pouvant être mise à jour (alias l' application Data ) qui transporte les fichiers de distribution sur l'appareil et les met à la disposition de l'application Updater. Les OEM doivent inclure cette application dans l’image système des appareils utilisant cette fonctionnalité.
  • tzdatacheck , un binaire de démarrage requis pour le fonctionnement correct et sûr des mises à jour de fuseau horaire.

L'arborescence des sources Android contient le code source générique pour les composants ci-dessus, que l'OEM peut choisir d'utiliser sans modification. Un code de test est fourni pour permettre aux OEM de vérifier automatiquement qu'ils ont correctement activé la fonctionnalité.

Installation de la distribution

Le processus d'installation de la distribution comprend les étapes suivantes :

  1. L'application de données est mise à jour via un téléchargement ou un chargement latéral sur l'App Store. Le processus du serveur système (via les classes timezone.RulesManagerServer/timezone.PackageTracker ) surveille les modifications apportées au nom du package d'application de données configuré et spécifique à l'OEM.

    Mises à jour de l'application de données
    Figure 1. Mises à jour de l'application de données
  2. Le processus du serveur système déclenche une vérification de mise à jour en diffusant une intention ciblée avec un jeton unique à usage unique à l'application Updater. Le serveur système garde une trace du jeton le plus récent qu'il a généré afin de pouvoir déterminer quand la vérification la plus récente qu'il a déclenchée est terminée ; tous les autres jetons sont ignorés.

    Déclencheur de mise à jour
    Figure 2. Déclencher la vérification de la mise à jour
  3. Lors de la vérification des mises à jour , l'application Updater effectue les tâches suivantes :
    • Interroge l’état actuel de l’appareil en appelant RulesManagerService.

      Appeler RulesManagerService
      Figure 3. Mises à jour de l'application de données, appelant RulesManagerService
    • Interroge l'application Data en interrogeant une URL ContentProvider et des spécifications de colonne bien définies pour obtenir des informations sur la distribution.

      Obtenir des informations sur la distribution
      Figure 4. Mises à jour de l'application de données, obtenez des informations sur la distribution
  4. L'application Updater prend l'action appropriée en fonction des informations dont elle dispose. Les actions disponibles incluent :
    • Demandez une installation. Les données de distribution sont lues à partir de l'application Data et transmises au RulesManagerService sur le serveur système. Le RulesManagerService reconfirme que la version et le contenu du format de distribution sont appropriés pour l'appareil et organise l'installation.
    • Demandez une désinstallation (c'est rare). Par exemple, si l'APK mis à jour dans /data est désactivé ou désinstallé et que l'appareil revient à la version présente dans /system .
    • Ne fais rien. Se produit lorsque la distribution de l'application Data s'avère invalide.
    Dans tous les cas, l'application Updater appelle RulesManagerService avec le jeton de vérification afin que le serveur système sache que la vérification est terminée et réussie.

    Vérification terminée
    Figure 5. Vérification terminée
  5. Redémarrez et tzdatacheck. Au prochain démarrage de l'appareil, le binaire tzdatacheck exécute toute opération par étapes. Le binaire tzdatacheck peut effectuer les tâches suivantes :
    • Exécutez l'opération par étapes en gérant la création, le remplacement et/ou la suppression des fichiers /data/misc/zoneinfo/current avant que d'autres composants du système ne soient ouverts et commencent à utiliser les fichiers.
    • Vérifiez que les fichiers dans /data sont corrects pour la version actuelle de la plate-forme, ce qui peut ne pas être le cas si l'appareil vient de recevoir une mise à jour du système et que la version du format de distribution a changé.
    • Assurez-vous que la version des règles IANA est identique ou plus récente que la version dans /system . Cela protège contre une mise à jour du système laissant un appareil avec des données de règles de fuseau horaire plus anciennes que celles présentes dans l'image /system .

Fiabilité

Le processus d'installation de bout en bout est asynchrone et réparti sur trois processus de système d'exploitation. À tout moment de l'installation, le périphérique peut perdre de l'alimentation, manquer d'espace disque ou rencontrer d'autres problèmes, ce qui rend la vérification de l'installation incomplète. Dans le meilleur des cas d’échec, l’application Updater informe le serveur système de l’échec ; dans le pire des cas, le RulesManagerService ne reçoit aucun appel.

Pour gérer cela, le code du serveur système indique si une vérification de mise à jour déclenchée est terminée et quel est le dernier code de version vérifié de l'application Data. Lorsque l'appareil est inactif et en charge, le code du serveur système peut vérifier l'état actuel. S'il découvre une vérification de mise à jour incomplète ou une version inattendue de Data App, il déclenche spontanément une vérification de mise à jour.

Sécurité

Lorsqu'il est activé, le code RulesManagerService dans le serveur système effectue plusieurs vérifications pour garantir que le système peut être utilisé en toute sécurité.

  • Les problèmes indiquant une image système mal configurée empêchent le démarrage d'un périphérique ; les exemples incluent une mauvaise configuration de l'application de mise à jour ou de données ou l'application de mise à jour ou de données ne se trouve pas dans /system/priv-app .
  • Les problèmes indiquant qu'une mauvaise application Data a été installée n'empêchent pas le démarrage d'un appareil, mais empêchent le déclenchement d'une vérification de mise à jour ; les exemples incluent un manque d’autorisations système requises ou l’application Data n’expose pas de ContentProvider sur l’URI attendu.

Les autorisations de fichiers pour les répertoires /data/misc/zoneinfo sont appliquées à l'aide des règles SELinux. Comme pour tout APK, l’application Data doit être signée par la même clé utilisée pour signer la version /system/priv-app . L’application Data devrait avoir un nom et une clé de package dédiés, spécifiques à l’OEM.

Intégration des mises à jour de fuseau horaire

Pour activer la fonctionnalité de mise à jour du fuseau horaire, les OEM :

  • Créez leur propre application de données.
  • Incluez les applications Updater et Data dans la création de l’image système.
  • Configurez le serveur système pour activer RulesManagerService.

En train de préparer

Avant de commencer, les OEM doivent examiner les considérations suivantes en matière de politique, d’assurance qualité et de sécurité :

  • Créez une clé de signature dédiée spécifique à l'application pour leur application de données.
  • Créez une stratégie de publication et de gestion des versions pour les mises à jour de fuseau horaire afin de comprendre quels appareils vont être mis à jour et comment ils peuvent garantir que les mises à jour ne sont installées que sur les appareils qui en ont besoin. Par exemple, les OEM peuvent souhaiter disposer d’une seule application de données pour tous leurs appareils ou choisir d’avoir différentes applications de données pour différents appareils. La décision a un impact sur le choix du nom du package, éventuellement sur les codes de version utilisés, et sur la stratégie d'assurance qualité.
  • Comprenez s’ils souhaitent utiliser les données de fuseau horaire Android d’AOSP ou créer les leurs.

Création d'une application de données

AOSP inclut tout le code source et les règles de construction nécessaires pour créer une application de données dans packages/apps/TimeZoneData , avec des instructions et des exemples de modèles pour AndroidManifest.xml et d'autres fichiers situés dans packages/apps/TimeZoneData/oem_template . Les exemples de modèles incluent à la fois une cible de construction pour le véritable APK de l'application Data et des cibles supplémentaires pour créer des versions de test de l'application Data.

Les OEM peuvent personnaliser l'application Data avec leur propre icône, leur nom, leurs traductions et d'autres détails. Cependant, comme l'application Data ne peut pas être lancée, l'icône apparaît uniquement dans l'écran Paramètres > Applications .

L'application Data est destinée à être construite avec une version tapas qui produit des APK pouvant être ajoutés à l'image système (pour la version initiale) et signés et distribués via une boutique d'applications (pour les mises à jour ultérieures). Pour plus de détails sur l'utilisation des tapas, consultez Création de l'application de données à l'aide de tapas .

Les OEM doivent installer l’application Data prédéfinie dans l’image système d’un appareil dans /system/priv-app . Pour inclure des APK prédéfinis (générés par le processus de création de tapas) dans l'image système, les OEM peuvent copier les exemples de fichiers dans packages/apps/TimeZoneData/oem_template/data_app_prebuilt . Les exemples de modèles incluent également des cibles de build pour inclure des versions de test de l'application Data dans les suites de tests.

Inclure les applications Updater et Data dans l'image système

Les OEM doivent placer les APK du programme de mise à jour et de l’application de données dans le répertoire /system/priv-app de l’image système. Pour ce faire, la création de l’image système doit inclure explicitement les cibles prédéfinies de l’application Updater et de l’application Data.

L'application Updater doit être signée avec la clé de plate-forme et incluse comme toute autre application système. La cible est définie dans packages/apps/TimeZoneUpdater comme TimeZoneUpdater . L’inclusion de l’application Data est spécifique à l’OEM et dépend du nom cible choisi pour la pré-construction.

Configuration du serveur système

Pour activer les mises à jour de fuseau horaire, les OEM peuvent configurer le serveur système en remplaçant les propriétés de configuration définies dans frameworks/base/core/res/res/values/config.xml .

Propriété Description Remplacement requis ?
config_enableUpdateableTimeZoneRules
Doit être défini sur true pour activer RulesManagerService. Oui
config_timeZoneRulesUpdateTrackingEnabled
Doit être défini sur true pour que le système écoute les modifications apportées à l’application Data. Oui
config_timeZoneRulesDataPackage
Nom du package de l’application de données spécifique à l’OEM. Oui
config_timeZoneRulesUpdaterPackage
Configuré pour l'application Updater par défaut. Modifiez uniquement lorsque vous fournissez une implémentation différente de l’application Updater. Non
config_timeZoneRulesCheckTimeMillisAllowed
Temps autorisé entre une vérification de mise à jour déclenchée par RulesManagerService et une réponse d'installation, de désinstallation ou de ne rien faire. Après ce point, un déclencheur de fiabilité spontané peut être généré. Non
config_timeZoneRulesCheckRetryCount
Nombre de vérifications de mise à jour séquentielles infructueuses autorisées avant que RulesManagerService cesse d'en générer davantage. Non

Les remplacements de configuration doivent figurer dans l'image système (et non dans l'image du fournisseur ou autre), car un périphérique mal configuré peut refuser de démarrer. Si les remplacements de configuration se trouvaient dans l'image du fournisseur, la mise à jour vers une image système sans application de données (ou avec des noms de package d'application de données/application de mise à jour différents) serait considérée comme une mauvaise configuration.

Tests xTS

xTS fait référence à toute suite de tests spécifique aux OEM qui est similaire aux suites de tests Android standard utilisant Tradefed (telles que CTS et VTS). Les OEM disposant de telles suites de tests peuvent ajouter les tests de mise à jour du fuseau horaire Android fournis aux emplacements suivants :

  • packages/apps/TimeZoneData/testing/xts inclut le code nécessaire aux tests fonctionnels automatisés de base.
  • packages/apps/TimeZoneData/oem_template/xts contient un exemple de structure de répertoires pour inclure des tests dans une suite xTS de type Tradefed. Comme pour les autres répertoires de modèles, les OEM doivent copier et personnaliser selon leurs besoins.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt contient une configuration au moment de la construction pour inclure les APK de test prédéfinis requis par le test.

Création de mises à jour de fuseau horaire

Lorsque l'IANA publie un nouvel ensemble de règles de fuseau horaire, l'équipe des bibliothèques principales d'Android génère des correctifs pour mettre à jour les versions dans AOSP. Les OEM utilisant le système Android d'origine et les fichiers de distribution peuvent récupérer ces validations, les utiliser pour créer une nouvelle version de leur application Data, puis publier la nouvelle version pour mettre à jour leurs appareils en production.

Étant donné que les applications Data contiennent des fichiers de distribution étroitement liés aux versions d'Android, les OEM doivent créer une nouvelle version de l'application Data pour chaque version Android prise en charge qu'un OEM souhaite mettre à jour. Par exemple, si un OEM souhaite fournir des mises à jour pour les appareils Android 8.1, 9 et 10, il doit effectuer le processus trois fois.

Étape 1 : Mise à jour des fichiers de données système/fuseau horaire et externes/icu

Au cours de cette étape, les OEM font le point sur les validations Android pour system/timezone et external/icu à partir des branches release -dev dans AOSP et appliquent ces validations à leur copie du code source Android.

Le correctif AOSP system/timezone contient des fichiers mis à jour dans system/timezone/input_data et system/timezone/output_data . Les OEM qui ont besoin d'apporter des correctifs locaux supplémentaires peuvent modifier les fichiers d'entrée, puis utiliser les fichiers dans system/timezone/input_data et external/icu pour générer des fichiers dans output_data .

Le fichier le plus important est system/timezone/output_data/distro/distro.zip , qui est automatiquement inclus lors de la création de l'APK de l'application Data.

Étape 2 : Mise à jour du code de version de l'application Data

Au cours de cette étape, les OEM mettent à jour le code de version de l’application Data. La version récupère automatiquement distro.zip , mais la nouvelle version de l'application Data doit avoir un nouveau code de version afin qu'elle soit reconnue comme nouvelle et soit utilisée pour remplacer une application Data préchargée ou une application Data installée sur un appareil par une mise à jour précédente.

Lors de la création de l'application Data à l'aide de fichiers copiés depuis package/apps/TimeZoneData/oem_template/data_app , vous pouvez trouver le code de version/le nom de la version appliqué à l'APK dans Android.mk :

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Des entrées similaires peuvent être trouvées dans testing/Android.mk (cependant, les codes de version de test doivent être supérieurs à la version de l'image système). Pour plus de détails, voir l' exemple de schéma de stratégie de code de version ; si l'exemple de schéma ou un schéma similaire est utilisé, les codes de version de test n'ont pas besoin d'être mis à jour car ils sont garantis être supérieurs aux codes de version réels.

Étape 3 : Reconstruire, signer, tester et publier

Au cours de cette étape, les OEM reconstruisent l'APK à l'aide de tapas, signent l'APK généré, puis testent et publient l'APK :

  • Pour les appareils non publiés (ou lors de la préparation d'une mise à jour du système pour un appareil publié), soumettez les nouveaux APK dans le répertoire prédéfini de l'application Data pour vous assurer que l'image système et les tests xTS disposent des derniers APK. Les OEM doivent vérifier que le nouveau fichier fonctionne correctement (c'est-à-dire qu'il réussit le CTS et tous les tests automatisés et manuels spécifiques aux OEM).
  • Pour les appareils commercialisés qui ne reçoivent plus de mises à jour du système, l'APK signé peut être publié uniquement via une boutique d'applications.

Les OEM sont responsables de l’assurance qualité et du test de l’application Data mise à jour sur leurs appareils avant sa sortie.

Stratégie de code de version de l'application de données

L'application Data doit disposer d'une stratégie de gestion des versions appropriée pour garantir que les appareils reçoivent les bons APK. Par exemple, si une mise à jour du système contient un APK plus ancien que celui téléchargé depuis l'App Store, la version de l'App Store doit être conservée.

Le code de la version APK doit inclure les informations suivantes :

  • Version au format distribution (majeure + mineure)
  • Un numéro de version incrémentiel (opaque)

Actuellement, le niveau d'API de la plateforme est fortement corrélé à la version du format de distribution car chaque niveau d'API est généralement associé à une nouvelle version d'ICU (ce qui rend les fichiers de distribution incompatibles). À l'avenir, Android pourrait modifier cela afin qu'un fichier de distribution puisse fonctionner sur plusieurs versions de la plate-forme Android (et le niveau d'API n'est pas utilisé dans le schéma de code de version de l'application Data).

Exemple de stratégie de code de version

Cet exemple de schéma de numéro de version garantit que les versions au format de distribution supérieur remplacent les versions au format de distribution inférieur. AndroidManifest.xml utilise android:minSdkVersion pour garantir que les anciens appareils ne reçoivent pas de versions avec un format de distribution supérieur à celui qu'ils peuvent gérer.

Vérification des versions
Figure 6. Exemple de stratégie de code de version
Exemple Valeur But
Oui Réservé Permet de futurs schémas alternatifs/APK de test. Il s'agit initialement (implicitement) de 0. Étant donné que le type sous-jacent est un type int 32 bits signé, ce schéma prend en charge jusqu'à deux futures révisions du schéma de numérotation.
01 Version grand format Suit la version au format majeur à 3 chiffres décimaux. Le format de distribution prend en charge 3 chiffres décimaux mais seuls 2 chiffres sont utilisés ici. Il est peu probable qu'il atteigne 100 étant donné l'augmentation importante attendue par niveau d'API. La version majeure 1 équivaut au niveau API 27.
1 Version en format mineur Suit la version au format mineur à 3 chiffres décimaux. Le format de distribution prend en charge 3 chiffres décimaux mais un seul chiffre est utilisé ici. Il est peu probable qu'il atteigne 10.
X Réservé Est 0 pour les versions de production (et peut être différent pour les APK de test).
ZZZZZ Numéro de version opaque Numéro décimal attribué sur demande. Inclut des espaces pour permettre des mises à jour interstitielles si nécessaire.

Le schéma pourrait être mieux compressé si le binaire était utilisé au lieu du décimal, mais ce schéma a l'avantage d'être lisible par l'homme. Si la plage complète de numéros est épuisée, le nom du package de l’application Data peut changer.

Le nom de la version est une représentation lisible des détails, par exemple : major=001,minor=001,iana=2017a, revision=1,respin=2 . Des exemples sont présentés dans le tableau suivant.

# Code de version minSdkVersion {Version au format majeur},{Version au format mineur},{Version des règles IANA},{Révision}
1 11000010 O-MR1 majeur = 001, mineur = 001, iana = 2017a, révision = 1
2 21000010 P. majeur = 002, mineur = 001, iana = 2017a, révision = 1
3 11000020 O-MR1 majeur = 001, mineur = 001, iana = 2017a, révision = 2
4 11000030 O-MR1 majeur = 001, mineur = 001, iana = 2017b, révision = 1
5 21000020 P. majeur = 002, mineur = 001, iana = 2017b, révision = 1
6 11000040 O-MR1 majeur = 001, mineur = 001, iana = 2018a, révision = 1
7 21000030 P. majeur = 002, mineur = 001, iana = 2018a, révision = 1
8 1123456789 - -
9 11000021 O-MR1 majeur = 001, mineur = 001, iana = 2017a, révision = 2, respin = 2
  • Les exemples 1 et 2 montrent deux versions APK pour la même version 2017a de l'IANA avec des versions de format majeur différentes. 2 est numériquement supérieur à 1, ce qui est nécessaire pour garantir que les appareils les plus récents reçoivent les versions au format supérieur. La minSdkVersion garantit que la version P ne sera pas fournie aux appareils O.
  • L'exemple 3 est une révision/correctif pour 1 et est numériquement supérieur à 1.
  • Les exemples 4 et 5 montrent les versions 2017b pour O-MR1 et P. Étant numériquement plus élevées, elles remplacent les versions IANA/révisions Android antérieures de leurs prédécesseurs respectifs.
  • Les exemples 6 et 7 montrent les versions 2018a pour O-MR1 et P.
  • L'exemple 8 démontre l'utilisation de Y pour remplacer complètement le schéma Y=0.
  • L'exemple 9 montre l'utilisation de l'espace laissé entre 3 et 4 pour relancer l'apk.

Comme chaque appareil est livré avec un APK par défaut, correctement versionné dans l'image système, il n'y a aucun risque qu'une version O-MR1 soit installée sur un appareil P car elle a un numéro de version inférieur à celui d'une version de l'image système P. Un appareil avec une version O-MR1 installée dans /data qui reçoit ensuite une mise à jour du système vers P utilise la version /system de préférence à la version O-MR1 dans /data car la version P est toujours supérieure à toute application destinée à O- MR1.

Construire l'application Data à l'aide de tapas

Les OEM sont responsables de la gestion de la plupart des aspects de l’application de données de fuseau horaire et de la configuration correcte de l’image système. L'application Data est destinée à être construite avec une version tapas qui produit des APK pouvant être ajoutés à l'image système (pour la version initiale) et signés et distribués via une boutique d'applications (pour les mises à jour ultérieures).

Tapas est une version allégée du système de construction Android qui utilise une arborescence source réduite pour produire des versions distribuables d'applications. Les OEM familiers avec le système de build Android normal doivent reconnaître les fichiers de build de la version normale de la plate-forme Android.

Création du manifeste

Une arborescence source réduite est généralement obtenue avec un fichier manifeste personnalisé qui fait référence uniquement aux projets Git nécessaires au système de build et à la création de l'application. Après avoir suivi les instructions dans Création d'une application de données , les OEM doivent avoir créé au moins deux projets Git spécifiques aux OEM à l'aide des fichiers modèles sous packages/apps/TimeZoneData/oem_template :

  • Un projet Git contient des fichiers d'application tels que le manifeste et les fichiers de build requis pour créer le fichier APK de l'application (par exemple, vendor/ oem /apps/TimeZoneData ). Ce projet contient également des règles de construction pour les APK de test pouvant être utilisés par les tests xTS.
  • Un projet Git contient les APK signés produits par la construction de l'application pour inclusion dans la construction de l'image système et les tests xTS.

La version d’application exploite plusieurs autres projets Git partagés avec la version de plateforme ou contenant des bibliothèques de codes indépendantes du fabricant OEM.

L'extrait de manifeste suivant contient l'ensemble minimal de projets Git nécessaires pour prendre en charge une version O-MR1 de l'application Data de fuseau horaire. Les OEM doivent ajouter leurs projets Git spécifiques aux OEM (qui incluent généralement un projet contenant le certificat de signature) à ce manifeste et peuvent configurer différentes branches en conséquence.

   <!-- Tapas Build -->
    <project
        path="build"
        name="platform/build">
        <copyfile src="core/root.mk" dest="Makefile" />
    </project>
    <project
        path="prebuilts/build-tools"
        name="platform/prebuilts/build-tools"
        clone-depth="1" />
    <project
        path="prebuilts/go/linux-x86"
        name="platform/prebuilts/go/linux-x86"
        clone-depth="1" />
    <project
        path="build/blueprint"
        name="platform/build/blueprint" />
    <project
        path="build/kati"
        name="platform/build/kati" />
    <project
        path="build/soong"
        name="platform/build/soong">
        <linkfile src="root.bp" dest="Android.bp" />
        <linkfile src="bootstrap.bash" dest="bootstrap.bash" />
    </project>

    <!-- SDK for system / public API stubs -->
    <project
        path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth="1" />
    <!-- App source -->
    <project
        path="system/timezone"
        name="platform/system/timezone" />
    <project
        path="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZoneData" />
    <!-- Enable repohooks -->
    <project
        path="tools/repohooks"
        name="platform/tools/repohooks"
        revision="main"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

Exécuter la construction de tapas

Une fois l'arborescence source établie, appelez la construction tapas à l'aide des commandes suivantes :

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

Une build réussie génère des fichiers dans le répertoire out/dist à des fins de test. Ces fichiers peuvent être placés dans le répertoire prédéfinis pour être inclus dans l'image système et/ou distribués via une boutique d'applications pour les appareils compatibles.