Rilevamento del fuso orario della telefonia

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 MCC (Mobile Country Code) e NITZ (Network Identity and Time Zone) .

Ad esempio, un dispositivo in Francia può identificare il fuso orario basandosi esclusivamente sull'MCC segnalato 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 Centro clienti 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 del 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 vengono spesso forniti suggerimenti di telefonia anche quando l'origine time_zone_detector non è attualmente la telefonia.

Limitazione del rilevamento del fuso orario della telefonia

Anche con i segnali NITZ corretti disponibili, il rilevamento del fuso orario della telefonia non funziona sempre 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.

Ci sono 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 distinti utilizzando i segnali NITZ durante l'inverno, ma durante le altre stagioni. Qualsiasi luogo con fusi orari sovrapposti in modo simile potrebbe riscontrare questo tipo di problema.

La tabella seguente analizza il comportamento del dispositivo a seconda della stagione per Denver e Phoenix come esempio:

Posizione e stagione Informazioni da MCC o NITZ Fuso orario e comportamento rilevati
Denver, Colorado
Inverno
Orario: 1 gennaio 2021 12:00:00
Paese: USA
Offset: UTC-7, nessuna ora legale
Due ID zona corrispondono:
  • America/Denver
  • America/Fenice

Il dispositivo è impostato correttamente su America/Denver.
Phoenix, Arizona
Inverno
Orario: 1 gennaio 2021 12:00:00
Paese: USA
Offset: UTC-7, nessuna ora legale
Due ID zona corrispondono:
  • America/Denver
  • America/Fenice

Il dispositivo è impostato in modo errato su America/Denver.
Denver, Colorado
Estate
Orario: 1 luglio 2021 12:00:00
Paese: USA
Offset: UTC-6, ora legale
Un ID zona corrisponde a:
  • America/Denver

Il dispositivo è impostato correttamente su America/Denver.
Phoenix, Arizona
Estate
Orario: 1 luglio 2021 12:00:00
Paese: USA
Offset: UTC-7, nessuna ora legale
Un ID zona corrisponde a:
  • America/Fenice

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 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 viene corretto non appena il dispositivo riceve un nuovo segnale NITZ (in particolare, uno che contiene informazioni di offset "UTC-7, nessuna ora legale"), ma ciò può richiedere del tempo e dipende dai vettori.

Di conseguenza, i calendari o altre app che archiviano o trasferiscono l'ID del fuso orario dall'inverno alla primavera potrebbero visualizzare e utilizzare l'ora locale errata fino a quando le app pertinenti non aggiornano l'ID del fuso orario.

Debug e test

La sezione seguente descrive i comandi della shell per il debug e il test della funzionalità di rilevamento del fuso orario della telefonia.

Configurazione dell'ambiente di prova

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 l'MCC e corrispondere alla copia del dispositivo di IANA TZDB (regole del fuso orario). I segnali NITZ che non sono coerenti con l'MCC rendono incerta l'origine della telefonia.

Ad esempio, se l'MCC utilizzato dalla cella di test è per gli Stati Uniti, il segnale NITZ deve contenere informazioni sull'"ora universale", l'offset e l'ora legale corretti per gli Stati Uniti.

Interazione con il servizio com.android.phone

Per verificare che il dispositivo riceva suggerimenti sul fuso orario telefonico corretti, utilizzare:

adb shell dumpsys activity service \
    com.android.phone/com.android.phone.TelephonyDebugService

Questo scarica le informazioni sulla telefonia, che possono essere trovate anche nelle segnalazioni di bug di Android. Sui dispositivi con più SIM, ci sono informazioni per ciascuna radio SIM.

I Registri del fuso orario mostrano i suggerimenti che il processo di telefonia ha inviato al time_zone_detector ei 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")]}