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 dei moduli 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 del fuso orario (Android 10 e versioni successive)

Il modulo Dati sui fusi orari 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 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 relative ai fusi orari su un dispositivo Android standard. Gli OEM possono scegliere di utilizzare questi file di dati durante la creazione di aggiornamenti relativi al fuso orario per i loro dispositivi o, se preferiscono, creare i propri file di dati. In tutti i casi, gli OEM mantengono il controllo sul controllo qualità/sui test, sulle tempistiche e sul lancio degli aggiornamenti delle regole relative ai fusi orari per i propri dispositivi supportati.

Dati e codice sorgente dei fusi orari di Android

Tutti i dispositivi Android standard, anche quelli che non utilizzano questa funzionalità, hanno bisogno di dati sulle regole per il fuso orario e devono includere un insieme predefinito di dati relativi alle regole per il fuso orario 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 libreria ICU4J/ICU4C in external/icu/ usa 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 dovrebbero contenere dati migliorati sulle regole per il fuso orario, in modo che i dispositivi possano essere aggiornati senza modificare /system.

I componenti di sistema Android che richiedono dati sulle 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 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 distro contengono anche metadati che consentono ai dispositivi di rilevare i problemi di controllo delle versioni.

Il formato file della distro dipende dalla release Android perché i contenuti cambiano in base alla versione di ICU, ai requisiti della piattaforma Android e ad altre modifiche alla 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 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 (nota anche come 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 come l'app di dati) che trasporta i file di 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 di origine di Android contiene codice sorgente generico per i componenti precedenti, 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 specifica per l'OEM configurato.
   
   

   Figura 1. Aggiornamenti delle app di dati.

2. Il processo del server di sistema attiva un controllo degli aggiornamenti trasmettendo un intent target con un token univoco e monouso all'app Updater. Il server di sistema tiene traccia del token più recente generato per poter determinare quando è stato completato il controllo più recente attivato; eventuali 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 delle app di dati, chiamata RulesManagerService.

   • Interroga l'app Dati eseguendo query su un URL ContentProvider ben definito e sulle specifiche della colonna per ottenere informazioni sulla distro.
     
     

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

4. L'app Updater intraprende 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 Dati e passati 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 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 di quelli presenti nell'immagine /system.

Affidabilità

La procedura di installazione end-to-end è asincrona e suddivisa in tre processi OS. In qualsiasi momento durante l'installazione, il dispositivo potrebbe non essere alimentato, esaurito lo spazio su disco o riscontrare altri problemi, causando un'incompleta verifica dell'installazione. Nel migliore dei casi, l'app Updater informa il server di 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 imprevista dell'app Data App, attiva spontaneamente un controllo degli aggiornamenti.

Sicurezza

Se abilitato, il codice RulesManagerService nel server di sistema esegue diversi controlli per garantire la sicurezza del sistema.

• 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 con qualsiasi APK, l'app Dati deve essere firmata con la stessa chiave utilizzata per firmare la versione di /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 build necessarie per creare un'app di 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 una destinazione di build per l'APK dell'app di dati reale e target aggiuntivi per la creazione di versioni di test dell'app di 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 deve essere creata con una build tapas che produce APK adatti all'aggiunta all'immagine di sistema (per la release iniziale) e firmata e distribuita tramite uno 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 APK predefiniti (generati dal processo di compilazione delle 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 di aggiornamento 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 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

Le sostituzioni della configurazione devono essere presenti nell'immagine di sistema (non del fornitore o di altro tipo), perché 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.

Creare aggiornamenti relativi al fuso orario

Quando IANA rilascia un nuovo set di regole per il fuso orario, il team delle librerie principali 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 Android per system/timezone e external/icu dai rami di sviluppo release in AOSP e applicano questi 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 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 di dati. La build seleziona automaticamente distro.zip, ma la nuova versione dell'app di dati deve avere un nuovo codice di versione in modo che venga riconosciuta come nuova e viene utilizzata per sostituire un'app di dati precaricata o un'app di dati installata su un dispositivo da un aggiornamento precedente.

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Puoi 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 per i codici 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: ricrea, firma, testa e rilascia

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

• Per i dispositivi non ancora rilasciati (o quando prepari un aggiornamento di sistema per un dispositivo rilasciato), invia i nuovi APK alla directory predefinita dell'app Dati 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 dei test dell'app di dati aggiornata sui propri dispositivi prima del rilascio.

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

Esempio di strategia per il 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 fisiche. 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'uso dello spazio lasciato tra 3 e 4 per ruotare nuovamente l'APK.

Ogni dispositivo è dotato di un APK predefinito con versioni appropriate nell'immagine di sistema, pertanto non c'è alcun 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 e che successivamente riceve un aggiornamento di sistema a P utilizza la versione /system anziché la 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 origini 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 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 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 utilizza diversi altri progetti Git condivisi con la build della piattaforma o che contengono librerie di codice indipendenti dall'OEM.

Il seguente snippet del manifest contiene l'insieme minimo di progetti Git necessario per supportare una build O-MR1 dell'app Data fuso orario. Gli OEM devono aggiungere i propri progetti Git specifici dell'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="main"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

Gestisci la creazione 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.