Mudanças de comportamento: apps destinados ao Android 13 ou a versões mais recentes

Como nas versões anteriores, o Android 13 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento abaixo se aplicam exclusivamente a apps destinados ao Android 13 ou versões mais recentes. Caso seu app seja direcionado ao Android 13 ou a versões mais recentes, faça modificações para oferecer suporte a esses comportamentos de forma adequada, quando aplicável.

Consulte também a lista de mudanças de comportamento que afetam todos os apps executados no Android 13.

Privacidade

A permissão de notificação afeta a aparência do serviço em primeiro plano

Se o usuário negar a permissão de notificação, ele não vai receber avisos relacionados a serviços em primeiro plano na gaveta de notificações. No entanto, os usuários ainda vão receber avisos relacionados a serviços em primeiro plano no Gerenciador de tarefas, independente de a permissão de notificação ser concedida ou não.

Nova permissão de execução para dispositivos Wi-Fi por perto

Nas versões anteriores do Android, o usuário precisa conceder ao app a permissão ACCESS_FINE_LOCATION para concluir vários casos de uso comuns de Wi-Fi.

Como é difícil para os usuários associar permissões de localização à funcionalidade Wi-Fi, o Android 13 (nível 33 da API) introduz uma nova permissão de execução no grupo de permissões NEARBY_DEVICES para apps que gerenciam as conexões de um dispositivo a pontos de acesso Wi-Fi por perto. Essa permissão, NEARBY_WIFI_DEVICES, atende a casos de uso de Wi-Fi como estes:

• Encontrar ou se conectar a dispositivos por perto, como impressoras ou dispositivos de transmissão de mídia. Esse fluxo de trabalho permite que o app execute estes tipos de tarefas:
  • Receber informações de AP fora da banda, como por BLE.
  • Descobrir e se conectar a dispositivos pelo Wi-Fi Aware e conexão usando um ponto de acesso somente local.
  • Descobrir e se conectar a dispositivos pelo Wi-Fi Direct.
• Iniciar uma conexão com um SSID conhecido, como um carro ou dispositivo de casa inteligente.
• Iniciar um ponto de acesso somente local.
• Se conectar a dispositivos por perto com o Wi-Fi Aware.

Contanto que o app não receba informações de localização física das APIs de Wi-Fi, solicite NEARBY_WIFI_DEVICES, em vez de ACCESS_FINE_LOCATION, quando o app for destinado ao Android 13 ou a versões mais recentes e use APIs de Wi-Fi. Ao declarar a permissão NEARBY_WIFI_DEVICES, declare explicitamente que o app nunca gera informações de localização física das APIs de Wi-Fi. Para fazer isso, defina o atributo android:usesPermissionFlags como neverForLocation. Esse processo é parecido com o que é feito no Android 12 (nível 31 da API) e versões mais recentes ao declarar que as informações do dispositivo Bluetooth nunca são usadas para localização.

Observação: essa mudança só vai afetar o app se você chamar uma API de Wi-Fi. Confira a lista de APIs afetadas.

Saiba mais sobre como solicitar permissão para acessar dispositivos Wi-Fi por perto.

Permissões de mídia granulares

Figura 1. Caixa de diálogo de permissões do sistema mostrada ao usuário ao solicitar a permissão READ_MEDIA_AUDIO.

Caso o app seja destinado ao Android 13 ou versões mais recentes e precise acessar arquivos de mídia criados por outros apps, solicite uma ou mais das permissões de mídia granulares abaixo em vez da permissão READ_EXTERNAL_STORAGE:

Tipo de mídia	Permissão necessária
Imagens e fotos	READ_MEDIA_IMAGES
Vídeos	READ_MEDIA_VIDEO
Arquivos de áudio	READ_MEDIA_AUDIO

Antes de acessar os arquivos de mídia de outro app, verifique se o usuário concedeu as permissões de mídia granulares adequadas ao seu app.

A Figura 1 mostra um app que solicita a permissão READ_MEDIA_AUDIO.

