Para dispositivos com Android 11 ou versões anteriores, a detecção automática de fuso horário no AOSP depende de sinais do subsistema de telefonia. Devido à dependência do subsistema de telefonia, a detecção automática de fuso horário no Android 11 ou versões anteriores é limitada a dispositivos de telefonia.
Quando a detecção de fuso horário de telefonia está disponível, ela funciona usando o código do país para dispositivos móveis (MCC) e os sinais de identidade de rede e fuso horário (NITZ).
Por exemplo, um dispositivo na Bélgica pode identificar o fuso horário com base apenas no MCC informado por torres de celular próximas. Isso é possível porque a Bélgica usa um único fuso horário.
Quando um país usa vários fusos horários, a MCC sozinha não é suficiente para identificar o fuso horário. Para esses países, o dispositivo também usa sinais NITZ para identificar o fuso horário correto. Isso funciona bem em muitos lugares do mundo, mas exige que os sinais NITZ estejam disponíveis e corretos, dependendo, portanto, das operadoras.
A detecção de fuso horário por telefonia é um detector passivo. Ele é executado o tempo todo, e
as sugestões de telefonia são feitas com frequência, mesmo quando o algoritmo
time_zone_detector
ativo não é de telefonia.
Limitação da detecção de fuso horário por telefonia
Mesmo com os sinais NITZ corretos disponíveis, a detecção de fuso horário da telefonia nem sempre funciona bem em todos os países. Isso acontece porque o NITZ contém apenas informações de ajuste e horário de verão, que nem sempre são suficientes para identificar um fuso horário de forma exclusiva.
Há muitos lugares no mundo em que esse problema de fuso horário pode ocorrer. Por exemplo, Denver, Colorado e Phoenix, Arizona, nos EUA, não podem ser diferenciadas usando sinais NITZ durante o inverno, mas podem em outras estações. Qualquer local com fusos horários semelhantes e sobrepostos pode ter esse tipo de problema.
A tabela a seguir detalha o comportamento do dispositivo dependendo da estação do ano em Denver e Phoenix, por exemplo:
Local e estação | Informações da MCC ou NITZ | Fuso horário e comportamento detectados |
---|---|---|
Denver, Colorado Inverno |
Horário: 1º de janeiro de 2021, 12:00:00 País: EUA Deslocamento: UTC-7, sem horário de verão |
Dois IDs de zona correspondem:
O dispositivo está corretamente definido como America/Denver. |
Phoenix, Arizona Inverno |
Horário: 1º de janeiro de 2021, 12:00:00 País: EUA Deslocamento: UTC-7, sem horário de verão |
Dois IDs de zona correspondem:
O dispositivo está incorretamente definido como America/Denver. |
Denver, Colorado Verão |
Horário: 1º de julho de 2021, 12:00:00 País: EUA Deslocamento: UTC-6, horário de verão |
Um ID de zona corresponde:
O dispositivo está corretamente definido como America/Denver. |
Phoenix, Arizona Verão |
Horário: 1º de julho de 2021, 12:00:00 País: EUA Deslocamento: UTC-7, sem horário de verão |
Um ID de zona corresponde:
O dispositivo está definido corretamente como America/Phoenix. |
Os exemplos na tabela mostram que, durante o inverno, os dispositivos Android em Denver ou no Arizona precisam escolher um de dois IDs de fuso horário correspondentes, o que pode estar incorreto para alguns dispositivos, mas ainda mostrar um horário local aparentemente correto. O relógio do dispositivo, os calendários e outros apps mostram o horário local esperado, mesmo que o ID do fuso horário esteja incorreto, porque ambos calculam o mesmo horário local durante o inverno.
No entanto, na primavera, quando Denver adota o horário de verão e Phoenix não, alguns dispositivos podem mostrar temporariamente a hora local incorreta se estiverem definidos com o ID de fuso horário errado para a localização do usuário. Isso é corrigido assim que o dispositivo recebe um novo sinal NITZ (especificamente, um que contém informações de compensação "UTC-7, sem horário de verão"), mas isso pode levar algum tempo e depende das operadoras.
Como resultado, calendários ou outros apps que armazenam ou transferem o ID do fuso horário do inverno para a primavera podem mostrar e usar a hora local errada até que os apps relevantes atualizem o ID do fuso horário.
Depuração e testes
A seção a seguir descreve comandos do shell para depurar e testar o recurso de detecção de fuso horário de telefonia.
Configuração do ambiente de teste
Os testadores geralmente usam um ambiente de teste com uma célula de telefonia de teste ou simulada para verificar o comportamento da detecção de fuso horário de telefonia. A célula de teste pode ser usada para simular redes com diferentes MCCs e enviar sinais NITZ para dispositivos e monitorar os efeitos deles.
Para que o dispositivo detecte o fuso horário, as informações do sinal NITZ precisam estar corretas, consistentes com o MCC e corresponder à cópia do dispositivo do TZDB da IANA (regras de fuso horário). Os indicadores NITZ inconsistentes com a MCC fazem com que o algoritmo de telefonia fique incerto.
Por exemplo, se a MCC usada pela célula de teste for dos EUA, o sinal NITZ precisará conter um UTC, um ajuste e informações de horário de verão corretos para algum lugar dos EUA.
Interagir com o serviço com.android.phone
Para verificar se o dispositivo está recebendo sugestões corretas de fuso horário de telefonia, use:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Isso gera informações de telefonia, que também podem ser encontradas em relatórios de bugs do Android. Em dispositivos com vários chips, há informações para cada rádio de chip.
Os registros de fuso horário mostram as sugestões que o processo de telefonia enviou ao time_zone_detector e os motivos para enviar as sugestões.
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")]}