Regole del fuso orario

Android 10 depreca 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 del modulo basato su APEX . AOSP da 8.1 a 13 include ancora il codice della piattaforma necessario agli OEM per abilitare gli aggiornamenti basati su APK, quindi i dispositivi che eseguono l'aggiornamento ad Android 10 possono ancora ricevere gli aggiornamenti dei dati del fuso orario forniti dai partner tramite APK. Tuttavia, il meccanismo di aggiornamento dell'APK non deve essere utilizzato su un dispositivo di produzione che riceve anche aggiornamenti del modulo poiché 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 del fuso orario (Android 10+)

Il modulo Time Zone Data supportato in Android 10 e versioni successive aggiorna l'ora legale (DST) e i fusi orari sui dispositivi Android, standardizzando i dati che possono cambiare frequentemente per motivi religiosi, politici e geopolitici.

Gli aggiornamenti utilizzano il seguente processo:

1. IANA rilascia un aggiornamento al database del fuso orario rilascia un aggiornamento in risposta a uno o più governi che modificano una regola del fuso orario nei loro paesi.
2. Google o il partner Android prepara un aggiornamento del modulo Time Zone Data (file APEX) contenente i fusi orari aggiornati.
3. Il dispositivo dell'utente finale scarica l'aggiornamento, si riavvia, quindi applica le modifiche, dopodiché i dati del fuso orario del dispositivo contengono i nuovi dati del fuso orario dall'aggiornamento.

Per i dettagli sui moduli, vedere Componenti del sistema modulare .

Aggiornamenti del fuso orario (Android 8.1–9)

Nota: la funzionalità del meccanismo di aggiornamento dei dati del fuso orario basato sull'APK è stata completamente rimossa da Android U in poi e non può essere trovata nel codice sorgente. I partner devono migrare completamente al modulo Time Zone Mainline.

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 del fuso orario senza richiedere un aggiornamento del sistema. Questo meccanismo consente agli utenti di ricevere aggiornamenti tempestivi (estendendo così la vita utile di un dispositivo Android) e consente ai partner Android di testare gli aggiornamenti del fuso orario indipendentemente dagli aggiornamenti dell'immagine del sistema.

Il team delle librerie principali di Android fornisce i file di dati necessari per aggiornare le regole del fuso orario su un dispositivo Android di serie. Gli OEM possono scegliere di utilizzare questi file di dati durante la creazione di aggiornamenti del fuso orario per i propri dispositivi o possono creare i propri file di dati, se lo si preferisce. In tutti i casi, gli OEM mantengono il controllo sulla garanzia/test di qualità, sui tempi e sul lancio degli aggiornamenti delle regole del fuso orario per i loro dispositivi supportati.

Codice sorgente e dati del fuso orario Android

Tutti i dispositivi Android di serie, anche quelli che non utilizzano questa funzione, necessitano dei dati delle regole del fuso orario e devono essere spediti con un set predefinito di dati delle regole del fuso orario nella partizione /system . Questi dati vengono quindi utilizzati dal codice delle seguenti librerie nell'albero dei sorgenti di Android:

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

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

• libcore/ e bionic/ code usano la copia /data dei file tzdata e tzlookup.xml .
• Il codice ICU4J/ICU4C utilizza i file in /data e torna a /system file per i dati che non sono presenti (per formati, stringhe localizzate, ecc.).

File di distribuzione

I file distro .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 versione.

Il formato del file di distribuzione dipende dalla versione di Android perché i contenuti cambiano con la versione ICU, i requisiti della piattaforma Android e altre modifiche alla versione. Android fornisce file di distribuzione per le versioni 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 di file distro a un dispositivo e l'installazione sicura dei file in esso contenuti. Il trasferimento e l'installazione richiedono quanto segue:

• Funzionalità del servizio piattaforma ( timezone.RulesManagerService ), 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 operazioni già organizzate.
• TimeZoneUpdater , un'app di sistema non aggiornabile (nota anche come app Updater ). Gli OEM devono includere questa app nell'immagine di sistema dei dispositivi che utilizzano la funzione.
• OEM TimeZoneData , un'app di sistema aggiornabile (nota anche come app Data ) che trasporta i file di distribuzione sul dispositivo e li rende disponibili all'app Updater. Gli OEM devono includere questa app nell'immagine di sistema dei dispositivi che utilizzano la funzione.
• tzdatacheck , un binario di avvio necessario per il corretto e sicuro funzionamento degli aggiornamenti del fuso orario.