Se você solicitar a permissão READ_MEDIA_IMAGES e READ_MEDIA_VIDEO ao mesmo tempo, apenas uma caixa de diálogo vai aparecer.

Se o app já tiver recebido a permissão READ_EXTERNAL_STORAGE, todas as permissões READ_MEDIA_* solicitadas serão concedidas automaticamente durante a atualização. Use o seguinte comando adb para analisar as permissões atualizadas:

adb shell cmd appops get --uid PACKAGE_NAME

Observação: caso o app precise acessar imagens, fotos e vídeos, recomendamos usar o seletor de fotos em vez de declarar as permissões READ_MEDIA_IMAGES e READ_MEDIA_VIDEO.

O uso de sensores corporais em segundo plano exige uma nova permissão

O Android 13 introduz o conceito de "acesso durante o uso" para sensores corporais, como frequência cardíaca, temperatura e percentual de oxigênio no sangue. Esse modelo de acesso é bastante parecido com o introduzido pelo sistema para informações de local no Android 10 (nível 29 da API).

Se o app for destinado ao Android 13 e exigir acesso a informações do sensor corporal durante a execução em segundo plano, vai ser necessário declarar a nova permissão BODY_SENSORS_BACKGROUND, além da permissão BODY_SENSORS existente.

Observação: essa é uma permissão com fortes restrições, que não pode ser concedida ao app até que o instalador do dispositivo libere a permissão. Para mais informações, consulte este guia sobre permissões restritas.

Performance e bateria

Uso de recursos da bateria

Se o usuário colocar seu app no estado "restrito" para o uso de bateria em segundo plano, quando seu app for direcionado ao Android 13, o sistema não vai entregar a transmissão BOOT_COMPLETED ou LOCKED_BOOT_COMPLETED até que o app seja iniciado por outros motivos.

Experiência do usuário

Controles de mídia derivados de PlaybackState

Em apps destinados ao Android 13 (nível 33 da API) e versões mais recentes, o sistema deriva os controles de mídia de ações PlaybackState. Isso permite que o sistema mostre um conjunto mais completo de controles, consistentes entre smartphones e tablets em termos técnicos e alinhados à maneira como os controles de mídia são renderizados em outras plataformas Android, como o Android Auto e o Android TV.

A Figura 2 mostra um exemplo de como eles são exibidos em um smartphone e em um tablet, respectivamente.

Figura 2: controles de mídia em smartphones e tablets

Antes do Android 13, o sistema exibia até cinco ações da notificação MediaStyle na ordem em que elas eram adicionadas. No modo compacto, quando as configurações rápidas estavam recolhidas, por exemplo, até três ações especificadas com setShowActionsInCompactView() eram mostradas.

A partir do Android 13, o sistema exibe até cinco botões de ação com base no PlaybackState, conforme descrito na tabela a seguir. No modo compacto, apenas os três primeiros slots de ação serão exibidos. No caso de apps que não são destinados ao Android 13 ou que não incluem um PlaybackState, o sistema vai mostrar controles de acordo com a lista Action adicionada à notificação MediaStyle, como descrito no parágrafo anterior.

Espaço	Ação	Critérios
1	Jogar	O estado atual do PlaybackState é um dos seguintes: STATE_NONE STATE_STOPPED STATE_PAUSED STATE_ERROR
	Ícone de carregamento	O estado atual do PlaybackState é um dos seguintes: STATE_CONNECTING STATE_BUFFERING
	Pausar	O estado atual do PlaybackState não está listado acima.
2	Anterior	As ações PlaybackState incluem ACTION_SKIP_TO_PREVIOUS.
	Personalizado	As ações PlaybackState não incluem ACTION_SKIP_TO_PREVIOUS e as ações personalizadas PlaybackState incluem uma ação personalizada que ainda não foi posicionada.
	Vazio	Os PlaybackState extras incluem um valor booleano true para a chave SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV.
