Mudanças de comportamento: todos os apps

O Android 10 inclui mudanças de comportamento que podem afetar seu app. As mudanças listadas nesta página se aplicam ao app quando ele é executado no Android 10, independentemente da targetSdkVersion dele. Você deve testar e modifique o app conforme necessário para oferecer suporte a essas mudanças corretamente.

Se a targetSdkVersion do app for 29 ou mais recente, também será necessário e oferecer suporte a outras mudanças. Leia as mudanças de comportamento para apps segmentando 29 para mais detalhes.

Observação : além das mudanças listadas nesta página, o Android 10 introduziu várias 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 Alterações de 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 que seu app pode usar no Android 9 (nível 28 da API). O Android 10 inclui listas atualizadas de interfaces não SDK restritas com base na colaboração com desenvolvedores do Android e nos testes internos mais recentes. Nosso objetivo é garantir que o público alternativas estão disponíveis antes de restringirmos as interfaces que não fazem parte do SDK.

Caso seu app não seja destinado ao Android 10 (nível 29 da API), algumas dessas mudanças pode não afetá-lo 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 sabe se o app usa interfaces não SDK, teste-o para descobrir. Caso seu app dependa de interfaces externas ao SDK, comece a planejar uma para SDKs alternativos. No entanto, entendemos que alguns apps têm casos de uso válidos para interfaces não SDK. Se você não encontrar uma alternativa para usar uma interface externa ao SDK para um recurso no seu app, é necessário solicitar uma nova API pública.

Para saber mais, consulte Atualizações para restrições de interface não SDK no Android 10. e consulte Restrições para interfaces que não sã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, você poderá estender o conteúdo do app de ponta a ponta e processar adequadamente gestos conflitantes. Para mais informações, consulte Navegação por gestos. na documentação do Google Cloud.

NDK

O Android 10 inclui as alterações do NDK descritas a seguir.

Objetos compartilhados não podem conter realocações de texto

O uso não permitido no Android 6.0 (API de nível 23) de realocações de texto em objetos compartilhados. O código precisa ser carregado como está e não pode ser modificada. 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. Se esses apps continuarem a usar objetos compartilhados que contenham texto realocações, eles correm alto risco de serem corrompidos.

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. Apps que dependem dos caminhos serem arquivos normais pode falhar:

• /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 também se aplicam à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. Então, O app dlopen(“/system/lib/libc.so”) continua funcionando, mas os apps vão encontrar a diferença quando eles realmente tentam examinar as bibliotecas carregadas lendo /proc/self/maps ou similar, o que não é comum, mas descobrimos que alguns aplicativos fazem isso como parte de seu processo anti-hacking. Nesse caso, o 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, segmentos executáveis de binários do sistema e as bibliotecas são mapeadas na memória somente de execução (não legível) como uma camada contra ataques de reutilização de código. Se o app executar operações de leitura segmentos de memória marcados como somente execução, seja por bug, vulnerabilidade ou Inspeção intencional da memória: o sistema envia um sinal SIGSEGV ao app.

Você pode identificar se esse comportamento causou uma falha examinando o arquivo tombstone em /data/tombstones/. Falha relacionada somente à 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 realizar operações como inspeção de memória, é marcar segmentos somente de execução como leitura+execução chamando mprotect(): No entanto, recomendamos que você o defina novamente como somente executar depois, já que essa configuração de permissão de acesso proporciona melhores para seu app e seus usuários.

Observação: chamadas para ptrace não são afetadas por esse comportamento, permitindo que você para depurar ptrace.

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 todos conexões TLS. Confira alguns detalhes importantes sobre o TLS 1.3 implementação:

• Os conjuntos de criptografia do TLS 1.3 não podem ser personalizados. A criptografia TLS 1.3 com suporte os pacotes são sempre ativados quando o TLS 1.3 está ativado. Qualquer tentativa de desativar eles chamando setEnabledCipherSuites() é ignorado.
• Quando o TLS 1.3 é negociado, HandshakeCompletedListener Os objetos são chamados antes da adição das sessões 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 de SSLEngine geram uma SSLHandshakeException ativado versões anteriores do Android, essas instâncias geram SSLProtocolException no Android 10 e versões mais recentes.
• Não há suporte ao modo 0-RTT.

Se quiser, você pode acessar 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 Ligando para 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 ACs raiz não emitiram esse certificado desde 2016 e não são mais confiáveis no Chrome nem em outros grandes navegadores.

