Para los dispositivos que ejecutan Android 11 o versiones anteriores, la detección automática de zona horaria en el AOSP se basa en señales del subsistema de telefonía. Debido a la dependencia del subsistema de telefonía, la detección automática de zona horaria en Android 11 o inferior se limita a los dispositivos de telefonía.
Cuando la detección de zona horaria de telefonía está disponible, funciona con las señales de código de país móvil (MCC) y de identidad de red y zona horaria (NITZ) .
Por ejemplo, un dispositivo en Francia puede identificar la zona horaria basándose únicamente en el MCC informado por las torres de telefonía celular cercanas. Esto es posible porque se sabe que Francia usa una sola zona horaria.
Cuando un país usa varias zonas horarias, el MCC por sí solo no es suficiente para identificar la zona horaria. Para estos países, el dispositivo también usa señales NITZ para identificar la zona horaria correcta. Esto funciona bien en muchos lugares del mundo, pero requiere que las señales NITZ estén disponibles y sean correctas y, por lo tanto, depende de los operadores.
La detección de zona horaria de telefonía es un detector pasivo . Se ejecuta en todo momento y, por lo tanto, a menudo se realizan sugerencias de telefonía incluso cuando el origen del detector de time_zone_detector
no es actualmente telefonía.
Limitación de detección de zona horaria de telefonía
Incluso con las señales NITZ correctas disponibles, la detección de zona horaria de telefonía no siempre funciona bien en todos los países. Esto se debe a que NITZ solo contiene información de horario de verano y compensación, que no siempre es suficiente para identificar de forma única una zona horaria.
Hay muchos lugares en el mundo donde podría ocurrir este problema de zona horaria. Por ejemplo, Denver Colorado y Phoenix Arizona en EE. UU. no se pueden distinguir mediante señales NITZ durante el invierno, pero sí durante otras estaciones. Cualquier ubicación con zonas horarias superpuestas de manera similar puede experimentar este tipo de problema.
La siguiente tabla desglosa el comportamiento del dispositivo según la temporada para Denver y Phoenix como ejemplo:
Ubicación y temporada | Información de MCC o NITZ | Zona horaria detectada y comportamiento |
---|---|---|
Denver, Colorado Invierno | Hora: 1 de enero de 2021 12:00:00 País: EE. UU. Desplazamiento: UTC-7, sin horario de verano | Coincidencia de dos ID de zona:
El dispositivo está configurado correctamente en América/Denver. |
Phoenix, Arizona Invierno | Hora: 1 de enero de 2021 12:00:00 País: EE. UU. Desplazamiento: UTC-7, sin horario de verano | Coincidencia de dos ID de zona:
El dispositivo está configurado incorrectamente para América/Denver. |
Denver, Colorado Verano | Hora: 1 de julio de 2021 12:00:00 País: EE. UU. Compensación: UTC-6, horario de verano | Coincidencias de ID de una zona:
El dispositivo está configurado correctamente en América/Denver. |
Phoenix, Arizona Verano | Hora: 1 de julio de 2021 12:00:00 País: EE. UU. Desplazamiento: UTC-7, sin horario de verano | Coincidencias de ID de una zona:
El dispositivo está configurado correctamente en America/Phoenix. |
Los ejemplos anteriores muestran que durante el invierno, los dispositivos Android en Denver o Arizona deben elegir uno de los dos identificadores de zona horaria coincidentes, que pueden ser incorrectos para algunos dispositivos, pero aun así muestran una hora local aparentemente correcta. El reloj del dispositivo, los calendarios y otras aplicaciones muestran la hora local esperada incluso si la identificación de la zona horaria es incorrecta porque ambas identificaciones de la zona horaria calculan la misma hora local durante el invierno.
Sin embargo, en primavera, cuando Denver observa el horario de verano y Phoenix no, es posible que algunos dispositivos muestren temporalmente la hora local incorrecta si están configurados con la ID de zona horaria incorrecta para la ubicación del usuario. Esto se corrige tan pronto como el dispositivo recibe una nueva señal NITZ (específicamente, una que contiene información de compensación "UTC-7, sin horario de verano"), pero esto puede llevar algún tiempo y depende de los operadores.
Como resultado, los calendarios u otras aplicaciones que almacenan o transfieren la identificación de la zona horaria desde el invierno hasta la primavera pueden mostrar y usar la hora local incorrecta hasta que las aplicaciones relevantes actualicen la identificación de la zona horaria.
Depuración y prueba
La siguiente sección describe los comandos de shell para depurar y probar la función de detección de zona horaria de telefonía.
Configuración del entorno de prueba
Los evaluadores suelen utilizar un entorno de prueba con una celda de telefonía de prueba o simulada para verificar el comportamiento de detección de la zona horaria de la telefonía. La celda de prueba se puede usar para simular redes con diferentes MCC y para enviar señales NITZ a dispositivos y luego monitorear sus efectos.
Para que el dispositivo detecte la zona horaria, la información de la señal NITZ debe ser correcta, coherente con el MCC y coincidir con la copia del dispositivo de IANA TZDB (reglas de zona horaria). Las señales NITZ que no son coherentes con el MCC hacen que el origen de la telefonía se vuelva incierto.
Por ejemplo, si el MCC utilizado por la celda de prueba es para los EE. UU., la señal NITZ debe contener información de "hora universal", compensación y horario de verano que sea correcta para algún lugar de los EE. UU.
Interactuando con el servicio com.android.phone
Para verificar que el dispositivo esté recibiendo las sugerencias de zona horaria de telefonía correctas, utilice:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Esto descarga información de telefonía, que también se puede encontrar en los informes de errores de Android. En dispositivos con múltiples SIM, hay información para cada radio SIM.
Los Registros de zona horaria muestran las sugerencias que el proceso de telefonía ha enviado al time_zone_detector y los motivos para enviar las sugerencias.
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")]}