L'albero dei sorgenti di Android contiene un codice sorgente generico per i componenti di cui sopra, che l'OEM può scegliere di utilizzare senza modifiche. Viene fornito un codice di test per consentire agli OEM di verificare automaticamente di aver abilitato la funzionalità correttamente.

Installazione distribuzione

Il processo di installazione della distribuzione include i seguenti passaggi:

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

   

2. Il processo del server di sistema attiva un controllo di aggiornamento trasmettendo un intento mirato con un token unico e monouso all'app Updater. Il server di sistema tiene traccia del token più recente che ha generato in modo da poter determinare quando è stato completato il controllo più recente attivato; tutti gli altri token vengono ignorati.
   
   

   

3. Durante il controllo dell'aggiornamento , l'app Updater esegue le seguenti attività:
   • Interroga lo stato del dispositivo corrente chiamando il RulesManagerService.
     
     

     

   • Esegue query sull'app Data eseguendo una query su un URL ContentProvider ben definito e specifiche di colonna per ottenere 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 della distribuzione vengono letti dall'app Dati e passati a RulesManagerService nel server di sistema. Il RulesManagerService riconferma che la versione e il contenuto del formato distro sono appropriati per il dispositivo e mette in scena l'installazione.
   • Richiedi una disinstallazione (questo è raro). Ad esempio, se l'APK aggiornato in /data viene disabilitato o disinstallato e il dispositivo torna alla versione presente in /system .
   • Fare niente. Si verifica quando la distribuzione dell'app dati risulta non valida.
   In tutti i casi, l'app Updater chiama il RulesManagerService con il token di controllo in modo che il server di sistema sappia che il controllo è completo e ha esito positivo.
   
   

   

5. Riavvia e tzdatacheck. Al successivo avvio del dispositivo, il binario tzdatacheck esegue qualsiasi operazione a fasi. Il binario tzdatacheck può eseguire le seguenti attività:
   • Eseguire l'operazione a fasi gestendo la creazione, la sostituzione e/o l'eliminazione dei /data/misc/zoneinfo/current prima che altri componenti del sistema abbiano aperto e iniziato a utilizzare i file.
   • 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 distro è cambiata.
   • Assicurati che la versione delle regole IANA sia la stessa o più recente della versione in /system . Ciò protegge da un aggiornamento del sistema che lascia un dispositivo con dati delle regole del fuso orario precedenti 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 perdere l'alimentazione, esaurire lo spazio su disco o riscontrare altri problemi, rendendo incompleto il controllo dell'installazione. Nel migliore dei casi non riuscito, l'app Updater informa il server di sistema che non ha avuto successo; nel peggiore dei casi senza successo, il RulesManagerService non riceve alcuna chiamata.

Per gestire ciò, il codice del server di sistema tiene traccia del completamento di un controllo di aggiornamento attivato e dell'ultimo codice di versione verificato dell'app dati. Quando il dispositivo è inattivo e in carica, il codice del server di sistema può verificare lo stato corrente. Se rileva un controllo degli aggiornamenti incompleto o una versione dell'app dati imprevista, attiva spontaneamente un controllo degli aggiornamenti.

Sicurezza

Quando 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 mal configurata impediscono l'avvio di un dispositivo; gli esempi includono una configurazione dell'app di aggiornamento o dati errata o l'app di aggiornamento o dati che non si trova in /system/priv-app .
• I problemi che indicano che è stata installata un'app Data errata 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.

I permessi dei file per le directory /data/misc/zoneinfo vengono applicati usando le regole di SELinux. Come con qualsiasi APK, l'app Data deve essere firmata dalla stessa chiave utilizzata per firmare la versione /system/priv-app . L'app Data dovrebbe avere un nome e una chiave del pacchetto specifici per OEM.

Integrazione degli aggiornamenti del fuso orario

Per abilitare la funzione di aggiornamento del fuso orario, gli OEM in genere:

• Crea la propria app dati.
• Includi le app Updater e Data nella build dell'immagine di sistema.
• Configurare il server di sistema per abilitare RulesManagerService.

Preparazione

