Détection du fuseau horaire de la téléphonie

Pour les appareils équipés d'Android 11 ou version antérieure, détection automatique du fuseau horaire dans le AOSP s'appuie sur les signaux du sous-système de téléphonie. En raison de la dépendance sur le sous-système téléphonique, la détection automatique du fuseau horaire sur Android 11 ou version antérieure ; est limité aux appareils de téléphonie.

Lorsque la détection du fuseau horaire téléphonique est disponible, elle utilise Mobile Country Code (MCC) (Code pays pour mobile) et Identité et fuseau horaire du réseau (NITZ) signaux.

Par exemple, un appareil en France ne peut identifier le fuseau horaire qu'en se basant sur CM signalés par les antennes-relais à proximité. C'est possible parce que la France est connue pour utiliser un seul fuseau horaire.

Lorsqu'un pays utilise plusieurs fuseaux horaires, le CM seul ne suffit pas à identifier le fuseau horaire. Dans ces pays, l'appareil utilise aussi des signaux NITZ pour identifier le bon fuseau horaire. Cette méthode fonctionne bien dans de nombreuses régions du monde. mais il exige que les signaux NITZ soient disponibles et corrects, et dépendent donc des opérateurs.

La détection du fuseau horaire téléphonique est un détecteur passif. Il fonctionne en permanence et Ainsi, les suggestions d'appels téléphoniques sont souvent envoyées, même lorsque le L'algorithme time_zone_detector n'est pas un service de téléphonie actuellement.

Limitation de la détection du fuseau horaire des services de téléphonie

Même si les signaux NITZ sont corrects, la détection du fuseau horaire téléphonique fonctionne toujours bien dans tous les pays. En effet, NITZ ne contient qu’un décalage et des informations relatives à l'heure d'été, qui ne suffisent pas toujours à identifier de façon unique fuseau horaire.

Il existe de nombreux endroits dans le monde où ce problème de fuseau horaire peut se produire. Par exemple, Denver, Colorado et Phoenix en Arizona aux États-Unis ne peuvent pas est différencié à l'aide de signaux NITZ en hiver, mais peut être distingué pendant d'autres saisons. Ce type de problème peut survenir dans les lieux dont les fuseaux horaires se chevauchent de façon similaire. problème.

Le tableau suivant détaille le comportement des appareils en fonction de la saison. à Denver et à Phoenix, par exemple:

Lieu et saison Informations fournies par le CM ou le NITZ Fuseau horaire et comportement détectés
Denver, Colorado
Hiver
Heure: 1er janvier 2021 12:00:00
Pays: États-Unis
Décalage: UTC-7, sans heure d'été
Deux ID de zone correspondent:
<ph type="x-smartling-placeholder">
    </ph>
  • Amérique/Denver
  • Amérique/Phoenix

L'appareil est correctement défini sur Amérique/Denver.
Phoenix, Arizona
Hiver
Heure: 1er janvier 2021 12:00:00
Pays: États-Unis
Décalage: UTC-7, sans heure d'été
Deux ID de zone correspondent:
<ph type="x-smartling-placeholder">
    </ph>
  • Amérique/Denver
  • Amérique/Phoenix

L'appareil est défini de manière incorrecte sur l'Amérique/Denver.
Denver, Colorado
Été
Heure: 1er juillet 2021 12:00:00
Pays: États-Unis
Décalage: UTC-6, heure d'été
Un ID de zone correspond:
<ph type="x-smartling-placeholder">
    </ph>
  • Amérique/Denver

L'appareil est correctement défini sur Amérique/Denver.
Phoenix, Arizona
Été
Heure: 1er juillet 2021 12:00:00
Pays: États-Unis
Décalage: UTC-7, sans heure d'été
Un ID de zone correspond:
<ph type="x-smartling-placeholder">
    </ph>
  • Amérique/Phoenix

L'appareil est correctement réglé sur Amérique/Phoenix.

Les exemples ci-dessus montrent qu'en hiver, les appareils Android basés à Denver ou L'Arizona doit choisir l'un des deux ID de fuseau horaire correspondants, ce qui peut être incorrect pour certains appareils tout en affichant une heure locale apparemment correcte. L'appareil horloge, agendas et autres applications affichent l'heure locale prévue, même si le L'identifiant de fuseau horaire est incorrect, car les deux identifiants de fuseau horaire calculent la même valeur locale en hiver.

Cependant, au printemps, lorsque Denver passe à l'heure d'été et que Phoenix le fait. non, certains appareils peuvent temporairement afficher l'heure locale incorrecte s'ils sont définis est associé au mauvais identifiant de fuseau horaire pour l'emplacement de l'utilisateur. Ce problème est résolu dès que lorsque l'appareil reçoit un nouveau signal NITZ (plus précisément, un signal contenant "UTC-7, sans heure d'été" les informations de décalage), mais cela peut prendre du temps et dépend des opérateurs.

Par conséquent, les agendas ou autres applications qui stockent ou conservent l'identifiant de fuseau horaire de l'hiver au printemps peut s'afficher et utiliser la mauvaise heure locale jusqu'au les applications concernées mettent à jour l'identifiant du fuseau horaire.

Débogage et test

La section suivante décrit les commandes shell permettant de déboguer et de tester les la fonctionnalité de détection du fuseau horaire téléphonique.

Configuration de l'environnement de test

Les testeurs utilisent généralement un environnement de test avec une cellule de téléphonie de test ou simulée pour vérifier le comportement de la détection du fuseau horaire téléphonique. La cellule de test peut être utilisée pour simuler des réseaux avec différents CM et envoyer des signaux NITZ aux appareils et puis surveiller leurs effets.

Pour que l'appareil détecte le fuseau horaire, les informations du signal NITZ doivent être correct, cohérent avec le CM, et doit correspondre à la copie du document TZDB de l'IANA sur l'appareil. (règles de fuseau horaire). Les signaux NITZ incohérents avec le CM provoquent de l'algorithme de téléphonie de manière incertaine.

Par exemple, si le MCC utilisé par la cellule de test est destiné aux États-Unis, le signal NITZ doit contenir une information "heure universelle", de décalage et d'heure d'été qui est correct pour quelque part aux États-Unis.

Interagir avec le service com.android.phone

Pour vérifier que l'appareil reçoit des suggestions de fuseau horaire de téléphonie correctes, procédez comme suit : utiliser:

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

Les informations de téléphonie, également disponibles dans le bug Android, sont supprimées rapports. Sur les appareils dotés de plusieurs cartes SIM, vous trouverez des informations sur chaque radio SIM.

Les journaux de fuseau horaire affichent les suggestions envoyées par le processus téléphonique. time_zone_detector et les raisons d'envoi des suggestions.

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