Mudanças de comportamento: todos os apps

A plataforma Android 17 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento a seguir se aplicam a todos os apps quando executados no Android 17, independente de targetSdkVersion. Teste seu app e modifique-o conforme necessário para ficar compatível com essas mudanças, se necessário.

Consulte também a lista de mudanças de comportamento que afetam apenas os apps destinados ao Android 17.

Funcionalidade principal

O Android 17 (nível 37 da API) inclui as mudanças a seguir que modificam ou expandem vários recursos principais do sistema Android.

Limites de memória do app

O Android 17 introduz limites de memória de apps com base na RAM total do dispositivo para criar um ambiente mais estável e determinístico para seus aplicativos e usuários do Android. No Android 17, os limites são definidos de forma conservadora para estabelecer valores de referência do sistema, visando vazamentos de memória extremos e outros outliers antes que eles causem instabilidade em todo o sistema, resultando em renderização lenta da interface, consumo elevado da bateria e encerramento de apps. Embora prevejamos um impacto mínimo na grande maioria das sessões de apps, recomendamos as práticas recomendadas de memória a seguir, incluindo o estabelecimento de um valor de referência para a memória.

Para determinar se a sessão do app foi afetada, chame getDescription em ApplicationExitInfo. Se o app foi afetado, o motivo da saída será REASON_OTHER e a descrição vai conter a string "MemoryLimiter:AnonSwap", além de outras informações. Também é possível usar o criação de perfil com base em gatilhos com TRIGGER_TYPE_ANOMALY para receber despejos de heap coletados quando o limite de memória é atingido.

A tarefa do LeakCanary no Android Studio Profiler.

Para ajudar você a encontrar vazamentos de memória, o Android Studio Panda adiciona a integração do LeakCanary diretamente no Android Studio Profiler como uma tarefa dedicada, contextualizada no ambiente de desenvolvimento integrado e totalmente integrada ao seu código-fonte.

Privacidade

O Android 17 inclui as mudanças a seguir para melhorar a privacidade do usuário.

Proteção de OTP por SMS

从 Android 17 开始，Android 将扩大对包含一次性密码 (OTP) 的短信的保护范围。

在之前的 Android 版本中，此保护主要侧重于 SMS Retriever 格式。对于大多数应用，包含 SMS Retriever 哈希的消息的递送延迟了 3 小时。不过，某些特定应用（例如默认短信处理程序）不受此延迟的影响，拥有哈希的应用也不受此延迟的影响。

从 Android 17 开始，此保护也适用于 WebOTP 格式的消息。如果应用有权读取短信，但不是 WebOTP 消息的预期接收者（由网域验证确定），则该应用在收到消息后 3 小时内无法访问该消息。此变更旨在提高用户安全性，确保只有与消息中提及的网域关联的应用才能以程序化方式读取验证码。

在这 3 小时的延迟期间，系统会保留 SMS_RECEIVED_ACTION 广播，并过滤 短信提供商 数据库查询。延迟结束后，这些应用即可使用短信。此变更适用于 所有应用，无论其目标 API 级别如何。

某些应用（例如默认短信辅助应用、已连接设备配套应用等）不受此延迟的影响。所有依赖于读取短信 来提取 动态密码 的应用都应过渡到使用 SMS Retriever 或 SMS User Consent API，以确保功能持续可用。

Segurança

O Android 17 inclui as melhorias a seguir na segurança de dispositivos e apps.

Plano de descontinuação de usesClearTraffic

In a future release, we plan to deprecate the usesCleartextTraffic element. Apps that need to make unencrypted (HTTP) connections should migrate to using a network security configuration file, which lets you specify which domains your app needs to make cleartext connections to.

Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:

  • Set the usesCleartextTraffic attribute to true
  • Use a network configuration file

If your app's minimum API level is 24 or higher, you can use a network configuration file and you don't need to set usesCleartextTraffic.

