Regole per i fusi orari

Android 10 ritira il meccanismo di aggiornamento dei dati del fuso orario basato su APK (disponibile in Android 8.1 e Android 9) e lo sostituisce con un meccanismo di aggiornamento dei moduli basato su APEX. AOSP 8.1-13 include ancora il codice della piattaforma necessario agli OEM per attivare gli aggiornamenti basati su APK, pertanto i dispositivi che eseguono l'upgrade ad Android 10 possono comunque ricevere aggiornamenti dei dati del fuso orario forniti dai partner tramite APK. Tuttavia, il meccanismo di aggiornamento degli 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 ignora gli aggiornamenti basati su APEX).

Aggiornamenti del fuso orario (Android 10 e versioni successive)

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

Gli aggiornamenti utilizzano la seguente procedura:

1. IANA rilascia un aggiornamento del database dei fusi orari in risposta alla modifica di una regola del fuso orario da parte di uno o più governi nei rispettivi paesi.
2. Google o il partner Android prepara un aggiornamento del modulo dei dati del fuso orario (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, vedi Componenti del sistema modulare.

Aggiornamenti del fuso orario (Android 8.1-9)

Nota:il meccanismo di aggiornamento dei dati del fuso orario basato su APK è stato completamente rimosso 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 eseguire il push dei dati aggiornati delle regole del fuso orario sui dispositivi senza richiedere un aggiornamento del 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 del fuso orario su un dispositivo Android stock. Gli OEM possono scegliere di utilizzare questi file di dati durante la creazione di aggiornamenti del fuso orario per i propri dispositivi oppure possono creare i propri file di dati, se preferiscono. In tutti i casi, gli OEM mantengono il controllo su garanzia/test di qualità, tempistiche e lancio degli aggiornamenti delle regole del fuso orario per i dispositivi supportati.

Codice sorgente e dati del fuso orario di Android

Tutti i dispositivi Android stock, anche quelli che non utilizzano questa funzionalità, necessitano di dati sulle regole del fuso orario e devono essere forniti con un insieme predefinito di dati sulle regole del fuso orario nella partizione /system. Questi dati vengono poi utilizzati dal codice delle seguenti librerie nell'albero delle origini di Android:

• Il codice gestito di libcore/ (ad esempio, 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 tengono traccia dei file di overlay che potrebbero essere presenti nella directory /data/misc/zoneinfo/current. I file di overlay devono contenere dati migliorati sulle regole del fuso orario, consentendo così l'aggiornamento dei dispositivi senza modificare /system.

I componenti di sistema Android che richiedono il controllo dei dati delle regole del fuso orario controllano prima le seguenti posizioni:

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

File di distribuzione

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

Il formato del file di distribuzione dipende dalla versione di Android perché i contenuti cambiano in base alla versione di ICU, ai requisiti della piattaforma Android e ad altre modifiche della release. Android fornisce file di distribuzione per le release Android supportate per ogni aggiornamento IANA (oltre all'aggiornamento dei file di sistema della piattaforma). Per mantenere aggiornati i propri dispositivi, gli OEM possono utilizzare questi file di distribuzione o crearne di propri utilizzando l'albero dei sorgenti di Android (che contiene gli script e altri file necessari per generare i file di distribuzione).

Componenti di aggiornamento del fuso orario

Un aggiornamento delle regole del fuso orario prevede la trasmissione dei file di distribuzione a un dispositivo e l'installazione sicura dei file contenuti. Il trasferimento e l'installazione richiedono quanto segue:

• Funzionalità del servizio di piattaforma (timezone.RulesManagerService), che è disabilitata per impostazione predefinita. Gli OEM devono abilitare la funzionalità tramite la configurazione. RulesManagerService viene eseguito nel processo del server di sistema e organizza le operazioni di aggiornamento del fuso orario scrivendo in /data/misc/zoneinfo/staged. RulesManagerService può anche sostituire o eliminare le operazioni già eseguite.
• 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 trasferisce i file di distribuzione al 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 binario di avvio necessario per il funzionamento corretto e sicuro degli aggiornamenti dei fusi orari.

L'albero delle origini 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 distribuzione include i seguenti passaggi:

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

   Figura 1. Aggiornamenti dell'app Dati.

2. Il processo del server di sistema attiva un controllo degli aggiornamenti trasmettendo un intent mirato con un token monouso univoco all'app Updater. Il server di sistema tiene traccia del token più recente generato in modo da poter determinare quando è stato completato l'ultimo controllo 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 una query sullo stato attuale del dispositivo chiamando RulesManagerService.
     
     

     Figura 3. Aggiornamenti dell'app Dati, che chiama RulesManagerService.

   • Esegue query sull'app Data eseguendo query su un URL ContentProvider ben definito e sulle specifiche delle colonne per ottenere informazioni sulla distribuzione.
     
     

     Figura 4. Aggiornamenti dell'app Dati, ricevi informazioni sulla distribuzione.

4. L'app Updater esegue l'azione appropriata in base alle informazioni in suo possesso. Le azioni disponibili includono:
   • Richiedi un'installazione. I dati di distribuzione vengono letti dall'app Data e vengono passati a RulesManagerService nel server di sistema. RulesManagerService verifica nuovamente che la versione e i contenuti del formato di distribuzione siano appropriati per il dispositivo e prepara l'installazione.
   • Richiedi una disinstallazione (è raro). 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 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 è completo e riuscito.
   
   

   Figura 5. Controllo completato.

5. Riavvia e tzdatacheck. Al successivo avvio del dispositivo, il binario tzdatacheck esegue qualsiasi operazione di gestione temporanea. Il programma binario tzdatacheck può eseguire le seguenti attività:
   • Esegui l'operazione in più fasi gestendo la creazione, la sostituzione e/o l'eliminazione dei file /data/misc/zoneinfo/current prima che altri componenti di sistema abbiano aperto e iniziato a utilizzare i file.
   • Verifica che i file in /data siano corretti per la versione attuale della piattaforma, il che potrebbe non verificarsi 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 uguale o più recente di quella in /system. In questo modo si evita che un aggiornamento del sistema lasci un dispositivo con dati delle regole del fuso orario meno recenti rispetto a quelli presenti nell'immagine /system.

Affidabilità

Il processo di installazione end-to-end è asincrono e suddiviso in tre processi del sistema operativo. In qualsiasi momento durante l'installazione, il dispositivo potrebbe spegnersi, esaurire lo spazio su disco o riscontrare altri problemi, causando l'incompletezza del controllo dell'installazione. Nel migliore dei casi di esito negativo, l'app Updater comunica al server di sistema che l'operazione non è riuscita; nel peggiore dei casi di esito negativo, RulesManagerService non riceve alcuna chiamata.

Per gestire questo problema, il codice del server di sistema tiene traccia del completamento di un controllo degli aggiornamenti attivato e del codice di versione dell'app dati controllato per ultimo. Quando il dispositivo è inattivo e in carica, il codice del server di sistema può controllare lo stato attuale. Se rileva un controllo degli aggiornamenti incompleto o una versione dell'app Dati imprevista, attiva spontaneamente un controllo degli aggiornamenti.

Sicurezza

Se attivato, 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 includono una configurazione errata dell'app Updater o Data oppure l'app Updater o Data non presente in /system/priv-app.
• I problemi che indicano che è stata installata un'app Data dannosa non impediscono l'avvio di un dispositivo, ma impediscono l'attivazione di un controllo degli aggiornamenti. Gli esempi includono la mancanza delle autorizzazioni di sistema richieste o l'app Data non espone un ContentProvider sull'URI previsto.

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

Integrare gli aggiornamenti del fuso orario

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

• Creare la propria app Dati.
• Includi le app Updater e Data nella build dell'immagine di sistema.
• Configura il server di sistema per abilitare RulesManagerService.

Preparazione

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

• Crea una chiave di firma specifica per l'app per i dati.
• Crea una strategia di rilascio e controllo delle versioni per gli aggiornamenti dei fusi orari per capire quali dispositivi verranno aggiornati e come possono assicurarsi che gli aggiornamenti vengano installati solo sui dispositivi che ne hanno bisogno. Ad esempio, gli OEM potrebbero voler avere una sola 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, sui codici di versione utilizzati e sulla strategia di controllo qualità.
• Capisci se vogliono utilizzare i dati sui fusi orari di Android stock di 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 per i dati in packages/apps/TimeZoneData, con istruzioni e modelli di esempio per AndroidManifest.xml e altri file che si trovano in packages/apps/TimeZoneData/oem_template. I modelli di esempio includono un target di build per l'APK dell'app Data reale e target aggiuntivi per creare versioni di test dell'app Data.

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

L'app Data deve essere creata con una build 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 delle tapas, vedi Creare l'app Data utilizzando le tapas.

Gli OEM devono installare l'app Dati preinstallata nell'immagine di sistema di un dispositivo in /system/priv-app. Per includere gli APK predefiniti (generati dal processo di build 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 build per includere versioni di test dell'app Dati nelle suite di test.

Includi le app Updater e Data nell'immagine di sistema

Gli OEM devono inserire gli APK delle app Updater e Data nella directory /system/priv-app dell'immagine di sistema. A questo scopo, la compilazione dell'immagine di sistema deve includere esplicitamente l'app Updater e i target precompilati dell'app Data.

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

Configurare il server di sistema

Per attivare gli aggiornamenti del fuso orario, gli OEM possono configurare il server di sistema eseguendo l'override delle 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

Gli override di configurazione devono essere nell'immagine di sistema (non fornitore o altro), in quanto un dispositivo configurato in modo errato può rifiutarsi di avviarsi. Se gli override della configurazione erano nell'immagine del fornitore, l'aggiornamento a un'immagine di sistema senza un'app Dati (o con nomi di pacchetti di app Dati/app Updater diversi) sarebbe considerato un errore di configurazione.

Test xTS

xTS si riferisce a qualsiasi suite di test specifica dell'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 funzionali automatizzati 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 copiare e personalizzare i modelli in base alle loro 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.

Creare 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 stock possono recuperare questi commit, utilizzarli per creare una nuova versione della propria app Dati e poi rilasciare la nuova versione per aggiornare i propri dispositivi in produzione.

Poiché le app per i dati contengono file di distribuzione strettamente correlati alle versioni di Android, gli OEM devono creare una nuova versione dell'app per i dati per ogni versione di 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 di sistema/fuso orario ed esterni/icu

In questo passaggio, gli OEM prendono i commit di Android system/timezone e external/icu dai rami release-dev in AOSP e li applicano alla loro copia del codice sorgente di Android.

La patch AOSP per il sistema/fuso orario contiene file aggiornati in system/timezone/input_data e system/timezone/output_data. Gli OEM che devono apportare correzioni locali aggiuntive 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 creazione dell'APK dell'app Dati.

Passaggio 2: aggiorna il codice versione dell'app Dati

In questo passaggio, gli OEM aggiornano il codice di versione dell'app Dati. La build recupera 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 venga utilizzata per sostituire un'app Dati precaricata o un'app Dati installata su un dispositivo da un precedente aggiornamento.

Quando crei l'app Data 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 :=

Voci simili sono disponibili in testing/Android.mk (tuttavia, i codici di versione di test devono essere superiori alla versione dell'immagine di sistema). Per i dettagli, consulta lo schema di strategia di esempio per il codice di versione; se viene utilizzato lo schema di esempio o uno simile, i codici di versione di test non devono essere aggiornati perché è garantito che siano superiori ai codici di versione reali.

Passaggio 3: ricompila, firma, testa e rilascia

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

• Per i dispositivi non rilasciati (o quando prepari un aggiornamento di sistema per un dispositivo rilasciato), invia i nuovi APK nella directory predefinita 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 superi CTS e tutti i test automatici e manuali specifici dell'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 Aggiornamento dati sui propri dispositivi prima del rilascio.

Strategia per il codice versione dell'app di dati

L'app Dati deve avere una strategia di controllo delle versioni adeguata 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 dallo store, deve essere mantenuta la versione dello store.

Il codice versione 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 è in genere associato a una nuova versione di ICU (il che rende incompatibili i file di distribuzione). In futuro, Android potrebbe modificare questa impostazione in modo che un file di distribuzione possa funzionare su più versioni della piattaforma Android (e il livello API non venga utilizzato nello schema del codice di versione dell'app Data).

Strategia di esempio per il codice di versione

Questo schema di numerazione delle versioni di esempio garantisce che le versioni del formato di distribuzione più recenti sostituiscano quelle meno recenti. AndroidManifest.xml utilizza android:minSdkVersion per assicurarsi che i dispositivi meno recenti non ricevano versioni con un formato di distribuzione più recente di quello che possono gestire.

Figura 6. Esempio di strategia del codice di versione.

Lo schema potrebbe essere compattato meglio se venisse utilizzato il sistema binario anziché quello decimale, ma questo schema ha il vantaggio di essere leggibile. Se l'intervallo numerico completo è esaurito, il nome del pacchetto dell'app 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 dell'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ù recenti. minSdkVersion garantisce che la versione P non venga fornita ai dispositivi O.
• L'esempio 3 è una revisione/correzione dell'esempio 1 ed è numericamente superiore a 1.
• Gli esempi 4 e 5 mostrano le release 2017b per O-MR1 e P. Essendo numericamente superiori, sostituiscono le versioni IANA/revisioni Android 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 dello spazio lasciato tra 3 e 4 per ricompilare l'APK.

Poiché ogni dispositivo viene fornito con un APK predefinito con la versione appropriata nell'immagine di sistema, non esiste il rischio che venga installata una versione O-MR1 su un dispositivo P perché ha un numero di versione inferiore rispetto a una versione dell'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 preferibilmente 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 sul fuso orario e della configurazione corretta dell'immagine di sistema. L'app Data è pensata per essere creata con una build 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 di Android che utilizza un albero delle origini ridotto per produrre versioni distribuibili delle app. Gli OEM che conoscono il normale sistema di compilazione Android dovrebbero riconoscere i file di compilazione dalla normale compilazione della piattaforma Android.

Crea il manifest

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

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

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

Il seguente snippet del manifest contiene il set minimo di progetti Git necessari per supportare una build O-MR1 dell'app per i dati sul fuso orario. Gli OEM devono aggiungere a questo manifest i propri progetti Git specifici dell'OEM (che in genere includono un progetto che contiene il certificato di firma) e possono configurare rami diversi di conseguenza.

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

Una volta stabilita la struttura ad albero dell'origine, richiama la build 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 build riuscita genera file nella directory out/dist per i test. Questi file possono essere inseriti nella directory prebuilt per l'inclusione nell'immagine di sistema e/o distribuiti tramite uno store per dispositivi compatibili.