Regole per il fuso orario

Android 10 ritira il meccanismo di aggiornamento dei dati sul fuso orario basato su APK (disponibile in Android 8.1 e Android 9) e lo sostituisce con un meccanismo di aggiornamento del modulo basato su APEX. AOSP 8.1 e 13 includono ancora il codice di piattaforma necessario per consentire agli OEM di attivare gli aggiornamenti basati su APK, pertanto i dispositivi che eseguono l'upgrade ad Android 10 possono comunque ricevere aggiornamenti dei dati sui fusi orari forniti dai partner tramite APK. Tuttavia, il meccanismo di aggiornamento APK non deve essere utilizzato su un dispositivo di produzione che riceve anche aggiornamenti dei moduli, in quanto un aggiornamento basato su APK sostituisce un aggiornamento basato su APEX (ovvero un dispositivo che ha ricevuto un aggiornamento APK ignorerebbe gli aggiornamenti basati su APEX).

Aggiornamenti dei fusi orari (Android 10 e versioni successive)

Il modulo Dati sui fusi orari supportato in Android 10 e versioni successive aggiorna l'ora legale e i fusi orari sui dispositivi Android, standardizzando i dati che possono cambiare spesso per motivi religiosi, politici e geopolitici.

Gli aggiornamenti utilizzano la seguente procedura:

1. IANA rilascia un aggiornamento al database dei fusi orari in risposta alla modifica di una regola del fuso orario da parte di uno o più governi nei loro paesi.
2. Google o il partner Android prepara un aggiornamento del modulo Dati sui fusi orari (file APEX) contenente i fusi orari aggiornati.
3. Il dispositivo dell'utente finale scarica l'aggiornamento, si riavvia e applica le modifiche, dopodiché i dati del fuso orario del dispositivo contengono i nuovi dati del fuso orario dell'aggiornamento.

Per informazioni dettagliate sui moduli, consulta Componenti del sistema modulare.

Aggiornamenti dei fusi orari (Android 8.1-9)

Nota:la funzionalità del meccanismo di aggiornamento dei dati relativi ai fusi orari basati su APK è stata completamente rimossa da Android 14 in poi e non è presente nel codice sorgente. I partner devono eseguire la migrazione completa al modulo principale fuso orario.

In Android 8.1 e Android 9, gli OEM possono utilizzare un meccanismo basato su APK per inviare ai dispositivi i dati aggiornati delle regole dei fusi orari senza richiedere un aggiornamento di sistema. Questo meccanismo consente agli utenti di ricevere aggiornamenti tempestivi (prolungando così la durata utile di un dispositivo Android) e ai partner Android di testare gli aggiornamenti dei fusi orari indipendentemente dagli aggiornamenti delle immagini di sistema.

Il team delle librerie di base di Android fornisce i file di dati necessari per aggiornare le regole dei fusi orari su un dispositivo Android standard. Gli OEM possono scegliere di utilizzare questi file di dati quando creano aggiornamenti dei fusi orari per i propri dispositivi oppure possono creare i propri file di dati, se preferiscono. In tutti i casi, gli OEM mantengono il controllo sul controllo qualità/sui test, sui tempi e sul lancio degli aggiornamenti delle regole relative ai fusi orari per i propri dispositivi supportati.

Dati e codice sorgente del fuso orario di Android

Tutti i dispositivi Android standard, anche quelli che non utilizzano questa funzionalità, richiedono dati sulle regole dei fusi orari e devono essere forniti con un insieme predefinito di dati sulle regole dei fusi orari nella partizione /system. Questi dati vengono poi utilizzati dal codice delle seguenti librerie nella struttura del codice sorgente di Android:

• Il codice gestito di libcore/ (ad es. java.util.TimeZone) utilizza i file tzdata e tzlookup.xml.
• Il codice della libreria nativa in bionic/ (ad esempio per mktime, chiamate di sistema localtime) utilizza il file tzdata.
• Il codice della libreria ICU4J/ICU4C in external/icu/ utilizza il file icu.dat.

Queste librerie monitorano i file di overlay che potrebbero essere presenti nella directory/data/misc/zoneinfo/current. I file di overlay dovrebbero contenere dati migliorati delle regole dei fusi orari, in modo da consentire l'aggiornamento dei dispositivi senza modificare /system.

I componenti di sistema Android che richiedono dati sulle regole del fuso orario controllano prima le seguenti posizioni:

