Règles de fuseau horaire

Applications 10 réprouve le mécanisme de mise à jour de temps de données de zone sur la base APK-(disponible dans les applications et les applications 8,1 9) et le remplace par un mécanisme de mise à jour de module à base d'APEX . AOSP continue d'inclure le code de plate-forme nécessaire aux OEM pour activer les mises à jour basées sur 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 le partenaire via 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 module car une mise à jour basée sur APK remplace une mise à jour basée sur APEX (c'est-à-dire qu'un appareil qui a reçu une mise à jour APK ignorerait les mises à jour basées sur APEX ).

Mises à jour des fuseaux horaires (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, normalisant les données qui peuvent changer fréquemment pour des raisons religieuses, politiques et géopolitiques.

Les mises à jour utilisent le processus suivant :

  1. IANA publie une mise à jour la base de données Time Zone publie une mise à jour en réponse à un ou plusieurs gouvernements changeant 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 des composants du système modulaire .

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

Dans Android 8.1 et Android 9, les OEM peuvent utiliser un mécanisme basé sur 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 (allongeant 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 de base Android fournit les fichiers de données nécessaires à la mise à jour des règles de fuseau horaire sur un appareil Android standard. 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 le souhaitent. 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 stocks appareils Android, même ceux qui ne pas utiliser cette fonctionnalité, les règles de la zone temps besoin de données et doivent être livrés avec un ensemble par défaut de règles de fuseau horaire données dans le /system partition. Ces données sont ensuite utilisées par le code des bibliothèques suivantes dans l'arborescence des sources Android :

  • Code managé de libcore/ (par exemple, java.util.TimeZone ) utilise tzdata et tzlookup.xml fichiers.
  • Code bibliothèque native dans bionic/ (par exemple, pour mktime appels système, localtime) utilise le tzdata fichier.
  • Code de la bibliothèque ICU4J / ICU4C dans external/icu/ utilise le ICU .dat fichier.

Ces bibliothèques gardent la trace des fichiers de superposition qui peuvent être présents dans le /data/misc/zoneinfo/current répertoire. Les fichiers calques sont censés contenir des règles de fuseau horaire amélioration des données, permettant ainsi des dispositifs à mettre à jour sans changer /system .

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

  • libcore/ et bionic/ code utilisent la /data des tzdata tzlookup.xml /data copie des tzdata et tzlookup.xml fichiers.
  • Code ICU4J / ICU4C utilisation des fichiers dans /data et revenir à /system de fichiers pour les données qui ne sont pas présents (pour les formats, les chaînes localisées, etc.).

Fichiers de distribution

Distro .zip fichiers contiennent les fichiers de données nécessaires pour alimenter le /data/misc/zoneinfo/current répertoire. 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 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 plate-forme). Pour maintenir leurs appareils à jour, les OEM peuvent utiliser ces fichiers de distribution ou créer les leurs à l'aide de l'arborescence source Android (qui contient les scripts et autres fichiers nécessaires pour générer des 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'il contient. Le transfert et l'installation nécessitent les éléments suivants :

  • Fonctionnalité de service de plate - forme ( timezone.RulesManagerService ), qui est désactivé par défaut. Les OEM doivent activer la fonctionnalité via la configuration. RulesManagerService exécute dans le processus du serveur du système et les étapes du temps des opérations de mise à jour de la zone en écrivant à /data/misc/zoneinfo/staged en /data/misc/zoneinfo/staged . RulesManagerService peut également remplacer ou supprimer déjà mis en scène des opérations.
  • TimeZoneUpdater , une application du système nonupdateable (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 actualisable (alias l'application des données) qui porte distro fichiers sur le périphérique et les met à disposition l'application Updater. Les OEM doivent inclure cette application dans l'image système des appareils utilisant cette fonctionnalité.
  • tzdatacheck , un binaire temps de démarrage requis pour le bon fonctionnement et la sécurité des mises à jour de fuseau horaire.

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

Installation de distribution

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

  1. Application des données est mis à jour par le biais d' un app store ou télécharger sideload. Le processus serveur du système (par timezone.RulesManagerServer/timezone.PackageTracker classes) montres pour des modifications à la configuration, OEM spécifique, le nom du package d'applications de données.

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

    Déclencher la mise à jour
    Figure 2. Vérification de mise à jour Trigger
  3. Lors de la vérification de la mise à jour, l'application Updater effectue les tâches suivantes:
    • Interroge l'état actuel du périphérique en appelant RulesManagerService.

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

      Obtenir des informations sur la distribution
      Figure 4. Mises à jour d'applications de données, obtenir des informations sur distro
  4. L'application prend Updater les mesures appropriées en fonction des informations dont il dispose. Les actions disponibles incluent :
    • Demander une installation. Les données de distribution sont lues à partir de l'application Data et transmises à 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 procède à l'installation.
    • Demander une désinstallation (ce qui est rare). Par exemple, si l'APK mis à jour /data est en cours de désactivation ou désinstallés et l'appareil revient à la présente version dans /system .
    • Ne fais rien. Se produit lorsque la distribution de l'application Data est invalide.
    Dans tous les cas, l'application Updater appelle le 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érifiez complète
  5. Redémarrez et tzdatacheck. Lors du prochain démarrage du périphérique, le binaire tzdatacheck exécute toute opération par étapes. Le binaire tzdatacheck peut effectuer les tâches suivantes :
    • Exécutez la mis en scène l' opération en manipulant la création, le remplacement et / ou la suppression de la /data/misc/zoneinfo/current fichiers avant d' autres composants du système ont ouvert et ont commencé à utiliser les fichiers.
    • Vérifiez que les fichiers /data sont correctes pour la version actuelle de la plate - forme, qui pourrait ne pas être le cas si l'appareil vient de recevoir une mise à jour du système et la version du format distro a changé.
    • Assurez -vous que la version des règles IANA est identique ou plus récent que la version en /system . Cela protège contre une mise à jour du système en laissant un appareil avec des règles de fuseau horaire plus de données que est présent dans le /system image.

Fiabilité

Le processus d'installation de bout en bout est asynchrone et divisé en trois processus de système d'exploitation. À tout moment au cours de l'installation, l'appareil peut perdre de l'énergie, 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, l'application Updater informe le serveur système qu'elle a échoué ; dans le pire des cas, le RulesManagerService ne reçoit aucun appel.

Pour gérer cela, le code du serveur système vérifie 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 de données. Lorsque l'appareil est inactif et en charge, le code du serveur système peut vérifier l'état actuel. S'il découvre un contrôle de mise à jour incomplet ou une version inattendue de Data App, il déclenche spontanément un contrôle 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 est sûr à utiliser.

  • 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 ou de mise à jour de données ou l'application de mise à jour ou données ne pas être 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 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 un ContentProvider sur l'URI attendu.

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

Intégration des mises à jour des fuseaux horaires

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

  • Créez leur propre application de données.
  • Incluez les applications Updater et Data dans la génération d'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 version et de version 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 avoir une seule application de données pour tous leurs appareils ou peuvent choisir d'avoir différentes applications de données pour différents appareils. La décision impacte le choix du nom du package, éventuellement les codes de version utilisés, et la stratégie d'assurance qualité.
  • Déterminez 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

PSBA comprend toutes les règles du code source et de construire nécessaires à la création d' une application de données dans les packages/apps/TimeZoneData , avec des instructions et des exemples de modèles pour AndroidManifest.xml et d' autres fichiers situés dans des packages/apps/TimeZoneData/oem_template . Les exemples de modèles incluent à la fois une cible de build pour le vrai APK de l'application Data et des cibles supplémentaires pour la création de versions de test de l'application Data.

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

L'application de données est destiné à être construit avec une construction de tapas qui produit des APK appropriés à ajouter à l'image du système (pour la version initiale) et signé et distribué par un magasin d'application (pour les mises à jour ultérieures). Pour plus de détails sur l' utilisation des tapas, voir Construire l'app données à l' aide des tapas .

OEM doit installer l'application prebuilt données dans l'image du système d'un dispositif /system/priv-app . Pour inclure APK (préconstruits générés par le processus de construction des tapas) dans l'image du système, les OEM peuvent copier les exemples de fichiers dans des packages/apps/TimeZoneData/oem_template/data_app_prebuilt . Les exemples de modèles incluent également des cibles de génération 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

OEM doit placer les applications et données Updater APK dans le /system/priv-app répertoire de l'image du système. Pour ce faire, la génération d'image système doit inclure explicitement les cibles prédéfinies de l'application de mise à jour et de l'application de données.

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

Configuration du serveur système

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

Biens La description Remplacement requis ?
config_enableUpdateableTimeZoneRules
Doit être réglé sur true pour activer le RulesManagerService. Oui
config_timeZoneRulesUpdateTrackingEnabled
Doit être réglé sur true que le système écouter les modifications apportées à l'application des données. Oui
config_timeZoneRulesDataPackage
Nom de 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 n'arrête d'en générer davantage. Non

Les remplacements de configuration doivent se trouver dans l'image système (pas de 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/de mise à jour différents) serait considérée comme une mauvaise configuration.

test 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 pour les tests fonctionnels automatisés de base.
  • packages/apps/TimeZoneData/oem_template/xts contient une structure de répertoires d'échantillons pour les tests , y compris dans une suite Tradefed comme XTS. 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 la configuration accumulation de temps 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 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 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 de données contiennent des fichiers étroitement distro liés aux versions Android, les constructeurs doivent créer une nouvelle version de l'application des données pour chaque version Android pris en charge qu'un OEM veut mettre à jour. Par exemple, si un OEM souhaite fournir des mises à jour pour les appareils Android 8.1, 9 et 10, il doit terminer le processus trois fois.

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

Dans cette étape, OEM Android faire le point pour commits system/timezone et external/icu à partir des branches de la libération dans PSBA et appliquent ces commits à leur copie du code source Android.

Le système / fuseau horaire patch PSBA contient des fichiers mis à jour dans le system/timezone/input_data et system/timezone/output_data . OEM qui ont besoin de faire des corrections locales supplémentaires peuvent modifier les fichiers d'entrée puis utilisez les fichiers system/timezone/input_data et external/icu pour générer des fichiers dans output_data .

Le plus important dossier est le system/timezone/output_data/distro/distro.zip , qui est inclus automatiquement lorsque l'application des données APK est construit.

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

Dans cette étape, les OEM mettent à jour le code de version de l'application Data. La construction reprend automatiquement distro.zip , mais la nouvelle version de l'application des données doit avoir un nouveau code de version il est reconnu comme nouveau et est utilisé pour remplacer une application de données préchargées ou une application de données installé sur un périphérique par une mise à jour précédente.

Lors de la construction des fichiers en utilisant l' application des données copiées à partir package/apps/TimeZoneData/oem_template/data_app , vous pouvez trouver le nom de code de la version / version appliquée à l'APK dans le Android.mk :

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Entrées similaires peuvent être trouvées dans les testing/Android.mk (cependant, les codes de version d'essai doit être supérieure à la version image du système). Pour plus de détails, consultez la Version exemple schéma de stratégie de code ; 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 supérieurs aux codes de version réels.

Étape 3 : Recréer, signer, tester et publier

Dans 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 publiés qui ne reçoivent plus les mises à jour du système, l'APK signé peut uniquement être publié 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 d'application de données

L'application des données doit avoir une stratégie de versionnage appropriée pour assurer que les appareils reçoivent les APK corrects. Par exemple, si une mise à jour du système est reçue qui contient un fichier 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 version APK doit inclure les informations suivantes :

  • Version au format distribution (majeure + mineure)
  • Un numéro de version incrémenté (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 peut modifier cela afin qu'un fichier de distribution puisse fonctionner sur plusieurs versions de 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 de format de distribution supérieur remplacent les versions de format de distribution inférieur. AndroidManifest.xml utilisations android:minSdkVersion pour assurer que les anciens appareils ne reçoivent pas les versions avec une version de format distro plus qu'ils ne peuvent gérer.

Vérification des versions
Figure 6. Exemple stratégie de code de version
Exemple Valeur But
Oui Réservé Permet de futurs schémas alternatifs/tests APK. Il est initialement (implicitement) 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 de format majeur Suit la version du 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 majeure attendue par niveau d'API. La version majeure 1 est équivalente au niveau d'API 27.
1 Version de format mineur Suit la version de format mineur à 3 chiffres décimaux. Le format de distribution prend en charge 3 chiffres décimaux, mais seul 1 chiffre est utilisé ici. Il est peu probable qu'il atteigne 10.
X Réservé Est égal à 0 pour les versions de production (et peut être différent pour les APK de test).
ZZZZZ Numéro de version opaque Nombre décimal attribué sur demande. Comprend des espaces pour permettre des mises à jour interstitielles si nécessaire.

Le schéma pourrait être mieux emballé si 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 numéros 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' homme 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 de format majeur},{Version de format mineur},{Version de 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 d'APK pour la même version IANA 2017a avec différentes versions de format majeur. 2 est numériquement supérieur à 1, ce qui est nécessaire pour garantir que les nouveaux appareils reçoivent les versions de format supérieur. Le minSdkVersion garantit que la version P ne sera pas fournie aux appareils O.
  • L'exemple 3 est une révision/correction 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 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 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 et 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 d'image système P. Dispositif avec une version O-MR1 installé dans /data qui reçoit alors une mise à jour du système à P utilise le /system Version de préférence à la version O-MR1 dans /data parce que la version P est toujours supérieure à toute application destinée à O- MR1.

Construire l'application Data à l'aide de tapas

Les OEM sont chargés de gérer la plupart des aspects de l'application Data de fuseau horaire et de configurer correctement l'image système. L'application de données est destiné à être construit avec une construction de tapas qui produit des APK appropriés à ajouter à l'image du système (pour la version initiale) et signé et distribué par un magasin d'application (pour les mises à jour ultérieures).

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

Création du manifeste

Une arborescence de sources 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 génération et à la génération de l'application. Après avoir suivi les instructions de création d' packages/apps/TimeZoneData/oem_template une application de données , OEM devrait avoir au moins deux projets spécifiques Git-OEM créés à l'aide des fichiers de modèle sous packages/apps/TimeZoneData/oem_template :

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

La version de l'application exploite plusieurs autres projets Git qui sont partagés avec la version de la plate-forme ou qui contiennent des bibliothèques de code indépendantes de l'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="master"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

Exécution de la construction de tapas

Après l'arbre source est établie, invoquer les tapas à l' aide des commandes build suivantes:

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

Une construction réussie génère des fichiers dans la out/dist répertoire pour les tests. 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 boutique d'applications pour les appareils compatibles.