Restrição das concessões implícitas de URI

No momento, se um app iniciar uma intent com um URI que tenha a ação ACTION_SEND, ACTION_SEND_MULTIPLE ou ACTION_IMAGE_CAPTURE, o sistema concederá automaticamente as permissões de leitura e gravação de URI ao app de destino. A partir do Android 18, o sistema não concederá mais essas permissões automaticamente. Por isso, recomendamos que os apps concedam explicitamente as permissões de URI relevantes em vez de confiar no sistema para concedê-las.

Para detectar o uso dessas intents no seu app, use StrictMode com detectImplicitUriPermissionGrant() para acionar uma violação:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

Como alternativa, você pode monitorar exceções registradas que contenham a mensagem Please set the grant explicitly in the app que aparece quando o sistema define implicitamente a concessão. Você pode monitorar esses registros usando o seguinte comando adb:

adb logcat | grep "Please set the grant explicitly in the app"

Para conceder explicitamente as permissões necessárias, adicione a FLAG_GRANT_READ_URI_PERMISSION flag às intents ACTION_SEND e ACTION_SEND_MULTIPLE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Inclua as flags FLAG_GRANT_READ_URI_PERMISSION e FLAG_GRANT_WRITE_URI_PERMISSION para ACTION_IMAGE_CAPTURE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Limites de keystore por app

Os apps precisam evitar criar um número excessivo de chaves no Android Keystore, porque ele é um recurso compartilhado para todos os apps no dispositivo. A partir do Android 17, o sistema impõe um limite no número de chaves que um app pode ter. O limite é de 50.000 chaves para apps que não são do sistema direcionados ao Android 17 (nível 37 da API) ou versões mais recentes e de 200.000 chaves para todos os outros apps. Os apps do sistema têm um limite de 200.000 chaves, independentemente do nível da API que segmentam.

Se um app tentar criar chaves além do limite, a criação vai falhar com um KeyStoreException. A string de mensagem da exceção contém informações sobre o limite de chaves. Se o app chamar getNumericErrorCode() na exceção, o valor de retorno vai depender do nível da API segmentado pelo app:

  • Apps destinados ao Android 17 (nível 37 da API) ou versões mais recentes: getNumericErrorCode() retorna o novo valor ERROR_TOO_MANY_KEYS.
  • Todos os outros apps: getNumericErrorCode() retorna ERROR_INCORRECT_USAGE.

Bloquear tráfego de loopback de perfil unificado

A partir do Android 17, o tráfego de loopback entre perfis não é mais permitido por padrão. O tráfego de loopback no mesmo perfil não é afetado. Essa mudança se aplica a todos os apps executados no Android 17 ou mais recente, independentemente do nível da API a que o app se destina.

Experiência do usuário e interface do sistema

O Android 17 inclui as mudanças a seguir que têm como objetivo criar uma experiência do usuário mais consistente e intuitiva.

Restauração da visibilidade padrão do IME após a rotação

A partir do Android 17, quando a configuração do dispositivo muda (por exemplo, devido à rotação) e isso não é processado pelo próprio app, a visibilidade anterior do IME não é restaurada.

Se o app passar por uma mudança de configuração que ele não processa e precisar que o teclado fique visível após a mudança, você precisará solicitar isso explicitamente. É possível fazer essa solicitação de uma das seguintes maneiras:

  • Defina o atributo android:windowSoftInputMode como stateAlwaysVisible.
  • Solicite o teclado de software de maneira programática no método onCreate() da atividade ou adicione o método onConfigurationChanged().

Contribuição humana

O Android 17 inclui as mudanças a seguir que afetam a forma como os apps interagem com dispositivos de entrada humana, como teclados e touchpads.

Os touchpads oferecem eventos relativos por padrão durante a captura do ponteiro

