Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
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 aggiornamenti dei dati del fuso orario forniti dai partner tramite APK. Tuttavia, il meccanismo di aggiornamento 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 Dati fuso orario 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 dei fusi orari rilascia un aggiornamento in risposta a uno o più governi che modificano una regola del fuso orario nei rispettivi paesi.
  2. Google o il partner Android preparano un aggiornamento del modulo dati 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, consultare Componenti di sistema modulari .

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 (prolungando così 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 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 di fuso orario per i propri dispositivi o, se si preferisce, possono creare i propri file di dati. In tutti i casi, gli OEM mantengono il controllo su garanzia / test di qualità, 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 di dati sulle regole del fuso orario e devono essere forniti con un set predefinito di dati sulle regole del fuso orario nella partizione /system . Questi dati vengono quindi utilizzati dal codice dalle seguenti librerie nella struttura 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 mktime , localtime) utilizza il file tzdata .
  • Il codice della libreria ICU4J / ICU4C in external/icu/ utilizza il file icu .dat .

Queste librerie tengono traccia dei file di overlay che potrebbero essere presenti nella directory /data/misc/zoneinfo/current . I file overlay dovrebbero contenere dati sulle regole del fuso orario migliorati, consentendo in tal modo di aggiornare i dispositivi senza cambiare /system .

I componenti del sistema Android che richiedono i dati della regola del fuso orario verificano 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 ricade nei 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 di distro contengono anche metadati che consentono ai dispositivi di rilevare i problemi di versioning.

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

  • Funzionalità del servizio piattaforma ( timezone.RulesManagerService ), che è disabilitato per impostazione predefinita. Gli OEM devono abilitare la funzionalità attraverso la configurazione. RulesManagerService viene eseguito nel processo del server di sistema e mette in scena le operazioni di aggiornamento del fuso orario scrivendo a /data/misc/zoneinfo/staged . RulesManagerService può anche sostituire o eliminare operazioni già organizzate.
  • TimeZoneUpdater , un'app di sistema non aggiornabile (ovvero l' 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 file binario di avvio necessario per il funzionamento corretto e sicuro 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 prova per consentire agli OEM di verificare automaticamente di aver abilitato correttamente la funzione.

Installazione Distro

Il processo di installazione della distribuzione comprende i seguenti passaggi:

  1. L'app per i dati viene aggiornata tramite download o sideload dell'app store. Il processo del server di sistema (tramite le classi timezone.RulesManagerServer/timezone.PackageTracker ) controlla le modifiche al nome del pacchetto dell'app Data configurata, specifico dell'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 unico e monouso all'app di aggiornamento. Il server di sistema tiene traccia del token più recente generato in modo da poter determinare quando il controllo più recente che ha attivato è stato completato; qualsiasi altro token viene ignorato.

    Attiva aggiornamento
    Figura 2. Controllo dell'aggiornamento del trigger
  3. Durante il controllo degli aggiornamenti , l'app di aggiornamento esegue le seguenti attività:
    • Interroga lo stato corrente del dispositivo chiamando RulesManagerService.

      Chiama RulesManagerService
      Figura 3. Aggiornamenti delle app dati, chiamando RulesManagerService
    • Esegue la query dell'app Dati eseguendo una query su un URL ContentProvider ben definito e sulle specifiche della colonna per ottenere informazioni sulla distribuzione.

      Ottieni informazioni sulla distro
      Figura 4. Aggiornamenti delle app di dati, informazioni sulla distribuzione
  4. L'app di aggiornamento esegue l'azione appropriata in base alle informazioni in suo possesso. Le azioni disponibili includono:
    • Richiedi un'installazione. I dati Distro vengono letti dall'app Dati e vengono passati al RulesManagerService nel server di sistema. RulesManagerService riconferma che la versione e il contenuto del formato di distribuzione sono appropriati per il dispositivo e mettono 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 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 corretto.

    Verifica completa
    Figura 5. Verifica completata
  5. Riavvia e tzdatacheck. Al successivo avvio del dispositivo, il binario tzdatacheck esegue qualsiasi operazione gestita. Il binario tzdatacheck può eseguire le seguenti attività:
    • Eseguire l'operazione a fasi gestendo la creazione, la sostituzione e / o la cancellazione dei file /data/misc/zoneinfo/current prima che altri componenti del sistema siano stati aperti e abbiano iniziato a utilizzare i file.
    • Verifica che i file in /data siano corretti per la versione della piattaforma corrente, che potrebbe non essere il caso se il dispositivo ha appena ricevuto un aggiornamento del sistema e la versione del formato di distribuzione è cambiata.
    • Assicurarsi che la versione delle regole IANA sia uguale o più recente della versione in /system . Questo protegge da un aggiornamento del sistema lasciando 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 energia, esaurire lo spazio su disco o riscontrare altri problemi, rendendo il controllo dell'installazione incompleto. Nel migliore caso non riuscito, l'app di aggiornamento informa il server di sistema che non ha avuto successo; nel peggiore dei casi non riusciti, RulesManagerService non riceve alcuna chiamata.