Qualquer tentativa de conexão falhará se a conexão for com um site que apresente uma 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 O servidor TLS envia uma mensagem de solicitação de certificado como parte de um handshake de TLS. A partir de O Android 10 Os objetos KeyChain respeitam os emissores e principais parâmetros de especificação 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 não há os certificados correspondam à especificação do servidor ou um dispositivo não tiver nenhum certificados instalados, o prompt de seleção de certificado não será exibido.

Além disso, não é necessário ter uma bloqueio de tela do dispositivo para importar chaves ou certificados de CA para um objeto KeyChain.

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 mais tamanhos de buffer precisos de getOutputSize().
• O pacote de criptografia TLS_FALLBACK_SCSV é omitido das tentativas de conexão com um protocolo máximo de TLS 1.2 ou superior. Devido a melhorias no servidor TLS implementações, não recomendamos a tentativa de substituto externo ao TLS. Em vez disso, use a negociação de versões 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 é respeitadas 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 em TLS.

Transmissões do Wi-Fi Direct

No Android 10, as seguintes transmissões são relacionadas a Wi-Fi Direct não são fixas:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Se seu aplicativo depende do recebimento dessas transmissões no momento de registro porque que eram fixas, use o método get() apropriado na inicialização para para conseguir as informações.

Funções do Wi-Fi Aware

O Android 10 adiciona suporte para facilitar a criação de soquetes TCP/UDP usando o Wi-Fi Aware os caminhos de dados. Para criar um soquete TCP/UDP conectado a um ServerSocket, o cliente dispositivo precisa saber o endereço IPv6 e a porta do servidor. Isso antes precisa ser comunicada fora de banda, por exemplo, usando BT ou camada Wi-Fi Aware 2 ou descobertas in-band usando outros protocolos, como mDNS. Com No 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 receba 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();

O cliente então realiza uma solicitação de rede Wi-Fi Aware para obter 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 muita memória, o que prejudica o desempenho de sistemas operacionais Android com pouca memória dispositivos.

Se um aplicativo executado em um dispositivo Go com o Android 9 ou anterior receber o SYSTEM_ALERT_WINDOW, o app vai manter a permissão mesmo se a seu dispositivo recebeu um upgrade 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 nega a solicitação automaticamente e leva o usuário a uma Configurações informando que a permissão não é concedida porque deixa o dispositivo mais lento. Se um app em um dispositivo Go chamar Settings.canDrawOverlays(), o método sempre retornará o valor "falso". 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

Dispositivos com o Android 10 ou versões mais recentes enviam um aviso aos usuários pela primeira vez. executam qualquer aplicativo destinado ao Android 5.1 (API de nível 22) ou anterior. Se o app exigir que o usuário conceda permissões, o usuário também poderá ajustar as permissões do app antes da primeira execução.

Devido à API de destino do Google Play requisitos, Um usuário vê esses avisos somente quando executa um app que não foi atualizado. recentemente. Para apps distribuídos por outras lojas, APIs de destino semelhantes entrar em vigor em 2019. Para mais informações sobre requisitos, consulte Como expandir os requisitos de nível desejado da API em de 2019.

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 os conjuntos semelhantes que usam o GCM. e a maioria dos servidores é compatível com as variantes GCM e CBC dessa cifra ou oferecer suporte a nenhum deles.

Observação: apps e bibliotecas precisam cruzar o conjunto de criptografia desejado. suítes com o valor de retorno de getSupportedCipherSuites() para preparar a seleção de pacotes de criptografia para remoções futuras.

Uso de apps

O Android 10 traz as seguintes mudanças de comportamento relacionadas ao uso de apps:

• Melhorias de uso do app UsageStats: O Android 10 monitora com precisão o uso de apps com UsageStats quando os apps são usada 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 definir um modo de exibição em escala de cinza por app.

• Estado de distração por app: O Android 10 pode definir apps seletivamente para um "estado de distração" em que as notificações são suprimidas e eles não aparecem como apps 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 com o Android 10 transmitir null para setSSLSocketFactory(), um IllegalArgumentException de segurança. Nas versões anteriores, transmitir null para setSSLSocketFactory() teve o mesmo efeito que transmitir o texto padrão atual fábrica.

A biblioteca android.preference está obsoleta

A biblioteca android.preference foi descontinuada no Android 10. Em vez disso, os desenvolvedores devem usar a biblioteca de preferências do AndroidX, parte do Android Jetpack. Para mais recursos que ajudam na migração e desenvolvimento, confira a versão atualizada da Configurações Guia junto com nosso exemplo público app e documentação de referência.

Mudanças na biblioteca de utilitários de arquivos ZIP

O Android 10 apresenta as mudanças abaixo nas classes da java.util.zip. que lida com arquivos ZIP. Essas mudanças tornam o comportamento da biblioteca mais consistente entre o Android e outras plataformas que usam java.util.zip.

