En el caso de los dispositivos que ejecutan Android 11 o versiones anteriores, la detección automática de la zona horaria en el AOSP se basa en señales del subsistema de telefonía. Debido a la dependencia en el subsistema de telefonía, detección automática de la zona horaria en Android 11 o versiones anteriores se limita a los dispositivos de telefonía.
Cuando la detección de zona horaria por telefonía está disponible, funciona con el Código móvil de país (MCC) y Identidad de red y zona horaria (NITZ) indicadores.
Por ejemplo, un dispositivo en Francia puede identificar la zona horaria únicamente según el MCC informado por torres de telefonía celular cercanas. Esto es posible porque se sabe que Francia usar una sola zona horaria.
Cuando un país utiliza varias zonas horarias, el MCC no es suficiente por sí solo para identificar la zona horaria. En estos países, el dispositivo también usa señales NITZ para lo siguiente: identificar la zona horaria correcta. Esto funciona bien en muchos lugares en todo el mundo. pero requiere que los indicadores NITZ estén disponibles y sean correctos, y por lo que dependen de los operadores.
La detección de la zona horaria de la telefonía es un detector pasivo. Se ejecuta en todo momento y
por lo que las sugerencias de telefonía se suelen hacer
El algoritmo time_zone_detector no es de telefonía.
Limitación de la detección de zona horaria por telefonía
Incluso con las señales NITZ correctas disponibles, la detección de zona horaria por telefonía no siempre funcionan bien en todos los países. Esto se debe a que NITZ solo contiene offset y información de horario de verano, que no siempre es suficiente para identificar de manera inequívoca zona horaria.
Existen muchos lugares en el mundo en los que podría ocurrir este problema de zona horaria. Por ejemplo, Denver, Colorado y Phoenix, Arizona en EE.UU. no pueden ser se distinguen mediante señales NITZ durante el invierno, pero pueden hacerlo durante otras estaciones. Cualquier ubicación con zonas horarias similares superpuestas puede experimentar este tipo de problema.
En la siguiente tabla, se desglosa el comportamiento del dispositivo según la temporada. de Denver y Phoenix como 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 a las 12:00:00 País: EE.UU. Compensación: UTC-7, sin horario de verano |
Dos IDs de zona coinciden:
El dispositivo está correctamente configurado en Estados Unidos/Denver. |
| Phoenix, Arizona Invierno |
Hora: 1 de enero de 2021 a las 12:00:00 País: EE.UU. Compensación: UTC-7, sin horario de verano |
Dos IDs de zona coinciden:
El dispositivo está configurado de forma incorrecta en Estados Unidos/Denver. |
| Denver, Colorado Verano |
Hora: 1 de julio de 2021, 12:00:00 País: EE.UU. Desplazamiento: UTC-6, horario de verano |
El ID de una zona coincide con lo siguiente:
El dispositivo está correctamente configurado en Estados Unidos/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 con lo siguiente:
El dispositivo está configurado correctamente en America/Phoenix. |
Los ejemplos anteriores muestran que, durante el invierno, los dispositivos Android en Denver Arizona debe elegir uno de los dos IDs de zona horaria que coincidan, lo que podría ser incorrecto para algunos dispositivos, pero aun así muestran una hora local aparentemente correcta. El dispositivo el reloj, los calendarios y otras aplicaciones muestran la hora local esperada incluso si la El ID de zona horaria es incorrecto porque ambos IDs de zona horaria calculan el mismo ID de zona horaria durante el invierno.
Sin embargo, en primavera, cuando Denver respeta el horario de verano y Phoenix sí lo hace no, es posible que algunos dispositivos muestren temporalmente la hora local incorrecta si se configuran al ID de zona horaria incorrecto para la ubicación del usuario. Esto se corregirá en cuanto cuando el dispositivo recibe una nueva señal NITZ (específicamente, una que contiene "UTC-7, horario de verano" información de desplazamiento), pero esto puede demorar un tiempo y depende de los operadores.
Como resultado, los calendarios y otras aplicaciones que almacenan o transfieren el ID de zona horaria de invierno a primavera podría mostrarse y usar una hora local incorrecta hasta la las apps relevantes actualizan el ID de zona horaria.
Depuración y pruebas
En la siguiente sección, se describen 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 pruebas
Por lo general, los verificadores usan un entorno de pruebas con una celda de telefonía simulada o de prueba. para comprobar el comportamiento de detección de zona horaria de telefonía. La celda de prueba se puede usar para simular redes con diferentes MCC y enviar señales NITZ a los dispositivos y y supervisar sus efectos.
Para que el dispositivo detecte la zona horaria, se debe agregar la información de la señal NITZ correctos, coherentes con el MCC y que coincidan con la copia del dispositivo del TZDB de IANA (reglas de zona horaria). Los indicadores de NITZ que no coinciden con la cuenta de MCC generan las que el algoritmo de telefonía sea incierto.
Por ejemplo, si el MCC que usa la celda de prueba es para EE.UU., la señal NITZ debe contener información de “horario universal”, de compensación y de horario de verano que es adecuado para un lugar de EE.UU.
Cómo interactuar con el servicio com.android.phone
Para verificar que el dispositivo esté recibiendo sugerencias correctas de zona horaria de telefonía, haz lo siguiente: usa:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Esta acción vuelca la información de telefonía, que también se puede encontrar en el informe de errores de Android informes. En los dispositivos con varias SIM, hay información para cada radio de la SIM.
Los Registros de zona horaria muestran las sugerencias que el proceso de telefonía envió a el 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")]}