• Il codice libcore/ e bionic/ utilizza la copia /data dei file tzdata e tzlookup.xml.
• Il codice ICU4J/ICU4C utilizza i file in /data e fa ricorso ai file /system per i dati non presenti (per formati, stringhe localizzate e così via).

File della distribuzione

I file .zip della distribuzione contengono i file di dati necessari per compilare la directory /data/misc/zoneinfo/current. I file della distribuzione contengono anche metadati che consentono ai dispositivi di rilevare i problemi di gestione delle versioni.

Il formato del file della distribuzione dipende dalla release di Android perché i contenuti cambiano con la versione di ICU, i requisiti della piattaforma Android e altre modifiche della release. Android fornisce i file di distribuzione per le release Android supportate per ogni aggiornamento IANA (oltre ad aggiornare i file di sistema della piattaforma). Per mantenere aggiornati i propri dispositivi, gli OEM possono utilizzare questi file di distribuzione o crearne di propri utilizzando la struttura del codice sorgente di Android (che contiene gli script e gli altri file necessari per generare i file di distribuzione).

Componenti di aggiornamento del fuso orario

Un aggiornamento delle regole relative ai fusi orari prevede la trasmissione dei file della distribuzione a un dispositivo e l'installazione sicura dei file al suo interno. Il trasferimento e l'installazione richiedono quanto segue:

• La funzionalità del servizio della piattaforma (timezone.RulesManagerService), che è disabilitata per impostazione predefinita. Gli OEM devono attivare la funzionalità tramite la configurazione. RulesManagerService viene eseguito nel processo del server di sistema e gestisce le operazioni di aggiornamento dei fusi orari scrivendo in /data/misc/zoneinfo/staged. RulesManagerService può anche sostituire o eliminare le operazioni già messe in scena.
• TimeZoneUpdater, un'app di sistema non aggiornabile (ovvero l'app Updater). Gli OEM devono includere questa app nell'immagine di sistema dei dispositivi che utilizzano la funzionalità.
• OEM TimeZoneData, un'app di sistema aggiornabile (nota anche come app Dati) che carica i file della distribuzione sul dispositivo e li rende disponibili per l'app Updater. Gli OEM devono includere questa app nell'immagine di sistema dei dispositivi che utilizzano la funzionalità.
• tzdatacheck, un file binario di avvio necessario per il funzionamento corretto e sicuro degli aggiornamenti dei fusi orari.

La struttura ad albero del codice sorgente di Android contiene il codice sorgente generico per i componenti sopra indicati, che l'OEM può scegliere di utilizzare senza modifiche. Il codice di test viene fornito per consentire agli OEM di verificare automaticamente di aver attivato correttamente la funzionalità.

Installazione della distro

La procedura di installazione della distro include i seguenti passaggi:

1. L'app di dati viene aggiornata tramite un download o un sideload dallo store. Il processo del server di sistema (tramite le classi timezone.RulesManagerServer/timezone.PackageTracker) monitora le modifiche al nome del pacchetto dell'app di dati configurato e specifico per l'OEM.
   
   

   Figura 1. Aggiornamenti delle app di dati.

2. Il processo del server di sistema attiva un controllo degli aggiornamenti trasmettendo un'intenzione mirata con un token univoco monouso all'app Updater. Il server di sistema tiene traccia del token più recente generato in modo da poter determinare quando è stato completato il controllo più recente che ha attivato. Tutti gli altri token vengono ignorati.
   
   

   Figura 2. Attiva il controllo degli aggiornamenti.

3. Durante il controllo degli aggiornamenti, l'app Updater esegue le seguenti attività:
   • Esegue query sullo stato attuale del dispositivo chiamando RulesManagerService.
     
     

     Figura 3. Aggiornamenti dell'app di dati, chiamata RulesManagerService.

   • Esegue query sull'app Dati eseguendo query su un URL ContentProvider e su specifiche di colonna ben definite per ottenere informazioni sulla distribuzione.
     
     

     Figura 4. Aggiornamenti dell'app di dati, informazioni sulla distribuzione.

