Per i dispositivi con Android 11 o versioni precedenti, il rilevamento automatico del fuso orario nel AOSP si basa sui segnali provenienti dal sottosistema di telefonia. A causa della dipendenza nel sottosistema della telefonia, rilevamento automatico del fuso orario su Android 11 o versioni precedenti è limitato ai dispositivi di telefonia.
Quando è disponibile il rilevamento del fuso orario per la telefonia, funziona utilizzando Mobile Country Code (Centro clienti) e Identità e fuso orario della rete (NITZ) e indicatori.
Ad esempio, un dispositivo in Francia è in grado di identificare il fuso orario basandosi esclusivamente sul Centro clienti segnalato dalle torri cellulari vicine. Ciò è possibile perché la Francia è nota utilizzano un unico fuso orario.
Quando un paese utilizza più fusi orari, il Centro clienti da solo non è sufficiente per identificare il fuso orario. Per questi paesi, il dispositivo utilizza anche i segnali NITZ per identificare il fuso orario corretto. Funziona bene in molte zone del mondo ma richiede che i segnali NITZ siano disponibili e corretti ed quindi dipendono dagli operatori.
Il rilevamento del fuso orario della telefonia è un rilevatore passivo. È sempre attivo e
quindi spesso i suggerimenti relativi alla telefonia vengono forniti anche quando
Al momento l'algoritmo di time_zone_detector non è la telefonia.
Limitazione del rilevamento del fuso orario per le telefonate
Anche con i corretti segnali NITZ disponibili, il rilevamento del fuso orario funzionano sempre bene in ogni paese. Questo perché NITZ contiene solo offset e ora legale, che non sempre sono sufficienti per identificare in modo univoco fuso orario.
Questo problema di fuso orario potrebbe verificarsi in molti luoghi del mondo. Ad esempio, Denver Colorado e Phoenix Arizona negli Stati Uniti non possono distinti tramite segnali NITZ durante l'inverno, ma possono durante altre stagioni. Qualsiasi località con fusi orari sovrapposti possono presentare questo tipo di problema.
Nella tabella seguente viene suddiviso il comportamento dei dispositivi in base alla stagione per Denver e Phoenix, ad esempio:
| Località e stagione | Informazioni dal Centro clienti o NITZ | Fuso orario e comportamento rilevati |
|---|---|---|
| Roma, Italia Inverno |
Data: 1° gennaio 2021 12:00:00 Paese: US Offset: UTC-7, senza ora legale |
Due ID zona corrispondono:
Il dispositivo è impostato correttamente su America/Denver. |
| Phoenix, Arizona Inverno |
Data: 1° gennaio 2021 12:00:00 Paese: US Offset: UTC-7, senza ora legale |
Due ID zona corrispondono:
Il dispositivo è impostato erroneamente su America/Denver. |
| Roma, Italia una scena estiva |
Data: 1° luglio 2021 12:00:00 Paese: US Offset: UTC-6, ora legale |
Un ID zona corrisponde a:
Il dispositivo è impostato correttamente su America/Denver. |
| Phoenix, Arizona una scena estiva |
Data: 1° luglio 2021 12:00:00 Paese: US Offset: UTC-7, senza ora legale |
Un ID zona corrisponde a:
Il dispositivo è impostato correttamente su America/Phoenix. |
Gli esempi sopra mostrano che durante l'inverno i dispositivi Android a Denver o Arizona deve scegliere uno dei due ID fuso orario corrispondenti, che potrebbero non essere corretti per alcuni dispositivi, ma mostra comunque l'ora locale corretta. Il dispositivo orologio, calendari e altre app visualizzano l'ora locale prevista anche se l'ID fuso orario non è corretto perché entrambi gli ID fuso orario calcolano lo stesso valore locale d'inverno.
Tuttavia, in primavera, quando Denver osserva l'ora legale e Phoenix sì no, alcuni dispositivi potrebbero mostrare temporaneamente l'ora locale errata se sono impostati all'ID fuso orario errato per la località dell'utente. Il problema verrà corretto non appena quando il dispositivo riceve un nuovo segnale NITZ (in particolare, uno che contiene "UTC-7, no ora legale" informazioni sull'offset), ma questa operazione può richiedere del tempo e dipende dagli operatori.
Di conseguenza, i calendari o altre app che memorizzano o mantengono l'ID fuso orario da inverno a primavera potrebbe visualizzare e utilizzare l'ora locale errata fino le app pertinenti aggiornano l'ID fuso orario.
Debug e test
La sezione seguente descrive i comandi shell per il debug e il test del funzionalità di rilevamento del fuso orario delle telefonate.
Configurazione dell'ambiente di test
I tester in genere utilizzano un ambiente di test con una cella di telefonia simulata o di test per controllare il comportamento di rilevamento del fuso orario della telefonia. La cella di test può essere utilizzata simulare reti con Centro clienti diversi e inviare segnali NITZ ai dispositivi e quindi monitorarne gli effetti.
Affinché il dispositivo rilevi il fuso orario, le informazioni sul segnale NITZ devono essere siano corretti, coerenti con il Centro clienti e corrispondano alla copia del dispositivo IANA TZDB (regole per il fuso orario). Gli indicatori NITZ non coerenti con il Centro clienti causano di telefonia mobile per diventare incerti.
Ad esempio, se il Centro clienti utilizzato dalla cella di test è per gli USA, il segnale NITZ deve contenere informazioni su "ora universale", offset e ora legale che è corretto per qualche località negli Stati Uniti.
Interagire con il servizio com.android.phone
Per verificare che il dispositivo riceva i suggerimenti corretti per il fuso orario, usa:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
che scarica le informazioni relative alla telefonia, che si possono trovare anche nel bug di Android. report. Sui dispositivi con più SIM, ci sono informazioni per ogni SIM radio.
I log del fuso orario mostrano i suggerimenti che il processo di telefonia ha inviato a time_zone_detector e i motivi per l'invio dei suggerimenti.
TimeServiceHelperImpl:
SystemClock.elapsedRealtime()=11864061
System.currentTimeMillis()=1620652067178
Time Logs:
...
Time zone Logs:
18602 / 2021-05-10T09:50:21.718Z - Suggesting time zone update:
TelephonyTimeZoneSuggestion{mSlotIndex=0, mZoneId='null', mMatchType=0, mQuality=0,
mDebugInfo=[getTimeZoneSuggestion: nitzSignal=TimestampedValue{mReferenceTimeMillis=14098,
mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,
mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}},
countryIsoCode=null, Detection
reason=handleNitzReceived(TimestampedValue{mReferenceTimeMillis=14098,
mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,
mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}})]}
18831 / 2021-05-10T09:50:21.948Z - Suggesting time zone update:
TelephonyTimeZoneSuggestion{mSlotIndex=0, mZoneId='Europe/London', mMatchType=3, mQuality=1,
mDebugInfo=[findTimeZoneFromCountryAndNitz: countryIsoCode=gb,
nitzSignal=TimestampedValue{mReferenceTimeMillis=14098,
mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,
mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}},
findTimeZoneFromCountryAndNitz: lookupResult=OffsetResult{mTimeZone(ID)=Europe/London,
mIsOnlyMatch=true}, Detection reason=handleCountryDetected("gb")]}