Prima di iniziare, gli OEM devono esaminare le seguenti considerazioni su politica, garanzia della qualità e sicurezza:

• Crea una chiave di firma specifica per l'app dedicata per l'app Dati.
• Crea una strategia di rilascio e controllo delle versioni per gli aggiornamenti del fuso orario per capire quali dispositivi verranno aggiornati e come possono garantire che gli aggiornamenti vengano installati solo sui dispositivi che ne hanno bisogno. Ad esempio, gli OEM potrebbero voler disporre di un'unica 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 sui codici di versione utilizzati e sulla strategia di controllo qualità.
• Scopri se vogliono utilizzare i dati del fuso orario Android di serie da AOSP o crearne di propri.

Creazione di un'app dati

AOSP include tutto il codice sorgente e le regole di compilazione necessarie per creare un'app 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 sia una destinazione di compilazione per l'APK dell'app Dati reale sia destinazioni aggiuntive per la creazione di versioni di prova dell'app Dati.

Gli OEM possono personalizzare l'app Dati con la propria icona, nome, 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 è pensata per essere costruita con una build tapas che produce APK adatti ad essere aggiunti all'immagine di sistema (per la versione iniziale) e firmati e distribuiti tramite un app store (per aggiornamenti successivi). Per i dettagli sull'utilizzo delle tapas, consulta Creazione dell'app Dati tramite tapas .

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

Comprese le app Updater e Data nell'immagine di sistema

Gli OEM devono inserire gli APK dell'app Updater e Data nella directory /system/priv-app dell'immagine di sistema. A tale scopo, la build dell'immagine di sistema deve includere in modo esplicito l'app Updater e le destinazioni predefinite dell'app Dati.

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 dell'OEM e dipende dal nome di destinazione scelto per la precompilazione.

Configurazione del server di sistema

Per abilitare gli aggiornamenti del fuso orario, gli OEM possono configurare il server di sistema sovrascrivendo 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 della configurazione devono essere nell'immagine del sistema (non del fornitore o altro) poiché un dispositivo configurato in modo errato può rifiutarsi di avviarsi. Se le sostituzioni della configurazione si trovassero nell'immagine del fornitore, l'aggiornamento a un'immagine di sistema senza un'app dati (o con nomi di pacchetti di app dati/app di aggiornamento diversi) sarebbe considerata 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 tali suite di test possono aggiungere i test di aggiornamento del fuso orario Android forniti nei seguenti percorsi:

• 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 con altre directory di modelli, gli OEM devono copiare e personalizzare 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.

Creazione di aggiornamenti del fuso orario

Quando IANA rilascia una nuova serie di regole del fuso orario, il team delle librerie principali di Android genera patch per aggiornare le versioni in AOSP. Gli OEM che utilizzano il sistema Android di serie e i file di distribuzione possono raccogliere questi commit, utilizzarli per creare una nuova versione della propria app Data, quindi rilasciare la nuova versione per aggiornare i propri dispositivi in ​​produzione.

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

Passaggio 1: aggiornamento dei file di sistema/fuso orario e dati esterni/icu

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

La patch AOSP system/timezone 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, quindi 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 quando viene creato l'APK dell'app Data.

Passaggio 2: aggiornamento del codice della versione dell'app Dati

