Para dispositivos com o Android 11 ou versões anteriores, a detecção automática de fuso horário no O AOSP depende de sinais do subsistema de telefonia. Devido à dependência no subsistema de telefonia, detecção automática de fuso horário no Android 11 ou versões anteriores é limitado 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 Identidade da rede e fuso horário (NITZ) sinais
Por exemplo, um dispositivo na França pode identificar o fuso horário com base apenas no MCC informada por torres de celular próximas. Isso é possível porque a França é conhecida por usam um único fuso horário.
Quando um país usa vários fusos horários, o MCC por si só não é suficiente para identificar no fuso horário. Nesses países, o dispositivo também usa sinais NITZ para identifique o fuso horário correto. Isso funciona bem em vários lugares do mundo mas exige que os sinais NITZ estejam disponíveis e corretos, portanto dependem das operadoras.
A detecção de fuso horário de telefonia é um detector passivo. Ele é executado o tempo todo
por isso as sugestões de telefonia costumam ser feitas mesmo quando o
No momento, o algoritmo time_zone_detector não é de telefonia.
Limitação da detecção de fuso horário para telefonia
Mesmo com sinais NITZ corretos disponíveis, a detecção de fuso horário de telefonia sempre funcionam bem em todos os países. Isso ocorre porque o NITZ contém apenas valores de deslocamento e informações sobre o horário de verão, que nem sempre são suficientes para identificar um determinado fuso horário.
Esse problema de fuso horário pode ocorrer em muitos lugares no mundo. Por exemplo, Denver Colorado e Phoenix Arizona, nos EUA, não podem ser usando sinais NITZ durante o inverno, mas pode fazer isso em outras estações. Qualquer local com fusos horários similares pode passar por esse tipo de problema.
A tabela a seguir detalha o comportamento do dispositivo de acordo com a estação do ano. para Denver e Phoenix como exemplo:
| Local e temporada | Informações da MCC ou do NITZ | Fuso horário e comportamento detectados |
|---|---|---|
| Denver, Colorado Inverno |
Horário: 1o 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á definido corretamente como America/Denver. |
| Fênix, Arizona Inverno |
Horário: 1o 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á definido incorretamente como America/Denver. |
| Denver, Colorado verão |
Horário: 1o 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á definido corretamente como America/Denver. |
| Fênix, Arizona verão |
Horário: 1o 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á definido corretamente como Estados Unidos/Phoenix. |
Os exemplos acima mostram que, durante o inverno, dispositivos Android em Denver ou O Arizona precisa escolher um dos dois IDs de fuso horário correspondentes, que podem estar incorretos. para alguns dispositivos, mas ainda exibe um horário local aparentemente correto. O dispositivo o relógio, os calendários e outros aplicativos exibem o horário local esperado, mesmo se o o ID de fuso horário está incorreto porque ambos os IDs de fuso horário calculam o mesmo valor durante o inverno.
No entanto, na primavera, quando Denver segue o horário de verão e Phoenix Alguns dispositivos podem exibir temporariamente a hora local incorreta se estiver definida para o ID de fuso horário incorreto do local do usuário. Isso será corrigido em breve já que o dispositivo recebe um novo sinal NITZ (especificamente, um que contenha "UTC-7, sem horário de verão" informações de deslocamento), mas isso pode levar algum tempo e depende das operadoras.
Por isso, agendas ou outros apps que armazenam ou são transferidos para o ID de fuso horário do inverno à primavera pode ser exibida e usar a hora local errada até que a apps relevantes atualizam 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 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 MCCs e enviar sinais NITZ a dispositivos e e monitorar seus efeitos.
Para que o dispositivo detecte o fuso horário, as informações do sinal NITZ precisam ser corretos, de acordo com o MCC e corresponder à cópia do dispositivo IANA TZDB (regras de fuso horário). Os sinais NITZ inconsistentes com o MCC fazem com que o o algoritmo de telefonia móvel fique incerto.
Por exemplo, se o MCC usado pela célula de teste for para os EUA, o indicador NITZ deve conter uma "hora universal", uma compensação e informações de horário de verão que está correta em algum lugar dos EUA.
Interagir com o serviço com.android.phone
Para verificar se o dispositivo está recebendo sugestões de fuso horário de telefonia corretas, usar:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Ele descarta informações de telefonia, que também podem ser encontradas em "Bug do Android". e detecção de ameaças. Em dispositivos com vários chips, há informações para cada rádio chip.
Os Registros de fuso horário mostram as sugestões que o processo de telefonia enviou para 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")]}