A partir do Android 17, se um app solicitar a captura de ponteiro usando View.requestPointerCapture() e o usuário usar um touchpad, o sistema reconhecerá o movimento do ponteiro e os gestos de rolagem dos toques do usuário e os informará ao app da mesma forma que os movimentos do ponteiro e da roda de rolagem de um mouse capturado. Na maioria dos casos, isso elimina a necessidade de apps que suportam mouses capturados adicionarem uma lógica de processamento especial para touchpads. Para mais detalhes, consulte a documentação de View.POINTER_CAPTURE_MODE_RELATIVE.

Antes, o sistema não tentava reconhecer gestos do touchpad e, em vez disso, entregava ao app os locais absolutos e brutos dos dedos em um formato semelhante aos toques na tela sensível ao toque. Se um app ainda precisar desses dados absolutos, ele deverá chamar o novo método View.requestPointerCapture(int) com View.POINTER_CAPTURE_MODE_ABSOLUTE.

Mídia

O Android 17 inclui as mudanças a seguir no comportamento da mídia.

Reforço da proteção de áudio em segundo plano

A partir do Android 17, o framework de áudio aplica restrições às interações de áudio em segundo plano, incluindo reprodução de áudio, solicitações de foco de áudio e APIs de mudança de volume, para garantir que essas mudanças sejam iniciadas intencionalmente pelo usuário.

Se o app tentar chamar APIs de áudio enquanto não estiver em um ciclo de vida válido, as APIs de reprodução de áudio e mudança de volume falharão silenciosamente, sem gerar uma exceção ou fornecer uma mensagem de falha. A API de seleção de áudio falha com o código de resultado AUDIOFOCUS_REQUEST_FAILED.

Para mais informações, incluindo estratégias de mitigação, consulte Reforço da proteção de áudio em segundo plano.

Conectividade

O Android 17 inclui as mudanças a seguir para melhorar a conectividade do dispositivo.

Novo pareamento autônomo para perdas de vínculo Bluetooth

O Android 17 apresenta o pareamento autônomo, uma melhoria no nível do sistema projetada para resolver automaticamente a perda de pareamento do Bluetooth.

Antes, se uma conexão fosse perdida, os usuários precisavam acessar manualmente as configurações para desparear e parear novamente o periférico. Esse recurso se baseia na melhoria de segurança do Android 16, permitindo que o sistema restabeleça conexões em segundo plano sem exigir que os usuários naveguem manualmente até as configurações para desconectar e reconectar periféricos.

Embora a maioria dos apps não exija mudanças de código, os desenvolvedores precisam estar cientes das seguintes mudanças de comportamento na pilha Bluetooth:

  • Novo contexto de pareamento:o ACTION_PAIRING_REQUEST agora inclui o extra EXTRA_PAIRING_CONTEXT, que permite que os apps distingam entre um pedido de pareamento padrão e uma tentativa de repareamento autônoma iniciada pelo sistema.
  • Atualizações condicionais de chaves:as chaves de segurança atuais só serão substituídas se o novo pareamento for bem-sucedido e a nova conexão atender ou exceder o nível de segurança da conexão anterior.
  • Mudança no tempo da intent:a intent ACTION_KEY_MISSING agora é transmitida apenas se a tentativa de pareamento autônomo falhar. Isso reduz o tratamento de erros desnecessário no app se o sistema recuperar a vinculação em segundo plano.
  • Notificação do usuário:o sistema gerencia o pareamento novamente por novas notificações e caixas de diálogo da interface. Os usuários vão precisar confirmar a tentativa de repareamento para garantir que eles estejam cientes da reconexão.

Os fabricantes de dispositivos periféricos e os desenvolvedores de apps complementares precisam verificar se o hardware e o app processam as transições de vinculação corretamente. Para testar esse comportamento, simule uma perda de vinculação remota usando um dos seguintes métodos:

  • Remova manualmente as informações de vinculação do dispositivo periférico.
  • Desvincule manualmente o dispositivo em: Configurações > Dispositivos conectados