4. L'app Updater esegue l'azione appropriata in base alle informazioni di cui dispone. Le azioni disponibili includono:
   • Richiedi un'installazione. I dati della distribuzione vengono letti dall'app Data e trasmessi a RulesManagerService nel server di sistema. Il servizio RulesManagerService conferma che la versione e i contenuti del formato della distribuzione sono appropriati per il dispositivo e gestisce le fasi dell'installazione.
   • Richiedi una disinstallazione (questo accade raramente). Ad esempio, se l'APK aggiornato in /data viene disattivato o disinstallato e il dispositivo torna alla versione presente in /system.
   • Non fare niente. Si verifica quando la distribuzione dell'app di dati non è valida.
   In tutti i casi, l'app Updater chiama RulesManagerService con il token di controllo in modo che il server di sistema sappia che il controllo è stato completato e superato.
   
   

   Figura 5. Controllo completato.

5. Riavvia e esegui tzdatacheck. Al successivo avvio del dispositivo, il codice binario tzdatacheck esegue qualsiasi operazione pianificata. Il programma binario tzdatacheck può eseguire le seguenti attività:
   • Esegui l'operazione pianificata gestendo la creazione, la sostituzione e/o l'eliminazione dei file /data/misc/zoneinfo/current prima che altri componenti di sistema vengano aperti e inizino a utilizzarli.
   • Verifica che i file in /data siano corretti per la versione corrente della piattaforma, il che potrebbe non essere il caso se il dispositivo ha appena ricevuto un aggiornamento di sistema e la versione del formato della distribuzione è cambiata.
   • Assicurati che la versione delle regole IANA sia la stessa o più recente di quella in /system. In questo modo, un aggiornamento di sistema non lascerà un dispositivo con dati delle regole dei fusi orari meno recenti rispetto a quelli presenti nell'immagine /system.

Affidabilità

La procedura di installazione end-to-end è asincrona e suddivisa in tre processi di sistema operativo. In qualsiasi momento durante l'installazione, il dispositivo potrebbe perdere alimentazione, esaurire lo spazio su disco o riscontrare altri problemi, causando l'incompletezza del controllo dell'installazione. Nel migliore dei casi, l'app Updater informa il server del sistema che l'aggiornamento non è andato a buon fine; nel peggiore dei casi, il servizio RulesManagerService non riceve alcuna chiamata.

Per gestire questo problema, il codice del server di sistema tiene traccia del completamento di un controllo di aggiornamento attivato e del codice della versione dell'app Data controllata per ultima. Quando il dispositivo è inattivo e in carica, il codice del server di sistema può controllare lo stato corrente. Se rileva un controllo degli aggiornamenti incompleto o una versione dell'app Data unexpected, attiva spontaneamente un controllo degli aggiornamenti.

Sicurezza

Se abilitato, il codice RulesManagerService nel server di sistema esegue diversi controlli per garantire che il sistema sia sicuro da usare.

• I problemi che indicano un'immagine di sistema configurata in modo errato impediscono l'avvio di un dispositivo. Alcuni esempi sono una configurazione errata dell'app Updater o Data o l'assenza dell'app Updater o Data in /system/priv-app.
• I problemi che indicano che è stata installata un'app Dati non valida non impediscono l'avvio del dispositivo, ma impediscono l'attivazione di un controllo degli aggiornamenti. Alcuni esempi sono la mancanza delle autorizzazioni di sistema richieste o il fatto che l'app Dati non esponga un ContentProvider nell'URI previsto.

Le autorizzazioni dei file per le directory /data/misc/zoneinfo vengono applicate utilizzando le regole SELinux. Come per qualsiasi APK, l'app di dati deve essere firmata con la stessa chiave utilizzata per firmare la versione /system/priv-app. L'app Dati dovrebbe avere un nome e una chiave del pacchetto dedicati e specifici per l'OEM.

Integrare gli aggiornamenti dei fusi orari

Per attivare la funzionalità di aggiornamento del fuso orario, in genere gli OEM:

• Creare la propria app di dati.
• Includi le app Updater e Data nella compilazione dell'immagine di sistema.
• Configura il server di sistema per attivare RulesManagerService.

Preparazione

Prima di iniziare, gli OEM devono esaminare le seguenti norme, le considerazioni sulla qualità e sulla sicurezza:

• Creare una chiave di firma dedicata specifica per l'app di dati.
• Crea una strategia di rilascio e di versionamento per gli aggiornamenti dei fusi orari per capire quali dispositivi verranno aggiornati e come assicurarti che gli aggiornamenti vengano installati solo sui dispositivi che ne hanno bisogno. Ad esempio, gli OEM potrebbero voler avere una singola app Dati per tutti i loro dispositivi o scegliere di avere app Dati diverse per dispositivi diversi. La decisione influisce sulla scelta del nome del pacchetto, eventualmente dei codici di versione utilizzati e della strategia di QA.
• Scopri se vuole utilizzare i dati sulle zone di fuso orario di Android stock da AOSP o crearne di propri.

