Na urządzeniach z Androidem 11 lub starszym automatyczne wykrywanie strefy czasowej AOSP wykorzystuje sygnały z podsystemu telefonicznego. Ze względu na zależność w podsystemie telefonicznym, automatyczne wykrywanie strefy czasowej na Androidzie 11 lub starszym jest ograniczona do urządzeń telefonicznych.
Jeśli wykrywanie strefy czasowej telefonu jest dostępne, działa ono przy użyciu Kod kraju urządzenia mobilnego (MCK) oraz Tożsamość sieci i strefa czasowa (NITZ) sygnałów.
Na przykład urządzenie we Francji może określić strefę czasową tylko na podstawie MCK zgłaszane przez pobliskie stacje bazowe. To możliwe, ponieważ Francja jest znana użyć jednej strefy czasowej.
Jeśli w danym kraju obowiązuje kilka stref czasowych, samo konto MCK nie wystarczy, strefę czasową. W tych krajach urządzenie wykorzystuje też sygnały NITZ do: poprawne ustawienie strefy czasowej. Ten system sprawdza się w wielu miejscach na świecie Wymaga to jednak, aby sygnały NITZ były zarówno dostępne, jak i prawidłowe, w związku z tym zależą od operatorów.
Wykrywanie strefy czasowej w telefonach jest pasywnym detektorem. Działa cały czas,
dlatego sugestie dotyczące połączeń telefonicznych są często generowane, nawet jeśli
Algorytm time_zone_detector nie obsługuje obecnie połączeń telefonicznych.
Ograniczenie wykrywania strefy czasowej w telefonach
Nawet jeśli dostępne są prawidłowe sygnały NITZ, wykrywanie strefy czasowej w telefonii nie jest możliwe w każdym kraju. Dzieje się tak, ponieważ NITZ zawiera tylko przesunięcie i zmiany czasu na letni lub zimowy, które nie zawsze wystarczają do jednoznacznego określenia strefie czasowej.
Ten problem ze strefą czasową może występować w wielu miejscach na świecie. Na przykład Denver Colorado i Phoenix w stanie Arizona w USA nie mogą być do rozróżniania na podstawie sygnałów NITZ zimą, ale można je też stosować w innych porach roku. W lokalizacjach z podobnie nakładającymi się strefami czasowymi może występować ten rodzaj Google Cloud.
W tabeli poniżej znajdziesz zestawienie zachowań urządzeń w zależności od pory roku. dla Denver i Phoenix.
| Lokalizacja i pora roku | Informacje z MCK lub NITZ | Wykryta strefa czasowa i zachowanie |
|---|---|---|
| Denver, Kolorado Zima |
Godzina: 1 stycznia 2021 r., godz. 12:00:00 Kraj: US Przesunięcie: UTC-7, bez zmiany czasu |
Pasujące identyfikatory 2 stref:
Urządzenie jest prawidłowo ustawione na Ameryka/Denver. |
| Phoenix, Arizona Zima |
Godzina: 1 stycznia 2021 r., godz. 12:00:00 Kraj: US Przesunięcie: UTC-7, bez zmiany czasu |
Pasujące identyfikatory 2 stref:
Urządzenie jest nieprawidłowo ustawione na Ameryka/Denver. |
| Denver, Kolorado Lato |
Godzina: 1 lipca 2021 r., godz. 12:00:00 Kraj: US Przesunięcie: UTC-6, czas letni |
Jeden identyfikator strefy pasuje do:
Urządzenie jest prawidłowo ustawione na Ameryka/Denver. |
| Phoenix, Arizona Lato |
Godzina: 1 lipca 2021 r., godz. 12:00:00 Kraj: US Przesunięcie: UTC-7, bez zmiany czasu |
Jeden identyfikator strefy pasuje do:
Urządzenie jest prawidłowo ustawione na America/Phoenix. |
Powyższe przykłady pokazują, że zimą urządzenia z Androidem w Denver i Arizona musi 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 będzie wyświetlać prawdopodobnie prawidłowy czas lokalny. Urządzenie zegar, kalendarze i inne aplikacje wyświetlają oczekiwany czas lokalny, nawet jeśli identyfikator strefy czasowej jest nieprawidłowy, ponieważ oba identyfikatory stref czasowych wyliczają tę samą lokalną wartość podczas zimy.
Jednak wiosną, gdy w Denver występuje czas letni, a w Phoenix nie. Niektóre urządzenia mogą tymczasowo wyświetlać nieprawidłowy czas lokalny, jeśli są ustawiony. z nieprawidłowym identyfikatorem strefy czasowej dla lokalizacji użytkownika. Poprawimy to jak najszybciej gdy urządzenie odbiera nowy sygnał NITZ (konkretnie „UTC-7, bez zmiany czasu” informacje o przesunięciu), ale może to zająć trochę czasu i zależy od operatorów.
W związku z tym kalendarze lub inne aplikacje, które przechowują lub przenoszą identyfikator strefy czasowej okres od zimy do wiosny może być wyświetlany z nieprawidłowym czasem lokalnym do odpowiednie aplikacje aktualizują identyfikator strefy czasowej.
Debugowanie i testowanie
W tej sekcji opisano polecenia powłoki służące do debugowania i testowania funkcji wykrywania strefy czasowej w telefonach.
Konfiguracja środowiska testowego
Testerzy zwykle używają środowiska testowego z testową lub symulowaną siecią telefoniczną. aby sprawdzić działanie wykrywania strefy czasowej w telefonach. Komórka testowa może być używana do: symulować sieci z różnymi MCK oraz wysyłać sygnały NITZ do urządzeń a potem monitorować ich efekty.
Aby urządzenie mogło wykryć strefę czasową, informacje o sygnale NITZ muszą być prawidłowe, zgodne z MCK i zgodne z kopią urządzenia w IANA TZDB. (reguły strefy czasowej). Sygnały NITZ, które są niezgodne z MCK, powodują algorytmu telefonii, aby nie był pewny.
Jeśli na przykład MCK używane przez komórkę testową dotyczy Stanów Zjednoczonych, sygnał NITZ musi zawierać „czas uniwersalny”, informacje o przesunięciu i zmiany czasu letniego, które jest właściwe dla lokalizacji w USA.
Korzystanie z usługi com.android.phone
Aby sprawdzić, czy urządzenie otrzymuje prawidłowe sugestie dotyczące strefy czasowej telefonii, użyj:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Powoduje to zapisywanie informacji o telefonach, które można również znaleźć w artykule o błędzie z Androidem. raportów. 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, do których zostały wysłane połączenia telefoniczne. time_zone_detector i 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")]}