A tale scopo, il codice del server di sistema tiene traccia del completamento di un controllo di aggiornamento attivato e dell'ultimo codice versione verificato 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 Data, attiva spontaneamente un controllo di aggiornamento.

Sicurezza

Se abilitato, il codice RulesManagerService nel server di sistema esegue numerosi 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 errata dell'app di aggiornamento o dei dati o l'app di aggiornamento o dei dati che non si trova in /system/priv-app .
  • I problemi che indicano che è stata installata un'app di dati errata non impediscono l'avvio di un dispositivo ma impediscono l'attivazione di un controllo di aggiornamento; gli esempi includono la mancanza delle autorizzazioni di sistema richieste o l'app Dati non espone un ContentProvider sull'URI previsto.

I permessi dei file per le directory /data/misc/zoneinfo sono applicati usando le regole SELinux. Come con qualsiasi APK, l'app per i dati deve essere firmata con la stessa chiave utilizzata per firmare la versione /system/priv-app . Si prevede che l'app Data abbia un nome e una chiave del pacchetto dedicati specifici dell'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 di aggiornamento e dati nella build dell'immagine del sistema.
  • Configurare il server di sistema per abilitare RulesManagerService.

Preparazione

Prima di iniziare, gli OEM dovrebbero rivedere la seguente politica, garanzia di qualità e considerazioni sulla sicurezza:

  • Crea una chiave di firma specifica per l'app dedicata per la loro app Dati.
  • Crea una strategia di rilascio e versione 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 di dati per tutti i loro dispositivi o scegliere di avere app di dati differenti per dispositivi diversi. La decisione incide sulla scelta del nome del pacchetto, possibilmente dei codici versione utilizzati e della strategia di QA.
  • Capire se vogliono utilizzare i dati stock timezone Android di AOSP o crearne uno proprio.

Creazione di un'app dati

AOSP include tutto il codice sorgente e le regole di creazione necessarie per creare un'app dati in packages/apps/TimeZoneData , con istruzioni e modelli di esempio per AndroidManifest.xml e altri file contenuti in packages/apps/TimeZoneData/oem_template . I modelli di esempio includono sia un target di build per l'APK dell'app Data reale sia target aggiuntivi per la creazione di versioni di test dell'app Data.

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

L'app Data è pensata per essere costruita con una build di tapas che produce APK adatti per essere aggiunti all'immagine di sistema (per la versione iniziale) e firmati e distribuiti attraverso un app store (per gli aggiornamenti successivi). Per i dettagli sull'uso delle tapas, vedi Creazione dell'app Dati utilizzando le tapas .

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

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

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

L'app di aggiornamento 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 il pre-build.

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 Sostituzione obbligatoria?
config_enableUpdateableTimeZoneRules
Deve essere impostato su true per abilitare RulesManagerService.
config_timeZoneRulesUpdateTrackingEnabled
Deve essere impostato su true per fare in modo che il sistema ascolti le modifiche all'app Data.
config_timeZoneRulesDataPackage
Nome del pacchetto dell'app Dati specifica OEM.
config_timeZoneRulesUpdaterPackage
Configurato per l'app di aggiornamento predefinita. Modifica solo quando fornisci un'implementazione dell'app di aggiornamento diversa. No
config_timeZoneRulesCheckTimeMillisAllowed
Tempo concesso tra l'attivazione di un controllo degli aggiornamenti da RulesManagerService e l'installazione, la disinstallazione o la mancata risposta. Dopo questo punto, può essere generato un trigger di affidabilità spontanea. No
config_timeZoneRulesCheckRetryCount
Il numero di controlli sequenziali di aggiornamenti non riusciti consentiti prima che il RulesManagerService interrompa la generazione di più. No

Le sostituzioni di configurazione devono trovarsi nell'immagine di sistema (non fornitore o altro) poiché un dispositivo configurato in modo errato può rifiutarsi di avviarsi. Se le sostituzioni di configurazione si trovavano 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 / app di aggiornamento diversi) sarebbe considerato una configurazione errata.

test xTS

xTS si riferisce a qualsiasi suite di test specifica 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 nelle seguenti posizioni:

  • packages/apps/TimeZoneData/testing/xts include il codice necessario per i test funzionali automatizzati di base.
  • packages/apps/TimeZoneData/oem_template/xts contiene una struttura di directory di esempio per includere i test in una suite xTS simile a Tradefed. Come 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 del tempo di compilazione per l'inclusione degli APK di test predefiniti richiesti dal test.

Creazione di aggiornamenti di fuso orario

Quando IANA rilascia un nuovo set di regole relative al 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, usarli per creare una nuova versione della loro app Data, quindi rilasciare la nuova versione per aggiornare i loro dispositivi in ​​produzione.