Crea un'app di dati

AOSP include tutto il codice sorgente e le regole di compilazione necessarie per creare un'app di dati in packages/apps/TimeZoneData, con istruzioni e modelli di esempio per AndroidManifest.xml e altri file in packages/apps/TimeZoneData/oem_template. I modelli di esempio includono sia un target di compilazione per l'APK dell'app Dati reale sia target aggiuntivi per la creazione di versioni di test dell'app Dati.

Gli OEM possono personalizzare l'app Dati con la propria icona, il proprio nome, le traduzioni e altri dettagli. Tuttavia, poiché l'app Dati non può essere avviata, l'icona viene visualizzata solo nella schermata Impostazioni > App.

L'app Dati è progettata per essere creata con una compilazione tapas che produce APK adatti per essere aggiunti all'immagine di sistema (per la release iniziale) e firmati e distribuiti tramite un app store (per gli aggiornamenti successivi). Per informazioni dettagliate sull'utilizzo di tapas, vedi Creare l'app Data utilizzando tapas.

Gli OEM devono installare l'app Dati predefinita nell'immagine di sistema di un dispositivo in /system/priv-app. Per includere gli APK precompilati (generati dal processo di compilazione di Tapas) nell'immagine di sistema, gli OEM possono copiare i file di esempio in packages/apps/TimeZoneData/oem_template/data_app_prebuilt. I modelli di esempio includono anche target di compilazione per includere le versioni di test dell'app Data nelle suite di test.

Includi le app Updater e Data nell'immagine di sistema

Gli OEM devono posizionare gli APK delle app Updater e Data nella directory /system/priv-app dell'immagine di sistema. Per farlo, la compilazione dell'immagine di sistema deve includere esplicitamente gli obiettivi precompilati dell'app Updater e dell'app Data.

L'app Updater deve essere firmata con la chiave della piattaforma e inclusa come qualsiasi altra app di sistema. Il target è definito in packages/apps/TimeZoneUpdater come TimeZoneUpdater. L'inclusione dell'app di dati è specifica per l'OEM e dipende dal nome target scelto per la precompilazione.

Configura il server di sistema

Per abilitare gli aggiornamenti dei fusi orari, gli OEM possono configurare il server di sistema overriding le proprietà di configurazione definite in frameworks/base/core/res/res/values/config.xml.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Le sostituzioni di configurazione devono essere nell'immagine di sistema (non del fornitore o di altro tipo) poiché un dispositivo configurato in modo errato può rifiutarsi di avviarsi. Se le sostituzioni di configurazione erano nell'immagine del fornitore, l'aggiornamento a un'immagine di sistema senza un'app di dati (o con nomi di pacchetti di app di dati/Updater diversi) sarebbe considerato una configurazione errata.

Test xTS

xTS si riferisce a qualsiasi suite di test specifica per OEM simile alle suite di test Android standard che utilizzano Tradefed (come CTS e VTS). Gli OEM che dispongono di queste suite di test possono aggiungere i test di aggiornamento del fuso orario di Android forniti nelle seguenti posizioni:

• packages/apps/TimeZoneData/testing/xts include il codice necessario per i test di funzionalità automatici di base.
• packages/apps/TimeZoneData/oem_template/xts contiene una struttura di directory di esempio per includere i test in una suite xTS simile a Tradefed. Come per altre directory di modelli, gli OEM devono copiarli e personalizzarli in base alle proprie esigenze.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt contiene la configurazione in fase di compilazione per includere gli APK di test predefiniti richiesti dal test.

Crea aggiornamenti del fuso orario

Quando l'IANA rilascia un nuovo insieme di regole per i fusi orari, il team delle librerie di base di Android genera patch per aggiornare le release in AOSP. Gli OEM che utilizzano i file di sistema e di distribuzione Android di serie possono acquisire questi commit, utilizzarli per creare una nuova versione della propria app di dati e poi rilasciare la nuova versione per aggiornare i propri dispositivi in produzione.

