Regole per il fuso orario

Android 10 ritira i dati relativi al fuso orario basati su APK meccanismo di aggiornamento (disponibile su Android 8.1 e Android 9) e lo sostituisce con un meccanismo di aggiornamento dei moduli basato su APEX. Le versioni AOSP da 8.1 a 13 includono ancora il codice della piattaforma necessario agli OEM per consentire Aggiornamenti basati su APK, quindi i dispositivi che eseguono l'upgrade ad Android 10 può comunque ricevere aggiornamenti dei dati relativi al fuso orario forniti dal partner tramite l'APK. Tuttavia, il meccanismo di aggiornamento dell'APK non deve essere utilizzato su un dispositivo di produzione che riceve anche aggiornamenti dei moduli, poiché un aggiornamento basato su APK sostituisce L'aggiornamento basato su APEX, ovvero un dispositivo che ha ricevuto un aggiornamento dell'APK ignora aggiornamenti basati su APEX).

Aggiornamenti dei fusi orari (Android 10 e versioni successive)

Il modulo Time Zone Data (Dati del fuso orario) supportato in Android 10 e aggiornamenti dell'ora legale (DST) e dei fusi orari sui dispositivi Android, standardizzare i dati che possono cambiare frequentemente per criteri religiosi, politici motivi geopolitici.

Gli aggiornamenti utilizzano la seguente procedura:

1. IANA rilascia un aggiornamento del database dei fusi orari rilascia un aggiornamento in risposta Uno o più governi hanno modificato una regola relativa al fuso orario nei propri paesi.
2. Google o il partner Android prepara un aggiornamento per il modulo Dati relativi al fuso orario (file APEX) contenente i fusi orari aggiornati.
3. Il dispositivo dell'utente finale scarica l'aggiornamento, si riavvia, quindi applica modifiche, dopodiché i dati relativi al fuso orario del dispositivo contengono il nuovo fuso orario dati dall'aggiornamento.

Per maggiori dettagli sui moduli, vedi Componenti del sistema modulare.

Aggiornamenti dei fusi orari (Android 8.1-9)

Nota: la funzionalità del meccanismo di aggiornamento dei dati relativi al fuso orario basato su APK ha è stata rimossa completamente da Android 14 in poi e non è possibile trovarla in il codice sorgente. I partner devono eseguire la migrazione completa Fuso orario Modulo Mainline.

In Android 8.1 e Android 9, gli OEM possono usare un meccanismo basato su APK per eseguire il push ha aggiornato i dati delle regole relative al fuso orario sui dispositivi senza richiedere un aggiornamento di sistema. Questo meccanismo consente agli utenti di ricevere aggiornamenti tempestivi (estendendo quindi il tutta la durata utile di un dispositivo Android) e consente ai partner Android di testare gli aggiornamenti del fuso orario indipendentemente dagli aggiornamenti delle immagini di sistema.

Il team delle librerie di base di Android fornisce i file di dati necessari aggiornare le regole del fuso orario su un dispositivo Android originale. Gli OEM possono scegliere di usare questi quando creano gli aggiornamenti del fuso orario per i loro dispositivi o possono creare file di dati, se preferisci. In ogni caso, gli OEM mantengono il controllo sulla qualità la garanzia/test, la tempistica e il lancio degli aggiornamenti delle regole del fuso orario per sui dispositivi supportati.

Codice sorgente e dati del fuso orario di Android

Tutti i dispositivi Android standard, anche quelli che non utilizzano questa funzionalità, hanno bisogno del fuso orario i dati sulle regole del fuso orario e devono essere forniti con un insieme predefinito di dati sulle regole del fuso orario nel /system partizione. Questi dati vengono quindi utilizzati dal codice che seguono nell'albero delle origini di Android:

• Codice gestito da libcore/ (ad esempio, java.util.TimeZone) utilizza tzdata e tzlookup.xml file.
• Codice libreria nativo in bionic/ (ad esempio, per mktime, per le chiamate di sistema con l'ora locale) utilizza il file tzdata.
• Il codice libreria ICU4J/ICU4C in external/icu/ utilizza l'icu .dat file.

Queste librerie tengono traccia dei file di overlay che potrebbero essere presenti Directory /data/misc/zoneinfo/current. Sono previsti file di overlay per contenere dati migliorati sulle regole del fuso orario, consentendo così l'aggiornamento dei dispositivi senza modificare /system.

I componenti di sistema Android che richiedono i dati della regola relativa al fuso orario controllano quanto segue per prima cosa:

• I codici libcore/ e bionic/ utilizzano i valori /data copia di tzdata e tzlookup.xml .
• I codici ICU4J/ICU4C utilizzano i file in /data e utilizzano /system file per i dati non presenti (per formati, localizzati stringhe e così via).

File distro

I file .zip Distro contengono i file di dati necessari per compilare Directory /data/misc/zoneinfo/current. I file distro hanno anche Contengono metadati che consentono ai dispositivi di rilevare i problemi di controllo delle versioni.

Il formato file della distro dipende dalla release di Android perché i contenuti cambiare con la versione di terapia intensiva, i requisiti della piattaforma Android e altre release modifiche. Android fornisce file distro per le release di Android supportate per ogni Aggiornamento IANA (oltre ad aggiornare i file di sistema della piattaforma). Per mantenere aggiornati, gli OEM possono usare questi file distro oppure crearne di propri ad albero delle origini Android (che contiene gli script e gli altri file necessari generare file distro).

Componenti dell'aggiornamento del fuso orario

Un aggiornamento delle regole del fuso orario comporta la trasmissione dei file distro a un dispositivo e l'installazione sicura dei file al suo interno. Trasferisci e richiede quanto segue:

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

La struttura di origine Android contiene codice sorgente generico per quanto indicato sopra che l'OEM può scegliere di utilizzare senza modifiche. Codice di test per consentire agli OEM di controllare automaticamente di avere attivato correttamente la funzione.

Installazione distro

La procedura di installazione della distro include i seguenti passaggi:

1. L'app di dati viene aggiornata tramite il download di uno store o tramite sideload. Il processo del server di sistema (attraverso timezone.RulesManagerServer/timezone.PackageTracker corsi) controlla le modifiche al pacchetto di app dati configurato, specifico per l'OEM .
   
   

   Figura 1. Aggiornamenti delle app di dati.

2. Il processo del server di sistema attiva un controllo degli aggiornamenti tramite trasmettere un intent mirato con un token univoco e monouso all'aggiornamento Richiesto Il server di sistema tiene traccia del token più recente che ha generato, in modo da può determinare quando è stato completato il controllo più recente attivato; qualsiasi altro vengono ignorati.
   
   

   Figura 2. Attiva il controllo degli aggiornamenti.

3. Durante il controllo degli aggiornamenti, l'app Updater esegue le le seguenti attività:
   .
   • Esegue una 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 specifiche di colonna per ottenere informazioni sulla distribuzione.
     
     

     Figura 4. Aggiornamenti delle app di dati, ottieni informazioni sulla distro.

4. L'app Updater intraprende l'azione appropriata in base ai le informazioni di cui dispone. Le azioni disponibili includono:
   • Richiedi un'installazione. I dati della distro vengono letti dall'app Dati e viene passato a RulesManagerService nel server di sistema. La RulesManagerService riconferma che la versione e il contenuto del formato distro sono appropriato per il dispositivo e mette in pausa l'installazione.
   • Richiedi una disinstallazione (si tratta di una situazione rara). Ad esempio, se il modello ha È in corso la disattivazione o la disinstallazione dell'APK in /data e il dispositivo è tornando alla versione presente in /system.
   • Non fare niente. Si verifica quando la distro dell'app di dati risulta non valida.
   di Gemini Advanced. In tutti i casi, l'app di aggiornamento chiama RulesManagerService con il token di controllo in modo che il server di sistema sappia che la verifica è stata completata e riuscita.
   
   

   Figura 5. Verifica completata.

5. Riavvia e tzdatacheck. Al successivo avvio del dispositivo, il programma binario tzdatacheck esegue qualsiasi operazione in fasi. Il file binario tzdatacheck può eseguire le seguenti attività:
   • Eseguire l'operazione in fasi gestendo la creazione, la sostituzione e/o l'eliminazione dei file /data/misc/zoneinfo/current prima del giorno altri componenti di sistema hanno aperto i file e hanno iniziato a utilizzarli.
   • Verifica che i file in /data siano corretti per la versione attuale della piattaforma, cosa che potrebbe non verificarsi se il dispositivo ha appena ricevuto aggiornamento di sistema e la versione del formato distro è cambiata.
   • Assicurati che la versione delle regole IANA sia la stessa o più recente di quella in /system. Questa opzione protegge da un aggiornamento di sistema che lascia un dispositivo con dati sulle regole per il fuso orario precedenti a quelli presenti in /system dell'immagine.

Affidabilità

Il processo di installazione end-to-end è asincrono e suddiviso in tre sistemi operativi i processi di machine learning. In qualsiasi momento durante l'installazione, il dispositivo potrebbe non essere alimentato, eseguire spazio su disco o altri problemi, che causano il controllo dell'installazione essere incompleti. Nel caso migliore infetto, l'app di aggiornamento informa il sistema server in cui l'operazione non è riuscita; nel peggiore dei casi, RulesManagerService non riceve alcuna chiamata.

Per gestire questo problema, il codice del server di sistema tiene traccia di se un evento è stato attivato controllo degli aggiornamenti completato e qual è l'ultimo codice di versione controllato dei dati È un'app. 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 dati imprevisti Versione dell'app, attiva spontaneamente un controllo degli aggiornamenti.

Sicurezza

Quando l'opzione è abilitata, il codice RulesManagerService nel server di sistema esegue diversi controlli per verificare che il sistema sia sicuro da usare.

• I problemi che indicano un'immagine di sistema non configurata correttamente impediscono a un dispositivo avvio; esempi includono una configurazione errata del programma di aggiornamento o dell'app dati oppure Il programma di aggiornamento o l'app di dati non si trova in /system/priv-app.
• I problemi che indicano che è stata installata un'app di dati errata non impediscono l'avvio del dispositivo, ma impedire l'attivazione di un controllo degli aggiornamenti. esempi includono la mancanza delle autorizzazioni di sistema necessarie oppure l'app Dati non espone un ContentProvider nell'URI previsto.

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

Integrare gli aggiornamenti relativi al fuso orario

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

• Creare la propria app di dati.
• Includi le app di aggiornamento e dati 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, controlli di qualità e considerazioni sulla sicurezza:

• Creare una chiave di firma dedicata specifica per l'app di dati.
• Creare una strategia di rilascio e controllo delle versioni per gli aggiornamenti del fuso orario per capire quali dispositivi verranno aggiornati e come garantire che gli aggiornamenti vengono installati solo sui dispositivi che ne hanno bisogno. Ad esempio, gli OEM potrebbero voler di avere un'unica app di dati per tutti i dispositivi o di avere diverse App di dati per dispositivi diversi. La decisione influisce sulla scelta del pacchetto ed eventualmente i codici di versione utilizzati, nonché la strategia di QA.
• Capire se vuole utilizzare i dati stock relativi al fuso orario di Android da AOSP o crearne uno proprio.

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 sia un target di build per l'APK dell'app di dati reale sia target aggiuntivi per la creazione di versioni di test dell'app di dati.

Gli OEM possono personalizzare l'app Dati con icone, nome, traduzioni e altri dettagli. Tuttavia, poiché non è possibile avviare l'app Dati, viene visualizzata l'icona. solo in Impostazioni > Schermata App.

L'app Dati è progettata per essere creata con una build tapas che produce APK adatti all'aggiunta all'immagine di sistema (per i di release) e firmati e distribuiti tramite uno store (per le ). Per maggiori dettagli sull'uso delle tapas, consulta la sezione Come creare App di dati che utilizza tapas.

Nota: firma sicura di APK e chiavi e non rientrano nell'ambito di questo articolo.

Gli OEM devono installare l'app Dati predefinita nell'immagine di sistema di un dispositivo /system/priv-app. Per includere APK predefiniti (generati dalle tapas di addestramento) nell'immagine di sistema, gli OEM possono copiare i file di esempio packages/apps/TimeZoneData/oem_template/data_app_prebuilt. La i modelli di esempio includono anche target di build per includere le versioni di test App di dati in suite di test.

Includi le app di aggiornamento e dati nell'immagine di sistema

Gli OEM devono inserire il programma di aggiornamento e gli APK dell'app dati nel Directory /system/priv-app dell'immagine di sistema. Per fare ciò, la build dell'immagine di sistema deve includere esplicitamente l'app di aggiornamento e l'app dati predefinita target.

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

Configura il server di sistema

Per abilitare gli aggiornamenti del fuso orario, gli OEM possono configurare il server di sistema tramite sull'override delle proprietà di configurazione definite frameworks/base/core/res/res/values/config.xml.

Proprietà	Descrizione	Override richiesto?
config_enableUpdateableTimeZoneRules	Deve essere impostato su true per abilitare RulesManagerService.	Sì
config_timeZoneRulesUpdateTrackingEnabled	Deve essere impostato su true affinché il sistema ascolti le modifiche apportate a l'app Dati.	Sì
config_timeZoneRulesDataPackage	Nome del pacchetto dell'app dati specifica per l'OEM.	Sì
config_timeZoneRulesUpdaterPackage	Configurata per l'app di aggiornamento predefinita. Cambia solo quando fornisci un valore un'implementazione diversa dell'app di aggiornamento.	No
config_timeZoneRulesCheckTimeMillisAllowed	Tempo consentito tra l'attivazione di un controllo degli aggiornamenti da parte della RulesManagerService e una risposta relativa all'installazione, alla disinstallazione o non esegue alcuna operazione. Dopo il giorno da questo punto, potrebbe essere generato un trigger di affidabilità spontaneo.	No
config_timeZoneRulesCheckRetryCount	Il numero di controlli di aggiornamento sequenziali non riusciti consentiti prima della data RulesManagerService non ne genera più.	No

Le sostituzioni della configurazione devono essere presenti nell'immagine di sistema (non nel fornitore o di altro tipo) poiché un dispositivo configurato in modo errato può rifiutarsi di avviarsi. Se la configurazione esegue l'override erano nell'immagine del fornitore, passando a un'immagine di sistema senza un'app di dati (o con nomi di pacchetti dell'app di dati/dell'app di aggiornamento diversi) è considerata una e non è corretta.

Test xTS

xTS si riferisce a qualsiasi suite di test specifica per OEM simile ad Android standard suite di test che utilizzano Tradefed (come CTS e VTS). OEM che dispongono di questo test possono aggiungere i test di aggiornamento del fuso orario Android forniti in località:

• packages/apps/TimeZoneData/testing/xts include il codice necessari per i test funzionali automatici di base.
• packages/apps/TimeZoneData/oem_template/xts contiene un esempio struttura di directory per includere i test in una suite xTS di tipo Tradefed. Come con altre directory dei modelli, gli OEM devono copiare e personalizzare e alle esigenze aziendali.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt contiene la configurazione in fase di build per l'inclusione degli APK di test predefiniti richiesti dal test.

di Gemini Advanced.

Nota: configurazione di una suite di test specifica per OEM non rientra nell'ambito di questo articolo.

Creare aggiornamenti relativi al fuso orario

Quando IANA rilascia un nuovo set di regole per il fuso orario, le librerie principali di Android genera patch per aggiornare le release in AOSP. OEM che utilizzano lo smartphone Android originale di sistema e distro possono ricevere questi commit, usali per creare dell'app di dati e rilasciare la nuova versione per aggiornare i dispositivi in produzione.

Nota: i seguenti passaggi non descrivono una aggiornare i file di dati di base nell'immagine /system, che è richiesta durante la preparazione dell'immagine di fabbrica o degli aggiornamenti di sistema. Questo processo genera il file distro per l'inclusione nell'app Dati. Per istruzioni su aggiornare i file della piattaforma, consulta /system/timezone/README.android.

Poiché le app di dati contengono file di distro strettamente legati alle versioni di Android, Gli OEM devono creare una nuova versione dell'app dati per ogni versione supportata Release di Android che un OEM vuole aggiornare. Ad esempio, se un OEM vuole fornisce aggiornamenti per Android 8.1, 9 e 10 dispositivi, devono completare la procedura tre volte.

Passaggio 1: aggiorna i file di dati di sistema/fuso orario ed esterni/icu

In questo passaggio, gli OEM fanno il punto sugli impegni Android per system/timezone e external/icu dal release-dev in AOSP e applicare questi commit alla loro copia il codice sorgente di Android.

La patch AOSP di sistema/fuso orario contiene file aggiornati in system/timezone/input_data e system/timezone/output_data. OEM che devono realizzare prodotti locali correzioni possono modificare i file di input e quindi utilizzare i file system/timezone/input_data e external/icu per generare file in output_data.

Il file più importante è system/timezone/output_data/distro/distro.zip, ovvero inclusi automaticamente quando viene creato l'APK dell'app di 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 rileva automaticamente distro.zip, ma la nuova versione L'app di dati deve avere un nuovo codice di versione affinché venga riconosciuta come nuova e utilizzata sostituire un'app di dati precaricata o un'app di dati installata su un dispositivo con una aggiornamento.

Quando crei l'app di dati utilizzando file copiati da package/apps/TimeZoneData/oem_template/data_app, puoi trovare codice versione/nome versione applicati 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 maggiori dettagli, Consulta la strategia di esempio per il codice di versione schema; se viene utilizzato lo schema di esempio o uno simile, il test non occorre aggiornare i codici di versione perché garantiscono che siano superiori rispetto ai codici di versione reali.

Passaggio 3: ricrea, firma, testa e rilascia

In questo passaggio, gli OEM ricreano l'APK utilizzando le tapas, firmano APK, quindi testa e rilascia l'APK:

• Per i dispositivi non ancora rilasciati (o durante la preparazione di un aggiornamento di sistema per 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 verifica che il nuovo file funzioni correttamente (vale a dire che supera CTS e qualsiasi test automatici e manuali specifici per OEM).
• Per i dispositivi rilasciati che non ricevono più aggiornamenti di sistema, l'APK firmato potrebbe essere rilasciato solo tramite uno store.

Gli OEM sono responsabili del controllo qualità e dei test dell'aggiornamento App di dati sui propri dispositivi prima del rilascio.

Strategia per il codice di versione dell'app di dati

L'app Dati deve avere un adatto strategia di controllo delle versioni per garantire che i dispositivi ricevano gli APK corretti. Per Ad esempio, se viene ricevuto un aggiornamento di sistema che contiene un APK meno recente di uno scaricata dallo store, la versione dello store deve essere mantenuta.

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

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

Attualmente, il livello API della piattaforma è strettamente 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 modificare questa impostazione in modo che che un file distro può funzionare su più release della piattaforma Android (e API non viene utilizzato nello schema del codice di versione dell'app di dati).

Esempio di strategia per il codice di versione

Questo esempio di schema di numeri con controllo delle versioni garantisce che un formato distro superiore prevalgono su quelle precedenti in formato distro. AndroidManifest.xml utilizza android:minSdkVersion per assicurati che i vecchi dispositivi non ricevano versioni con un formato distro superiore di quella che è in grado di gestire.

Figura 6. Esempio di strategia del codice di versione.

Esempio	Valore	Finalità
A	Riservata	Consente schemi alternativi/APK di test futuri. All'inizio (implicitamente) 0. Poiché il tipo sottostante è un tipo int firmato a 32 bit, questo schema supporta fino a due future revisioni dello schema di numerazione.
01	Versione formato principale	Tiene traccia della versione del formato principale con tre cifre decimali. Il formato distro supporta Qui vengono utilizzate solo 2 cifre decimali. È improbabile che raggiunga 100 dato l'incremento maggiore previsto per livello API. La versione principale 1 è equivalente al livello API 27.
1	Versione formato secondario	Tiene traccia della versione del formato minore con tre cifre decimali. Il formato distro supporta Qui viene utilizzata solo 1 cifra. È improbabile che raggiunga 10.
X	Riservata	È 0 per le release di produzione (e potrebbe essere diverso per gli APK di test).
ZZZZZ	Numero di versione opaco	Numero decimale assegnato on demand. Include intervalli vuoti per consentire l'inserimento di interstitial aggiornamenti da apportare, se necessario.

Lo schema potrebbe essere pacchettizzato meglio se si utilizzasse il file binario al posto del decimale, ma questo schema ha il vantaggio di essere leggibile. Se l'intero intervallo di numeri è esaurito, il nome del pacchetto dell'app di dati potrebbe cambiare.

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

#	Codice versione	Versione minSdk	{Versione con formato principale},{Versione con formato minore},{Regole IANA version},{Revisione}
1	11000010	O-MR1	maggiore=001,minor=001,iana=2017a,revision=1
2	21000010	P	maggiore=002,minor=001,iana=2017a,revision=1
3	11000020	O-MR1	maggiore=001,minor=001,iana=2017a,revision=2
4	11000030	O-MR1	maggiore=001,minor=001,iana=2017b,revision=1
5	21000020	P	maggiore=002,minor=001,iana=2017b,revision=1
6	11000040	O-MR1	maggiore=001,minor=001,iana=2018a,revision=1
7	21000030	P	maggiore=002,minor=001,iana=2018a,revision=1
8	1123456789	-	-
9	11000021	O-MR1	maggiore=001,minor=001,iana=2017a,revision=2,respin=2

• Gli esempi 1 e 2 mostrano due versioni dell'APK per la stessa release IANA 2017a con versioni in formato principale diverse. 2 è numericamente maggiore di 1, ovvero necessario per garantire che i dispositivi più recenti ricevano le versioni nel formato superiore. La minSdkVersion garantisce che la versione P non venga fornita a O dispositivi.
• L'esempio 3 è una revisione/correzione per 1 ed è numericamente superiore a 1.
• Gli esempi 4 e 5 mostrano le release del 2017b per O-MR1 e P. Essere numericamente superiori, sostituiscono le release IANA/revisioni Android precedenti delle rispettive i suoi predecessori.
• Gli esempi 6 e 7 mostrano le release del 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 dello spazio lasciato tra 3 e 4 per ripetere la rotazione l'APK.

Poiché ogni dispositivo viene fornito con un APK predefinito e con le versioni appropriate, nel immagine di sistema, 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. R dispositivo con una versione O-MR1 installata in /data che poi riceve un aggiornamento di sistema a P utilizza invece la versione /system per la versione O-MR1 in /data perché la versione P è sempre superiore di qualsiasi app destinata a O-MR1.

Crea l'app di dati utilizzando le tapas

Gli OEM sono responsabili della gestione della maggior parte degli aspetti dell'app Dati relativi al fuso orario. configurare correttamente l'immagine di sistema. L'app Dati è pensata per essere con una build tapas che produce APK adatti all'aggiunta l'immagine di sistema (per la release iniziale) e firmata e distribuita tramite store (per aggiornamenti successivi).

Tapas è una versione semplificata della build Android che utilizza una struttura ad albero di origine ridotta per produrre versioni distribuibili app. Gli OEM che hanno familiarità con il normale sistema di build Android devono riconoscere il creare file dalla normale build della piattaforma Android.

Creare il manifest

Per ottenere una struttura dell'origine ridotta, è possibile utilizzare un file manifest personalizzato si riferisce solo ai progetti Git richiesti dal sistema di compilazione e per creare dell'app. Dopo aver seguito le istruzioni in per la creazione di un'app di dati, gli OEM dovrebbero avere Almeno due progetti Git specifici dell'OEM creati utilizzando i file modello 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 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 inclusione nella build dell'immagine di sistema e nei test xTS.

La build dell'app sfrutta molti altri progetti Git condivisi con o contenere librerie di codice indipendenti dagli OEM.

Il seguente snippet manifest contiene l'insieme minimo di progetti Git necessarie per supportare una build O-MR1 dell'app Dati del fuso orario. OEM devono aggiungere i propri progetti Git specifici dell'OEM (che in genere includono un contiene il certificato di firma) a questo manifest e potrebbe configurare si ramifica 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 di 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 test. Questi file possono essere inseriti nella directory predefinita l'immagine di sistema e/o i contenuti distribuiti tramite uno store per dispositivi mobili.