Android 10 depreca il meccanismo di aggiornamento dei dati del fuso orario basato su APK (disponibile in Android 8.1 e Android 9) e lo sostituisce con un meccanismo di aggiornamento del modulo basato su APEX . AOSP da 8.1 a 13 include ancora il codice della piattaforma necessario agli OEM per abilitare gli aggiornamenti basati su APK, quindi i dispositivi che eseguono l'aggiornamento ad Android 10 possono comunque ricevere aggiornamenti dei dati sul 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:
- 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.
- Google o il partner Android prepara un aggiornamento del modulo Time Zone Data (file APEX) contenente i fusi orari aggiornati.
- 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 derivanti dall'aggiornamento.
Per dettagli sui moduli, vedere Componenti del sistema modulare .
Aggiornamenti del fuso orario (Android 8.1–9)
Nota: la funzionalità del meccanismo di aggiornamento dei dati del fuso orario basato su APK è stata completamente rimossa da Android 14 in poi e non può essere trovata nel codice sorgente. I partner devono eseguire la migrazione completa al modulo Time Zone Mainline.
In Android 8.1 e Android 9, gli OEM possono utilizzare un meccanismo basato su APK per inviare ai dispositivi i dati aggiornati sulle regole del fuso orario senza richiedere un aggiornamento del sistema. Questo meccanismo consente agli utenti di ricevere aggiornamenti tempestivi (prolungando così la vita utile di un dispositivo Android) e consente ai partner Android di testare gli aggiornamenti del fuso orario indipendentemente dagli aggiornamenti dell'immagine del sistema.
Il team delle librerie principali di Android fornisce i file di dati necessari per aggiornare le regole del fuso orario su un dispositivo Android di serie. Gli OEM possono scegliere di utilizzare questi file di dati durante la creazione di aggiornamenti del fuso orario per i propri dispositivi o, se preferiscono, creare i propri file di dati. In tutti i casi, gli OEM mantengono il controllo su 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 funzionalità, necessitano dei 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 delle seguenti librerie nell'albero dei sorgenti Android:
- Il codice gestito da
libcore/
(ad esempio,java.util.TimeZone
) utilizza i filetzdata
etzlookup.xml
. - Il codice della libreria nativa in
bionic/
(ad esempio, permktime
, chiamate di sistema localtime) utilizza il filetzdata
. - Il codice della libreria ICU4J/ICU4C in
external/icu/
utilizza il file icu.dat
.
Queste librerie tengono traccia dei file sovrapposti che potrebbero essere presenti nella directory /data/misc/zoneinfo/current
. Si prevede che i file sovrapposti contengano dati migliorati sulle regole del fuso orario, consentendo così l'aggiornamento dei dispositivi senza modificare /system
.
I componenti del sistema Android che necessitano dei dati delle regole del fuso orario controllano prima le seguenti posizioni:
- Il codice
libcore/
ebionic/
utilizza la copia/data
dei filetzdata
etzlookup.xml
. - Il codice ICU4J/ICU4C utilizza i file in
/data
e ricorre ai file/system
per i dati che non sono presenti (per formati, stringhe localizzate, ecc.).
File di distribuzione
I file Distro .zip
contengono i file di dati necessari per popolare la directory /data/misc/zoneinfo/current
. I file di distribuzione contengono anche metadati che consentono ai dispositivi di rilevare problemi di controllo delle versioni.
Il formato del file della distribuzione dipende dalla versione di Android perché i contenuti cambiano con la versione ICU, i requisiti della piattaforma Android e altre modifiche alla versione. Android fornisce file di distribuzione per le versioni Android supportate per ogni aggiornamento IANA (oltre all'aggiornamento dei file di sistema della piattaforma). Per mantenere aggiornati i propri dispositivi, gli OEM possono utilizzare questi file di distribuzione o crearne di propri utilizzando l'albero dei sorgenti Android (che contiene gli script e altri file necessari per generare 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 al suo interno. Il trasferimento e l'installazione richiedono quanto segue:
- Funzionalità del servizio piattaforma (
timezone.RulesManagerService
), disabilitata per impostazione predefinita. Gli OEM devono abilitare la funzionalità tramite la configurazione.RulesManagerService
viene eseguito nel processo del server di sistema e organizza le operazioni di aggiornamento del fuso orario scrivendo in/data/misc/zoneinfo/staged
.RulesManagerService
può anche sostituire o eliminare operazioni già organizzate. -
TimeZoneUpdater
, un'app di sistema non aggiornabile (nota anche come app Updater ). Gli OEM devono includere questa app nell'immagine di sistema dei dispositivi che utilizzano la funzionalità. - OEM
TimeZoneData
, un'app di sistema aggiornabile (nota anche come app Dati ) che trasporta i file distro sul dispositivo e li rende disponibili all'app Updater. Gli OEM devono includere questa app nell'immagine di sistema dei dispositivi che utilizzano la funzionalità. -
tzdatacheck
, un binario all'avvio richiesto per il funzionamento corretto e sicuro degli aggiornamenti del fuso orario.
L'albero dei sorgenti Android contiene codice sorgente generico per i componenti di cui sopra, che l'OEM può scegliere di utilizzare senza modifiche. Il codice di test viene fornito per consentire agli OEM di verificare automaticamente di aver abilitato correttamente la funzionalità.
Installazione della distribuzione
Il processo di installazione della distribuzione include i seguenti passaggi:
- L'app dati viene aggiornata tramite il download o il 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 dati configurato, specifico dell'OEM.Figura 1. Aggiornamenti dell'app dati - 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 token viene ignorato.
Figura 2. Attiva il controllo degli aggiornamenti - Durante il controllo degli aggiornamenti , l'app Updater esegue le seguenti attività:
- Interroga lo stato corrente del dispositivo chiamando RulesManagerService.
Figura 3. Aggiornamenti dell'app dati, chiamata RulesManagerService - Interroga l'app Dati eseguendo una query su un URL ContentProvider e specifiche di colonna ben definiti per ottenere informazioni sulla distribuzione.
Figura 4. Aggiornamenti dell'app dati, ottieni informazioni sulla distribuzione
- Interroga lo stato corrente del dispositivo chiamando RulesManagerService.
- L'app Updater esegue l'azione appropriata in base alle informazioni in suo possesso. Le azioni disponibili includono:
- Richiedi un'installazione. I dati della distribuzione vengono letti dall'app Dati e passati a RulesManagerService nel server di sistema. RulesManagerService riconferma che la versione e il contenuto del formato della distribuzione sono appropriati per il dispositivo e mette in scena l'installazione.
- Richiedi una disinstallazione (questo è raro). Ad esempio, se l'APK aggiornato in
/data
viene disabilitato o disinstallato e il dispositivo torna alla versione presente in/system
. - Fare niente. Si verifica quando la distribuzione dell'app dati risulta non valida.
Figura 5. Controllo completato - Riavvia e tzdatacheck. Al successivo avvio del dispositivo, il binario tzdatacheck esegue qualsiasi operazione in fasi. Il binario tzdatacheck può eseguire le seguenti attività:
- Esegui l'operazione graduale gestendo la creazione, la sostituzione e/o l'eliminazione dei file
/data/misc/zoneinfo/current
prima che altri componenti del sistema si aprano e inizino a utilizzare i file. - Verifica che i file in
/data
siano corretti per la versione corrente della piattaforma, il che potrebbe non essere il caso se il dispositivo ha appena ricevuto un aggiornamento di sistema e la versione del formato della distribuzione è cambiata. - Assicurati che la versione delle regole IANA sia uguale o successiva alla versione in
/system
. Ciò protegge da un aggiornamento del sistema che lascia un dispositivo con dati sulle regole del fuso orario precedenti a quelli presenti nell'immagine/system
.
- Esegui l'operazione graduale gestendo la creazione, la sostituzione e/o l'eliminazione dei file
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 l'operazione non ha avuto successo; nel peggiore dei casi di insuccesso, RulesManagerService non riceve alcuna chiamata.
Per gestire ciò, il codice del server di sistema tiene traccia se un controllo di aggiornamento attivato è stato completato e qual è l'ultimo codice di versione controllato dell'app dati. Quando il dispositivo è inattivo e in carica, il codice del server di sistema può verificare lo stato corrente. Se rileva un controllo degli aggiornamenti incompleto o una versione inaspettata dell'app dati, attiva spontaneamente un controllo degli aggiornamenti.
Sicurezza
Quando abilitato, il codice RulesManagerService nel server di sistema esegue diversi controlli per garantire che il sistema sia sicuro da usare.
- I problemi che indicano un'immagine di sistema configurata in modo errato impediscono l'avvio del dispositivo; gli esempi includono una configurazione errata del programma di aggiornamento o dell'app dati oppure che il programma di aggiornamento o l'app dati non si trovano in
/system/priv-app
. - I problemi che indicano che è stata installata un'app dati errata non impediscono l'avvio del dispositivo ma impediscono l'attivazione di un controllo degli aggiornamenti; gli esempi includono la mancanza delle autorizzazioni di sistema richieste o l'app Dati non espone un ContentProvider sull'URI previsto.
I permessi sui file per le directory /data/misc/zoneinfo
vengono applicati utilizzando le regole SELinux. Come con qualsiasi APK, l'app Dati deve essere firmata con la stessa chiave utilizzata per firmare la versione /system/priv-app
. Si prevede che l'app Dati abbia un nome e una chiave di pacchetto dedicati e specifici dell'OEM.
Integrazione degli aggiornamenti del fuso orario
Per abilitare la funzionalità 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 rivedere le seguenti considerazioni su politica, garanzia di qualità e sicurezza:
- Creare una chiave di firma dedicata specifica per l'app per l'app dati.
- Creare una strategia di rilascio e controllo delle versioni per gli aggiornamenti del fuso orario per comprendere 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 diverse per dispositivi diversi. La decisione influisce sulla scelta del nome del pacchetto, eventualmente sui codici di versione utilizzati e sulla strategia di QA.
- Scopri se desiderano utilizzare i dati di fuso orario Android di serie di AOSP o crearne di propri.
Creazione di un'app dati
AOSP include tutto il codice sorgente e le regole di compilazione necessarie per creare un'app dati in packages/apps/TimeZoneData
, con istruzioni e modelli di esempio per AndroidManifest.xml
e altri file situati in packages/apps/TimeZoneData/oem_template
. I modelli di esempio includono sia una destinazione di compilazione per l'APK dell'app dati reale sia destinazioni aggiuntive per la creazione di versioni di prova dell'app dati.
Gli OEM possono personalizzare l'app Dati con la propria icona, nome, traduzioni e altri dettagli. Tuttavia, poiché l'app Dati non può essere avviata, l'icona viene visualizzata solo nella schermata Impostazioni > App .
L'app Data è pensata per essere realizzata con una build tapas che produce APK adatti ad essere aggiunti all'immagine di sistema (per il rilascio iniziale) e firmati e distribuiti tramite un app store (per gli aggiornamenti successivi). Per informazioni dettagliate sull'utilizzo di tapas, vedere Creazione dell'app Dati utilizzando tapas .
Gli OEM devono installare l'app Dati preintegrata nell'immagine di sistema di un dispositivo in /system/priv-app
. Per includere APK predefiniti (generati dal processo di compilazione tapas) nell'immagine di sistema, gli OEM possono copiare i file di esempio in packages/apps/TimeZoneData/oem_template/data_app_prebuilt
. I modelli di esempio includono anche destinazioni di compilazione per includere versioni di test dell'app Dati nelle suite di test.
Includere le app Updater e Data nell'immagine di sistema
Gli OEM devono posizionare gli APK dell'aggiornamento e dell'app dati nella directory /system/priv-app
dell'immagine di sistema. A tale scopo, la build dell'immagine di sistema deve includere esplicitamente le destinazioni predefinite dell'app Updater e dell'app dati.
L'app Updater deve essere firmata con la chiave della piattaforma e inclusa come qualsiasi altra app di sistema. La destinazione è definita in packages/apps/TimeZoneUpdater
come TimeZoneUpdater
. L'inclusione dell'app dati è specifica dell'OEM e dipende dal nome di destinazione scelto per la precompilazione.
Configurazione del server di sistema
Per abilitare gli aggiornamenti del fuso orario, gli OEM possono configurare il server di sistema sovrascrivendo le proprietà di configurazione definite in frameworks/base/core/res/res/values/config.xml
.
Proprietà | Descrizione | È necessario eseguire l'override? |
---|---|---|
config_enableUpdateableTimeZoneRules | Deve essere impostato su true per abilitare RulesManagerService. | SÌ |
config_timeZoneRulesUpdateTrackingEnabled | Deve essere impostato su true affinché il sistema ascolti le modifiche all'app Dati. | SÌ |
config_timeZoneRulesDataPackage | Nome del pacchetto dell'app dati specifica dell'OEM. | SÌ |
config_timeZoneRulesUpdaterPackage | Configurato per l'app di aggiornamento predefinita. Modificare solo quando si fornisce un'implementazione diversa dell'app Updater. | NO |
config_timeZoneRulesCheckTimeMillisAllowed | Tempo consentito tra l'attivazione di un controllo degli aggiornamenti da parte di RulesManagerService e una risposta di installazione, disinstallazione o non fare nulla. Dopo questo punto, può essere generato un trigger di affidabilità spontaneo. | NO |
config_timeZoneRulesCheckRetryCount | Il numero di controlli sequenziali di aggiornamenti non riusciti consentiti prima che RulesManagerService smetta di generarne altri. | NO |
Le sostituzioni della configurazione dovrebbero essere nell'immagine del sistema (non nel fornitore o altro) poiché un dispositivo configurato in modo errato può rifiutarsi di avviarsi. Se le sostituzioni della configurazione fossero nell'immagine del fornitore, l'aggiornamento a un'immagine di sistema senza un'app dati (o con nomi di pacchetti app dati/app di aggiornamento diversi) sarebbe considerato una configurazione errata.
test xTS
xTS si riferisce a qualsiasi suite di test specifica per OEM simile alle suite di test Android standard che utilizzano Tradefed (come CTS e VTS). Gli OEM che dispongono di 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 test in una suite xTS simile a Tradefed. Come con altre directory di modelli, gli OEM sono tenuti a copiare e personalizzare in base alle proprie esigenze. -
packages/apps/TimeZoneData/oem_template/data_app_prebuilt
contiene la configurazione in fase di compilazione per includere gli APK di test predefiniti richiesti dal test.
Creazione di aggiornamenti del fuso orario
Quando IANA rilascia una nuova serie di regole sul fuso orario, il team delle librerie principali di Android genera patch per aggiornare le versioni in AOSP. Gli OEM che utilizzano il sistema Android di serie e i file di distribuzione possono raccogliere questi commit, utilizzarli per creare una nuova versione della propria app Dati, quindi rilasciare la nuova versione per aggiornare i propri dispositivi in produzione.
Poiché le app dati contengono file di distribuzione 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 dispositivi Android 8.1, 9 e 10, deve completare il processo tre volte.
Passaggio 1: aggiornamento dei file di dati di sistema/fuso orario e esterni/icu
In questa fase, gli OEM fanno il punto sui commit Android per system/timezone
ed external/icu
dai rami release -dev in AOSP e applicano tali commit alla loro copia del codice sorgente Android.
La patch AOSP system/timezone contiene file aggiornati in system/timezone/input_data
e system/timezone/output_data
. Gli OEM che necessitano di 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 incluso automaticamente quando viene creato l'APK dell'app dati.
Passaggio 2: aggiornamento del codice della versione dell'app Dati
In questo passaggio, gli OEM aggiornano il codice di versione dell'app Dati. La build preleva automaticamente distro.zip
, ma la nuova versione dell'app Dati deve avere un nuovo codice di versione in modo che venga riconosciuta come nuova e venga utilizzata per sostituire un'app Dati precaricata o un'app Dati installata su un dispositivo con un aggiornamento precedente.
Quando crei l'app Dati utilizzando file copiati da package/apps/TimeZoneData/oem_template/data_app
, puoi trovare il codice/nome della versione applicato all'APK in Android.mk
:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
Voci simili possono essere trovate in testing/Android.mk
(tuttavia, i codici della versione di prova devono essere superiori alla versione dell'immagine del 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 necessitano di essere aggiornati perché è garantito che siano superiori ai codici della versione reale.
Passaggio 3: ricostruzione, firma, test e rilascio
In questa fase, gli OEM ricostruiscono l'APK utilizzando tapas, firmano l'APK generato, quindi testano e rilasciano l'APK:
- Per i dispositivi non rilasciati (o quando si prepara un aggiornamento di sistema per un dispositivo rilasciato), inviare i nuovi APK nella directory predefinita dell'app Dati per garantire che l'immagine di sistema e i test xTS dispongano degli APK più recenti. Gli OEM devono verificare che il nuovo file funzioni correttamente (ovvero, che superi CTS e qualsiasi test automatico e manuale specifico dell'OEM).
- Per i dispositivi rilasciati che non ricevono più aggiornamenti di sistema, l'APK firmato potrebbe essere rilasciato solo tramite un app store.
Gli OEM sono responsabili del controllo qualità e del test dell'app Dati aggiornata sui propri dispositivi prima del rilascio.
Strategia del codice della versione dell'app dati
L'app Dati 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 mantenuta.
Il codice della versione APK dovrebbe includere le seguenti informazioni:
- Versione in formato distribuzione (maggiore + minore)
- Un numero di versione incrementale (opaco).
Attualmente, il livello API della piattaforma è fortemente correlato alla versione del formato della distribuzione 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 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 esempio di schema del numero di versione garantisce che le versioni del formato di distribuzione superiore sostituiscano le versioni del formato di distribuzione inferiore. AndroidManifest.xml
usa android:minSdkVersion
per garantire che i vecchi dispositivi non ricevano versioni con un formato di distribuzione superiore a quello che possono gestire.
![Controllo della versione](https://source.android.com/static/docs/core/permissions/images/tz_version_check.png?authuser=5&hl=it)
Esempio | Valore | Scopo |
---|---|---|
Y | Riservato | Consente futuri schemi alternativi/APK di test. Inizialmente è (implicitamente) 0. Poiché il tipo sottostante è un tipo int con segno a 32 bit, 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 distribuzione supporta 3 cifre decimali ma qui vengono utilizzate solo 2 cifre. È improbabile che raggiunga 100 dato il notevole incremento 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 a 3 cifre decimali. Il formato della distribuzione supporta 3 cifre decimali ma qui viene utilizzata solo 1 cifra. Difficilmente arriveremo a 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 l'esecuzione di aggiornamenti interstitial, se necessario. |
Lo schema potrebbe essere impacchettato meglio se venisse utilizzato il formato binario invece del decimale, ma questo schema ha il vantaggio di essere leggibile dall'uomo. Se l'intervallo di numeri completo viene esaurito, il nome del pacchetto dell'app dati potrebbe cambiare.
Il nome della versione è una rappresentazione leggibile dei dettagli, ad esempio: major=001,minor=001,iana=2017a, revision=1,respin=2
. Gli esempi sono mostrati nella tabella seguente.
# | Codice della 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 superiore a 1, necessario per garantire che i dispositivi più recenti ricevano le versioni di formato superiore. minSdkVersion garantisce che la versione P non venga fornita ai dispositivi O.
- L'esempio 3 è una revisione/correzione per 1 ed è numericamente superiore a 1.
- Gli esempi 4 e 5 mostrano le versioni 2017b per O-MR1 e P. Essendo numericamente più elevate, sostituiscono le versioni IANA/revisioni Android precedenti dei rispettivi predecessori.
- Gli esempi 6 e 7 mostrano le versioni 2018a per O-MR1 e P.
- L'esempio 8 dimostra l'uso di Y per sostituire completamente lo schema Y=0.
- L'esempio 9 dimostra l'uso dello spazio 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'è 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 di sistema in P utilizza la versione /system
anziché la versione O-MR1 in /data
perché la versione P è sempre superiore a qualsiasi app destinata a O- MR1.
Creazione dell'app Dati utilizzando tapas
Gli OEM sono responsabili della gestione della maggior parte degli aspetti dell'app Dati del fuso orario e della corretta configurazione dell'immagine del sistema. L'app Data è pensata per essere realizzata con una build tapas che produce APK adatti ad essere aggiunti all'immagine di sistema (per il rilascio iniziale) e firmati e distribuiti tramite un app store (per gli 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 manifesto
Un albero dei sorgenti ridotto viene solitamente ottenuto 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 dell'app come il manifest e i file di build necessari per creare il file APK dell'app (ad esempio,
vendor/ oem /apps/TimeZoneData
). Questo progetto contiene anche regole di compilazione per gli APK di test che possono essere utilizzati dai test xTS. - Un progetto Git contiene gli APK firmati prodotti dalla build dell'app per l'inclusione nella build dell'immagine di sistema e nei test xTS.
La build dell'app sfrutta diversi altri progetti Git condivisi con la build della piattaforma o che contengono librerie di 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 dati del fuso orario. Gli OEM devono aggiungere i propri progetti Git specifici dell'OEM (che in genere includono un progetto che contiene il certificato di firma) a questo manifest e possono configurare di conseguenza diversi rami.
<!-- 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" />
Esecuzione della build delle tapas
Dopo aver stabilito l'albero dei sorgenti, richiamare 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 predefinita per essere inclusi nell'immagine del sistema e/o distribuiti tramite un app store per dispositivi compatibili.