O Android 9 (API de nível 28) introduz diversas mudanças ao sistema Android. As mudanças de comportamento a seguir se aplicam a todos os apps quando são executados na plataforma Android 9, independentemente do nível da API de destino. Todos os desenvolvedores precisam analisar essas mudanças e modificar os apps para que sejam compatíveis com elas, quando aplicável.
Para ver as mudanças que afetam apenas apps direcionados ao nível 28 da API ou mais recente, consulte Mudanças de comportamento: apps direcionados ao nível 28 da API ou mais recente.
Gerenciamento de energia
O Android 9 apresenta novos recursos para melhorar o gerenciamento de energia dos dispositivos. Essas mudanças, junto com recursos que já estavam presentes antes do Android 9, ajudam a garantir que os recursos do sistema sejam disponibilizados aos apps que mais precisam deles.
Veja mais detalhes em Gerenciamento de energia.
Mudanças de privacidade
Para melhorar a privacidade do usuário, o Android 9 introduz várias mudanças de comportamento, como limitar o acesso de apps em segundo plano aos sensores do dispositivo, restringir informações recuperadas de buscas por Wi-Fi e novas regras e grupos de permissões relacionados a chamadas telefônicas, estado do telefone e buscas por Wi-Fi.
Essas mudanças afetam todos os apps executados no Android 9, independentemente da versão do SDK de destino.
Acesso limitado aos sensores em segundo plano
O Android 9 limita a capacidade de apps em segundo plano de acessar a entrada do usuário e os dados do sensor. Se o app estiver sendo executado em segundo plano em um dispositivo com o Android 9, o sistema aplicará as restrições abaixo a ele:
- Seu app não pode acessar o microfone ou a câmera.
- Os sensores que usam o modo de relatório contínuo, como acelerômetros e giroscópios, não recebem eventos.
- Os sensores que usam os modos de relatório on-change ou one-shot não recebem eventos.
Se o app precisar detectar eventos do sensor em dispositivos com o Android 9, use um serviço em primeiro plano.
Acesso restrito aos registros de chamadas
O Android 9 introduz o
grupo de permissões
CALL_LOG
e move as permissões
READ_CALL_LOG
,
WRITE_CALL_LOG
e
PROCESS_OUTGOING_CALLS
para esse grupo. Nas versões anteriores do Android, essas permissões
ficavam no grupo de permissões PHONE
.
Esse grupo de permissões CALL_LOG
oferece aos usuários melhor controle e visibilidade para
apps que precisam de acesso a informações sensíveis sobre chamadas telefônicas, como
leitura de registros de chamadas e identificação de números de telefone.
Se o app exigir acesso aos registros de chamadas ou precisar processar chamadas realizadas, você
vai precisar solicitar explicitamente essas permissões do
grupo de permissões
CALL_LOG
. Caso contrário, ocorre uma
SecurityException
.
Observação : como essas permissões mudaram de grupo e são concedidas no momento da execução, é possível que o usuário negue acesso do app às informações de registros de chamadas telefônicas. Nesse caso, seu app precisa ser capaz de lidar com a falta de acesso às informações sem problemas.
Se o app já segue as práticas recomendadas de permissões de execução, ele pode processar a mudança no grupo de permissões.
Acesso restrito a números de telefone
Os apps executados no Android 9 não podem ler números de telefone ou o estado do smartphone sem antes adquirir a permissão READ_CALL_LOG
, além das outras permissões exigidas pelos casos de uso do seu app.
Os números de telefone associados a chamadas recebidas e realizadas ficam visíveis na
transmissão
do estado do telefone,
por exemplo, para chamadas recebidas e realizadas, e podem ser acessados pela classe
PhoneStateListener
.
No entanto, sem a permissão
READ_CALL_LOG
, o campo do número de telefone fornecido nas
transmissões PHONE_STATE_CHANGED
e por PhoneStateListener
fica vazio.
Para ler números de telefone a partir do estado do telefone, atualize o app para solicitar as permissões necessárias com base no seu caso de uso:
- Para ler os números da ação da
intent
PHONE_STATE
, você precisa das permissõesREAD_CALL_LOG
eREAD_PHONE_STATE
. - Para ler números de
onCallStateChanged()
, você precisa apenas da permissãoREAD_CALL_LOG
. Você não precisa da permissãoREAD_PHONE_STATE
.
Acesso restrito a informações de conexão e local de Wi-Fi
No Android 9, os requisitos de permissão para um app fazer buscas por Wi-Fi são mais rigorosos do que nas versões anteriores. Para ver detalhes, consulte Restrições de busca por Wi-Fi.
Restrições semelhantes também se aplicam ao método
getConnectionInfo()
, que retorna um objeto WifiInfo
que descreve a conexão Wi-Fi atual. Você só poderá usar os métodos desse
objeto para extrair os valores de SSID e BSSID se o app de chamada tiver as seguintes
permissões:
- ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION
- ACCESS_WIFI_STATE
A recuperação do SSID ou do BSSID também exige que os Serviços de localização estejam ativados no dispositivo (em Configurações > Localização).
Informações removidas dos métodos de serviço Wi-Fi
No Android 9, os eventos e transmissões a seguir não recebem informações sobre a localização ou dados de identificação pessoal do usuário:
- Os métodos
getScanResults()
egetConnectionInfo()
deWifiManager
. - Os métodos
discoverServices()
eaddServiceRequest()
deWifiP2pManager
. - A transmissão
NETWORK_STATE_CHANGED_ACTION
.
A transmissão do sistema NETWORK_STATE_CHANGED_ACTION
pelo Wi-Fi não contém mais o SSID (anteriormente EXTRA_SSID),
o BSSID (anteriormente EXTRA_BSSID) ou informações de conexão (anteriormente
EXTRA_NETWORK_INFO). Caso o app precise dessas informações, chame
getConnectionInfo()
.
As informações de telefonia agora dependem da configuração de localização do dispositivo
Se o usuário tiver desativado a localização do dispositivo em um dispositivo com o Android 9, os métodos a seguir não fornecerão resultados:
Restrições para o uso de interfaces que não fazem parte do SDK
Para ajudar a garantir a estabilidade e a compatibilidade do app, a plataforma restringe o uso de alguns métodos e campos externos ao SDK. Essas restrições se aplicam se você tenta acessar esses métodos e campos diretamente, por reflexão ou usando JNI. No Android 9, seu app pode continuar acessando essas interfaces restritas. A plataforma usa avisos e entradas de registro para chamar sua atenção. Se o app mostrar esse aviso, é importante adotar uma estratégia de implementação diferente da interface restrita. Se você achar que nenhuma estratégia alternativa é viável, registre um bug para pedir a reconsideração da restrição.
O artigo Restrições em interfaces não SDK contém mais informações importantes. Revise-o para garantir que seu app continue funcionando corretamente.
Mudanças no comportamento de segurança
Mudanças na segurança do dispositivo
O Android 9 adiciona vários recursos que melhoram a segurança do app, independentemente da versão de destino dele.
Mudanças na implementação de TLS
A implementação do TLS do sistema passou por várias mudanças no Android 9:
- Se uma instância de
SSLSocket
não se conectar enquanto estiver sendo criada, o sistema vai gerar umaIOException
em vez de umaNullPointerException
. - A classe
SSLEngine
gerencia de forma limpa todos os alertasclose_notify
que ocorrem.
Para saber mais sobre como fazer solicitações da Web seguras em um app Android, consulte Um exemplo de HTTPS.
Filtro de SECCOMP mais rígido
O Android 9 restringe ainda mais as chamadas de sistema disponíveis aos aplicativos. Esse comportamento é uma extensão do filtro SECCOMP incluído no Android 8.0 (nível 26 da API).
Mudanças na criptografia
O Android 9 apresenta várias mudanças na implementação e no processamento de algoritmos criptográficos.
Implementações Conscrypt de parâmetros e algoritmos
O Android 9 oferece outras implementações de parâmetros de algoritmo no Conscrypt. Esses parâmetros incluem: AES, DESEDE, OAEP e EC. As versões do Bouncy Castle (link em inglês) desses parâmetros e de muitos algoritmos foram descontinuadas no Android 9.
Se o app for direcionado ao Android 8.1 (nível 27 da API) ou versões anteriores, você vai receber um aviso
ao solicitar a implementação do Bouncy Castle de um desses algoritmos
descontinuados. No entanto, se o seu objetivo é o Android 9, cada uma dessas solicitações gerará uma
NoSuchAlgorithmException
.
Outras mudanças
O Android 9 apresenta diversas outras alterações relacionadas a criptografia:
- Ao usar chaves PBE, se o Bouncy Castle estiver esperando um vetor de inicialização (IV) e seu app não fornecer um, você receberá um aviso.
- A implementação Conscrypt da criptografia ARC4 permite especificar ARC4/ECB/NoPadding ou ARC4/NONE/NoPadding.
- O provedor Crypto Java Cryptography Architecture (JCA) foi removido. Como
resultado, se o app chamar
SecureRandom.getInstance("SHA1PRNG", "Crypto")
, ocorrerá umaNoSuchProviderException
. - Se o app analisar as chaves RSA em buffers maiores que a estrutura da chave, não vai haver mais uma exceção.
Para saber mais sobre como usar os recursos criptográficos do Android, consulte Criptografia.
Os arquivos criptografados seguros do Android não são mais compatíveis
O Android 9 remove completamente o suporte a arquivos criptografados protegidos pelo Android (ASECs, na sigla em inglês).
No Android 2.2 (API de nível 8), os ASECs foram lançados para oferecer suporte à funcionalidade apps em cartões SD. No Android 6.0 (nível 23 da API), a plataforma lançou uma tecnologia de dispositivo de armazenamento adotável que os desenvolvedores podem usar em vez de ASECs.
Atualizações nas bibliotecas de ICU
O Android 9 usa a versão 60 da biblioteca ICU. O Android 8.0 (API de nível 26) e o Android 8.1 (API de nível 27) usam a ICU 58.
A ICU é usada para fornecer APIs públicas abaixo da android.icu package
e é usada internamente na Plataforma Android para suporte à internacionalização.
Por exemplo, ele é usado para implementar classes do Android em java.util
, java.text
e android.text.format
.
A atualização da ICU 60 contém muitas mudanças pequenas, mas úteis, incluindo o suporte a dados do Emoji 5.0 e melhorias nos formatos de data/hora, conforme documentado nas notas da versão da ICU 59 e da ICU 60.
Estas são algumas mudanças de destaque dessa atualização:
- A forma como a plataforma lida com os fusos horários mudou.
- A plataforma lida melhor com GMT e UTC. UTC não é mais sinônimo de
GMT.
A ICU agora fornece nomes de fusos traduzidos para GMT e UTC. Essa mudança afeta o comportamento de formatação e análise de
android.icu
para zonas como "GMT", "Etc/GMT", "UTC", "Etc/UTC" e "Zulu". - Agora,
java.text.SimpleDateFormat
usa a ICU para fornecer nomes de exibição para UTC /GMT, o que significa:- A formatação de
zzzz
gera uma string longa localizada para várias localidades. Anteriormente, ele produzia "UTC" para UTC e strings como "GMT+00:00" para GMT. - A análise de
zzzz
reconhece strings como "Universal Coordenada" e "Tempo Média de Greenwich". - Os apps poderão ter problemas de compatibilidade se presumirem
que "UTC" ou "GMT+00:00" são saídas para
zzzz
em todos os idiomas.
- A formatação de
- O comportamento de
java.text.DateFormatSymbols.getZoneStrings()
mudou:- Assim como em
SimpleDateFormat
, UTC e GMT agora têm nomes longos. As variantes de DST de nomes de fusos horários para a zona UTC, como "UTC", "Etc/UTC" e "Zulu", se tornam GMT+00:00, que é o substituto padrão quando não há nomes disponíveis, em vez da string codificadaUTC
. - Alguns IDs de zona são reconhecidos corretamente como sinônimos de outras
zonas, de modo que o Android encontra strings de
IDs de zona arcaicas, como
Eire
, que anteriormente não podiam ser resolvidas.
- Assim como em
- Ásia/Hanoi não é mais uma zona reconhecida. Por esse motivo,
java.util.TimeZones.getAvailableIds()
não retorna esse valor ejava.util.TimeZone.getTimeZone()
não o reconhece. Esse comportamento é consistente com o comportamentoandroid.icu
existente.
- A plataforma lida melhor com GMT e UTC. UTC não é mais sinônimo de
GMT.
- O método
android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String)
pode gerar umaParseException
mesmo ao analisar um texto de moeda legítimo. Para evitar esse problema, useNumberFormat.parseCurrency
, disponível desde o Android 7.0 (API de nível 24), para texto de moeda no estiloPLURALCURRENCYSTYLE
.
Mudanças no Android Test
O Android 9 introduz várias mudanças na biblioteca e na estrutura de classes do framework de teste do Android. Essas mudanças ajudam os desenvolvedores a usar APIs públicas com suporte ao framework, mas também permitem mais flexibilidade na criação e execução de testes usando bibliotecas de terceiros ou lógica personalizada.
Bibliotecas removidas do framework
O Android 9 reorganiza as classes baseadas em JUnit em três bibliotecas:
android.test.base, android.test.runner e android.test.mock.
Essa mudança permite que você execute testes em uma versão do JUnit que funciona melhor
com as dependências do seu projeto. Essa versão do JUnit pode ser diferente
da fornecida pelo android.jar
.
Para saber mais sobre como as classes baseadas em JUnit são organizadas nessas bibliotecas e como preparar o projeto do app para programar e executar testes, consulte Configurar o projeto para o Android Test.
Mudanças no build do pacote de testes
O método addRequirements()
na classe
TestSuiteBuilder
foi removido, e a própria classe TestSuiteBuilder
foi descontinuada.
O método addRequirements()
exigia que os desenvolvedores fornecessem argumentos com
tipos que são APIs ocultas, tornando a API inválida.
Decodificador de UTF Java
UTF-8 é o conjunto de caracteres padrão no Android. Uma sequência de bytes UTF-8 pode ser decodificada
por um construtor String
, como String(byte[] bytes)
.
O decodificador UTF-8 no Android 9 segue os padrões Unicode com mais detalhes do que nas versões anteriores. As mudanças são:
- A forma não mais curta de UTF-8, como
<C0, AF>
, é tratada como mal formada. - A forma substituta de UTF-8, como
U+D800
..U+DFFF
, é tratada como se tivesse sido formada incorretamente. - A subparte máxima é substituída por uma única
U+FFFD
. Por exemplo, na sequência de bytes "41 C0 AF 41 F4 80 80 41
", as subpartes máximas são "C0
", "AF
" e "F4 80 80
". "F4 80 80
" pode ser a subsequência inicial de "F4 80 80 80
", mas "C0
" não pode ser a subsequência inicial de qualquer sequência de unidades de código bem formada. Assim, a saída precisa ser "A\ufffd\ufffdA\ufffdA
". - Para decodificar uma sequência UTF-8 / CESU-8 modificada no Android 9 ou versões mais recentes, use o método
DataInputStream.readUTF()
ou o método JNINewStringUTF()
.
Verificação de nome do host usando um certificado
A RFC 2818 (link em inglês) descreve dois
métodos para corresponder um nome de domínio a um certificado usando os nomes disponíveis
na extensão subjectAltName
(SAN
) ou, na ausência de uma
extensão SAN
, voltando para commonName
(CN
).
No entanto, o substituto do CN
foi descontinuado na RFC 2818. Por esse motivo,
o Android não volta mais a usar a CN
. Para verificar um nome do host, o servidor
precisa apresentar um certificado com um SAN
correspondente. Certificados que não contêm um SAN
correspondente ao nome do host não são mais confiáveis.
Pesquisas de endereço de rede podem causar violações de rede
As pesquisas de endereço de rede que exigem resolução de nome podem envolver E/S de rede e, portanto, são consideradas operações de bloqueio. Operações de bloqueio na linha de execução principal podem causar pausas ou instabilidade.
A classe StrictMode
é uma ferramenta de desenvolvimento que ajuda
os desenvolvedores a detectar problemas no código.
No Android 9 e versões mais recentes, StrictMode
detecta violações
de rede causadas por pesquisas de endereço de rede que exigem resolução de nome.
Não envie seus apps com o StrictMode
ativado. Se você fizer isso, seus
apps poderão apresentar exceções, como
NetworkOnMainThreadException
, ao usar os métodos
detectNetwork()
ou
detectAll()
para acessar uma
política que detecta violações de rede.
Resolver um endereço IP numérico não é considerado uma operação de bloqueio. A resolução numérica de endereços IP funciona da mesma forma que nas versões anteriores ao Android 9.
Inclusão de tags de soquete
Nas versões da plataforma anteriores ao Android 9, se um soquete for marcado usando o método setThreadStatsTag()
, ele será desmarcado quando for enviado para outro processo usando a IPC de binder com um contêiner ParcelFileDescriptor
.
No Android 9 e versões mais recentes, a tag de soquete é mantida quando enviada para outro
processo usando um binder IPC. Essa alteração pode afetar as estatísticas de tráfego de rede, por
exemplo, ao usar o
método queryDetailsForUidTag()
.
Se você quiser manter o comportamento das versões anteriores, que desmarcam um soquete que é enviado para outro processo, chame untagSocket()
antes de enviá-lo.
Quantidade informada de bytes disponíveis no soquete
O método available()
retorna 0
quando é chamado
depois de invocar o método shutdownInput()
.
Relatórios de recursos de rede mais detalhados para VPNs
No Android 8.1 (API de nível 27) e versões anteriores, a
classe NetworkCapabilities
informava apenas um conjunto limitado de
informações para VPNs, como
TRANSPORT_VPN
, mas omitindo
NET_CAPABILITY_NOT_VPN
. Essa limitação
dificultou a determinação se o uso de uma VPN resultaria em cobranças
para o usuário do app. Por exemplo, verificar
NET_CAPABILITY_NOT_METERED
não
determinaria se as redes são limitadas ou não.
No Android 9 e versões mais recentes, quando uma VPN chama o método
setUnderlyingNetworks()
, o sistema Android mescla os transportes e os recursos de qualquer
rede subjacente e retorna o resultado como os recursos de rede eficazes
da rede VPN.
No Android 9 e versões mais recentes, os apps que já verificam
NET_CAPABILITY_NOT_METERED
recebem os recursos de rede da VPN e das
redes subjacentes.
Os arquivos na pasta xt_qtaguid não estão mais disponíveis para apps
A partir do Android 9, os apps não podem ter acesso direto
de leitura aos arquivos na pasta /proc/net/xt_qtaguid
. O motivo é
garantir a consistência com alguns dispositivos que não têm esses arquivos.
As APIs públicas que dependem desses arquivos, TrafficStats
e
NetworkStatsManager
, continuam funcionando conforme o esperado.
No entanto, as funções
cutils
sem suporte, como
qtaguid_tagSocket()
,
podem não funcionar da forma esperada em dispositivos diferentes.
O requisito FLAG_ACTIVITY_NEW_TASK agora é aplicado
Com o Android 9, não é possível iniciar uma atividade em um
contexto de não atividade, a menos que você transmita a flag de intent
FLAG_ACTIVITY_NEW_TASK
.
Se você tentar iniciar uma atividade sem transmitir essa flag, ela
não será iniciada, e o sistema vai mostrar uma mensagem no registro.
Mudanças na rotação da tela
A partir do Android 9, há mudanças significativas no modo de rotação retrato. No Android 8.0 (API de nível 26), os usuários podem alternar entre os modos de rotação rotação automática e retrato usando um bloco do Quicksettings ou as configurações de tela. O modo retrato foi renomeado como bloqueio de rotação, e fica ativo quando a rotação automática está desativada. Não há mudanças no modo de giro automático.
Quando o dispositivo está no modo de bloqueio de rotação, o usuário pode bloquear a tela em qualquer
rotação compatível com a atividade na parte de cima e visível. Uma atividade não pode presumir que
sempre será renderizada no modo retrato. Se a atividade principal puder ser renderizada em
várias rotações no modo de rotação automática, as mesmas opções precisarão estar disponíveis no
modo de rotação bloqueada, com algumas exceções baseadas na configuração screenOrientation
da atividade (consulte a tabela abaixo).
Atividades que solicitam uma orientação específica (por exemplo,
screenOrientation=landscape
) ignoram a preferência de bloqueio do usuário e se comportam
da mesma forma que no Android 8.0.
A preferência de orientação da tela pode ser definida no nível da atividade no manifesto do Android ou de forma programática com setRequestedOrientation().
O modo de bloqueio de rotação funciona definindo a preferência de rotação do usuário que o WindowManager usa ao processar a rotação da atividade. A preferência de rotação do usuário pode ser alterada nos casos abaixo. Há um viés de retorno à rotação natural do dispositivo, que normalmente é retrato para dispositivos com formato de smartphone:
- Quando o usuário aceita uma sugestão de rotação, a preferência de rotação muda para a sugestão.
- Quando o usuário alterna para um app no modo retrato forçado (incluindo a tela de bloqueio ou a tela de início), a preferência de rotação muda para retrato.
A tabela a seguir resume o comportamento de rotação das orientações de tela comuns:
Orientação da tela | Comportamento |
---|---|
não especificado, usuário | No giro automático e no bloqueio de rotação, a atividade pode ser renderizada em retrato ou paisagem (e vice-versa). Espere oferecer suporte para layouts no modo retrato e no modo paisagem. |
UserLandscape | No giro automático e no bloqueio de rotação, a atividade pode ser renderizada em paisagem ou paisagem invertida. Espere oferecer suporte apenas para layouts no modo paisagem. |
Retrato | No giro automático e no bloqueio de rotação, a atividade pode ser renderizada em retrato ou retrato invertido. Espere oferecer suporte apenas para layouts no modo retrato. |
Usuário completo | No giro automático e no bloqueio de rotação, a atividade pode ser renderizada em retrato ou paisagem (e vice-versa). Espere oferecer suporte para layouts de retrato e paisagem. Os usuários do bloqueio de rotação terão a opção de bloquear no modo retrato invertido, geralmente 180o. |
sensor, fullSensor, sensorPortrait, sensorLandscape | A preferência do modo de bloqueio de rotação é ignorada e é tratada como se o giro automático estivesse ativo. Use isso somente em circunstâncias excepcionais considerando a experiência do usuário com muito cuidado. |
A descontinuação do cliente Apache HTTP afeta apps com ClassLoader não padrão
Com o Android 6.0,
removemos o suporte ao cliente Apache HTTP.
Essa mudança não afeta a grande maioria dos apps que não são direcionados
ao Android 9 ou versões mais recentes. No entanto, a mudança pode afetar determinados apps que
usam uma estrutura ClassLoader
não padrão,
mesmo que eles não sejam direcionados ao Android 9 ou versões mais recentes.
Um app poderá ser afetado se usar um ClassLoader
não padrão que delega explicitamente
para o ClassLoader
do sistema. Em vez disso, esses apps precisam delegar ao app
ClassLoader
ao procurar classes em org.apache.http.*
. Se eles
delegarem ao ClassLoader
do sistema, os apps falharão no Android 9 ou versões mais recentes
com uma NoClassDefFoundError
,
porque essas classes não são mais conhecidas pelo ClassLoader
do sistema. Para
evitar problemas semelhantes no futuro, os apps precisam carregar classes
pelo app ClassLoader
em vez de acessar diretamente o ClassLoader
do sistema.
Enumerar câmeras
Os apps executados em dispositivos Android 9 podem descobrir todas as câmeras disponíveis chamando
getCameraIdList()
.
O app não pode presumir que o dispositivo tem apenas uma câmera traseira ou
uma frontal.
Por exemplo, se o app tiver um botão para alternar entre as câmeras frontal e traseira, poderá haver mais de uma câmera frontal ou traseira para escolher. Você precisa percorrer a lista de câmeras, examinar as características de cada uma e decidir quais delas expor ao usuário.