Google 致力于为黑人社区推动种族平等。查看具体举措
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

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 continua a includere 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 APK non dovrebbe 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 dei dati sul fuso orario (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)

In Android 8.1 e Android 9, gli OEM possono utilizzare un meccanismo basato su APK per inviare i dati aggiornati delle regole del fuso orario ai dispositivi senza richiedere un aggiornamento del sistema. Questo meccanismo consente agli utenti di ricevere aggiornamenti tempestivi (estendendo così la durata 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 l'aggiornamento delle 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 desidera. In tutti i casi, gli OEM mantengono il controllo sulla garanzia di qualità / test, tempistica e 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 forniti 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 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 possono essere presenti nella directory /data/misc/zoneinfo/current . I file di overlay dovrebbero contenere dati migliorati sulle regole del fuso orario, consentendo in tal modo l'aggiornamento dei dispositivi senza modificare /system .

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

  • libcore/ e bionic/ code 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 che non sono presenti (per formati, stringhe localizzate, ecc.).

File Distro

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

Il formato del file distro dipende dal rilascio 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 comporta la trasmissione di file di distribuzione a un dispositivo e l'installazione sicura dei file contenuti all'interno. Il trasferimento e l'installazione richiedono quanto segue:

  • Funzionalità del servizio della 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 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 di aggiornamento ). 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 di aggiornamento. Gli OEM devono includere questa app nell'immagine di sistema dei dispositivi che utilizzano la funzione.
  • tzdatacheck , un binario all'avvio richiesto per il funzionamento corretto e sicuro degli aggiornamenti del fuso orario.

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

Installazione di Distro

Il processo di installazione della distribuzione include i seguenti passaggi:

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

    Aggiornamenti dell'app dati
    Figura 1. Aggiornamenti dell'app dati
  2. Il processo del server di sistema attiva un controllo degli aggiornamenti trasmettendo un intento mirato con un token univoco e monouso all'app Updater. Il server di sistema tiene traccia del token più recente generato in modo da poter determinare quando è stato completato il controllo più recente attivato; qualsiasi altro gettone viene ignorato.

    Attiva aggiornamento
    Figura 2. Trigger update check
  3. Durante il controllo degli aggiornamenti , l'app Updater esegue le seguenti attività:
    • Esegue una query sullo stato corrente del dispositivo chiamando RulesManagerService.

      Chiama RulesManagerService
      Figura 3. Aggiornamenti dell'app dati, chiamata RulesManagerService
    • Esegue query sull'app Data eseguendo una query su un URL ContentProvider ben definito e sulle specifiche di colonna per ottenere informazioni sulla distribuzione.

      Ottieni informazioni sulla distribuzione
      Figura 4. Aggiornamenti dell'app dati, 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 Distro vengono letti dall'app Data e passati a RulesManagerService nel server di sistema. Il RulesManagerService riconferma che la versione e il contenuto del formato della distribuzione sono appropriati per il dispositivo e organizza l'installazione.
    • Richiedi una disinstallazione (questo è raro). Ad esempio, se l'APK aggiornato in /data viene disabilitato o disinstallato e il dispositivo sta tornando alla versione presente in /system .
    • Fare niente. Si verifica quando la distribuzione dell'app Data 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.

    Verifica completata
    Figura 5. Verifica completata
  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 file /data/misc/zoneinfo/current prima che altri componenti del sistema si /data/misc/zoneinfo/current a utilizzare i file.
    • Verificare 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 della versione in /system . Ciò protegge da un aggiornamento del sistema che lascia un dispositivo con dati delle regole del fuso orario più vecchi di 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 alimentazione, esaurire lo spazio su disco o riscontrare altri problemi, rendendo incompleto il controllo dell'installazione. Nel migliore dei casi senza successo, l'app Updater informa il server di sistema che non ha avuto successo; nel peggiore dei casi, il RulesManagerService non riceve alcuna chiamata.

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

