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 está 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 pelas torres de celular próximas. Isto é possível porque se sabe que a França usa um único fuso horário.
Quando um país utiliza vários fusos horários, o MCC por si só não é suficiente para identificar o fuso horário. Para estes países, o dispositivo também utiliza sinais NITZ para identificar o fuso horário correto. Isto funciona bem em muitos lugares ao redor do mundo, mas exige 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, sugestões de telefonia são frequentemente feitas mesmo quando o algoritmo time_zone_detector ativo não é de telefonia no momento.
Limitação da detecção de fuso horário de telefonia
Mesmo com 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 distinguidas usando sinais NITZ durante o inverno, mas podem durante outras estações. Qualquer local com fusos horários sobrepostos semelhantes pode enfrentar esse tipo de problema.
A tabela a seguir detalha o comportamento do dispositivo dependendo da temporada para Denver e Phoenix, por exemplo:
| Localização e temporada | Informações do MCC ou NITZ | Fuso horário e comportamento detectados |
|---|---|---|
| Denver, Colorado Inverno | Hora: 1º de janeiro de 2021 12:00:00 País: EUA Compensação: UTC-7, sem horário de verão | Dois IDs de zona correspondem:
O dispositivo está configurado corretamente para América/Denver. |
| Fênix, Arizona Inverno | Hora: 1º de janeiro de 2021 12:00:00 País: EUA Compensação: 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 | Hora: 1º de julho de 2021 12:00:00 País: EUA Compensação: UTC-6, horário de verão | Um ID de zona corresponde a:
O dispositivo está configurado corretamente para América/Denver. |
| Fênix, Arizona Verão | Hora: 1º de julho de 2021 12:00:00 País: EUA Compensação: UTC-7, sem horário de verão | Um ID de zona corresponde a:
O dispositivo está configurado corretamente para América/Phoenix. |
Os exemplos acima mostram que durante o inverno, os dispositivos Android em Denver ou Arizona devem escolher um dos dois IDs 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, os calendários e outros aplicativos exibem a hora local esperada, mesmo que o ID do fuso horário esteja incorreto, porque ambos os IDs de fuso horário calculam a mesma hora local durante o inverno.
No entanto, na primavera, quando Denver observa o horário de verão e Phoenix não, alguns dispositivos podem mostrar temporariamente a hora local incorreta se estiverem configurados 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 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 comandos shell para depuração e teste do recurso de detecção de fuso horário de telefonia.
Configuração do ambiente de teste
Os testadores normalmente usam um ambiente de teste com uma célula de telefonia simulada ou de teste para verificar o comportamento de detecção do fuso horário da telefonia. A célula de teste pode ser usada para simular redes com diferentes CCMs e para enviar sinais NITZ aos dispositivos e então 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 IANA TZDB (regras de fuso horário) do dispositivo. Os sinais NITZ que são inconsistentes com o MCC fazem com que o algoritmo de telefonia fique incerto.
Por exemplo, se o CCM usado pela célula de teste for para os EUA, o sinal NITZ deverá conter um "horário universal", deslocamento e informações de horário de verão que sejam corretos 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 múltiplos 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")]}