Bei Geräten mit Android 11 oder niedriger basiert die automatische Zeitzonenerkennung im AOSP auf Signalen vom Telefonie-Subsystem. 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, verwendet sie die Signale Mobile Country Code (MCC) und Network Identity and Time Zone (NITZ) .
Beispielsweise kann ein Gerät in Frankreich die Zeitzone ausschließlich anhand des MCC ermitteln, das von nahegelegenen Mobilfunkmasten gemeldet wird. Dies ist möglich, da Frankreich bekanntermaßen eine einzige Zeitzone verwendet.
Wenn ein Land mehrere Zeitzonen verwendet, reicht das MCC allein nicht aus, um die Zeitzone zu identifizieren. Für diese Länder nutzt das Gerät zusätzlich NITZ-Signale, um die richtige Zeitzone zu ermitteln. Dies funktioniert an vielen Orten auf der Welt gut, erfordert jedoch, dass NITZ-Signale verfügbar und korrekt sind, und ist daher von den Netzbetreibern abhängig.
Bei der Telefon-Zeitzonenerkennung handelt es sich um einen passiven Detektor. Es läuft jederzeit und daher werden Telefonvorschläge häufig auch dann gemacht, wenn der aktive time_zone_detector -Algorithmus derzeit nicht Telefonie ist.
Einschränkung der Telefon-Zeitzonenerkennung
Auch wenn korrekte NITZ-Signale verfügbar sind, funktioniert die Zeitzonenerkennung bei der Telefonie nicht in jedem Land einwandfrei. Dies liegt daran, dass NITZ nur Offset- und Sommerzeitinformationen enthält, die nicht immer ausreichen, um eine Zeitzone eindeutig zu identifizieren.
Es gibt viele Orte auf der Welt, an denen dieses Zeitzonenproblem auftreten kann. Beispielsweise können Denver, Colorado und Phoenix, Arizona in den USA im Winter nicht mithilfe von NITZ-Signalen unterschieden werden, in anderen Jahreszeiten jedoch schon. An jedem Ort mit ähnlich überlappenden Zeitzonen kann dieses Problem auftreten.
Die folgende Tabelle schlüsselt das Geräteverhalten je nach Jahreszeit beispielhaft für Denver und Phoenix auf:
| Standort und Jahreszeit | Informationen von MCC oder NITZ | Erkannte Zeitzone und Verhalten |
|---|---|---|
| Denver, Colorado Winter | Zeit: 1. Januar 2021 12:00:00 Land: USA Offset: UTC-7, keine Sommerzeit | Zwei Zonen-IDs stimmen überein:
Das Gerät ist korrekt auf Amerika/Denver eingestellt. |
| Phoenix, Arizona Winter | Zeit: 1. Januar 2021 12:00:00 Land: USA Offset: UTC-7, keine Sommerzeit | Zwei Zonen-IDs stimmen überein:
Das Gerät ist fälschlicherweise auf Amerika/Denver eingestellt. |
| Denver, Colorado Sommer | Zeit: 1. Juli 2021 12:00:00 Land: USA Offset: UTC-6, Sommerzeit | Eine Zonen-ID stimmt überein:
Das Gerät ist korrekt auf Amerika/Denver eingestellt. |
| Phoenix, Arizona Sommer | Zeit: 1. Juli 2021 12:00:00 Land: USA Offset: UTC-7, keine Sommerzeit | Eine Zonen-ID stimmt überein:
Das Gerät ist korrekt auf Amerika/Phoenix eingestellt. |
Die obigen Beispiele zeigen, dass Android-Geräte in Denver oder Arizona im Winter eine von zwei übereinstimmenden Zeitzonen-IDs wählen müssen, was für einige Geräte möglicherweise falsch ist, aber dennoch eine scheinbar korrekte Ortszeit anzeigt. Die Geräteuhr, 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.
Wenn jedoch im Frühjahr in Denver Sommerzeit gilt und in Phoenix nicht, zeigen einige Geräte möglicherweise vorübergehend die falsche Ortszeit an, wenn sie auf die falsche Zeitzonen-ID für den Standort des Benutzers eingestellt sind. Dies wird korrigiert, sobald das Gerät ein neues NITZ-Signal empfängt (insbesondere eines, das die Offset-Informationen „UTC-7, keine Sommerzeit“ enthält). Dies kann jedoch einige Zeit dauern und hängt vom Mobilfunkanbieter ab.
Daher kann es sein, dass Kalender oder andere Apps, die die Zeitzonen-ID vom Winter auf den Frühling speichern oder übertragen, die falsche Ortszeit anzeigen und verwenden, bis die entsprechenden Apps die Zeitzonen-ID aktualisieren.
Debuggen und Testen
Im folgenden Abschnitt werden Shell-Befehle zum Debuggen und Testen der Telefonie-Zeitzonenerkennungsfunktion beschrieben.
Einrichtung der Testumgebung
Tester verwenden in der Regel eine Testumgebung mit einer Test- oder simulierten Telefonzelle, um das Erkennungsverhalten der Telefonzeitzone zu überprüfen. Mit der Testzelle können Netzwerke mit unterschiedlichen MCCs simuliert und NITZ-Signale an Geräte gesendet und deren Auswirkungen anschließend überwacht 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 Telefonalgorithmus unsicher wird.
Wenn beispielsweise der von der Testzelle verwendete MCC für die USA bestimmt ist, muss das NITZ-Signal eine „Weltzeit“, einen Offset und Informationen zur Sommerzeit enthalten, die für irgendwo in den USA korrekt sind.
Interaktion mit dem Dienst com.android.phone
Um zu überprüfen, ob das Gerät korrekte Zeitzonenvorschläge für die Telefonie empfängt, verwenden Sie Folgendes:
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 SIMs gibt es Informationen für jedes SIM-Radio.
Die Zeitzonenprotokolle zeigen 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")]}