Para dispositivos com Android 11 ou inferior, 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 inferior é limitada a dispositivos de telefonia.
Quando a detecção de fuso horário de telefonia está disponível, ela funciona usando os sinais Mobile Country Code (MCC) e Network Identity and Time Zone (NITZ) .
Por exemplo, um dispositivo na França pode identificar o fuso horário com base apenas no MCC informado por torres de celular próximas. Isso é possível porque a França é conhecida por usar um único fuso horário.
Quando um país usa vários fusos horários, a MCC por si só 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 ao redor do mundo, mas requer que os sinais NITZ estejam disponíveis e corretos e, portanto, depende das operadoras.
A detecção de fuso horário de telefonia é um detector passivo . Ele é executado o tempo todo e, portanto, as sugestões de telefonia geralmente são feitas mesmo quando a origem do time_zone_detector não é a telefonia no momento.
Limitação da detecção de fuso horário de telefonia
Mesmo com os sinais NITZ corretos disponíveis, a detecção de fuso horário de telefonia nem sempre funciona bem em todos os países. Isso ocorre porque o NITZ contém apenas informações de deslocamento e horário de verão, que nem sempre são suficientes para identificar exclusivamente um fuso horário.
Existem muitos lugares no mundo onde esse problema de fuso horário pode ocorrer. Por exemplo, Denver Colorado e Phoenix Arizona nos EUA não podem ser distinguidos usando sinais NITZ durante o inverno, mas podem durante outras estações. Qualquer local com fusos horários sobrepostos da mesma forma pode enfrentar esse tipo de problema.
A tabela a seguir detalha o comportamento do dispositivo dependendo da temporada para Denver e Phoenix como exemplo:
| Local e temporada | Informações do 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 Offset: UTC-7, sem horário de verão | Dois IDs de zona correspondem:
O dispositivo está configurado corretamente para América/Denver. |
| Phoenix, Arizona Inverno | Horário: 1º de janeiro de 2021 12:00:00 País: EUA Offset: UTC-7, sem horário de verão | Dois IDs de zona correspondem:
O dispositivo está configurado incorretamente para América/Denver. |
| Denver, Colorado Verão | Horário: 1º de julho de 2021 12:00:00 País: EUA Offset: UTC-6, horário de verão | Um ID de zona corresponde:
O dispositivo está configurado corretamente para América/Denver. |
| Phoenix, Arizona Verão | Horário: 1º de julho de 2021 12:00:00 País: EUA Offset: UTC-7, sem horário de verão | Um ID de zona corresponde:
O dispositivo está configurado corretamente para America/Phoenix. |
Os exemplos acima mostram que durante o inverno, os dispositivos Android em Denver ou Arizona devem escolher um dos dois códigos de fuso horário correspondentes, que podem estar incorretos para alguns dispositivos, mas ainda exibem uma hora local aparentemente correta. O relógio do dispositivo, calendários e outros aplicativos exibem a hora local esperada, mesmo que o ID do fuso horário esteja incorreto, porque ambos os IDs do fuso horário calculam o mesmo horário local durante o inverno.
No entanto, na primavera, quando Denver observa o horário de verão e o Phoenix não, alguns dispositivos podem mostrar temporariamente a hora local incorreta se estiverem configurados com o ID de fuso horário incorreto 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 aplicativos que armazenam ou transferem o ID do fuso horário do inverno para a primavera podem exibir e usar a hora local errada até que os aplicativos relevantes atualizem o ID do fuso horário.
Depuração e teste
A seção a seguir descreve os 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 de detecção de fuso horário de telefonia. A célula de teste pode ser usada para simular redes com diferentes CCMs e enviar sinais NITZ para dispositivos e depois monitorar seus efeitos.
Para que o dispositivo detecte o fuso horário, as informações do sinal NITZ devem estar corretas, consistentes com o MCC e corresponder à cópia do dispositivo do TZDB da IANA (regras de fuso horário). Os sinais NITZ que são inconsistentes com o MCC fazem com que a origem da telefonia se torne incerta.
Por exemplo, se o MCC usado pela célula de teste for para os EUA, o sinal NITZ deve conter um "horário universal", deslocamento e informações de horário de verão corretas para algum lugar nos EUA.
Interagindo 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 despeja informações de telefonia, que também podem ser encontradas em relatórios de bugs do Android. Em dispositivos com vários SIMs, há informações para cada rádio SIM.
Os logs de fuso horário mostram as sugestões que o processo de telefonia enviou ao time_zone_detector e os motivos do envio das 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")]}