Bei Geräten mit Android 11 oder niedriger basiert die automatische Zeitzonenerkennung im AOSP auf Signalen des Telefonsubsystems. Aufgrund der Abhängigkeit vom Telefonie-Subsystem ist die automatische Zeitzonenerkennung unter Android 11 oder niedriger auf Telefoniegeräte beschränkt.
Wenn die Zeitzonenerkennung für die Telefonie verfügbar ist, funktioniert sie mit den Signalen Mobile Country Code (MCC) und Network Identity and Time Zone (NITZ).
Beispielsweise kann ein Gerät in Frankreich die Zeitzone nur anhand des von nahe gelegenen Mobilfunkmasten gemeldeten Kundencenters identifizieren. Das ist möglich, da Frankreich bekanntlich nur eine Zeitzone hat.
Wenn in einem Land mehrere Zeitzonen verwendet werden, reicht das Kundencenter alleine nicht aus, um die Zeitzone zu ermitteln. Für diese Länder 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 ist es vom Mobilfunkanbieter abhängig.
Die Zeitzonenerkennung für die Telefonie ist ein passiver Detektor. Er läuft immer und daher werden Telefonievorschläge oft auch dann gemacht, wenn der aktive time_zone_detector
-Algorithmus derzeit nicht für Telefonie zuständig ist.
Einschränkung der Zeitzonenerkennung für Telefonie
Selbst wenn korrekte NITZ-Signale verfügbar sind, funktioniert die Erkennung der Telefoniezeitzone nicht immer in jedem Land. Das liegt daran, dass NITZ nur Informationen zur Offset- und Sommerzeit enthält, die nicht immer ausreichen, um eine Zeitzone eindeutig zu identifizieren.
An vielen Orten auf der Welt kann dieses Zeitzonenproblem auftreten. Denver Colorado und Phoenix Arizona in den USA können beispielsweise im Winter nicht anhand von NITZ-Signalen unterschieden werden, in anderen Saisons jedoch. Bei jedem Ort mit ähnlich überlappenden Zeitzonen kann dieses Problem auftreten.
In der folgenden Tabelle wird das Geräteverhalten je nach Jahreszeit für Denver und Phoenix aufgeschlüsselt:
Standort und Saison | Informationen von MCC oder NITZ | Erkannte Zeitzone und erkanntes Verhalten |
---|---|---|
Denver, Colorado Winter |
Uhrzeit: 1. Januar 2021, 12:00:00 Land: USA Offset: UTC-7, keine Sommerzeit |
Zwei Zonen-IDs stimmen überein:
Das Gerät ist richtig auf „Amerika/Denver“ eingestellt. |
Phoenix, Arizona Winter |
Zeit: 1. Januar 2021, 12:00:00 Land: USA Zeitzonendifferenz: UTC-7, keine Sommerzeit |
Zwei Zonen-IDs stimmen überein:
Das Gerät ist falsch auf „Amerika/Denver“ eingestellt. |
Denver, Colorado Sommer |
Zeit: 1. Juli 2021, 12:00:00 Land: USA Zeitzonendifferenz: UTC-6, Sommerzeit |
Eine Zonen-ID stimmt überein mit:
Das Gerät ist richtig auf „Amerika/Denver“ eingestellt. |
Phoenix, Arizona Sommer |
Zeit: 1. Juli 2021, 12:00:00 Land: USA Zeitzonendifferenz: UTC-7, keine Sommerzeit |
Eine Zonen-ID stimmt überein:
Das Gerät ist richtig auf „Amerika/Phoenix“ eingestellt. |
Die Beispiele oben zeigen, dass Android-Geräte in Denver oder Arizona im Winter eine von zwei übereinstimmenden Zeitzonen-IDs auswählen müssen, die für einige Geräte möglicherweise falsch sind, aber trotzdem eine scheinbar korrekte Ortszeit anzeigen. Die Uhr des Geräts, der Kalender und andere Apps zeigen die erwartete Ortszeit an, auch wenn die Zeitzonen-ID falsch ist, da beide Zeitzonen-IDs im Winter dieselbe Ortszeit berechnen.
Im Frühjahr, wenn in Denver die Sommerzeit gilt, in Phoenix aber nicht, wird auf einigen Geräten möglicherweise vorübergehend die falsche Ortszeit angezeigt, wenn sie auf die falsche Zeitzonen-ID für den Standort des Nutzers eingestellt sind. Dies wird korrigiert, sobald das Gerät ein neues NITZ-Signal empfängt (insbesondere eines, das die Zeitabweichung „UTC-7, keine Sommerzeit“ enthält). Das kann jedoch einige Zeit dauern und ist vom Mobilfunkanbieter abhängig.
Daher wird in Kalendern oder anderen Apps, die die Zeitzonen-ID vom Winter zum Frühling speichern oder übernehmen, möglicherweise die falsche Ortszeit angezeigt und verwendet, bis die entsprechenden Apps die Zeitzonen-ID aktualisieren.
Fehlerbehebung und Tests
Im folgenden Abschnitt werden Shell-Befehle zum Debuggen und Testen der Funktion zur Zeitzonenerkennung für die Telefonie beschrieben.
Testumgebung einrichten
Tester verwenden in der Regel eine Testumgebung mit einer Test- oder simulierten Telefonzelle, um das Verhalten der Zeitzonenerkennung für Telefonie zu prüfen. Mit der Testzelle können Netzwerke mit verschiedenen Zeitzonen simuliert, NITZ-Signale an Geräte gesendet und die Auswirkungen dann 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 zu Unsicherheiten beim Telefoniealgorithmus.
Wenn das von der Testzelle verwendete MCC beispielsweise für die USA gilt, muss das NITZ-Signal eine „Universalzeit“, einen Zeitunterschied 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 die richtigen Zeitzonenvorschläge für die Telefonie erhält:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Dadurch werden Informationen zur Telefonie ausgegeben, die auch in Android-Fehlerberichten zu finden sind. Auf Geräten mit mehreren SIM-Karten gibt es Informationen für jedes SIM-Funkschnittstellenmodul.
Die Zeitzonenprotokolle enthalten die Vorschläge, die der Telefonieprozess an den time_zone_detector gesendet hat, und 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")]}