Poiché le app di dati contengono file di distribuzione strettamente correlati alle versioni di Android, gli OEM devono creare una nuova versione dell'app di dati per ogni release Android supportata che un OEM vuole aggiornare. Ad esempio, se un OEM vuole fornire aggiornamenti per i dispositivi Android 8.1, 9 e 10, deve completare la procedura tre volte.

Passaggio 1: aggiorna i file di dati system/timezone ed external/icu

In questo passaggio, gli OEM acquisiscono i commit di Android di serie per system/timezone e external/icu dai branch release-dev in AOSP e li applicano alla propria copia del codice sorgente di Android.

La patch AOSP system/timezone contiene file aggiornati in system/timezone/input_data e system/timezone/output_data. Gli OEM che devono apportare ulteriori correzioni locali possono modificare i file di input e poi utilizzare i file in system/timezone/input_data e external/icu per generare file in output_data.

Il file più importante è system/timezone/output_data/distro/distro.zip, che viene incluso automaticamente durante la compilazione dell'APK dell'app Dati.

Passaggio 2: aggiorna il codice di versione dell'app Dati

In questo passaggio, gli OEM aggiornano il codice di versione dell'app Dati. La compilazione acquisisce automaticamente distro.zip, ma la nuova versione dell'app Dati deve avere un nuovo codice di versione in modo che venga riconosciuta come nuova e utilizzata per sostituire un'app Dati precaricata o un'app Dati installata su un dispositivo da un aggiornamento precedente.

Quando crei l'app Dati utilizzando i file copiati da package/apps/TimeZoneData/oem_template/data_app, puoi trovare il codice di versione/nome della versione applicato all'APK in Android.mk:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

