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

O Android 17 apresenta limites de memória para apps com base na RAM total do dispositivo para criar um ambiente mais estável e determinístico para seus apps e usuários do Android. Esses limites se concentram em vazamentos de memória 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 prevemos 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 uma linha de base para a memória.

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

A documentação Gerenciar a memória do app fornece informações para ajudar a diagnosticar problemas de memória do app e otimizar o consumo de recursos.

Testar o comportamento do app nas restrições de memória

Você pode usar Android Debug Bridge (adb) para ajustar ou desativar os limites de memória em qualquer dispositivo que os imponha. O comando de shell am fornece três subcomandos para ajustar os limites de memória. Esses comandos não têm efeito em um dispositivo que não impõe limites de memória.

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

Instrui o limitador de memória a ignorar alguns ou todos os processos. A transmissão de um UID (ID de usuário do Android) instrui o limitador de memória a ignorar a aplicação em todos os processos associados a esse UID. Você também pode transmitir all (ignorar todos os apps) ou none (não ignorar nenhum app). A transmissão de none substitui todas as chamadas anteriores para am memory-limiter ignore.

Se você instruir o limitador de memória a ignorar um UID, ainda poderá aplicar um limite de memória manual a um processo no app chamando am memory-limiter manual.

manual

Instrui o sistema a impor uma restrição de memória ao processo com o PID (ID do processo) especificado. A restrição de memória é especificada como um número inteiro de MB. Por exemplo, a transmissão de 30 especifica que o processo está limitado a 30 MB de memória. A transmissão de max remove todos os limites de memória nesse processo. A transmissão de none remove todos os limites manuais definidos no processo, restaurando o limite padrão do sistema (se houver).

status

Informa o status atual do limitador de memória. O status inclui os limites de memória impostos a processos visíveis e não visíveis.

Privacidade

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

Proteção de OTP por SMS

Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).

In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.

Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.

During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay. This change applies to all apps, regardless of their target API level.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

Segurança

O Android 17 inclui as seguintes melhorias 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 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 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 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, 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 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

Beginning with Android 17, if an app requests pointer capture using View.requestPointerCapture() and the user uses a touchpad, the system recognizes pointer movement and scrolling gestures from the user's touches and reports them to the app in the same way as pointer and scroll wheel movements from a captured mouse. In most cases, this removes the need for apps that support captured mice to add special handling logic for touchpads. For more details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.

Previously, the system did not attempt to recognize gestures from the touchpad, and instead delivered the raw, absolute finger locations to the app in a similar format to touchscreen touches. If an app still requires this absolute data, it should call the new View.requestPointerCapture(int) method with View.POINTER_CAPTURE_MODE_ABSOLUTE instead.

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