Inflater

Nas versões anteriores, alguns métodos na classe Inflater geravam uma IllegalStateException se eles 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 recebe argumentos do tipo File, int e Charset não gera uma ZipException se o arquivo ZIP fornecido não contiver arquivos.

ZipOutputStream

No Android 10 e versões mais recentes, a O método finish() em ZipOutputStream não gera ZipException se ele tentar gravar uma stream de saída de um arquivo ZIP que não contém nenhum arquivo.

Mudanças da câmera

Muitos aplicativos que usam a câmera presumem que, se o dispositivo estiver no modo retrato, o dispositivo físico também estará na orientação retrato, como descrito em Orientação da câmera. Essa era uma suposição segura no passado, mas que tem mudou com a expansão dos formatos disponíveis, como dobráveis. Isso nesses dispositivos pode resultar em rotação ou escala incorreta (ou exibição do visor da câmera.

Os aplicativos direcionados ao nível 24 da API ou mais recente devem definir explicitamente android:resizeableActivity e fornecem a funcionalidade necessária para lidar operação de várias janelas.

Acompanhamento de uso da bateria

A partir do Android 10, SystemHealthManager redefinições suas estatísticas de uso da bateria sempre que o dispositivo for desconectado após uma grande evento de carregamento. Em termos gerais, um grande evento de carregamento é: o dispositivo foi totalmente carregado ou o dispositivo passou de quase cheio para quase todo carregado.

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 descontinuando o Android Beam, um recurso mais antigo iniciar o compartilhamento de dados entre dispositivos por meio de comunicação a curta distância (NFC, na sigla em inglês). Também estamos descontinuando várias das APIs de NFC relacionadas. O Android Beam permanece disponível opcionalmente para parceiros de produção de dispositivos que queiram usá-lo, mas não está mais em desenvolvimento ativo. O Android vai continuar oferecendo suporte a outros dispositivos capacidades e APIs, e casos de uso como leitura de tags e os pagamentos continuarão funcionando conforme esperado.

Mudança de 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 houver uma correspondência de largura zero no início da entrada. Isso também afeta String.split(). Por exemplo, "x".split("") agora retorna {"x"}. Ela costumava retornar {"", "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 uma IllegalArgumentException em vez de IndexOutOfBoundsException se a substituição String terminar com um único caractere de barra invertida, o que é ilegal. O A mesma exceção será gerada se a String de substituição terminar com um $. Anteriormente, nenhuma exceção era gerada nesse cenário.
• O replaceFirst(null) não chama mais reset() no Matcher se gerar uma NullPointerException. NullPointerException agora também é gerado quando há não há correspondência. Antes, ele era gerado apenas quando havia uma correspondência.
• start(int group), end(int group) e group(int group) agora geram uma general IndexOutOfBoundsException se o índice do grupo estiver fora dos limites. Anteriormente, esses métodos geravam ArrayIndexOutOfBoundsException.

O ângulo padrão para GradientDrawable agora é TOP_BOTTOM

No Android 10, se você definir uma GradientDrawable em XML e não fornecerem uma medida de ângulo, a orientação de gradiente o padrão é TOP_BOTTOM Isso é diferente das 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 define uma medida de ângulo de 0 para aplicativos legados se nenhum ângulo medida é especificada.

Como gerar registros de objetos serializados usando o SUID padrão

No Android 7.0 (nível 24 da API) e versões mais recentes, a plataforma corrigiu para o padrão serialVersionUID para serializáveis objetos. Esta correção não afetou os apps direcionados ao nível 23 da API ou anterior.

No Android 10 e versões mais recentes, se um app for direcionado ao nível 23 da API ou anterior e depender da serialVersionUID padrão antiga e incorreta, o sistema vai registrar um aviso e sugerir uma correção de código.

Especificamente, o sistema registrará 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 um serialVersionUID.
• O serialVersionUID padrão é diferente do serialVersionUID seria se o app segmentasse o nível 24 da API ou mais recente.

Esse aviso é registrado uma vez para cada classe afetada. A mensagem de aviso inclui uma sugestão de correção, que é definir o serialVersionUID como o valor padrão que seria calculado se o app segmentado para o 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 direcionado ao nível da API 23 ou anterior, o objeto será lido corretamente por apps segmentados para 24 ou mais recente. e vice-versa.

java.io.FileChannel.map() muda

A partir do Android 10, o FileChannel.map() não é compatível com arquivos não padrão, como /dev/zero, cujo tamanho não pode ser alterado usando truncate(). Anterior do Android engoliram o erro retornado por truncate(), mas o Android 10 gera uma IOException. Se você precisar do comportamento antigo, use o código nativo.