Bei Geräten mit Android 11 oder niedriger basiert die automatische Zeitzonenerkennung im AOSP auf Signalen des Telefoniesubsystems. Da die automatische Zeitzonenerkennung von Android 11 oder niedriger vom Telefoniesubsystem abhängig ist, ist sie auf Telefoniegeräte beschränkt.
Wenn die Zeitzonenerkennung für die Telefonie verfügbar ist, funktioniert sie mithilfe des Mobile Country Code (MCC) und der Network Identity and Time Zone (NITZ)-Signale.
Ein Gerät in Belgien kann die Zeitzone beispielsweise nur anhand des MCC ermitteln, der von nahegelegenen Mobilfunkmasten gemeldet wird. Das ist möglich, da in Belgien nur eine Zeitzone verwendet wird.
Wenn in einem Land mehrere Zeitzonen verwendet werden, reicht der MCC allein nicht aus, um die Zeitzone zu ermitteln. In diesen Ländern verwendet das Gerät auch NITZ-Signale, um die richtige Zeitzone zu ermitteln. Das funktioniert an vielen Orten auf der Welt gut, erfordert aber, dass NITZ-Signale sowohl verfügbar als auch korrekt sind. Daher hängt es von den Mobilfunkanbietern ab.
Die Zeitzonenerkennung für Telefonie ist ein passiver Detektor. Er wird jederzeit ausgeführt. Daher werden oft Telefonievorschläge gemacht, auch wenn der aktive time_zone_detector
-Algorithmus gerade nicht für Telefonie verwendet wird.
Einschränkung der Zeitzonenerkennung bei Telefonie
Auch wenn korrekte NITZ-Signale verfügbar sind, funktioniert die Zeitzonenerkennung für die Telefonie nicht immer in allen Ländern. Das liegt daran, dass NITZ nur Informationen zu Zeitzonenverschiebung und Sommerzeit enthält, die nicht immer ausreichen, um eine Zeitzone eindeutig zu identifizieren.
Dieses Zeitzonenproblem kann an vielen Orten der Welt auftreten. Beispielsweise können Denver, Colorado, und Phoenix, Arizona, in den USA im Winter nicht anhand von NITZ-Signalen unterschieden werden, in anderen Jahreszeiten aber schon. Dieses Problem kann an jedem Ort mit ähnlich überlappenden Zeitzonen auftreten.
In der folgenden Tabelle wird das Geräteverhalten je nach Jahreszeit für Denver und Phoenix als Beispiel aufgeschlüsselt:
Ort und Jahreszeit | Informationen von MCC oder NITZ | Erkannte Zeitzone und Verhalten |
---|---|---|
Denver, Colorado Winter |
Zeit: 1. Januar 2021, 12:00:00 Land: USA Zeitzonenabweichung: UTC-7, keine Sommerzeit |
Zwei Zonen-IDs stimmen überein:
Das Gerät ist korrekt auf „America/Denver“ eingestellt. |
Phoenix, Arizona Winter |
Zeit: 1. Januar 2021, 12:00:00 Land: USA Zeitzonenabweichung: UTC-7, keine Sommerzeit |
Zwei Zonen-IDs stimmen überein:
Das Gerät ist falsch auf „America/Denver“ eingestellt. |
Denver, Colorado Sommer |
Zeit: 1. Juli 2021, 12:00:00 Land: USA Zeitzonenabweichung: UTC-6, Sommerzeit |
Eine Zonen-ID stimmt überein:
Das Gerät ist korrekt auf „America/Denver“ eingestellt. |
Phoenix, Arizona Sommer |
Zeit: 1. Juli 2021, 12:00:00 Land: USA Zeitzonenabweichung: UTC-7, keine Sommerzeit |
Eine Zonen-ID stimmt überein:
Das Gerät ist richtig auf „America/Phoenix“ eingestellt. |
Die Beispiele in der Tabelle zeigen, dass Android-Geräte in Denver oder Arizona im Winter eine von zwei passenden Zeitzonen-IDs auswählen müssen. Diese ist möglicherweise für einige Geräte falsch, zeigt aber trotzdem eine scheinbar korrekte Ortszeit an. Auf dem Gerät werden die Uhrzeit, Kalender und andere Apps in der erwarteten Ortszeit angezeigt, auch wenn die Zeitzonen-ID falsch ist, da für beide Zeitzonen-IDs im Winter dieselbe Ortszeit berechnet wird.
Im Frühjahr, wenn in Denver die Sommerzeit gilt und in Phoenix nicht, kann es jedoch vorkommen, dass auf einigen Geräten vorübergehend die falsche Ortszeit angezeigt wird, wenn sie auf die falsche Zeitzonen-ID für den Standort des Nutzers eingestellt sind. Das wird korrigiert, sobald das Gerät ein neues NITZ-Signal empfängt, das die Offsetinformationen „UTC-7, keine Sommerzeit“ enthält. Das kann jedoch einige Zeit dauern und hängt vom Mobilfunkanbieter ab.
Daher kann es sein, dass in Kalendern oder anderen Apps, in denen die Zeitzonen-ID vom Winter in den Frühling übernommen wird, bis zur Aktualisierung der Zeitzonen-ID in den entsprechenden Apps die falsche Ortszeit angezeigt und verwendet wird.
Debugging und Tests
Im folgenden Abschnitt werden Shell-Befehle zum Debuggen und Testen der Funktion zur Erkennung der Zeitzone für Telefonie beschrieben.
Testumgebung einrichten
Tester verwenden in der Regel eine Testumgebung mit einer Test- oder simulierten Telefoniezelle, um das Verhalten bei der Erkennung der Telefonie-Zeitzone zu prüfen. Mit der Testzelle können Netzwerke mit unterschiedlichen MCCs simuliert und NITZ-Signale an Geräte gesendet werden. Anschließend können die Auswirkungen beobachtet werden.
Damit das Gerät die Zeitzone erkennen kann, müssen die NITZ-Signalinformationen korrekt sein, mit dem MCC übereinstimmen und mit der Kopie der IANA TZDB (Zeitzonenregeln) des Geräts übereinstimmen. NITZ-Signale, die nicht mit dem MCC übereinstimmen, führen dazu, dass der Telefoniealgorithmus unsicher wird.
Wenn der vom Test-Cell verwendete MCC beispielsweise für die USA gilt, muss das NITZ-Signal eine UTC, eine Zeitverschiebung und Informationen zur Sommerzeit enthalten, die für einen Ort in den USA korrekt sind.
Mit dem Dienst „com.android.phone“ interagieren
So prüfen Sie, ob das Gerät korrekte Vorschläge für die Telefoniezeitzone erhält:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Dadurch werden Telefonieinformationen ausgegeben, die auch in Android-Fehlerberichten zu finden sind. Auf Geräten mit mehreren SIM-Karten sind Informationen für jedes SIM-Funkmodul verfügbar.
Die Zeitzonen-Logs enthalten die Vorschläge, die der Telefonieprozess an den time_zone_detector gesendet hat, sowie die Gründe für das Senden der Vorschläge.
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")]}