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 recebem avisos relacionados a serviços em primeiro plano no Gerenciador de tarefas, independentemente da permissão de notificação ter sido concedida.
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.
Saiba mais sobre como solicitar permissão para acessar dispositivos Wi-Fi por perto.
Permissões de mídia granulares
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 apropriadas para seu aplicativo.
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.
Caso seu app tenha recebido o
READ_EXTERNAL_STORAGE
todas as permissões READ_MEDIA_* solicitadas serão concedidas
automaticamente ao fazer o upgrade. É possível usar o seguinte comando ADB para analisar
permissões atualizadas:
adb shell cmd appops get --uid PACKAGE_NAME
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.
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.
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:
|
| Ícone de carregamento |
O estado atual do PlaybackState é um dos seguintes:
|
|
| 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
O uso de BluetoothAdapter#enable() e BluetoothAdapter#disable() foi descontinuado
Em apps direcionados ao Android 13 (nível 33 da API) ou versões mais recentes, o
BluetoothAdapter#enable() e
Os métodos BluetoothAdapter#disable() foram descontinuados e estão sempre
retornar false.
Os seguintes tipos de apps estão isentos dessas mudanças:
- Apps do proprietário do dispositivo
- Aplicativos 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.