In questo passaggio, gli OEM aggiornano il codice della versione dell'app Dati. La build preleva automaticamente distro.zip , ma la nuova versione dell'app Dati deve avere un nuovo codice di versione, quindi viene riconosciuta come nuova e viene utilizzata per sostituire un'app Dati precaricata o un'app Dati installata su un dispositivo da un aggiornamento precedente.

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Voci simili possono essere trovate in testing/Android.mk (tuttavia, i codici della versione di prova devono essere superiori alla versione dell'immagine di sistema). Per i dettagli, vedere lo schema di strategia del codice della versione di esempio ; se viene utilizzato lo schema di esempio o uno schema simile, non è necessario aggiornare i codici della versione di prova perché è garantito che siano superiori ai codici della versione reale.

Passaggio 3: ricostruzione, firma, test e rilascio

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

• Per i dispositivi non rilasciati (o durante la preparazione di un aggiornamento di sistema per un dispositivo rilasciato), invia i nuovi APK nella directory predefinita dell'app Dati per assicurarti che l'immagine di sistema e i test xTS dispongano degli APK più recenti. Gli OEM devono verificare che il nuovo file funzioni correttamente (ovvero, supera CTS e qualsiasi test automatico e manuale specifico 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 della qualità e del test dell'app Data aggiornata sui propri dispositivi prima del rilascio.

Strategia del codice della versione dell'app dati

L'app Data deve disporre di 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 che contiene un APK precedente rispetto a quello scaricato dall'App Store, la versione dell'App Store deve essere conservata.

Il codice della versione APK dovrebbe includere le seguenti informazioni:

• Versione in formato distribuzione (maggiore + minore)
• Un numero di versione incrementale (opaco).

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

Esempio di strategia del codice della versione

Questo schema del numero di versione di esempio garantisce che le versioni in formato distro superiori sostituiscano le versioni in formato distro inferiore. AndroidManifest.xml usa android:minSdkVersion per garantire che i vecchi dispositivi non ricevano versioni con una versione in formato distro superiore a quella che possono gestire.

Lo schema potrebbe essere compresso meglio se fosse utilizzato binario anziché decimale, ma questo schema ha il vantaggio di essere leggibile dall'uomo. Se l'intervallo di numeri completo è esaurito, il nome del pacchetto dell'app dati potrebbe cambiare.

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

• Gli esempi 1 e 2 mostrano due versioni APK per la stessa versione IANA 2017a con diverse versioni di formato principale. 2 è numericamente maggiore di 1, necessario per garantire che i dispositivi più recenti ricevano le versioni di formato superiore. minSdkVersion garantisce che la versione P non venga fornita ai dispositivi O.
• L'esempio 3 è una revisione/correzione per 1 ed è numericamente maggiore di 1.
• Gli esempi 4 e 5 mostrano le versioni 2017b per O-MR1 e P. Essendo numericamente superiori, sostituiscono le precedenti versioni IANA/revisioni Android dei rispettivi predecessori.
• Gli esempi 6 e 7 mostrano le versioni 2018a per O-MR1 e P.
• L'esempio 8 mostra l'uso di Y per sostituire completamente lo schema Y=0.
• L'esempio 9 mostra l'uso del gap lasciato tra 3 e 4 per girare nuovamente l'apk.

Poiché ogni dispositivo viene fornito con un APK predefinito con versione appropriata nell'immagine di sistema, non c'è il rischio che una versione O-MR1 venga installata 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 quindi riceve un aggiornamento di sistema in P utilizza la versione /system invece della versione O-MR1 in /data perché la versione P è sempre superiore a qualsiasi app destinata a O- MR1.

Creazione dell'app Dati utilizzando tapas

Gli OEM sono responsabili della gestione della maggior parte degli aspetti dell'app Dati del fuso orario e della corretta configurazione dell'immagine del sistema. L'app Data è pensata per essere costruita con una build tapas che produce APK adatti ad essere aggiunti all'immagine di sistema (per la versione iniziale) e firmati e distribuiti tramite un app store (per aggiornamenti successivi).

Tapas è una versione ridotta del sistema di build Android che utilizza un albero dei sorgenti ridotto per produrre versioni distribuibili di app. Gli OEM che hanno familiarità con il normale sistema di build Android dovrebbero riconoscere i file di build dalla normale build della piattaforma Android.

Creazione del manifesto

Un albero dei sorgenti ridotto si ottiene in genere con un file manifest personalizzato che fa riferimento solo ai progetti Git necessari al sistema di compilazione e per la creazione dell'app. Dopo aver seguito le istruzioni in Creazione di un'app di dati , gli OEM devono avere almeno due progetti Git specifici per 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 build 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 build dell'app per l'inclusione nella build dell'immagine di sistema e nei test xTS.

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

Il frammento di codice manifest seguente contiene il set minimo di progetti Git necessari per supportare una build O-MR1 dell'app dati del fuso orario. Gli OEM devono aggiungere i loro progetti Git specifici per OEM (che in genere includono un progetto che contiene il certificato di firma) a questo manifest 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="master"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

Esecuzione della build di tapas

Dopo aver stabilito l'albero dei sorgenti, richiama la build tapas usando 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 il test. Questi file possono essere inseriti nella directory predefinita per essere inclusi nell'immagine di sistema e/o distribuiti tramite un app store per dispositivi compatibili.