Sicurezza

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

  • I problemi che indicano un'immagine di sistema configurata male impediscono l'avvio di un dispositivo; gli esempi includono un aggiornamento errato o una configurazione dell'app dati o l'applicazione di aggiornamento o dati non presente in /system/priv-app .
  • I problemi che indicano che è stata installata un'app dati non valida 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 sui file per le directory /data/misc/zoneinfo vengono applicati usando le regole SELinux. Come con qualsiasi APK, l'app Data deve essere firmata con la 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.
  • Includere 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 dovrebbero esaminare le seguenti considerazioni sulla politica, sulla garanzia della qualità e sulla sicurezza:

  • Crea una chiave di firma specifica per l'app dedicata per la loro 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 avere un'unica app dati per tutti i loro dispositivi o potrebbero scegliere di avere app dati differenti per dispositivi diversi. La decisione influisce sulla scelta del nome del pacchetto, possibilmente sui codici di versione utilizzati e sulla strategia di QA.
  • Capire se desiderano utilizzare i dati del fuso orario Android di stock da AOSP o crearne uno personalizzato.

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 situati in packages/apps/TimeZoneData/oem_template . I modelli di esempio includono sia una destinazione di compilazione per l'APK dell'app Data reale sia destinazioni aggiuntive per la creazione di versioni di prova dell'app Data.

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 app store (per aggiornamenti successivi). Per i dettagli sull'utilizzo delle tapas, vedere Creazione dell'app Dati utilizzando le tapas .

