W przypadku urządzeń z Androidem 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 telefonicznego automatyczne wykrywanie strefy czasowej na Androidzie 11 lub starszym jest ograniczone do urządzeń telefonicznych.
Gdy wykrywanie strefy czasowej w telefonii jest dostępne, działa na podstawie sygnałów kodu kraju komórkowego (MCC) i tożsamości sieci oraz strefy czasowej (NITZ).
Na przykład urządzenie we Francji może określić strefę czasową wyłącznie na podstawie MRC przekazanego przez pobliskie wieże komórkowe. Jest to możliwe, ponieważ Francja używa tylko jednej strefy czasowej.
Jeśli w danym kraju obowiązuje kilka stref czasowych, samo konto MCK nie wystarcza do określenia strefy czasowej. W przypadku tych krajów urządzenie korzysta też z sygnałów NITZ, aby określić właściwą strefę czasową. Ta metoda sprawdza się w wielu miejscach na świecie, ale wymaga, aby sygnały NITZ były dostępne i prawidłowe, a to z kolei zależy od operatorów.
Wykrywanie strefy czasowej na podstawie telefonii to pasywny detektor. Jest ona aktywna przez cały czas, dlatego sugestie dotyczące rozmów telefonicznych są często wyświetlane nawet wtedy, gdy aktywny algorytm time_zone_detector nie jest obecnie związany z telefonami.
Ograniczenia wykrywania strefy czasowej w telefonii
Nawet przy prawidłowych sygnałach NITZ wykrywanie strefy czasowej w telefonii nie zawsze działa prawidłowo we wszystkich krajach. Dzieje się tak, ponieważ NITZ zawiera tylko informacje o przesunięciu i czasie letnim, które nie zawsze wystarczają do jednoznacznego zidentyfikowania strefy czasowej.
Ten problem ze strefami czasowymi może występować w wielu miejscach na świecie. Na przykład w Stanach Zjednoczonych nie można odróżnić Denver w Kolorado od Phoenix w Arizonie za pomocą sygnałów NITZ w zimie, ale można to zrobić w innych porach roku. Ten problem może wystąpić w przypadku dowolnej lokalizacji z podobnie nakładającymi się strefami czasowymi.
W poniższej tabeli podano przykładowe zachowanie urządzeń w zależności od sezonu w Denver i Phoenix:
| lokalizacja i pory roku, | Informacje z MCK lub NITZ | Wykrywanie strefy czasowej i zachowania |
|---|---|---|
| Denver, Kolorado Zima |
Czas: 1 stycznia 2021 r., 12:00:00 Kraj: Stany Zjednoczone Odchylenie: UTC-7, bez czasu letniego |
Dwa identyfikatory strefy są identyczne:
Urządzenie jest prawidłowo skonfigurowane na America/Denver. |
| Phoenix, Arizona Zima |
Czas: 1 stycznia 2021 r., 12:00:00 Kraj: Stany Zjednoczone Odchylenie: UTC-7, bez czasu letniego |
Dwa identyfikatory strefy są identyczne:
Urządzenie jest nieprawidłowo skonfigurowane na America/Denver. |
| Denver, Kolorado Lato |
Czas: 1 lipca 2021 r., 12:00:00 Kraj: USA Odchylenie: UTC-6, czas letni |
Jeden identyfikator strefy pasuje:
Urządzenie jest prawidłowo skonfigurowane na America/Denver. |
| Phoenix, Arizona Lato |
Czas: 1 lipca 2021 r., 12:00:00 Kraj: USA Odchylenie: UTC-7, bez czasu letniego |
Jeden identyfikator strefy pasuje:
Urządzenie jest prawidłowo ustawione na „Ameryka/Phoenix”. |
Z powyższych przykładów wynika, że zimą urządzenia z Androidem w Denver lub Arizonie muszą wybrać jeden z 2 pasujących identyfikatorów strefy czasowej, który może być nieprawidłowy w przypadku niektórych urządzeń, ale nadal wyświetla prawidłowy czas lokalny. Zegar, kalendarze i inne aplikacje na urządzeniu wyświetlają oczekiwany czas lokalny, nawet jeśli identyfikator strefy czasowej jest nieprawidłowy, ponieważ oba identyfikatory stref czasowych zwracają ten sam czas lokalny zimą.
Jednak wiosną, gdy w Denver obowiązuje czas letni, a w Phoenix nie, niektóre urządzenia mogą tymczasowo wyświetlać nieprawidłowy czas lokalny, jeśli mają ustawiony nieprawidłowy identyfikator strefy czasowej dla lokalizacji użytkownika. Błąd ten zostanie skorygowany, gdy urządzenie otrzyma nowy sygnał NITZ (szczególnie ten, który zawiera informacje o zmianie czasu „UTC-7, bez czasu letniego”), ale może to zająć trochę czasu i zależy od operatora.
W efekcie kalendarze i inne aplikacje, które przechowują lub przenoszą 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 tej sekcji opisano polecenia powłoki służące do debugowania i testowania funkcji wykrywania strefy czasowej w telefonii.
Konfigurowanie środowiska testowego
Testerzy zwykle korzystają z testowego środowiska z testowym lub symulowanym elementem telefonii komórkowej, aby sprawdzić zachowanie wykrywania strefy czasowej telefonii komórkowej. Komórka testowa może być używana do symulowania sieci z różnymi MCK i wysyłania sygnałów NITZ do urządzeń, a następnie do monitorowania ich efektów.
Aby urządzenie mogło wykryć strefę czasową, informacje o sygnale NITZ muszą być prawidłowe, zgodne z MCC i pasować do kopii IANA TZDB (zasady strefy czasowej) na urządzeniu. Sygnały NITZ, które są niezgodne z kontem MCK, powodują, że algorytm telefoniczny staje się niepewny.
Jeśli np. konto MCC używane przez komórkę testową znajduje się w Stanach Zjednoczonych, sygnał NITZ musi zawierać informacje o „czasie uniwersalnym” i o zmianie czasu na czas letni, które są prawidłowe dla jakiegoś miejsca w Stanach Zjednoczonych.
Interakcja z usługą com.android.phone
Aby sprawdzić, czy urządzenie otrzymuje prawidłowe sugestie stref czasowych, wykonaj jedną z tych czynności:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Wyświetla informacje o telefonii, które można też znaleźć w raportach o błędach Androida. Na urządzeniach z wieloma kartami SIM dostępne są informacje o każdym radio na karcie SIM.
W sekcji Dzienniki strefy czasowej znajdziesz sugestie, które zostały wysłane przez proces telefoniczny do detektora strefy czasowej, oraz przyczyny ich wysłania.
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")]}