O Android 10 inclui mudanças de comportamento que podem afetar seu app.
As mudanças listadas nesta página se aplicam quando o app é executado
no Android 10, independentemente da targetSdkVersion
dele. Você precisa testar seu app e modificá-lo conforme necessário para oferecer compatibilidade com essas mudanças da maneira correta.
Se a targetSdkVersion do seu app for 29
ou superior, você também precisará oferecer compatibilidade com outras mudanças. Leia as mudanças de comportamento dos apps destinados à versão 29 para ver detalhes.
Observação : além das mudanças listadas nesta página, o Android 10 introduz um grande número de mudanças e restrições relacionadas à privacidade, incluindo o seguinte:
- Acesso em segundo plano à localização do dispositivo
- Início da atividade em segundo plano
- Informações de afinidade de contatos
- Randomização de endereço MAC
- Metadados da câmera
- Modelo de permissões
Essas mudanças afetam todos os apps e melhoram a privacidade do usuário. Para saber mais sobre como oferecer suporte a essas mudanças, consulte a página Mudanças na privacidade.
Restrições da interface não SDK
Para garantir a estabilidade e a compatibilidade do app, a plataforma começou a restringir quais interfaces não SDK seu app pode usar no Android 9 (API de nível 28). O Android 10 inclui listas atualizadas de interfaces não SDK restritas baseadas na colaboração com desenvolvedores do Android e nos testes internos mais recentes. Nosso objetivo é garantir que alternativas públicas estejam disponíveis antes de restringirmos as interfaces não SDK.
Se você não pretende desenvolver apps para o Android 10 (API de nível 29), algumas das mudanças podem não afetar você imediatamente. No entanto, embora atualmente seja possível usar algumas interfaces não SDK (dependendo do nível da API de destino do app), o uso de qualquer método ou campo não SDK sempre apresenta um alto risco de corromper o app.
Se você não souber se seu app usa interfaces não SDK, poderá testá-lo para descobrir. Se ele depende de interfaces não SDK, comece a planejar uma migração para alternativas SDK. No entanto, entendemos que alguns apps têm casos de uso válidos para interfaces não SDK. Caso você não encontre uma alternativa para deixar de usar uma interface não SDK em um recurso no seu app, solicite uma nova API pública.
Para saber mais, consulte Atualizações para restrições de interface não SDK no Android 10 e Restrições para interfaces não SDK.
Navegação por gestos
A partir do Android 10, os usuários podem ativar a navegação por gestos no dispositivo. Se um usuário ativar a navegação por gestos, isso afetará todos os apps no dispositivo, independentemente de o app ser ou não destinado à API de nível 29. Por exemplo, se o usuário deslizar da borda da tela para o centro, o sistema interpretará esse gesto como uma navegação de retorno, a menos que o app modifique especificamente esse gesto para partes da tela.
Para tornar seu app compatível com a navegação por gestos, estenda o conteúdo do app de ponta a ponta na tela e resolva adequadamente os conflitos de gestos. Para mais informações, consulte a documentação de Navegação por gestos.
NDK
O Android 10 inclui as alterações do NDK descritas a seguir.
Objetos compartilhados não podem conter realocações de texto
No Android 6.0 (API de nível 23), o uso de realocações de texto em objetos compartilhados foi proibido. O código precisa ser carregado como está e não pode ser modificado. Essa alteração melhora o tempo de carregamento e a segurança dos apps.
O SELinux impõe essa restrição em apps direcionados ao Android 10 ou versões mais recentes. Esses apps correm alto risco de serem corrompidos caso continuem utilizando objetos compartilhados que contenham realocações de texto.
Alterações nos caminhos das bibliotecas Bionic e do vinculador dinâmico
A partir do Android 10, vários caminhos são links simbólicos em vez de arquivos comuns. Os apps que dependem de os caminhos serem arquivos comuns podem ser corrompidos:
/system/lib/libc.so
->/apex/com.android.runtime/lib/bionic/libc.so
/system/lib/libm.so
->/apex/com.android.runtime/lib/bionic/libm.so
/system/lib/libdl.so
->/apex/com.android.runtime/lib/bionic/libdl.so
/system/bin/linker
->/apex/com.android.runtime/bin/linker
Essas mudanças se aplicam também às variantes de 64 bits do arquivo, com
lib/
substituído por lib64/
.
Para compatibilidade, os links simbólicos são fornecidos nos caminhos antigos. Por exemplo, /system/lib/libc.so
é um link simbólico para /apex/com.android.runtime/lib/bionic/libc.so
. Assim, dlopen(“/system/lib/libc.so”)
continua a funcionar, mas os apps vão encontrar
a diferença quando tentarem examinar as bibliotecas carregadas lendo
/proc/self/maps
ou semelhante, o que não é usual, mas descobrimos que
alguns apps fazem isso como parte do processo de combate a hackers. Nesse caso, os caminhos /apex/…
precisam ser adicionados como caminhos válidos para os arquivos Bionic.
Binários/bibliotecas do sistema mapeados para memória somente de execução
A partir do Android 10, os segmentos executáveis de binários e bibliotecas do sistema são mapeados para memória somente de execução (não legível) como uma técnica para aumentar a proteção contra ataques de reutilização de código. O sistema enviará um sinal SIGSEGV
ao seu app caso este execute operações de leitura em segmentos de memória marcados como somente execução, seja por bug, vulnerabilidade ou inspeção intencional da memória.
Você pode identificar se esse comportamento causou uma falha examinando o arquivo de marca de exclusão relacionado em /data/tombstones/
. Uma falha relacionada apenas à execução contém a seguinte mensagem de cancelamento:
Cause: execute-only (no-read) memory access error; likely due to data in .text.
Para contornar esse problema e executar operações como a inspeção de memória, é possível marcar segmentos somente de execução como leitura + execução chamando mprotect()
. No entanto, é altamente recomendável configurá-los novamente como somente de execução em seguida, porque isso proporciona melhor proteção para seu app e seus usuários.
Segurança
O Android 10 inclui as seguintes alterações de segurança.
TLS 1.3 ativado por padrão
No Android 10 e versões mais recentes, o TLS 1.3 é ativado por padrão para todas as conexões TLS. Confira alguns detalhes importantes sobre nossa implementação do TLS 1.3:
- Os conjuntos de criptografia do TLS 1.3 não podem ser personalizados. Os conjuntos de criptografia do TLS 1.3 compatíveis são sempre ativados quando o TLS 1.3 está ativado. Qualquer tentativa de desativá-los chamando
setEnabledCipherSuites()
será ignorada. - Quando o TLS 1.3 é negociado, os objetos
HandshakeCompletedListener
são chamados antes que as sessões sejam adicionadas ao cache da sessão. No TLS 1.2 e em outras versões anteriores, esses objetos são chamados depois que as sessões são adicionadas ao cache da sessão. - Em algumas situações em que as instâncias
SSLEngine
geram umSSLHandshakeException
em versões anteriores do Android, essas instâncias geram umSSLProtocolException
no Android 10 e versões mais recentes. - Não há suporte ao modo 0-RTT.
Se quiser, você pode extrair um SSLContext
que tenha o TLS 1.3 desativado chamando
SSLContext.getInstance("TLSv1.2")
.
Você também pode ativar ou desativar versões de protocolo em cada conexão, chamando setEnabledProtocols()
em um objeto apropriado.
Certificados assinados com SHA-1 não são confiáveis no TLS
No Android 10, os certificados que usam o algoritmo de hash SHA-1 não são confiáveis nas conexões TLS. As CAs raiz não emitem esse certificado desde 2016 e não são mais confiáveis no Chrome nem nos outros principais navegadores.
Qualquer tentativa de conexão falhará se a conexão for com um site que apresente um certificado usando SHA-1.
Mudanças e melhorias no comportamento do KeyChain
Alguns navegadores, como o Google Chrome, permitem que os usuários escolham um certificado quando um servidor TLS envia uma mensagem de solicitação de certificado como parte de um handshake de TLS. No
Android 10,
os objetos KeyChain
respeitam os emissores e
parâmetros de especificação da chave ao chamar KeyChain.choosePrivateKeyAlias()
para
mostrar aos usuários uma solicitação de seleção de certificado. Em particular, esse comando não contém opções que não atendem às especificações do servidor.
Se não houver certificados selecionáveis pelo usuário disponíveis, como acontece quando nenhum certificado corresponde à especificação do servidor ou um dispositivo não possui nenhum certificado instalado, o prompt de seleção de certificado não vai aparecer.
Além disso, não é necessário ter um bloqueio de tela do dispositivo para importar chaves ou certificados de CA para um objeto KeyChain
no Android 10 ou versões posteriores.
Outras mudanças de TLS e criptografia
Houve várias pequenas mudanças nas bibliotecas de TLS e criptografia que entram em vigor no Android 10:
- As criptografias AES/GCM/NoPadding e ChaCha20/Poly1305/NoPadding retornam tamanhos de buffer mais precisos de
getOutputSize()
. - O pacote de criptografia
TLS_FALLBACK_SCSV
é omitido nas tentativas de conexão com um protocolo máximo de TLS 1.2 ou posterior. Devido a melhorias nas implementações do servidor TLS, não recomendamos a tentativa de substituto externo ao TLS. Em vez disso, recomendamos confiar na negociação da versão do TLS. - ChaCha20-Poly1305 é um alias para ChaCha20/Poly1305/NoPadding.
- Nomes de host com pontos à direita não são considerados nomes de host SNI válidos.
- A extensão supported_signature_algorithms em
CertificateRequest
é respeitada ao escolher uma chave de assinatura para respostas de certificado. - Chaves de assinatura opacas, como as do Android Keystore, podem ser usadas com assinaturas RSA-PSS no TLS.
Transmissões do Wi-Fi Direct
No Android 10, as seguintes transmissões relacionadas ao Wi-Fi Direct não são fixas:
Se seu app dependia do recebimento dessas transmissões no momento de registro porque elas eram fixas, use o método get()
apropriado na inicialização para conseguir as informações.
Funções do Wi-Fi Aware
O Android 10 adiciona compatibilidade para facilitar a criação de soquetes TCP/UDP usando os caminhos de dados do Wi-Fi Aware. Para criar um soquete TCP/UDP conectando-o a um ServerSocket
, o dispositivo cliente precisa conhecer o endereço IPv6 e a porta do servidor. Antes da atualização, isso precisava ser comunicado fora da banda, por exemplo, com uma mensagem de camada dupla por BT ou Wi-Fi Aware, ou descoberto dentro da banda com outros protocolos, como mDNS. Com o Android 10, as informações podem ser comunicadas como parte da configuração da rede.
O servidor pode fazer uma destas ações:
- Inicialize um
ServerSocket
e defina ou obtenha a porta a ser usada. - Especificar as informações da porta como parte da solicitação de rede Wi-Fi Aware.
O exemplo de código a seguir mostra como especificar informações de porta como parte da solicitação de rede:
Kotlin
val ss = ServerSocket() val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle) .setPskPassphrase("some-password") .setPort(ss.localPort) .build() val myNetworkRequest = NetworkRequest.Builder() .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE) .setNetworkSpecifier(ns) .build()
Java
ServerSocket ss = new ServerSocket(); WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier .Builder(discoverySession, peerHandle) .setPskPassphrase(“some-password”) .setPort(ss.getLocalPort()) .build(); NetworkRequest myNetworkRequest = new NetworkRequest.Builder() .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE) .setNetworkSpecifier(ns) .build();
Em seguida, o cliente realiza uma solicitação de rede Wi-Fi Aware para conseguir o IPv6 e a porta fornecida pelo servidor:
Kotlin
val callback = object : ConnectivityManager.NetworkCallback() { override fun onAvailable(network: Network) { ... } override fun onLinkPropertiesChanged(network: Network, linkProperties: LinkProperties) { ... } override fun onCapabilitiesChanged(network: Network, networkCapabilities: NetworkCapabilities) { ... val ti = networkCapabilities.transportInfo if (ti is WifiAwareNetworkInfo) { val peerAddress = ti.peerIpv6Addr val peerPort = ti.port } } override fun onLost(network: Network) { ... } }; connMgr.requestNetwork(networkRequest, callback)
Java
callback = new ConnectivityManager.NetworkCallback() { @Override public void onAvailable(Network network) { ... } @Override public void onLinkPropertiesChanged(Network network, LinkProperties linkProperties) { ... } @Override public void onCapabilitiesChanged(Network network, NetworkCapabilities networkCapabilities) { ... TransportInfo ti = networkCapabilities.getTransportInfo(); if (ti instanceof WifiAwareNetworkInfo) { WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti; Inet6Address peerAddress = info.getPeerIpv6Addr(); int peerPort = info.getPort(); } } @Override public void onLost(Network network) { ... } }; connMgr.requestNetwork(networkRequest, callback);
SYSTEM_ALERT_WINDOW em dispositivos Android Go
Apps executados em dispositivos Android 10 (versão Go) não podem receber a permissão
SYSTEM_ALERT_WINDOW
. Isso acontece porque o desenho de janelas de sobreposição usa memória demais e prejudica o desempenho de dispositivos Android com pouca memória.
Se um app executado em um dispositivo Go com o Android 9 ou versões anteriores receber a permissão SYSTEM_ALERT_WINDOW
, o app vai manter a permissão mesmo se o dispositivo for atualizado para o Android 10. No entanto, os apps que ainda não tiverem essa permissão não poderão recebê-la após o upgrade do dispositivo.
Se um app em um dispositivo Go enviar uma intent com a ação
ACTION_MANAGE_OVERLAY_PERMISSION
,
o sistema vai negar automaticamente a solicitação e levar o usuário a uma tela de
Configurações que informa que a permissão não é concedida porque ela
deixa o dispositivo lento. Se um app em um dispositivo Go chamar
Settings.canDrawOverlays()
,
o método sempre vai retornar "false". Novamente, essas restrições não se aplicam a apps
que receberam a permissão SYSTEM_ALERT_WINDOW
antes do upgrade do dispositivo para o Android 10.
Avisos para apps voltados a versões anteriores do Android
Os dispositivos que executam o Android 10 ou versões posteriores avisam os usuários na primeira vez em que executam qualquer app destinado ao Android 5.1 (API de nível 22) ou versões anteriores. Se o app exigir que o usuário conceda permissões, ele também poderá ajustar as permissões do app antes da primeira execução.
Devido aos requisitos de API de destino do Google Play, o usuário vê esses avisos apenas quando executa um app que não foi atualizado recentemente. Para apps distribuídos por outras lojas, requisitos de API de destino semelhantes entram em vigor em 2019. Para saber mais sobre esses requisitos, consulte Aumentar os requisitos de nível de API de destino em 2019 (link em inglês).
Conjuntos de criptografia CBC SHA-2 removidos
Os seguintes conjuntos de criptografia CBC SHA-2 foram removidos da plataforma:
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Esses conjuntos de criptografia são menos seguros do que conjuntos de criptografia semelhantes que usam o GCM. A maior parte dos servidores ou é compatível com as variantes GCM e CBC desses conjuntos ou não é compatível com nenhum deles.
Uso de apps
O Android 10 traz as seguintes mudanças de comportamento relacionadas ao uso de apps:
Melhorias no uso do app UsageStats: o Android 10 agora monitora com precisão o uso de apps com o UsageStats quando eles são usados no modo de tela dividida ou picture-in-picture. Além disso, o Android 10 rastreia corretamente o uso de apps instantâneos.
Escala de cinza por app: o Android 10 pode configurar apps individualmente para um modo de exibição em escala de cinza.
Estado de distração por app: o Android 10 pode definir seletivamente apps para um "estado de distração", em que as notificações são suprimidas e os apps não aparecem como sugeridos.
Suspensão e reprodução: no Android 10, os apps suspensos não podem tocar áudio.
Mudanças na conexão HTTPS
Se um app executado no Android 10 transmitir null
para
setSSLSocketFactory()
,
ocorrerá uma IllegalArgumentException
. Nas versões anteriores, transmitir null
para setSSLSocketFactory()
tinha o mesmo efeito que transmitir a fábrica
padrão atual.
A biblioteca android.preference está obsoleta
A biblioteca android.preference
está obsoleta a partir do Android 10.
Em vez dela, os desenvolvedores precisam usar a biblioteca de preferências do AndroidX, parte do Android Jetpack. Para ver outros recursos que podem ajudar na migração e no desenvolvimento, consulte o Guia de configurações atualizado, assim como nosso app de amostra público (link em inglês) e a documentação de referência.
Mudanças na biblioteca de utilitários de arquivos ZIP
O Android 10 traz as seguintes mudanças nas classes do pacote java.util.zip
, que processa arquivos ZIP. Essas mudanças tornam o comportamento da biblioteca mais consistente entre o Android e outras plataformas que usam java.util.zip
.
Inflater
Em versões anteriores, alguns métodos na classe Inflater
geravam um
IllegalStateException
se fossem
invocados após uma chamada para end()
.
No Android 10, esses métodos geram uma
NullPointerException
.
ZipFile
No Android 10 e versões mais recentes, o construtor de
ZipFile
que usa argumentos do tipo File
, int
e Charset
não gera um
ZipException
se o arquivo ZIP fornecido
não tiver nenhum arquivo.
ZipOutputStream
No Android 10 e versões mais recentes, o método
finish()
em
ZipOutputStream
não gera um
ZipException
se tentar gravar um
fluxo de saída para um arquivo ZIP que não contenha nenhum arquivo.
Mudanças da câmera
Muitos apps que usam câmeras presumem que, se o dispositivo estiver em uma configuração de retrato, o dispositivo físico também estará na orientação de retrato, conforme descrito em Orientação da câmera. No passado, essa era uma suposição segura, mas isso mudou com a expansão dos formatos disponíveis, como dispositivos dobráveis. Nesses dispositivos, essa suposição pode levar a uma exibição rotacionada ou dimensionada incorretamente (ou ambas) no visor da câmera.
Os apps para a API de nível 24 ou posterior precisam definir explicitamente android:resizeableActivity
e fornecer a funcionalidade necessária para operações em várias janelas.
Acompanhamento de uso da bateria
A partir do Android 10,
o SystemHealthManager
redefine
as estatísticas de uso da bateria sempre que o dispositivo é desconectado após um evento de
carga principal. Em termos gerais, um grande evento de carga ocorre quando o dispositivo foi completamente carregado ou quando a carga do dispositivo passou de quase vazia para quase cheia.
Antes do Android 10, as estatísticas de uso da bateria eram redefinidas sempre que o dispositivo era desconectado, independentemente de quão pequena tivesse sido a mudança no nível de bateria.
Obsolescência do Android Beam
No Android 10, estamos oficialmente tornando obsoleto o Android Beam, um recurso antigo para iniciar o compartilhamento de dados entre dispositivos por meio da comunicação a curta distância (NFC, na sigla em inglês). Também estamos suspendendo várias APIs NFC relacionadas. O Android Beam permanece disponível opcionalmente para parceiros de produção de dispositivos que quiserem usá-lo, mas não está mais em desenvolvimento ativo. No entanto, o Android continuará oferecendo compatibilidade para outros recursos e APIs de NFC, e casos de uso como leitura de tags e pagamentos continuarão funcionando conforme o esperado.
Mudança no comportamento de java.math.BigDecimal.stripTrailingZeros()
BigDecimal.stripTrailingZeros()
não preserva mais zeros à direita como um caso especial se o valor de entrada for zero.
Mudanças no comportamento de java.util.regex.Matcher e Pattern
O resultado de split()
foi alterado para não começar mais com um String
vazio
("") quando há uma correspondência de largura zero no início da entrada. Isso também afeta String.split()
. Por exemplo, "x".split("")
agora retorna {"x"}
, enquanto retornava {"", "x"}
em versões mais antigas do Android.
"aardvark".split("(?=a)"
agora retorna {"a", "ardv", "ark"}
em vez de {"", "a", "ardv", "ark"}
.
O comportamento de exceção para argumentos inválidos também foi aprimorado:
appendReplacement(StringBuffer, String)
agora gera umIllegalArgumentException
em vez deIndexOutOfBoundsException
se a substituiçãoString
terminar com uma barra invertida isolada, o que é ilegal. A mesma exceção agora é gerada se a substituiçãoString
terminar com um$
. Antes, nenhuma exceção era gerada nesse cenário.- O
replaceFirst(null)
não chama maisreset()
noMatcher
se ele gerar umNullPointerException
.NullPointerException
também é gerada quando não há correspondência. Antes, ela era gerada apenas quando havia uma correspondência. start(int group)
,end(int group)
egroup(int group)
agora geram umIndexOutOfBoundsException
mais geral se o índice do grupo estiver fora dos limites. Antes, esses métodos geravamArrayIndexOutOfBoundsException
.
O ângulo padrão para GradientDrawable agora é TOP_BOTTOM
No Android 10, se você definir um
GradientDrawable
em XML e não fornecer uma medição de ângulo, a orientação do gradiente
será definida como padrão para
TOP_BOTTOM
.
Essa é uma mudança em relação às versões anteriores do Android, em que o padrão era
LEFT_RIGHT
.
Como solução alternativa, se você atualizar para a versão mais recente do AAPT2, a ferramenta vai definir uma medição de ângulo de 0 para apps legados se nenhuma medição de ângulo for especificada.
Registro de objetos serializados usando o SUID padrão
A partir do Android 7.0 (nível 24 da API), a plataforma fez uma correção
no serialVersionUID
padrão para objetos
serializáveis. Essa correção
não afetou apps direcionados à API de nível 23 ou anterior.
A partir do Android 10, se um app for direcionado ao nível 23 da API ou a versões anteriores
e depender do serialVersionUID
padrão antigo e incorreto, o sistema vai registrar
um aviso e sugerir uma correção de código.
Especificamente, o sistema registra um aviso se todas as condições a seguir forem verdadeiras:
- O app é destinado à API de nível 23 ou anterior.
- Uma classe é serializada.
- A classe serializada usa o
serialVersionUID
padrão, em vez de definir explicitamente umserialVersionUID
. - O
serialVersionUID
padrão é diferente doserialVersionUID
se o app fosse direcionado ao nível 24 da API ou mais recente.
Esse aviso é registrado uma vez para cada classe afetada.
A mensagem de aviso inclui uma correção sugerida, que é definir explicitamente
o serialVersionUID
com o valor padrão que seria calculado se
o app fosse direcionado ao nível 24 da API ou mais recente. Ao usar essa correção, você garante que,
se um objeto dessa classe for serializado em um app destinado à API de nível
23 ou anterior, ele será lido corretamente por apps destinados ao nível 24 ou mais recente,
e vice-versa.
Mudanças em java.io.FileChannel.map()
A partir do Android 10, FileChannel.map()
não é compatível com arquivos que não são padrão, como /dev/zero
, cujo tamanho não pode ser alterado usando truncate()
. As versões anteriores do Android omitiam o errno retornado por
truncate()
, mas o Android 10 gera uma IOException. Se você precisar do comportamento anterior, terá que usar o código nativo.