Règles de fuseau horaire

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

Mises à jour du fuseau horaire (Android 10 ou version ultérieure)

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

Les mises à jour suivent le processus suivant:

1. L'IANA publie une mise à jour de la base de données des fuseaux horaires en réponse à la modification d'une règle de fuseau horaire par un ou plusieurs gouvernements dans leur pays.
2. Google ou le partenaire Android prépare une mise à jour du module de données de fuseau horaire (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. Les données de fuseau horaire de l'appareil contiennent alors les nouvelles données de fuseau horaire de la mise à jour.

Pour en savoir plus sur les modules, consultez la section Composants du système modulaire.

Mises à jour des fuseaux horaires (Android 8.1 à 9)

Remarque:La fonctionnalité de mécanisme de mise à jour des données de fuseau horaire basée sur l'APK a été complètement supprimée à partir d'Android 14 et n'est plus disponible dans le code source. Les partenaires doivent migrer complètement vers le module principal de la zone horaire.

Sous Android 8.1 et Android 9, les OEM peuvent utiliser un mécanisme basé sur un APK pour transmettre les données de règles de fuseau horaire mises à jour 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 aux partenaires Android de tester les mises à jour de fuseau horaire indépendamment des mises à jour d'images système.

L'équipe des bibliothèques principales Android fournit les fichiers de données nécessaires pour mettre à jour les 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 de créer leurs propres fichiers de données s'ils le 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 compatibles.

Code source et données des fuseaux horaires 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 source Android:

• Le code géré de libcore/ (par exemple, java.util.TimeZone) utilise des fichiers tzdata et tzlookup.xml.
• Le code de la bibliothèque native 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 permettent de suivre les fichiers de superposition qui peuvent être présents dans le répertoire /data/misc/zoneinfo/current. Les fichiers de superposition devraient contenir des données de règles de fuseau horaire améliorées, ce qui permet de mettre à jour les appareils sans modifier /system.

Les composants du système Android qui ont besoin de données de règles de fuseau horaire vérifient d'abord les emplacements suivants:

• Le code libcore/ et bionic/ utilise la copie /data des fichiers tzdata et tzlookup.xml.
• Le code ICU4J/ICU4C utilise les fichiers dans /data et utilise les 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 .zip de distribution contiennent les fichiers de données nécessaires pour renseigner 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 gestion des versions.

Le format de fichier de distribution dépend de la version d'Android, car le contenu change avec la version d'ICU, les exigences de la plate-forme Android et d'autres modifications de version. Android fournit des fichiers de distribution pour les versions Android compatibles à chaque mise à jour de l'IANA (en plus de mettre à jour les fichiers système de la plate-forme). Pour mettre à jour leurs appareils, les OEM peuvent utiliser ces fichiers de distribution ou en créer eux-mêmes à l'aide de l'arborescence source Android (qui contient les scripts et autres fichiers nécessaires à la génération de 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 à 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 plate-forme (timezone.RulesManagerService), qui est désactivée par défaut. Les OEM doivent activer cette fonctionnalité via la configuration. RulesManagerService s'exécute dans le processus du serveur système et met en scène 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à mises en scène.
• TimeZoneUpdater, une application système non actualisable (également appelée application de mise à jour). Les OEM doivent inclure cette application dans l'image système des appareils qui utilisent cette fonctionnalité.
• OEM TimeZoneData, une application système pouvant être mise à jour (également appelée application de données) qui transfère les fichiers de distribution sur l'appareil et les met à la disposition de l'application de mise à jour. Les OEM doivent inclure cette application dans l'image système des appareils qui utilisent cette fonctionnalité.
• tzdatacheck, un binaire au démarrage requis pour le bon et sûr fonctionnement des mises à jour de fuseau horaire.

L'arborescence source Android contient du 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 activé la fonctionnalité correctement.

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 sur une plate-forme de téléchargement d'applications ou un téléchargement parallèle. 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é, spécifique à l'OEM.
   
   

   Figure 1 : Mises à jour des applications de données.

2. Le processus du serveur système déclenche une vérification de mise à jour en diffusant un intent ciblé avec un jeton unique à usage unique à l'application de mise à jour. Le serveur système suit le jeton le plus récent qu'il a généré afin de 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.
   
   

   Figure 2. Déclencher la vérification de la mise à jour.

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

     Figure 3. Mises à jour de l'application de données, appel de 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.
     
     

     Figure 4. Mises à jour de l'application de données, informations sur la distribution.

4. L'application de mise à jour prend les mesures appropriées en fonction des informations dont elle dispose. Voici quelques-unes des actions disponibles :
   • Demandez une installation. Les données de distribution sont lues à partir de l'application Data et transmises à RulesManagerService sur le serveur système. RulesManagerService confirme à nouveau que la version et le contenu du format de distribution sont adaptés à l'appareil, puis met en place l'installation.
   • Demander une désinstallation (ce cas 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 rien faire. Se produit lorsque la distribution de l'application Data est jugée non valide.
   Dans tous les cas, l'application de mise à jour 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.
   
   

   Figure 5. Vérification terminée.

5. Redémarrez et exécutez tzdatacheck. Lors du prochain démarrage de l'appareil, le binaire tzdatacheck exécute toute opération en phase. 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 système ne les aient ouverts et commencé à les utiliser.
   • Vérifiez que les fichiers de /data sont corrects pour la version actuelle de la plate-forme, ce qui n'est peut-être pas 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 celle de /system. Cela permet d'éviter qu'une mise à jour du système laisse 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 d'OS. À tout moment pendant l'installation, l'appareil peut perdre de l'alimentation, manquer d'espace disque ou rencontrer d'autres problèmes, ce qui peut entraîner l'incomplétude de la vérification de l'installation. Dans le meilleur des cas, l'application Updater informe le serveur système de l'échec. Dans le pire des cas, RulesManagerService ne reçoit aucun appel.

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

Sécurité

Lorsqu'il est activé, le code RulesManagerService du serveur système effectue plusieurs vérifications pour s'assurer que le système peut être utilisé sans danger.

• Les problèmes qui indiquent une image système mal configurée empêchent le démarrage de l'appareil. Par exemple, une mauvaise configuration de l'application de mise à jour ou de données, ou l'absence de l'application de mise à jour ou de données dans /system/priv-app.
• Les problèmes qui indiquent qu'une mauvaise application Data a été installée n'empêchent pas le démarrage de l'appareil, mais empêchent le déclenchement d'une vérification de mise à jour. Par exemple, il peut s'agir d'un manque d'autorisations système requises ou de l'absence d'exposition d'un ContentProvider sur l'URI attendu.

Les autorisations de fichier pour les répertoires /data/misc/zoneinfo sont appliquées à l'aide de 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 doit disposer d'un nom et d'une clé de package dédiés, spécifiques à l'OEM.

Intégrer les mises à jour des fuseaux horaires

Pour activer la fonctionnalité de mise à jour du fuseau horaire, les OEM effectuent généralement les opérations suivantes:

• Créer sa propre application de données
• Incluez les applications Updater et Data dans la compilation de l'image système.
• Configurez le serveur système pour activer RulesManagerService.

Préparation

Avant de commencer, les OEM doivent consulter les règles, les considérations de qualité et de sécurité suivantes:

• Créer une clé de signature dédiée à l'application de données
• Créez une stratégie de publication et de gestion des versions pour les mises à jour des fuseaux horaires afin de comprendre quels appareils seront mis à jour et comment vous pouvez vous assurer que les mises à jour ne sont installées que sur les appareils qui en ont besoin. Par exemple, les OEM peuvent choisir d'avoir une seule application Data pour tous leurs appareils ou d'en avoir plusieurs pour différents appareils. Cette 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 de contrôle qualité.
• Déterminez s'il souhaite utiliser les données de fuseau horaire Android d'origine d'AOSP ou créer les siennes.

Créer une application de données

AOSP inclut tout le code source et les règles de compilation nécessaires pour créer une application Data 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 compilation pour l'APK de l'application Data réelle et des cibles supplémentaires pour créer des versions de test de l'application Data.

Les OEM peuvent personnaliser l'application Données avec leur propre icône, leur propre nom, leurs propres traductions et d'autres informations. Toutefois, comme l'application Data ne peut pas être lancée, l'icône n'apparaît que sur l'écran Settings > Apps (Paramètres > Applications).

L'application Data doit être compilée avec une compilation tapas qui produit des APK pouvant être ajoutés à l'image système (pour la version initiale), signés et distribués via une plate-forme de téléchargement d'applications (pour les mises à jour ultérieures). Pour en savoir plus sur l'utilisation de tapas, consultez Créer l'application Data à l'aide de tapas.

Les OEM doivent installer l'application Data précompilée 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 compilation 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 compilation pour inclure des versions de test de l'application Data dans des suites de test.

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

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

L'application de mise à jour 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 de la cible choisi pour le prébuild.

Configurer le serveur système

Pour activer les mises à jour du 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.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Les forçages de configuration doivent se trouver dans l'image système (et non chez le fournisseur ou ailleurs), car un appareil mal configuré peut refuser de démarrer. Si les forçages de configuration se trouvaient dans l'image du fournisseur, la mise à jour vers une image système sans application Data (ou avec des noms de package d'application Data/Updater différents) serait considérée comme une mauvaise configuration.

Tests xTS

xTS désigne toute suite de tests spécifique à l'OEM qui est semblable aux suites de tests Android standards utilisant Tradefed (comme CTS et VTS). Les OEM disposant de telles suites de test 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épertoire permettant d'inclure des tests dans une suite xTS semblable à Tradefed. Comme pour les autres répertoires de modèles, les OEM doivent les copier et les personnaliser en fonction de leurs besoins.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt contient la configuration au moment de la compilation pour inclure les APK de test prédéfinis requis par le test.

Créer des mises à jour de fuseau horaire

Lorsque l'IANA publie un nouvel ensemble de règles de fuseau horaire, l'équipe des bibliothèques principales Android génère des correctifs pour mettre à jour les versions dans AOSP. Les OEM qui utilisent le système Android d'origine et les fichiers de distribution peuvent récupérer ces commits, 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 Android, les OEM doivent créer une nouvelle version de l'application Data pour chaque version Android compatible 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 suivre le processus trois fois.

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

À cette étape, les OEM récupèrent les commits Android pour system/timezone et external/icu à partir des branches release-dev dans AOSP et les appliquent à leur copie du code source Android.

Le correctif AOSP système/fuseau horaire contient des fichiers mis à jour dans system/timezone/input_data et system/timezone/output_data. Les OEM qui doivent 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 compilation de l'APK de l'application Data.

Étape 2: Mettez à jour le code de version de l'application Data

À cette étape, les OEM mettent à jour le code de version de l'application Data. La compilation détecte automatiquement distro.zip, mais la nouvelle version de l'application Data doit disposer d'un nouveau code de version pour être reconnue comme nouvelle et 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.

Lorsque vous créez l'application Data à l'aide de fichiers copiés à partir de package/apps/TimeZoneData/oem_template/data_app, vous pouvez trouver le code de version/le nom de 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 en savoir plus, consultez 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 comme étant supérieurs aux codes de version réels.

Étape 3: Recompilez, signez, testez et publiez

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

• Pour les appareils non commercialisés (ou lors de la préparation d'une mise à jour du système pour un appareil commercialisé), envoyez les nouveaux APK dans le répertoire précompilé 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 passe les tests CTS et tous les tests manuels et automatisés spécifiques à l'OEM).
• Pour les appareils commercialisés qui ne reçoivent plus de mises à jour du système, l'APK signé ne peut être publié que via une plate-forme de téléchargement d'applications.

Les OEM sont responsables de l'assurance qualité et des tests de l'application Data mise à jour sur leurs appareils avant sa publication.

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 s'assurer que les appareils reçoivent les APK appropriés. Par exemple, si une mise à jour du système contient un APK plus ancien que celui téléchargé depuis la plate-forme de téléchargement d'applications, la version de la plate-forme de téléchargement d'applications doit être conservée.

Le code de version de l'APK doit inclure les informations suivantes:

• Version au format de distribution (majeur + mineur)
• Numéro de version incrémentiel (opaque)

Actuellement, le niveau d'API de la plate-forme 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 pourra modifier ce paramètre afin qu'un fichier de distribution puisse fonctionner sur plusieurs versions de la plate-forme Android (et que le niveau d'API ne soit 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érotation de version garantit que les versions de format de distribution supérieures remplacent les versions de format de distribution inférieures. AndroidManifest.xml utilise android:minSdkVersion pour s'assurer que les anciens appareils ne reçoivent pas de versions avec une version de format de distribution supérieure à celle qu'ils peuvent gérer.

Figure 6. Exemple de stratégie de code de version.

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

Le nom de la version est une représentation lisible par l'humain des détails, par exemple: major=001,minor=001,iana=2017a, revision=1,respin=2. Vous trouverez des exemples dans le tableau suivant.

• Les exemples 1 et 2 montrent deux versions d'APK pour la même version IANA 2017a avec différentes versions majeures de format. Le chiffre 2 est numériquement supérieur au chiffre 1, ce qui est nécessaire pour s'assurer que les appareils plus récents reçoivent les versions de format supérieures. La valeur minSdkVersion garantit que la version P ne sera pas fournie aux appareils O.
• L'exemple 3 est une révision/correction de l'exemple 1 et est numériquement supérieur à l'exemple 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/Android précédentes de leurs prédécesseurs respectifs.
• Les exemples 6 et 7 montrent les versions 2018a pour O-MR1 et P.
• L'exemple 8 montre comment utiliser Y pour remplacer complètement le schéma Y=0.
• L'exemple 9 montre comment utiliser l'espace laissé entre 3 et 4 pour recompiler l'APK.

Étant donné que chaque appareil est livré avec un APK par défaut avec une version appropriée 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 possède un numéro de version inférieur à celui d'une version d'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.

Créer l'application Data à l'aide de tapas

Les OEM sont chargés de gérer la plupart des aspects de l'application de données sur les fuseaux horaires et de configurer correctement l'image système. L'application Data doit être compilée avec un build tapas qui produit des APK pouvant être ajoutés à l'image système (pour la version initiale), signés et distribués via une plate-forme de téléchargement d'applications (pour les mises à jour ultérieures).

Tapas est une version allégée du système de compilation Android qui utilise un arbre source réduit pour produire des versions distribuables d'applications. Les OEM qui connaissent le système de compilation Android normal doivent reconnaître les fichiers de compilation de la compilation de la plate-forme Android normale.

Créer le fichier manifeste

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

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

La compilation de l'application utilise plusieurs autres projets Git partagés avec la compilation de la plate-forme ou contenant des bibliothèques de code indépendantes de l'OEM.

L'extrait de code manifeste suivant contient l'ensemble minimal de projets Git requis pour prendre en charge une version O-MR1 de l'application de données de fuseau horaire. Les OEM doivent ajouter leurs projets Git spécifiques à l'OEM (qui incluent généralement un projet contenant le certificat de signature) à ce fichier 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 le build tapas

Une fois l'arborescence source établie, appelez la compilation 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 compilation 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 "prebuilts" pour être inclus dans l'image système et/ou distribués via une plate-forme de téléchargement d'applications pour les appareils compatibles.