Zeitzonenerkennung für Telefonie

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:
  • Amerika/Denver
  • Amerika/Phoenix

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:
  • Amerika/Denver
  • Amerika/Phoenix

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:
  • Amerika/Denver

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:
  • Amerika/Phoenix

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")]}