3	Próxima	As ações PlaybackState incluem ACTION_SKIP_TO_NEXT.
	Personalizado	As ações PlaybackState não incluem ACTION_SKIP_TO_NEXT e as ações personalizadas PlaybackState incluem uma ação personalizada que ainda não foi posicionada.
	Vazio	Os PlaybackState extras incluem um valor booleano true para a chave SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT.
4	Personalizado	As ações personalizadas PlaybackStateincluem uma ação personalizada que ainda não foi posicionada.
5	Personalizado	As ações personalizadas PlaybackStateincluem uma ação personalizada que ainda não foi posicionada.

As ações personalizadas são posicionadas na ordem em que foram adicionadas ao PlaybackState.

Tema de cores do app aplicado automaticamente ao conteúdo do WebView

Em apps destinados ao Android 13 (nível 33 da API) ou versões mais recentes, o método setForceDark() foi descontinuado, nada vai acontecer se o método for chamado.

Em vez disso, o WebView sempre define a consulta de mídia prefers-color-scheme de acordo com o atributo de tema do app, isLightTheme. Em outras palavras, se isLightTheme for true ou não for especificado, prefers-color-scheme vai ser light. Caso contrário, será dark. Esse comportamento significa que o estilo claro ou escuro do conteúdo da Web vai ser aplicado automaticamente para corresponder ao tema do app, se houver suporte.

Para a maioria dos apps, o novo comportamento precisa aplicar os estilos de app apropriados automaticamente. No entanto, é preciso testá-lo para verificar se você pode ter controlado manualmente as configurações do modo escuro.

Se você ainda precisar personalizar o comportamento do tema de cores do app, use o método setAlgorithmicDarkeningAllowed(). Para compatibilidade com versões anteriores do Android, recomendamos o uso do método setAlgorithmicDarkeningAllowed() equivalente no AndroidX.

Consulte a documentação desse método para saber mais sobre o comportamento que você pode esperar no app, dependendo das configurações targetSdkVersion e de temas do app.

Conectividade

BluetoothAdapter#enable() e BluetoothAdapter#disable() foram descontinuados

Em apps destinados ao Android 13 (nível 33 da API) ou mais recentes, os métodos BluetoothAdapter#enable() e BluetoothAdapter#disable() foram descontinuados e sempre retornam false.

Os seguintes tipos de apps estão isentos dessas mudanças:

• Apps do proprietário do dispositivo
• Apps do proprietário do perfil
• Apps do sistema

Google Play Services

Permissão necessária para o ID de publicidade

Os apps que usam o ID de publicidade do Google Play Services e são direcionados ao Android 13 (nível 33 da API) e versões mais recentes precisam declarar a permissão normal do AD_ID no arquivo de manifesto do app desta maneira:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

Caso o app não declare essa permissão ao ser direcionado para o Android 13 ou versões mais recentes, o ID de publicidade é automaticamente removido e substituído por uma string de zeros.

Se o app usa SDKs que declaram a permissão AD_ID no manifesto da biblioteca, a permissão é mesclada com o arquivo de manifesto do app por padrão. Nesse caso, não é necessário declarar a permissão no arquivo manifesto do seu app.

Para saber mais, consulte ID de publicidade na Ajuda do Play Console.

Atualização das restrições não SDK

O Android 13 inclui listas atualizadas de interfaces não SDK restritas com base na colaboração de desenvolvedores do Android e nos testes internos mais recentes. Antes de restringirmos interfaces não SDK, sempre que possível, garantimos que haja alternativas públicas disponíveis.

Caso seu app não seja destinado ao Android 13, é possível que algumas dessas mudanças não afetem você 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, é possível testá-lo para descobrir. Se ele depende de interfaces não SDK, planeje uma migração para alternativas SDK. No entanto, entendemos que alguns apps têm casos de uso válidos para interfaces não SDK. Caso você não encontre uma alternativa para deixar de usar uma interface não SDK em um recurso no app, solicite uma nova API pública.

Para saber mais sobre as mudanças dessa versão do Android, consulte Atualizações para restrições de interfaces não SDK no Android 13. Para saber mais sobre interfaces não SDK em geral, consulte Restrições para interfaces não SDK.