Mudanças de comportamento: todos os apps

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:

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:

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:

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á uma NoSuchProviderException.
  • 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.
    • 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 codificada UTC.
      • 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.
    • Ásia/Hanoi não é mais uma zona reconhecida. Por esse motivo, java.util.TimeZones.getAvailableIds() não retorna esse valor e java.util.TimeZone.getTimeZone() não o reconhece. Esse comportamento é consistente com o comportamento android.icu existente.
  • O método android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) pode gerar uma ParseException mesmo ao analisar um texto de moeda legítimo. Para evitar esse problema, use NumberFormat.parseCurrency, disponível desde o Android 7.0 (API de nível 24), para texto de moeda no estilo PLURALCURRENCYSTYLE.

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 JNI NewStringUTF().

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.