Poiché le app di dati contengono file di distribuzione strettamente collegati 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 del sistema / fuso orario e file di dati esterni / icu

In questo passaggio, gli OEM fanno il punto degli commit di Android per system/timezone e external/icu dalle filiali di rilascio -dev in AOSP e applicano tali commit alla loro copia del codice sorgente Android.

La patch AOSP di sistema / fuso orario 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, 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 automaticamente incluso al momento della system/timezone/output_data/distro/distro.zip dell'app Data.

Passaggio 2: aggiornamento del codice versione dell'app Dati

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

Quando si package/apps/TimeZoneData/oem_template/data_app l'app Dati utilizzando i file copiati dal package/apps/TimeZoneData/oem_template/data_app , è possibile trovare il codice versione / nome versione applicato all'APK in Android.mk :

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Voci simili sono disponibili in testing/Android.mk (tuttavia, i codici della versione di prova devono essere superiori alla versione dell'immagine di sistema). Per i dettagli, consultare lo schema di strategia del codice 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 usando le tapas, firmano l'APK generato, quindi testano e rilasciano l'APK:

  • Per i dispositivi non rilasciati (o quando si prepara un aggiornamento del sistema per un dispositivo rilasciato), inviare i nuovi APK nella directory precompilata dell'app Dati per assicurarsi che l'immagine del sistema e i test xTS abbiano gli APK più recenti. Gli OEM dovrebbero testare il corretto funzionamento del nuovo file (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 dell'assicurazione della qualità e del test dell'app Data aggiornata sui propri dispositivi prima del rilascio.

Strategia del codice versione app dati

L'app Dati deve avere una strategia di controllo delle versioni adatta per garantire che i dispositivi ricevano gli APK corretti. Ad esempio, se si riceve un aggiornamento del sistema che contiene un APK precedente a quello scaricato da un app store, è necessario conservare la versione dell'app store.

Il codice della versione APK deve includere le seguenti informazioni:

  • Versione in 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 (che rende incompatibili i file distro). 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 del codice della versione dell'app Data).

Esempio di strategia del codice versione

Questo schema di numeri di versione di esempio garantisce che le versioni con formato distro superiore sostituiscano le versioni con formato distro inferiore. AndroidManifest.xml utilizza android:minSdkVersion per garantire che i vecchi dispositivi non ricevano versioni con una versione in formato distro superiore di quanto possano gestire.

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

Lo schema potrebbe essere impacchettato meglio se si usasse 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 Data potrebbe cambiare.

Il nome della versione è una rappresentazione leggibile dall'uomo dei 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 minore}, {Versione regole IANA}, {Revisione}
1 11000010 O-MR1 major = 001, minore = 001, iana = 2017A, revision = 1
2 21000010 P major = 002, minore = 001, iana = 2017A, revision = 1
3 11000020 O-MR1 major = 001, minore = 001, iana = 2017A, revision = 2
4 11000030 O-MR1 major = 001, minore = 001, iana = 2017B, revision = 1
5 21000020 P major = 002, minore = 001, iana = 2017B, revision = 1
6 11000040 O-MR1 major = 001, minore = 001, iana = 2018a, revision = 1
7 21000030 P major = 002, minore = 001, iana = 2018a, revision = 1
8 1123456789 - -
9 11000021 O-MR1 major = 001, minore = 001, iana = 2017A, revision = 2, respin = 2
  • Gli esempi 1 e 2 mostrano due versioni APK per la stessa versione IANA 2017a con diverse versioni di formato principale. 2 è numericamente superiore a 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 superiore a 1.
  • Gli esempi 4 e 5 mostrano le versioni 2017b per O-MR1 e P. Essendo numericamente più alte, sostituiscono le versioni IANA precedenti / le 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 dello spazio lasciato tra 3 e 4 per ripetere la rotazione dell'apk.

Poiché ogni dispositivo viene fornito con un APK predefinito, con una versione appropriata nell'immagine di sistema, non vi è 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 riceve quindi un aggiornamento del 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 tramite tapas

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

Tapas è una versione ridotta del sistema di build Android che utilizza un albero di 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.

Creare il manifest

Un albero dei sorgenti ridotto viene solitamente ottenuto con un file manifest personalizzato che si riferisce 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 per 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 creazione per APK di test che possono essere utilizzate dai test xTS.
  • Un progetto Git contiene gli APK firmati prodotti dalla build dell'app per l'inclusione nella build dell'immagine di sistema e nei test xTS.

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

Il seguente frammento di manifest contiene il set minimo di progetti Git necessari per supportare una build O-MR1 dell'app Data time zone. 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 di tapas build

Dopo aver stabilito l'albero dei sorgenti, invoca la build di 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 corretta genera file nella directory out/dist per il test. Questi file possono essere inseriti nella directory dei prebuilt per l'inclusione nell'immagine di sistema e / o distribuiti attraverso un app store per dispositivi compatibili.