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 telefonii automatyczne wykrywanie strefy czasowej w Androidzie 11 lub starszym jest ograniczone do urządzeń telefonicznych.
Gdy wykrywanie strefy czasowej w telefonii jest dostępne, działa ono 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, sama usługa MCC nie wystarczy 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 telefonów 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 na podstawie sygnałów NITZ w zimie, ale można to zrobić w innych porach roku. Ten problem może wystąpić w dowolnej lokalizacji z podobnie nakładającymi się strefami czasowymi.
W tabeli poniżej znajdziesz informacje o sposobie działania urządzenia w zależności od pory roku w przypadku 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, brak 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, brak 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 Summer |
Czas: 1 lipca 2021 r., 12:00:00 Kraj: Stany Zjednoczone Odchylenie: UTC-7, bez czasu letniego |
Jeden identyfikator strefy pasuje:
Urządzenie jest prawidłowo skonfigurowane na America/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 dają w zimie ten sam czas lokalny.
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 na „UTC-7, bez czasu letniego”). Może to jednak 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.
Konfiguracja ś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 służyć do symulowania sieci z różnymi kontami MCC i do wysyłania sygnałów NITZ do urządzeń, a następnie do monitorowania ich wpływu.
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.TelephonyDebugServiceWyświetla informacje o telefonii, które można też znaleźć w raportach o błędach Androida. Na urządzeniach z większą liczbą kart SIM są informacje o każdym radiu SIM.
Dzienniki strefy czasowej zawierają sugestie wysłane przez proces telefonii do time_zone_detector oraz powody wysłania tych 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")]}