W przypadku urządzeń z systemem Android 11 lub starszym automatyczne wykrywanie strefy czasowej w AOSP opiera się na sygnałach z podsystemu telefonii. Ze względu na zależność od podsystemu telefonii automatyczne wykrywanie strefy czasowej w systemie Android 11 lub starszym ogranicza się do urządzeń telefonicznych.
Jeśli dostępna jest funkcja wykrywania strefy czasowej w telefonii, działa ona przy użyciu sygnałów kodu kraju telefonu komórkowego (MCC) oraz tożsamości sieci i strefy czasowej (NITZ) .
Na przykład urządzenie we Francji może zidentyfikować strefę czasową wyłącznie na podstawie numeru MCC zgłoszonego przez pobliskie stacje bazowe sieci komórkowych. Jest to możliwe, ponieważ we Francji obowiązuje jedna strefa czasowa.
Jeśli kraj korzysta z wielu stref czasowych, samo oznaczenie MCC nie wystarczy do zidentyfikowania strefy czasowej. W przypadku tych krajów urządzenie wykorzystuje również sygnały NITZ do identyfikacji właściwej strefy czasowej. Działa to dobrze w wielu miejscach na świecie, ale wymaga, aby sygnały NITZ były dostępne i prawidłowe, a zatem jest zależne od przewoźników.
Wykrywanie strefy czasowej telefonii jest detektorem pasywnym . Działa przez cały czas, dlatego często pojawiają się sugestie dotyczące telefonii, nawet jeśli aktywny algorytm time_zone_detector nie jest aktualnie telefonią.
Ograniczenie wykrywania strefy czasowej telefonii
Nawet przy dostępności prawidłowych sygnałów NITZ telefoniczne wykrywanie stref czasowych nie zawsze działa dobrze w każdym kraju. Dzieje się tak dlatego, że NITZ zawiera jedynie informacje o przesunięciu i czasie letnim, które nie zawsze są wystarczające do jednoznacznego zidentyfikowania strefy czasowej.
Jest wiele miejsc na świecie, w których może wystąpić problem ze strefą czasową. Na przykład Denver w Kolorado i Phoenix w Arizonie w USA nie można rozróżnić za pomocą sygnałów NITZ zimą, ale można to zrobić w innych porach roku. Tego rodzaju problemy mogą wystąpić w dowolnej lokalizacji o podobnie nakładających się strefach czasowych.
Poniższa tabela przedstawia zachowanie urządzenia w zależności od pory roku, na przykład dla Denver i Phoenix:
| Lokalizacja i sezon | Informacje z MCC lub NITZ | Wykryta strefa czasowa i zachowanie |
|---|---|---|
| Denver, Colorado Zima | Czas: 1 stycznia 2021 r., godzina 12:00:00 Kraj: USA Przesunięcie: UTC-7, brak czasu letniego | Identyfikatory dwóch stref pasują do siebie:
Urządzenie jest prawidłowo ustawione na America/Denver. |
| Phoenix, Arizona Zima | Czas: 1 stycznia 2021 r., godzina 12:00:00 Kraj: USA Przesunięcie: UTC-7, brak czasu letniego | Identyfikatory dwóch stref pasują do siebie:
Urządzenie jest nieprawidłowo ustawione na Amerykę/Denver. |
| Denver, Colorado Lato | Czas: 1 lipca 2021 r., godzina 12:00:00 Kraj: USA Przesunięcie: UTC-6, czas letni | Identyfikator jednej strefy pasuje:
Urządzenie jest prawidłowo ustawione na America/Denver. |
| Phoenix, Arizona Lato | Czas: 1 lipca 2021 r., godzina 12:00:00 Kraj: USA Przesunięcie: UTC-7, brak czasu letniego | Identyfikator jednej strefy pasuje:
Urządzenie jest prawidłowo ustawione na America/Phoenix. |
Powyższe przykłady pokazują, że zimą urządzenia z Androidem w Denver lub Arizonie muszą wybrać jeden z dwóch pasujących identyfikatorów strefy czasowej, który może być nieprawidłowy w przypadku niektórych urządzeń, ale nadal wyświetla pozornie prawidłowy czas lokalny. Zegar urządzenia, kalendarze i inne aplikacje wyświetlają oczekiwany czas lokalny, nawet jeśli identyfikator strefy czasowej jest nieprawidłowy, ponieważ oba identyfikatory stref czasowych obliczają ten sam czas lokalny w okresie zimowym.
Jednak wiosną, kiedy Denver przestrzega czasu letniego, a Phoenix nie, niektóre urządzenia mogą tymczasowo wyświetlać nieprawidłowy czas lokalny, jeśli są ustawione na nieprawidłowy identyfikator strefy czasowej dla lokalizacji użytkownika. Jest to korygowane, gdy tylko urządzenie odbierze nowy sygnał NITZ (w szczególności taki, który zawiera informację o przesunięciu „UTC-7, brak czasu letniego”), ale może to zająć trochę czasu i zależy od przewoźników.
W rezultacie kalendarze lub inne aplikacje przechowujące lub przenoszące identyfikator strefy czasowej z zimy na wiosnę mogą wyświetlać i używać nieprawidłowego czasu lokalnego, dopóki odpowiednie aplikacje nie zaktualizują identyfikatora strefy czasowej.
Debugowanie i testowanie
W poniższej sekcji opisano polecenia powłoki służące do debugowania i testowania funkcji wykrywania strefy czasowej w telefonii.
Konfiguracja środowiska testowego
Testerzy zazwyczaj korzystają ze środowiska testowego z testową lub symulowaną komórką telefoniczną, aby sprawdzić zachowanie wykrywania strefy czasowej w telefonii. Komórkę testową można wykorzystać do symulacji sieci z różnymi MCC oraz do wysyłania sygnałów NITZ do urządzeń, a następnie monitorowania ich efektów.
Aby urządzenie mogło wykryć strefę czasową, informacja o sygnale NITZ musi być poprawna, zgodna z MCC i zgodna z kopią urządzenia IANA TZDB (zasady strefy czasowej). Sygnały NITZ niezgodne z MCC powodują, że algorytm telefoniczny staje się niepewny.
Na przykład, jeśli MCC używany przez komórkę testową jest przeznaczony dla USA, sygnał NITZ musi zawierać informacje o „czasie uniwersalnym”, przesunięciu i czasie letnim, które są prawidłowe dla jakiegoś miejsca w USA.
Interakcja z usługą com.android.phone
Aby sprawdzić, czy urządzenie otrzymuje prawidłowe sugestie dotyczące telefonicznej strefy czasowej, użyj:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Spowoduje to zrzucenie informacji telefonicznych, które można również znaleźć w raportach o błędach Androida. Na urządzeniach z wieloma kartami SIM dostępne są informacje o każdym radiu SIM.
Dzienniki stref czasowych pokazują sugestie, które proces telefonii wysłał do time_zone_detector, oraz powody wysłania sugestii.
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")]}