Gli OEM devono installare l'app Data precostruita nell'immagine di sistema di un dispositivo in /system/priv-app . Per includere APK precostruiti (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 obiettivi di compilazione per includere versioni di test dell'app Data nelle suite di test.

Comprese le app Updater e Data nell'immagine di sistema

Gli OEM devono posizionare gli APK dell'app di aggiornamento e dati nella 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 le destinazioni predefinite dell'app dati.

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 dati è specifica dell'OEM e dipende dal nome di destinazione scelto per la pre-compilazione.

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 .

Proprietà Descrizione Override richiesto?
config_enableUpdateableTimeZoneRules
Deve essere impostato su true per abilitare RulesManagerService.
config_timeZoneRulesUpdateTrackingEnabled
Deve essere impostato su true per consentire al sistema di ascoltare le modifiche all'app Dati.
config_timeZoneRulesDataPackage
Nome del pacchetto dell'app Dati specifica dell'OEM.
config_timeZoneRulesUpdaterPackage
Configurato per l'app di aggiornamento predefinita. Modificare solo quando si fornisce un'implementazione dell'app di aggiornamento diversa. No
config_timeZoneRulesCheckTimeMillisAllowed
Tempo consentito tra un controllo di aggiornamento attivato da RulesManagerService e una risposta di installazione, disinstallazione o non eseguire alcuna operazione. Dopo questo punto, può essere generato un trigger di affidabilità spontaneo. No
config_timeZoneRulesCheckRetryCount
Il numero di controlli di aggiornamento sequenziali non riusciti consentiti prima che RulesManagerService smetta di generarne altri. No

Le modifiche alla configurazione dovrebbero essere nell'immagine del sistema (non del fornitore o di altro tipo) poiché un dispositivo configurato in modo errato può rifiutarsi di avviarsi. Se le sostituzioni di configurazione fossero nell'immagine del fornitore, l'aggiornamento a un'immagine di sistema senza un'app dati (o con diversi nomi di pacchetto app dati / app di aggiornamento) sarebbe considerato un errore di configurazione.

xTS test

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

Creazione di aggiornamenti del fuso orario

Quando IANA rilascia un nuovo set 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 distro possono raccogliere questi commit, utilizzarli per creare una nuova versione della loro app Data, quindi rilasciare la nuova versione per aggiornare i loro dispositivi in ​​produzione.

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

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

In questo passaggio, gli OEM prendono in considerazione i commit Android per system/timezone ed external/icu dai rami di rilascio -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 necessitano di 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 Data

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

Quando si package/apps/TimeZoneData/oem_template/data_app l'app Data utilizzando i file copiati da package/apps/TimeZoneData/oem_template/data_app , è possibile trovare il codice della versione / il nome della versione applicati 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 di versione di esempio ; se viene utilizzato lo schema di esempio o uno schema simile, i codici della versione di prova non devono essere aggiornati perché sono garantiti essere 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 precostruita dell'app Dati per assicurarti che l'immagine del sistema e i test xTS abbiano gli APK più recenti. Gli OEM dovrebbero verificare che il nuovo file funzioni correttamente (ovvero, supera 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 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 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 che contiene un APK precedente a quello scaricato dall'app store, la versione dell'app store dovrebbe essere conservata.

Il codice della versione APK dovrebbe includere le seguenti informazioni:

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

Attualmente, il livello API della piattaforma è fortemente correlato alla versione in formato distro perché ogni livello API è solitamente associato a una nuova versione di ICU (il che rende i file della distribuzione incompatibili). 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 viene utilizzato nello schema di codice della versione dell'app dati).

Esempio di strategia del codice di versione

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

Controllo della versione
Figura 6. Esempio di strategia del codice di versione
Esempio Valore Scopo
Y Riservato Consente futuri schemi alternativi / APK di test. Inizialmente (implicitamente) è 0. Poiché il tipo sottostante è un tipo int a 32 bit con segno, questo schema supporta fino a due future revisioni dello schema di numerazione.
01 Versione in formato principale Tiene traccia della versione del formato principale a 3 cifre decimali. Il formato della distro supporta 3 cifre decimali, ma qui vengono utilizzate solo 2 cifre. È improbabile che raggiunga 100 dato il maggiore incremento previsto per livello API. La versione principale 1 è equivalente al livello API 27.
1 Versione in formato minore Tiene traccia della versione in formato minore a 3 cifre decimali. Il formato della distribuzione supporta 3 cifre decimali ma qui viene utilizzata solo 1 cifra. È improbabile che raggiunga 10.
X Riservato È 0 per le versioni di produzione (e potrebbe essere diverso per gli APK di prova).
ZZZZZ Numero di versione opaco Numero decimale assegnato su richiesta. Include spazi vuoti per consentire gli aggiornamenti interstitial, se necessario.

Lo schema potrebbe essere impacchettato meglio se fosse usato binario invece di 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.

# Codice versione minSdkVersion {Versione formato principale}, {Versione formato secondario}, {Versione regole IANA}, {Revisione}
1 11000010 O-MR1 maggiore = 001, minore = 001, iana = 2017a, revisione = 1
2 21000010 P maggiore = 002, minore = 001, iana = 2017a, revisione = 1
3 11000020 O-MR1 maggiore = 001, minore = 001, iana = 2017a, revisione = 2
4 11000030 O-MR1 maggiore = 001, minore = 001, iana = 2017b, revisione = 1
5 21000020 P maggiore = 002, minore = 001, iana = 2017b, revisione = 1
6 11000040 O-MR1 maggiore = 001, minore = 001, iana = 2018a, revisione = 1
7 21000030 P maggiore = 002, minore = 001, iana = 2018a, revisione = 1
8 1123456789 - -
9 11000021 O-MR1 maggiore = 001, minore = 001, iana = 2017a, revisione = 2, respin = 2
  • Gli esempi 1 e 2 mostrano due versioni APK per la stessa versione IANA 2017a con versioni di formato principale diverse. 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 verrà 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 più elevate, 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 dimostra l'uso dello spazio vuoto lasciato tra 3 e 4 per far girare nuovamente l'apk.

Poiché ogni dispositivo viene fornito con un APK predefinito con versione appropriata nell'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. 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.

Creazione dell'app Data utilizzando tapas

Gli OEM sono responsabili della gestione della maggior parte degli aspetti dell'app Dati del fuso orario e della configurazione corretta dell'immagine del sistema. L'app Data è pensata per essere realizzata con una build tapas che produce APK adatti ad essere aggiunti all'immagine di sistema (per la versione iniziale) e firmati e distribuiti tramite 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 delle 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 manifest

Un albero dei sorgenti ridotto di solito si ottiene 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 dati , gli OEM dovrebbero avere almeno due progetti Git specifici dell'OEM creati utilizzando i file modello in packages/apps/TimeZoneData/oem_template :

  • Un progetto Git contiene file di app come manifest e 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 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 del sistema e nei test xTS.

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

Il seguente frammento di manifesto contiene il set minimo di progetti Git necessari per supportare una build O-MR1 dell'app Data del fuso orario. Gli OEM devono aggiungere i loro progetti Git specifici dell'OEM (che in genere includono un progetto che contiene il certificato di firma) a questo manifesto 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 costruzione di tapas

Dopo aver stabilito l'albero di origine, invoca 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 compilazione riuscita genera file nella directory out/dist per il test. Questi file possono essere inseriti nella directory prebuilts per l'inclusione nell'immagine di sistema e / o distribuiti tramite un app store per dispositivi compatibili.