Règles de fuseau horaire

Android 10 abandonne les données de fuseau horaire basées sur l'APK de mise à jour (disponible sur Android 8.1 et Android 9) et le remplace par un mécanisme de mise à jour de modules basé sur AAPEX. Les versions 8.1 à 13 d'AOSP incluent toujours le code de plate-forme nécessaire aux OEM pour activer Mises à jour basées sur l'APK (pour les appareils passant à Android 10) peuvent toujours recevoir des mises à jour de fuseaux horaires 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 aussi des mises à jour du module, car une mise à jour basée sur l'APK remplace Mise à jour basée sur APEX (c'est-à-dire qu'un appareil ayant reçu une mise à jour de l'APK ignorerait mises à jour basées sur APEX).

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

Le module de données de fuseau horaire compatible avec Android 10 et des mises à jour à l'heure d'été (DST) et aux fuseaux horaires sur les appareils Android, normaliser les données qui peuvent changer fréquemment pour des raisons religieuses, politiques pour des raisons géopolitiques.

Les mises à jour utilisent le processus suivant:

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

Pour en savoir plus sur les modules, consultez Composants du système modulaires.

Mise à jour du fuseau horaire (Android 8.1 à 9)

Remarque:Le mécanisme de mise à jour des données de fuseau horaire basé sur l'APK a été complètement supprimé d'Android 14 et est introuvable dans le code source. Les partenaires doivent effectuer une migration complète vers Fuseau horaire Module principal.

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

L'équipe chargée des bibliothèques principales Android fournit les fichiers de données nécessaires pour Mise à jour des règles de fuseau horaire sur un appareil Android d'origine Les OEM peuvent choisir d'utiliser des fichiers de données lorsqu'ils créent des mises à jour de fuseau horaire pour leurs appareils ou peuvent créer leurs vos propres fichiers de données, si vous le souhaitez. Dans tous les cas, les OEM gardent le contrôle sur la qualité l'assurance et les tests, le calendrier et le lancement des mises à jour des règles de fuseau horaire pour leurs appareils compatibles.

Code source et données du fuseau horaire Android

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

• Code géré de libcore/ (par exemple, java.util.TimeZone) utilise tzdata et tzlookup.xml fichiers.
• Le code de bibliothèque native dans bionic/ (par exemple, pour mktime, appels système en heure locale) utilise le fichier tzdata.
• Le code de bibliothèque ICU4J/ICU4C dans external/icu/ utilise l'icu .dat.

Ces bibliothèques assurent le suivi des fichiers de superposition susceptibles d'être présents dans le Répertoire /data/misc/zoneinfo/current. Les fichiers de superposition sont attendus contenant 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 les éléments suivants : d'abord les emplacements:

• Les codes libcore/ et bionic/ utilisent le Copie /data de tzdata et tzlookup.xml .
• Le code ICU4J/ICU4C utilise les fichiers de /data et se rabat sur /system fichiers pour les données manquantes (pour les formats, (chaînes de caractères, etc.).

Fichiers de distribution

Les fichiers de distribution .zip contiennent les fichiers de données nécessaires pour renseigner le /data/misc/zoneinfo/current. Les fichiers de distribution contiennent des métadonnées permettant 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 avec la version ICU, les exigences de la plate-forme Android et d'autres versions des modifications. Android fournit des fichiers de distribution pour les versions Android compatibles pour chaque Mise à jour de l’IANA (en plus de mettre à jour les fichiers système de la plate-forme). Pour que leur appareils à jour, les OEM peuvent utiliser ces fichiers de distribution ou créer les leurs l'arborescence source Android (qui contient les scripts et autres fichiers requis pour générer des fichiers de distribution).

Composants de la mise à jour du fuseau horaire

Une mise à jour des règles de fuseau horaire implique la transmission des fichiers de distribution appareil et l'installation sécurisée des fichiers qu'il contient. Transférer et l'installation nécessite les éléments suivants:

• Fonctionnalité du service de plate-forme (timezone.RulesManagerService), qui est désactivé par défaut. Les OEM doivent activer cette fonctionnalité via la configuration. RulesManagerService s'exécute dans le processus et les étapes du serveur système de mise à jour du fuseau horaire en écrivant dans /data/misc/zoneinfo/staged RulesManagerService peut remplacer ou supprimer également des opérations en préproduction.
• TimeZoneUpdater, une application système qui ne peut pas être mise à jour (c'est-à-dire l'application de mise à jour). Les OEM doivent inclure cette application dans l'image système. d'appareils utilisant cette fonctionnalité.
• OEM TimeZoneData, une application système pouvant être mise à jour (aussi appelée (l'application de données) qui transfère les fichiers de distribution vers l'appareil disponible pour l'application de mise à jour. Les OEM doivent inclure cette application dans l'image système de appareils utilisant cette fonctionnalité.
• tzdatacheck, Un binaire de démarrage requis pour le bon fonctionnement et la sécurité des mises à jour du fuseau horaire.

L'arborescence source Android contient du code source générique pour ce qui précède que l'OEM peut choisir d'utiliser sans modification. Tester le code permet aux OEM de vérifier automatiquement s'ils ont activé la fonctionnalité correctement.

Installation de 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 indépendant. Le processus du serveur système (via timezone.RulesManagerServer/timezone.PackageTracker cours) surveille les modifications apportées au package d'application de données configuré, spécifique à l'OEM son nom.
   
   

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

2. Le processus du serveur système déclenche une vérification des mises à jour par diffuser un intent ciblé avec un jeton unique à usage unique au programme de mise à jour ; Appli. Le serveur système assure le suivi du jeton le plus récent qu'il a généré afin qu'il peut déterminer quand la vérification la plus récente qu'il a déclenchée s'est terminée ; toute autre les jetons sont ignorés.
   
   

   Figure 2. Déclencher la vérification des mises à jour.

3. Pendant la recherche de mises à jour, l'application de mise à jour effectue les tâches suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • 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 bien définie et pour obtenir des informations sur la distribution.
     
     

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

4. L'application de mise à jour prend les mesures appropriées en fonction de la les informations dont elle dispose. Les actions disponibles incluent: <ph type="x-smartling-placeholder">
   </ph>
   • Demandez une installation. Les données de distribution sont lues depuis l'application Data et est transmis au service RulesManagerService du serveur système. La "RulesManagerService" confirme à nouveau que la version et le contenu du format de distribution sont adaptée à l'appareil et organise l'installation.
   • Demander une désinstallation (cas rare) Par exemple, si la version mise à jour L'APK dans /data est en cours de désactivation ou de désinstallation, et l'appareil est en revenant à la version présente dans /system.
   • Ne rien faire. Se produit lorsque la distribution de l'application Data n'est pas valide.
   Dans tous les cas, l'application de mise à jour appelle le service 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émarrer et tzdatacheck. Lors du prochain démarrage de l’appareil, le binaire tzdatacheck exécute toute opération en préproduction. Le binaire tzdatacheck peut effectuer les tâches suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Exécuter l'opération en préproduction en gérant la création, le remplacement et/ou la suppression des fichiers /data/misc/zoneinfo/current avant d’autres composants du système ont ouvert et commencé à utiliser les fichiers.
   • Vérifiez que les fichiers dans /data sont corrects pour le fichier actuel de la plate-forme, ce qui n'est pas toujours le cas si l'appareil vient de recevoir la mise à jour du système et la version du format de distribution a changé.
   • Assurez-vous que la version des règles de l'IANA est identique ou plus récente que la version dans /system Cela constitue une protection contre les mises à jour du système qui quittent l'appareil avec des données de règles de fuseau horaire plus anciennes que celles présentes dans /system l'image.

Fiabilité

Le processus d'installation de bout en bout est asynchrone et réparti sur trois systèmes d'exploitation processus. L'appareil peut se mettre hors tension à tout moment pendant l'installation, manque d'espace disque ou de rencontrer d'autres problèmes, ce qui amène le contrôle de l'installation être incomplètes. Dans le meilleur des cas, l'outil de mise à jour informe le système serveur qu'elle a échoué ; dans le pire des cas, le RulesManagerService ne reçoit aucun appel.

Pour gérer cette situation, le code du serveur système garde une trace du déclenchement d'un événement de dernière mise à jour et le code de la dernière version vérifiée de l'application. Lorsque l'appareil est inactif et en charge, le code du serveur du système peut vérifier l'état actuel. S'il découvre une vérification des mises à jour incomplète ou des données inattendues version de l'application, celle-ci déclenche spontanément une recherche de mises à jour.

Sécurité

Lorsque cette option est activée, le code RulesManagerService du serveur système effectue plusieurs vérifications pour s’assurer que le système peut être utilisé en toute sécurité.

• Les problèmes indiquant une image système mal configurée empêchent un appareil démarrage ; Il peut s'agir, par exemple, d'une mauvaise configuration de l'application de mise à jour ou de l'application de données, ou L'outil de mise à jour ou l'application de données ne se trouvent pas dans /system/priv-app.
• Les problèmes indiquant qu'une application de données incorrecte a été installée n'empêchent pas le démarrage de l'appareil, mais qui empêchent le déclenchement d'une vérification des mises à jour ; exemples ne disposent pas des autorisations système requises ou l'application Data n'expose pas ContentProvider à l'URI attendu.

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

Intégrer les mises à jour du fuseau horaire

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

• créer sa propre application de données ;
• Incluez les applications de mise à jour et de données dans le build de l'image système.
• Configurez le serveur système pour activer le service RulesManagerService.

Préparation

Avant de commencer, les OEM doivent examiner les règles suivantes : et de sécurité:

• Créer une clé de signature spécifique à l'application Data.
• Créer une stratégie de publication et de gestion des versions pour les mises à jour du fuseau horaire pour comprendre quels appareils vont être mis à jour et comment s'assurer que les mises à jour ne sont installées que sur les appareils qui en ont besoin. Par exemple, les OEM peuvent vouloir d'avoir une seule application de données pour tous leurs appareils ou de choisir d'avoir Applications de données pour différents appareils. La décision a un impact sur le choix du package les codes de version utilisés et la stratégie de contrôle qualité.
• Déterminer s'il souhaite utiliser les données de fuseau horaire boursières d'Android à partir d'AOSP ou créer les leurs.

Créer une application de données

AOSP inclut tout le code source et les règles de compilation nécessaires à la création d’une application de données dans packages/apps/TimeZoneData, avec des instructions et des exemples de modèles pour AndroidManifest.xml et les autres fichiers situés dans packages/apps/TimeZoneData/oem_template Exemples de modèles : à la fois une cible de compilation 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 leurs propres icônes, noms, traductions et d'autres détails. Toutefois, comme l'application Data ne peut pas être lancée, l'icône s'affiche uniquement dans les Paramètres > Applications.

L'application Data est conçue pour être compilée avec un build tapas. qui génère des APK pouvant être ajoutés à l'image système (pour les applications de sortie) et signées et distribuées via une plate-forme de téléchargement d'applications (pour des mises à jour). Pour en savoir plus sur l'utilisation de tapas, consultez la section Créer la Application de données utilisant des tapas

Les OEM doivent installer l'application Data intégrée dans l'image système d'un appareil /system/priv-app Pour inclure des APK prédéfinis (générés par l'outil Tapas) processus de compilation) dans l'image système, les OEM peuvent copier les fichiers d'exemple packages/apps/TimeZoneData/oem_template/data_app_prebuilt La Les modèles d'exemple incluent également des cibles de compilation pour inclure les versions de test Application de données dans des suites de tests

Inclure l'outil de mise à jour et les applications de données dans l'image système

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

L'application de mise à jour doit être signée avec la clé de plate-forme et incluse comme n'importe quelle une autre application système. La cible est définie dans packages/apps/TimeZoneUpdater en tant que TimeZoneUpdater. La L'inclusion d'applications de données est spécifique à l'OEM et dépend du nom de la cible choisie pour le la précompilation.

Configurer le serveur système

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Les remplacements de configuration doivent figurer dans l'image système (et non dans l'image du fournisseur ou d'un autre fournisseur). car un appareil mal configuré peut refuser de démarrer. Si la configuration remplace se trouvaient dans l'image du fournisseur, en effectuant une mise à jour vers une image système sans application Data (ou associés à des noms de package d'application de données ou de mise à jour différents) sera considéré comme un lors d'une mauvaise configuration.

Tests xTS

xTS fait référence à toute suite de tests spécifique à l'OEM semblable à la version standard d'Android des suites de tests utilisant Tradefed (CTS et VTS, par exemple). qui proposent ce type de test peuvent ajouter les tests de mise à jour du fuseau horaire Android fournis emplacements:

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

Mettre à jour le fuseau horaire

Lorsque l'IANA publie un nouvel ensemble de règles de fuseau horaire, les bibliothèques principales d'Android génère des correctifs pour mettre à jour les versions dans AOSP. OEM utilisant la version d'Android et les fichiers de distribution peuvent récupérer ces commits, les utiliser pour créer de son application Data, puis publiera la nouvelle version pour mettre à jour ses appareils. en production.

Les applications de données contenant des fichiers de distribution étroitement liés aux versions d'Android, Les OEM doivent créer une nouvelle version de l'application Data pour toutes les versions Version d'Android qu'un OEM souhaite mettre à jour. Par exemple, si un OEM veut fournissent des mises à jour pour Android 8.1, 9 et 10 ; appareils, ils doivent terminer le processus trois fois.

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

À cette étape, les OEM font l'inventaire des commits Android pour system/timezone et external/icu à partir du release-dev dans AOSP et appliquer ces commits à leur copie de le code source Android.

Le correctif AOSP du système/fuseau horaire contient des fichiers mis à jour dans system/timezone/input_data et system/timezone/output_data OEM qui ont besoin de développer des les correctifs peuvent modifier les fichiers d'entrée, puis utiliser les fichiers dans system/timezone/input_data et external/icu à 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

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

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Vous trouverez des entrées similaires dans testing/Android.mk (mais la codes de version de test doivent être supérieurs à ceux de l'image système). Pour en savoir plus, consultez l'exemple de stratégie de code de version schéma. si l'exemple de schéma ou un schéma similaire est utilisé, le test les codes de version n'ont pas besoin d'être mis à jour, car leur version supérieure que les vrais codes de version.

Étape 3: Recompilez, signez, testez et publiez vos applications

Lors de cette étape, les OEM recompilent l'APK à l'aide de tapas, signent le code généré APK, puis testez-le et publiez-le:

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

Les OEM sont responsables de l'assurance qualité et du test des versions mises à jour. Application de données sur leurs appareils avant leur sortie

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

L'application Data doit disposer d'un adaptée de gestion des versions pour vous assurer que les appareils reçoivent les bons APK. Pour exemple, si une mise à jour du système contient un APK plus ancien qu'un téléchargée à partir de la plate-forme de téléchargement d'applications, la version de la plate-forme doit être conservée.

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

• Version du format Distro (majeure + mineure)
• Numéro de version incrémentiel (opaque)

Actuellement, le niveau d'API de la plate-forme est fortement corrélé à la version au format de distribution car chaque niveau d'API est généralement associé à une nouvelle version de la bibliothèque ICU (qui rend les fichiers de distribution incompatibles). À l'avenir, Android changera cela pour que qu'un fichier de distribution peut fonctionner sur plusieurs versions de la plate-forme Android (et les API n'est pas utilisé dans le schéma de code de la 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 le format de distribution remplacent les versions au format de distribution inférieur. AndroidManifest.xml utilise android:minSdkVersion pour Assurez-vous que les anciens appareils ne reçoivent pas de versions avec un format de distribution supérieur qu'elles ne peuvent gérer.

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

Le schéma pourrait être mieux empaqueté si le binaire était utilisé au lieu de décimal, mais ce schéma a l'avantage d'être lisible par l'homme. Si la plage de nombres complète est épuisé, 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 : Exemple: major=001,minor=001,iana=2017a, revision=1,respin=2. Des exemples sont présentés dans le tableau suivant.

• Les exemples 1 et 2 montrent deux versions d'APK pour la même version de l'IANA en 2017a avec différentes versions majeures de formats. 2 est numériquement supérieur à 1, ce qui est pour garantir que les appareils les plus récents reçoivent les versions au format plus élevé. La minSdkVersion garantit que la version P ne sera pas fournie aux appareils O.
• L'exemple 3 est une révision/correction pour 1, dont la valeur numérique est supérieure à 1.
• Les exemples 4 et 5 illustrent les versions 2017b d'O-MR1 et P. Valeurs numériques plus élevées, elles remplacent les versions précédentes de l'IANA/les révisions d'Android de leurs de leurs prédécesseurs.
• Les exemples 6 et 7 illustrent les versions d'O-MR1 et P datant de 2018a.
• L'exemple 8 illustre l'utilisation de Y pour remplacer complètement le schéma Y=0.
• L'exemple 9 illustre l'utilisation de l'écart laissé entre 3 et 4 pour effectuer un nouveau retournement. l'APK.

Chaque appareil est fourni avec un APK par défaut dont la version est appropriée dans le l'image système, il n'y a aucun risque qu'une version d'O-MR1 soit installée sur un appareil P. car son numéro de version est inférieur à celui d'une version d'image système P. A appareil équipé d'une version O-MR1 dans /data, qui reçoit ensuite une mise à jour du système vers P utilise la version /system plutôt que la version O-MR1 dans /data, car la version P est toujours supérieure que n'importe quelle application conçue pour O-MR1.

Créer l'application Data en utilisant des tapas

Les OEM sont responsables de la gestion de la plupart des aspects de l’application de données de fuseau horaire et configurer correctement l'image système. L'application Data est conçue pour être avec un build tapas qui génère des APK pouvant être ajoutés l'image système (pour la version initiale), et signée et distribuée via un sur la plate-forme de téléchargement d'applications (pour les mises à jour ultérieures).

Tapas est une version allégée du build Android qui utilise une arborescence source réduite pour produire des versions distribuables applications. Les OEM familiarisés avec le système de compilation Android normal doivent reconnaître à partir du build normal de la plate-forme Android.

Créer le fichier manifeste

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

• Un projet Git contient des fichiers d'application tels que le fichier manifeste et le fichiers de compilation requis pour créer le fichier APK de l'application (par exemple, vendor/oem/apps/TimeZoneData). Ce projet a aussi contient 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 le build de l'application pour dans le build d'image système et les tests xTS.

La compilation de l'application exploite plusieurs autres projets Git partagés avec ou contiennent des bibliothèques de code indépendantes de l'OEM.

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

Gère la construction de tapas

Une fois l'arborescence source établie, appelez le build 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 pour tests. Ces fichiers peuvent être placés dans le répertoire prédéfini pour être inclus dans l'image système et/ou distribuée via une plate-forme de téléchargement d'applications pour appareils.