Mudanças de comportamento: todos os apps

A plataforma Android 17 inclui mudanças de comportamento que podem afetar seu app. As mudanças a seguir se aplicam a todos os apps quando executados no Android 17, independente da targetSdkVersion. Teste o app e modifique-o conforme necessário para oferecer suporte a 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.

Principal recurso

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

Limites de memória para apps

Android 17 introduces app memory limits based on the device's total RAM to create a more stable and deterministic environment for your apps and Android users. These limits focus on memory leaks and other outliers before they trigger system-wide instability resulting in UI stuttering, higher battery drain, and apps being killed. While we anticipate minimal impact on the vast majority of app sessions, we recommend the following memory best practices, including establishing a baseline for memory.

You can determine if your app session was impacted by calling getDescription in ApplicationExitInfo; if your app was affected, the exit reason will be REASON_OTHER and the description will contain the string "MemoryLimiter:AnonSwap" along with other information. You can also use trigger-based profiling with TRIGGER_TYPE_ANOMALY to get heap dumps that are collected when the memory limit is hit.

The Manage your app's memory documentation gives information to help you diagnose your app's memory issues and optimize its resource consumption.

Test your app's behavior under the memory constraints

You can use Android Debug Bridge (adb) to adjust or disable the memory limits on any device that imposes them. The shell command am provides three subcommands to adjust the memory limits. (These commands have no effect on a device which does not impose memory limits.)

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

Instructs the memory limiter to ignore some or all processes. Passing a UID (Android User ID) instructs the memory limiter to ignore enforcement on all processes associated with that UID. You can also pass all (ignore all apps) or none (do not ignore any apps). Passing none overrides any previous calls to am memory-limiter ignore.

If you instruct the memory limiter to ignore a UID, you can still apply a manual memory limit to a process within the app by calling am memory-limiter manual.

manual

Instructs the system to impose a memory constraint on the process with the specified PID (Process ID). The memory constraint is specified as an integer number of MB; for example, passing 30 specifies that the process is limited to 30 MB of memory. Passing max removes all memory limits on that process. Passing none removes any manual limits set on the process, restoring the system's default limit (if any).

status

Reports the current status of the memory limiter. The status includes the memory limits imposed on visible and non-visible processes.

Privacidade

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

Proteção de OTP por SMS

A partir do Android 17, o sistema operacional vai ampliar a proteção para mensagens SMS que contêm senhas únicas (OTP).

Em versões anteriores do Android, essa proteção se concentrava principalmente no formato do SMS Retriever. A entrega de mensagens com um hash do SMS Retriever foi atrasada por três horas para a maioria dos apps. No entanto, alguns apps (como o processador de SMS padrão) foram isentos do atraso, e o app proprietário do hash também foi isento.

A partir do Android 17, a proteção também é aplicada a mensagens no formato WebOTP. Se um app tiver permissão para ler mensagens SMS, mas não for o destinatário pretendido de uma mensagem WebOTP (conforme determinado pela verificação de domínio), a mensagem não ficará acessível ao app até três horas após o recebimento. O objetivo dessa mudança é melhorar a segurança do usuário, garantindo que apenas apps associados ao domínio mencionado na mensagem possam ler o código de verificação de forma programática.

Durante esse atraso de três horas, a transmissão SMS_RECEIVED_ACTION é retida e as consultas do banco de dados do provedor de SMS são filtradas. A mensagem SMS fica disponível para esses apps após o atraso. Essa mudança se aplica a todos os apps, independentemente do nível desejado da API.

Alguns apps, como o assistente de SMS padrão, apps complementares de dispositivos conectados etc., são isentos desse atraso. Todos os apps que dependem da leitura de mensagens SMS para extração de senhas únicas precisam migrar para o uso das APIs SMS Retriever ou Consentimento do usuário de SMS para garantir a continuidade da funcionalidade.

Segurança

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

Plano de descontinuação de usesClearTraffic

Em uma versão futura, planejamos descontinuar o elemento usesCleartextTraffic. Os apps que precisam fazer conexões não criptografadas (HTTP) devem migrar para usar um arquivo de configuração de segurança de rede, que permite especificar a quais domínios o app precisa fazer conexões de texto não criptografado.

Os arquivos de configuração de segurança de rede só são compatíveis com níveis de API 24 e mais recentes. Se o nível mínimo da API do seu app for inferior a 24, faça ambos os procedimentos a seguir:

  • Defina o atributo usesCleartextTraffic como true.
  • Usar um arquivo de configuração de rede

Se o nível mínimo da API do app for 24 ou mais recente, você poderá usar um arquivo de configuração de rede e não precisará definir usesCleartextTraffic.

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

Atualmente, 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 vai mais conceder essas permissões automaticamente. Por isso, recomendamos que os apps concedam explicitamente as permissões de URI relevantes em vez de depender do sistema para isso.

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, monitore 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. É possível 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 FLAG_GRANT_READ_URI_PERMISSION à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 intents ACTION_IMAGE_CAPTURE:

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 segmentado.

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 mais recente: getNumericErrorCode() retorna o novo valor ERROR_TOO_MANY_KEYS.
  • Todos os outros apps: getNumericErrorCode() retorna ERROR_INCORRECT_USAGE.

Bloquear o tráfego de loopback entre perfis unificados

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 versões mais recentes, independente do nível da API a que o app é destinado.

Experiência do usuário e interface do sistema

O Android 17 inclui as seguintes mudanças que visam 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, por 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 não é processada e precisar que o teclado fique visível após a mudança, você precisará solicitar isso explicitamente. Você pode fazer essa solicitação de uma das seguintes maneiras:

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

Entrada humana

O Android 17 inclui as seguintes mudanças 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 de 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 os locais absolutos e brutos dos dedos ao app 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 seguintes mudanças no comportamento de mídia.

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

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

For more information, including mitigation strategies, see Background audio hardening.

Conectividade

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

Novo pareamento autônomo para perdas de vinculação 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 os 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 de intenção:a intenção 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 pareamento 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 conexã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