È possibile trovare voci simili in testing/Android.mk (tuttavia, i codici di versione di test devono essere superiori alla versione dell'immagine di sistema). Per maggiori dettagli, consulta lo schema di strategia di codice di versione di esempio. Se viene utilizzato lo schema di esempio o uno schema simile, i codici di versione di test non devono essere aggiornati perché è garantito che siano superiori ai codici di versione reali.

Passaggio 3: ricostruisci, firma, testa e rilascia

In questo passaggio, gli OEM ricostruiscono l'APK utilizzando tapas, firmano l'APK generato, quindi lo testano e lo rilasciano:

• Per i dispositivi non ancora rilasciati (o quando prepari un aggiornamento di sistema per un dispositivo rilasciato), invia i nuovi APK nella directory precompilata dell'app Data per assicurarti che l'immagine di sistema e i test xTS abbiano gli APK più recenti. Gli OEM devono verificare che il nuovo file funzioni correttamente (ovvero che superi i test CTS e qualsiasi test manuale e automatico specifico per l'OEM).
• Per i dispositivi rilasciati che non ricevono più aggiornamenti di sistema, l'APK firmato potrebbe essere rilasciato solo tramite un app store.

Gli OEM sono responsabili della garanzia di qualità e del test dell'app Data aggiornata sui propri dispositivi prima del rilascio.

Strategia per il codice versione dell'app di dati

L'app di dati deve avere una strategia di gestione delle versioni appropriata per garantire che i dispositivi ricevano gli APK corretti. Ad esempio, se viene ricevuto un aggiornamento di sistema contenente un APK precedente a quello scaricato dall'app store, la versione dell'app store deve essere conservata.

Il codice di versione dell'APK deve includere le seguenti informazioni:

• Versione del formato della distribuzione (principale + secondaria)
• Un numero di versione incrementale (opaco)

Attualmente, il livello API della piattaforma è fortemente correlato alla versione del formato della distribuzione perché ogni livello API è solitamente associato a una nuova versione di ICU (che rende i file della distribuzione incompatibili). In futuro, Android potrebbe cambiare in modo che un file di distribuzione possa funzionare su più release della piattaforma Android (e il livello API non viene utilizzato nello schema del codice di versione dell'app di dati).

Esempio di strategia di codice di versione

Questo schema di numerazione delle versioni di esempio garantisce che le versioni del formato di distribuzione superiore sostituiscano le versioni del formato di distribuzione inferiore. AndroidManifest.xml utilizza android:minSdkVersion per assicurarsi che i vecchi dispositivi non ricevano versioni con una versione del formato della distribuzione superiore a quella che possono gestire.

Figura 6. Esempio di strategia di codice di versione.

Lo schema potrebbe essere compresso meglio se si utilizzasse il sistema binario anziché decimale, ma questo schema ha il vantaggio di essere leggibile da persone. Se l'intervallo di numeri completo è esaurito, il nome del pacchetto dell'app di dati potrebbe cambiare.

Il nome della versione è una rappresentazione leggibile dei dettagli, ad esempio major=001,minor=001,iana=2017a, revision=1,respin=2. Gli esempi sono riportati nella tabella seguente.

• Gli esempi 1 e 2 mostrano due versioni APK per la stessa release IANA 2017a con versioni principali del formato diverse. 2 è numericamente superiore a 1, il che è necessario per garantire che i dispositivi più recenti ricevano le versioni del formato più elevato. La proprietà minSdkVersion garantisce che la versione P non venga fornita ai dispositivi O.
• L'esempio 3 è una revisione/correzione di 1 ed è numericamente superiore a 1.
• Gli esempi 4 e 5 mostrano le release 2017b per O-MR1 e P. Poiché sono numericamente superiori, sostituiscono le release/revisioni Android IANA precedenti dei rispettivi predecessori.
• Gli esempi 6 e 7 mostrano le release 2018a per O-MR1 e P.
• L'esempio 8 mostra l'utilizzo di Y per sostituire completamente lo schema Y=0.
• L'esempio 9 mostra l'utilizzo dell'intervallo tra 3 e 4 per eseguire nuovamente il respinning dell'apk.

Poiché ogni dispositivo viene fornito con un APK predefinito con una versione appropriata nell'immagine di sistema, non c'è il rischio che venga installata una versione O-MR1 su un dispositivo P perché ha un numero di versione inferiore a quello di un'immagine di sistema P. Un dispositivo con una versione O-MR1 installata in /data che poi riceve un aggiornamento di sistema a P utilizza la versione /system in preferenza alla versione O-MR1 in /data perché la versione P è sempre superiore a qualsiasi app destinata a O-MR1.

Creare l'app Dati utilizzando tapas

Gli OEM sono responsabili della gestione della maggior parte degli aspetti dell'app Dati fuso orario e della configurazione corretta dell'immagine di sistema. L'app Dati è progettata per essere creata con una compilazione tapas che produce APK adatti per essere aggiunti all'immagine di sistema (per la release iniziale) e firmati e distribuiti tramite un app store (per gli aggiornamenti successivi).

Tapas è una versione semplificata del sistema di compilazione Android che utilizza una struttura ad albero delle sorgenti ridotta per produrre versioni distribuibili delle app. Gli OEM che hanno dimestichezza con il normale sistema di compilazione di Android dovrebbero riconoscere i file di compilazione della normale compilazione della piattaforma Android.

Crea il file manifest

Un albero di origine ridotto viene solitamente ottenuto con un file manifest personalizzato che fa riferimento solo ai progetti Git necessari per il sistema di compilazione e per la compilazione dell'app. Dopo aver seguito le istruzioni riportate in Creazione di un'app di dati, gli OEM devono avere almeno due progetti Git specifici per l'OEM creati utilizzando i file modello in packages/apps/TimeZoneData/oem_template:

• Un progetto Git contiene file dell'app come il manifest e i file di compilazione necessari per creare il file APK dell'app (ad esempio,vendor/oem/apps/TimeZoneData). Questo progetto contiene anche regole di compilazione per gli APK di test che possono essere utilizzati dai test xTS.
• Un progetto Git contiene gli APK firmati prodotti dalla compilazione dell'app per la loro inclusione nella compilazione dell'immagine di sistema e nei test xTS.

La compilazione dell'app sfrutta diversi altri progetti Git condivisi con la compilazione della piattaforma o contenenti librerie di codice indipendenti dall'OEM.

Il seguente snippet manifest contiene l'insieme minimo di progetti Git necessari per supportare una build O-MR1 dell'app Dati per i fusi orari. Gli OEM devono aggiungere a questo manifest i propri progetti Git specifici per l'OEM (che in genere includono un progetto contenente il certificato di firma) e possono configurare di conseguenza diversi branch.

   <!-- 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" />

Esegui la build di tapas

Dopo aver stabilito la struttura dell'albero di origine, invoca la compilazione tapas utilizzando i seguenti comandi:

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

Una compilazione riuscita genera file nella directory out/dist per i test. Questi file possono essere inseriti nella directory prebuilt per essere inclusi nell'immagine di sistema e/o distribuiti tramite un app store per i dispositivi compatibili.