Zeitzonenerkennung für Telefonie

Bei Geräten mit Android 11 oder niedriger wird die automatische Zeitzonenerkennung in der AOSP stützt sich auf Signale vom Telefoniesubsystem. Aufgrund der Abhängigkeit auf dem Telefoniesubsystem, automatische Zeitzonenerkennung unter Android 11 oder niedriger auf Telefoniegeräte beschränkt.

Wenn die Erkennung der Telefonie-Zeitzone verfügbar ist, funktioniert sie mit dem Ländercode für Mobilgeräte (Kundencenter) und Netzwerkidentität und -zeitzone (NITZ) Signale.

Beispielsweise kann ein Gerät in Frankreich die Zeitzone nur anhand des Kundencenter-Konto von Mobilfunkmasten in der Nähe gemeldet Das ist möglich, weil Frankreich bekannt ist, eine einzige Zeitzone verwenden.

Wenn in einem Land mehrere Zeitzonen verwendet werden, reicht das Kundencenter alleine nicht aus, um in der Zeitzone. In diesen Ländern nutzt das Gerät auch NITZ-Signale, um um die richtige Zeitzone zu ermitteln. Das funktioniert an vielen Orten auf der ganzen Welt gut. NITZ-Signale müssen verfügbar und korrekt sein daher von Mobilfunkanbietern abhängig.

Die Zeitzonenerkennung für Telefonie ist ein passiver Detektor. Sie läuft zu jeder Zeit und Daher werden Telefonievorschläge häufig gemacht, selbst wenn die aktive Der time_zone_detector-Algorithmus ist derzeit keine Telefonie.

Einschränkung der Erkennung der Telefonie-Zeitzone

Auch wenn korrekte NITZ-Signale verfügbar sind, wird bei der Erkennung der Telefoniezeitzone in jedem Land gut funktionieren. Das liegt daran, dass NITZ nur Offset und Sommerzeit angeben, die nicht immer ausreichen, um ein Zeitzone.

Es gibt viele Orte auf der Welt, an denen dieses Zeitzonenproblem auftreten könnte. Beispielsweise können Denver Colorado und Phoenix Arizona in den USA nicht mithilfe von NITZ-Signalen während des Winters, während dies zu anderen Jahreszeiten möglich ist. An Orten mit ähnlich überlappenden Zeitzonen kann diese Art von Problemen auftreten. Problem.

In der folgenden Tabelle ist das Geräteverhalten je nach Jahreszeit aufgeschlüsselt: für Denver und Phoenix:

Standort und Saison Informationen aus dem Kundencenter oder der NITZ Erkannte Zeitzone und erkanntes Verhalten
Denver, Colorado
Winterzeit
Uhrzeit: 1. Januar 2021, 12:00:00
Land: USA
Zeitverschiebung: UTC-7, keine Sommerzeit
Zwei Zonen-IDs stimmen überein:
<ph type="x-smartling-placeholder">
    </ph>
  • Amerika/Denver
  • Amerika/Phoenix

Das Gerät ist richtig auf „Amerika/Denver“ eingestellt.
Phoenix, Arizona
Winterzeit
Uhrzeit: 1. Januar 2021, 12:00:00
Land: USA
Zeitverschiebung: UTC-7, keine Sommerzeit
Zwei Zonen-IDs stimmen überein:
<ph type="x-smartling-placeholder">
    </ph>
  • Amerika/Denver
  • Amerika/Phoenix

Das Gerät ist fälschlicherweise auf „Amerika/Denver“ eingestellt.
Denver, Colorado
Sommer
Uhrzeit: 1. Juli 2021, 12:00:00
Land: USA
Zeitverschiebung: UTC-6, Sommerzeit
Eine Zonen-ID stimmt überein:
<ph type="x-smartling-placeholder">
    </ph>
  • Amerika/Denver

Das Gerät ist richtig auf „Amerika/Denver“ eingestellt.
Phoenix, Arizona
Sommer
Uhrzeit: 1. Juli 2021, 12:00:00
Land: USA
Zeitverschiebung: UTC-7, keine Sommerzeit
Eine Zonen-ID stimmt überein:
<ph type="x-smartling-placeholder">
    </ph>
  • Amerika/Phoenix

Das Gerät ist richtig auf „Amerika/Phoenix“ eingestellt.

Die Beispiele oben zeigen, dass im Winter Android-Geräte in Denver und Arizona muss eine von zwei übereinstimmenden Zeitzonen-IDs auswählen. Diese ist möglicherweise falsch. für einige Geräte, zeigt aber dennoch eine scheinbar korrekte Ortszeit an. Das Gerät Uhr, Kalender und andere Apps die erwartete Ortszeit anzeigen, auch wenn das Die Zeitzonen-ID ist falsch, da beide Zeitzonen-IDs denselben lokalen Wert berechnen im Winter zu einem Erlebnis.

Im Frühling, wenn Denver jedoch die Sommerzeit gilt, in Phoenix nicht, kann es vorkommen, dass auf einigen Geräten vorübergehend die falsche Ortszeit angezeigt wird, die falsche Zeitzonen-ID für den Standort des Nutzers verwenden. Dies wird so schnell wie möglich korrigiert. da das Gerät ein neues NITZ-Signal empfängt (insbesondere eines, das „UTC-7, keine Sommerzeit“ Informationen zum Versatz) Je nach Mobilfunkanbieter kann dies jedoch einige Zeit dauern.

Daher können Kalender oder andere Apps die Zeitzonen-ID speichern oder übertragen. zwischen Winter und Frühling wird möglicherweise die falsche Ortszeit angezeigt, wird die Zeitzonen-ID aktualisiert.

Fehlerbehebung und Tests

Im folgenden Abschnitt werden Shell-Befehle zum Debugging und Testen der die Erkennung der Zeitzone für Telefonie.

Einrichtung der Testumgebung

Tester verwenden normalerweise eine Testumgebung mit einer Test- oder simulierten Telefoniezelle um das Verhalten bei der Erkennung der Zeitzonen in der Telefonie zu prüfen. Mit der Testzelle können Sie Netzwerke mit verschiedenen Kundencentern simulieren und NITZ-Signale an Geräte und und deren Auswirkungen überwachen.

Damit das Gerät die Zeitzone erkennt, müssen die NITZ-Signalinformationen korrekt und mit dem Kundencenter übereinstimmen und mit der Gerätekopie der IANA TZDB übereinstimmen. (Zeitzonenregeln). NITZ-Signale, die nicht mit dem Kundencenter übereinstimmen, führen zu Telefoniealgorithmus ungewiss zu werden.

Wenn das von der Testzelle verwendete Kundencenter beispielsweise für die USA bestimmt ist, wird das NITZ-Signal muss Informationen zur Weltzeit (Universal Time), Offset (Versatz) und Sommerzeit (Sommerzeit) enthalten, irgendwo in den USA korrekt ist.

Mit dem Dienst com.android.phone interagieren

So überprüfen Sie, ob das Gerät die richtigen Vorschläge für die Telefoniezeitzone erhält: verwenden:

adb shell dumpsys activity service \
    com.android.phone/com.android.phone.TelephonyDebugService

Dadurch werden Telefonieinformationen gelöscht, die auch im Android-Programmfehler enthalten sind. Berichte. Auf Geräten mit mehreren SIM-Karten werden Informationen zu den einzelnen SIM-Karten angezeigt.

Die Zeitzonenprotokolle enthalten die Vorschläge, an die der Telefonieprozess gesendet wurde. die Zeitzone 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")]}