Per i dispositivi con Android 11 o versioni precedenti, il rilevamento automatico del fuso orario nell'AOSP si basa sui segnali del sottosistema di telefonia. A causa della dipendenza dal sottosistema di telefonia, il rilevamento automatico del fuso orario su Android 11 o versioni precedenti è limitato ai dispositivi di telefonia.
Quando è disponibile il rilevamento del fuso orario della telefonia, funziona utilizzando i segnali Mobile Country Code (MCC) e Network Identity and Time Zone (NITZ) .
Ad esempio, un dispositivo in Francia può identificare il fuso orario basandosi esclusivamente sul MCC riportato dai ripetitori cellulari vicini. Ciò è possibile perché è noto che la Francia utilizza un unico fuso orario.
Quando un Paese utilizza più fusi orari, il solo MCC 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 molti luoghi in tutto il mondo, ma richiede che i segnali NITZ siano disponibili e corretti e dipende quindi dai vettori.
Il rilevamento del fuso orario della telefonia è un rilevatore passivo . Funziona in ogni momento e quindi i suggerimenti di telefonia vengono spesso forniti anche quando l'algoritmo time_zone_detector attivo non è attualmente telefonia.
Limitazione del rilevamento del fuso orario della telefonia
Anche con la disponibilità dei segnali NITZ corretti, il rilevamento del fuso orario della telefonia non sempre funziona bene in tutti i paesi. Questo perché NITZ contiene solo informazioni sull'offset e sull'ora legale, che non sono sempre sufficienti per identificare in modo univoco un fuso orario.
Esistono molti posti nel mondo in cui potrebbe verificarsi questo problema di fuso orario. Ad esempio, Denver Colorado e Phoenix Arizona negli Stati Uniti non possono essere distinte utilizzando i segnali NITZ durante l'inverno, ma sì durante le altre stagioni. Qualsiasi località con fusi orari sovrapposti in modo simile potrebbe riscontrare questo tipo di problema.
La seguente tabella suddivide il comportamento del dispositivo in base alla stagione, ad esempio per Denver e Phoenix:
| Posizione e stagione | Informazioni da MCC o NITZ | Fuso orario e comportamento rilevati |
|---|---|---|
| Denver, Colorado Inverno | Orario: 1 gennaio 2021 12:00:00 Paese: Stati Uniti Offset: UTC-7, nessuna ora legale | Due ID di zona corrispondono:
Il dispositivo è impostato correttamente su America/Denver. |
| Phoenix, Arizona Inverno | Orario: 1 gennaio 2021 12:00:00 Paese: Stati Uniti Offset: UTC-7, nessuna ora legale | Due ID di zona corrispondono:
Il dispositivo è impostato erroneamente su America/Denver. |
| Denver, Colorado Estate | Orario: 1 luglio 2021 12:00:00 Paese: Stati Uniti Offset: UTC-6, ora legale | Un ID zona corrisponde a:
Il dispositivo è impostato correttamente su America/Denver. |
| Phoenix, Arizona Estate | Orario: 1 luglio 2021 12:00:00 Paese: Stati Uniti Offset: UTC-7, nessuna 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 in Arizona devono scegliere uno dei due ID di fuso orario corrispondenti, che potrebbero non essere corretti per alcuni dispositivi ma visualizzare comunque un'ora locale apparentemente corretta. L'orologio del dispositivo, i calendari e le altre app visualizzano l'ora locale prevista anche se l'ID del fuso orario non è corretto perché entrambi gli ID del fuso orario calcolano la stessa ora locale durante l'inverno.
Tuttavia, in primavera, quando Denver osserva l'ora legale e Phoenix no, alcuni dispositivi potrebbero mostrare temporaneamente l'ora locale errata se sono impostati sull'ID del fuso orario errato per la posizione dell'utente. Questo problema viene corretto non appena il dispositivo riceve un nuovo segnale NITZ (nello specifico, uno che contiene informazioni sull'offset "UTC-7, nessuna ora legale"), ma ciò può richiedere del tempo e dipende dagli operatori.
Di conseguenza, i calendari o altre app che memorizzano o trasferiscono l'ID del fuso orario dall'inverno alla primavera potrebbero visualizzare e utilizzare l'ora locale sbagliata finché le app pertinenti non aggiornano l'ID del fuso orario.
Debug e test
La sezione seguente descrive i comandi shell per il debug e il test della funzionalità di rilevamento del fuso orario della telefonia.
Configurazione dell'ambiente di test
I tester utilizzano in genere un ambiente di test con una cella di telefonia di prova o simulata per verificare il comportamento di rilevamento del fuso orario della telefonia. La cella di test può essere utilizzata per simulare reti con diversi MCC e per inviare segnali NITZ ai dispositivi e quindi monitorarne gli effetti.
Affinché il dispositivo rilevi il fuso orario, le informazioni sul segnale NITZ devono essere corrette, coerenti con MCC e corrispondere alla copia del dispositivo IANA TZDB (regole sul fuso orario). I segnali NITZ che non sono coerenti con l'MCC rendono incerto l'algoritmo di telefonia.
Ad esempio, se l'MCC utilizzato dalla cella di test è per gli Stati Uniti, il segnale NITZ deve contenere informazioni su "ora universale", offset e ora legale corrette per qualche parte negli Stati Uniti.
Interagire con il servizio com.android.phone
Per verificare che il dispositivo riceva suggerimenti di fuso orario corretti per la telefonia, utilizzare:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Questo scarica le informazioni di telefonia, che possono essere trovate anche nelle segnalazioni di bug di Android. Sui dispositivi con più SIM, sono disponibili informazioni per ciascuna radio SIM.
I registri del fuso orario mostrano i suggerimenti che il processo di telefonia ha inviato al time_zone_detector e i motivi dell'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")]}