Pour les appareils équipés d'Android 11 ou version antérieure, la détection automatique du fuseau horaire dans l'AOSP s'appuie sur les signaux du sous-système de téléphonie. En raison de la dépendance au sous-système de téléphonie, la détection automatique du fuseau horaire sur Android 11 ou version antérieure est limitée aux appareils de téléphonie.
Lorsque la détection du fuseau horaire de téléphonie est disponible, elle fonctionne à l'aide des signaux Mobile Country Code (MCC) et Network Identity and Time Zone (NITZ).
Par exemple, un appareil en France peut identifier le fuseau horaire uniquement en fonction du MCC signalé par les tours de téléphonie mobile à proximité. Cela est possible, car la France n'utilise qu'un seul fuseau horaire.
Lorsqu'un pays utilise plusieurs fuseaux horaires, le MCC seul ne suffit pas à identifier le fuseau horaire. Pour ces pays, l'appareil utilise également des signaux NITZ pour identifier le bon fuseau horaire. Cette méthode fonctionne bien dans de nombreux endroits du monde, mais elle nécessite que les signaux NITZ soient à la fois disponibles et corrects, et dépend donc des opérateurs.
La détection du fuseau horaire par téléphonie est un détecteur passif. Comme il s'exécute en permanence, des suggestions de téléphonie sont souvent émises même lorsque l'algorithme time_zone_detector actif n'est pas actuellement un service de téléphonie.
Limites de la détection du fuseau horaire de téléphonie
Même si des signaux NITZ corrects sont disponibles, la détection du fuseau horaire de téléphonie ne fonctionne pas toujours bien dans tous les pays. En effet, NITZ ne contient que des informations sur le décalage et l'heure d'été, qui ne suffisent pas toujours à identifier de manière unique un fuseau horaire.
Ce problème de fuseau horaire peut se produire dans de nombreux endroits du monde. Par exemple, Denver Colorado et Phoenix en Arizona aux États-Unis ne peuvent pas être identifiés à l'aide des signaux NITZ en hiver, mais ils le peuvent pendant les autres saisons. Ce type de problème peut se produire dans n'importe quel lieu où les fuseaux horaires se chevauchent.
Le tableau suivant présente le comportement de l'appareil en fonction de la saison pour Denver et Phoenix, par exemple:
| Lieu et saison | Informations provenant du MCC ou du 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:
L'appareil est correctement défini sur America/Denver. |
| Phoenix (Arizona), États-Unis Hiver |
Heure: 1er janvier 2021 12:00:00 Pays: États-Unis Décalage: UTC-7, pas d'heure d'été |
Deux ID de zone correspondent:
L'appareil est incorrectement défini sur Amérique/Denver. |
| Denver (Colorado), États-Unis Été |
Heure: 1er juillet 2021 12:00:00 Pays: États-Unis Décalage: UTC-6, heure d'été |
Un ID de zone correspond:
L'appareil est correctement défini sur America/Denver. |
| Phoenix (Arizona), États-Unis Été |
Heure: 1er juillet 2021 12:00:00 Pays: États-Unis Décalage: UTC-7, sans heure d'été |
Un ID de zone correspond:
L'appareil est correctement défini sur America/Phoenix. |
Les exemples ci-dessus montrent que pendant l'hiver, les appareils Android situés à Denver ou en Arizona doivent choisir l'un des deux ID de fuseau horaire correspondants, qui peuvent être incorrects pour certains appareils, mais qui affichent toujours une heure locale apparemment correcte. L'horloge de l'appareil, les agendas et les autres applications affichent l'heure locale attendue même si l'ID de fuseau horaire est incorrect, car les deux ID de fuseau horaire calculent la même heure locale en hiver.
Toutefois, au printemps, lorsque Denver observe l'heure d'été et que Phoenix ne le fait pas, il est possible que certains appareils affichent temporairement l'heure locale incorrecte s'ils sont définis sur le mauvais ID de fuseau horaire pour l'emplacement de l'utilisateur. Ce problème est résolu dès que l'appareil reçoit un nouveau signal NITZ (plus précisément, qui contient les informations de décalage UTC-7, pas d'heure d'été), mais cela peut prendre un certain temps et dépend des opérateurs.
Par conséquent, les agendas ou autres applications qui stockent ou conservent l'ID de fuseau horaire de l'hiver au printemps peuvent s'afficher et utiliser la mauvaise heure locale jusqu'à ce que les applications concernées mettent à jour l'ID de fuseau horaire.
Débogage et test
La section suivante décrit les commandes shell permettant de déboguer et de tester la fonctionnalité de détection des fuseaux horaires téléphoniques.
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 détection du fuseau horaire de la téléphonie. La cellule de test peut être utilisée pour simuler des réseaux avec différents MCC, envoyer des signaux NITZ aux appareils, puis surveiller leurs effets.
Pour que l'appareil détecte le fuseau horaire, les informations du signal NITZ doivent être correctes, cohérentes avec le MCC et correspondre à la copie de la base de données IANA TZDB (règles de fuseau horaire) de l'appareil. Les signaux NITZ qui ne sont pas cohérents avec le CM rendent l'algorithme de téléphonie incertain.
Par exemple, si le MCC utilisé par la cellule de test est destiné aux États-Unis, le signal NITZ doit contenir une "heure universelle", un décalage et des informations sur l'heure d'été correctes pour un endroit situé aux États-Unis.
Interagir avec le service com.android.phone
Pour vérifier que l'appareil reçoit les suggestions de fuseaux horaires de téléphonie appropriées, utilisez:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Cela permet de vider les informations de téléphonie, qui se trouvent également dans les rapports de bugs Android. Sur les appareils dotés de plusieurs cartes SIM, vous trouverez des informations sur chaque radio SIM.
Les journaux du fuseau horaire affichent les suggestions que le processus de téléphonie a envoyées au détecteur de fuseau horaire et les raisons de leur envoi.
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")]}