Para dispositivos con Android 11 o versiones anteriores, la detección automática de zona horaria en 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 versiones anteriores se limita a dispositivos de telefonía.
Cuando la detección de zona horaria de telefonía está disponible, funciona utilizando 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 utiliza una única zona horaria.
Cuando un país utiliza varias zonas horarias, el MCC por sí solo no es suficiente para identificar la zona horaria. Para estos países, el dispositivo también utiliza 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, por lo que a menudo se realizan sugerencias de telefonía incluso cuando el algoritmo time_zone_detector activo no es actualmente de telefonía.
Limitación de la detección de zona horaria de telefonía
Incluso con 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 compensación y horario de verano, que no siempre son suficientes 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 los EE. UU. no se pueden distinguir utilizando señales NITZ durante el invierno, pero sí durante otras estaciones. Cualquier ubicación con zonas horarias similarmente superpuestas puede experimentar este tipo de problema.
La siguiente tabla desglosa el comportamiento del dispositivo según la temporada para Denver y Phoenix a modo de ejemplo:
| Ubicación y temporada | Información de MCC o NITZ | Zona horaria y comportamiento detectados |
|---|---|---|
| Denver, Colorado Invierno | Hora: 1 de enero de 2021 12:00:00 País: EE. UU. Compensación: UTC-7, sin horario de verano | Coinciden 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. Compensación: UTC-7, sin horario de verano | Coinciden dos ID de zona:
El dispositivo está configurado incorrectamente en 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 | El ID de una zona coincide:
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. Compensación: UTC-7, sin horario de verano | El ID de una zona coincide:
El dispositivo está configurado correctamente en América/Phoenix. |
Los ejemplos anteriores muestran que durante el invierno, los dispositivos Android en Denver o Arizona deben elegir una de dos ID de zona horaria coincidentes, que pueden ser incorrectas para algunos dispositivos pero aún así muestran una hora local aparentemente correcta. El reloj del dispositivo, los calendarios y otras aplicaciones muestran la hora local esperada incluso si el ID de la zona horaria es incorrecto porque ambos ID de zona horaria calculan la misma hora local durante el invierno.
Sin embargo, en primavera, cuando Denver observa el horario de verano y Phoenix no, algunos dispositivos pueden mostrar temporalmente la hora local incorrecta si están configurados con una 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 el ID de zona horaria del invierno a la primavera pueden mostrar y utilizar la hora local incorrecta hasta que las aplicaciones relevantes actualicen el ID de 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 simulada o de prueba para comprobar el comportamiento de detección de la zona horaria de la telefonía. La celda de prueba se puede utilizar para simular redes con diferentes MCC y 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 son inconsistentes con el MCC hacen que el algoritmo de telefonía se vuelva incierto.
Por ejemplo, si el MCC utilizado por la celda de prueba es para 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 EE. UU.
Interactuando con el servicio com.android.phone
Para verificar que el dispositivo esté recibiendo sugerencias de zona horaria de telefonía correcta, 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 del envío de 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")]}