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

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

No momento, se um app iniciar uma intent com um URI que tenha a ação Send, SendMultiple ou ImageCapture, o sistema vai conceder automaticamente as permissões de leitura e gravação de URI ao app de destino. Planejamos mudar esse comportamento no Android 18. Por isso, recomendamos que os apps concedam explicitamente as permissões de URI relevantes em vez de depender do sistema para concedê-las.

Limites de keystore por app

Os apps precisam evitar a criação de 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 ao número de chaves que um app pode ter. O limite é de 50.000 chaves para apps não relacionados ao 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 a que são direcionados.

Se um app tentar criar chaves além do limite, a criação vai falhar com a 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 a que o app é direcionado:

  • Apps direcionados 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.

Experiência do usuário e interface do sistema

O Android 17 inclui as seguintes mudanças 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, 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 virtual de forma programática no método onCreate() da sua 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 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 oferecem suporte a mouses capturados para adicionar uma lógica de tratamento especial para touchpads. Para mais detalhes, consulte a documentação de View.POINTER_CAPTURE_MODE_RELATIVE.

Anteriormente, 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 exigir esses dados absolutos, ele precisará chamar o novo View.requestPointerCapture(int) método com View.POINTER_CAPTURE_MODE_ABSOLUTE em vez disso.

Mídia

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

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

A partir do Android 17, o framework de áudio impõe 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 foco de áudio falha com o código de resultado AUDIOFOCUS_REQUEST_FAILED.

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

Conectividade

O Android 17 inclui as seguintes mudanças 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