Bem-vindo à Visualização do desenvolvedor do Android 12. Envie seu feedback com antecedência e frequência e ajude a deixar o Android 12 ainda melhor.

Mudanças de comportamento: todos os apps

A plataforma Android 12 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 12, independentemente da targetSdkVersion. Teste seu app e modifique-o conforme necessário para ficar compatível com essas mudanças, quando aplicável.

Consulte também a lista de mudanças de comportamento que afetam apenas os apps destinados ao Android 12.

Experiência do usuário

Melhorias no modo imersivo para navegação por gestos

O Android 12 simplifica o modo imersivo a fim de tornar a navegação por gestos mais fácil e consistente com outras experiências de atividades, como assistir um vídeo e ler um livro. Os apps ainda podem ter proteção contra gestos acidentais em experiências de jogos em tela cheia, para que o usuário não saia no meio do jogo acidentalmente. Todas as outras experiências em tela cheia ou imersivas agora permitem que o usuário navegue pelo smartphone com o gesto de deslizar.

Para tornar isso possível, os comportamentos existentes de experiências imersivas que não são fixas (BEHAVIOR_SHOW_BARS_BY_TOUCH, BEHAVIOR_SHOW_BARS_BY_SWIPE) foram suspensos a partir do Android 12. Eles foram substituídos pelo comportamento padrão (BEHAVIOR_DEFAULT), que aceita gestos como o de deslizar uma vez para ocultar barras do sistema. Essa sinalização exibe diferentes comportamentos visuais e funcionais, dependendo do modo:

  • No modo de três botões, o comportamento visual e funcional é o mesmo do modo imersivo em versões anteriores ao Android 12.
  • No modo de navegação por gestos, o comportamento é o seguinte:
    • Visualmente, é o mesmo que o do modo imersivo no Android 11 e versões anteriores.
    • Funcionalmente, os gestos são permitidos mesmo quando a barra está oculta. Para acionar o recurso "voltar" é necessário apenas um gesto de deslizar, em vez dos dois necessários para o Android 11. Não é necessário deslizar mais vezes para arrastar a barra de notificação para baixo ou começar a ir para a tela inicial.

O modo imersivo fixo (BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE) não mudou no Android 12. Veja a compatibilidade desse recurso com versões anteriores:

Atraso de notificações de serviços em primeiro plano

Para oferecer uma experiência simplificada para serviços em primeiro plano de curta duração no Android 12, o sistema pode atrasar a exibição de notificações de alguns serviços em primeiro plano por 10 segundos. Essa mudança possibilita que as tarefas de curta duração sejam concluídas antes que as notificações sejam exibidas.

Se um serviço em primeiro plano tiver pelo menos uma das características a seguir, o sistema mostrará a notificação associada imediatamente após o início do serviço:

  • O serviço está associado a uma notificação que inclui botões de ação.
  • O serviço tem um foregroundServiceType de connectedDevice, mediaPlayback, mediaProjection ou phoneCall.
  • O serviço tem um caso de uso relacionado a chamadas telefônicas, navegação ou reprodução de mídia, conforme definido no atributo de categoria da notificação.

  • O serviço desativou a mudança de comportamento chamando setShowForegroundImmediately() ao configurar a notificação.

Privacidade

Restrições no endereço MAC do Netlink

O Android 12 restringe ainda mais o acesso ao endereço MAC de um dispositivo, que consiste em um identificador não reconfigurável, para todos os apps que não são do sistema, independentemente do nível da API de destino.

As APIs relacionadas retornam valores vazios ou de marcador, dependendo da versão do SDK de destino do app:

  • Se o app for destinado ao Android 12, a API retornará nulo.
  • Se o app for destinado ao Android 11 ou versões anteriores, a API retornará um valor de marcador codificado: 02:00:00:00:00:00

Os desenvolvedores precisam usar ConnectivityManager em vez de APIs de nível inferior, como NetworkInterface, getifaddrs(), ou soquetes do Netlink. Quando um desenvolvedor chama NetworkInterface.getHardwareAddress() no código, a saída do logcat exibe: CompatibilityChangeReporter: Compat change id reported: 170188668;

Os desenvolvedores podem usar a sinalização de compatibilidade chamada RETURN_NULL_HARDWARE_ADDRESS para alternar o comportamento de NetworkInterface.getHardwareAddress() entre retornar um valor nulo quando ativado ou 02:00:00:00:00:00 quando desativado.

Segurança

Eventos de toque não confiáveis estão bloqueados

Para preservar a segurança do sistema e uma boa experiência do usuário, o Android 12 impede que os apps consumam eventos de toque em que uma sobreposição oculte o app de forma não segura. Em outras palavras, o sistema bloqueia toques que são transmitidos por determinadas janelas, com algumas exceções.

Apps afetados

Essa mudança afeta os apps que optam por permitir que toques sejam transmitidos pelas janelas, por exemplo, usando a sinalização FLAG_NOT_TOUCHABLE. Alguns exemplos incluem os seguintes:

Exceções

Os toques de transmissão são permitidos nos seguintes casos:

  • Interações dentro do app. O app exibe a sobreposição, que aparece somente quando o usuário está interagindo com o próprio app.
  • Janelas confiáveis. Essas janelas incluem, entre outras:

  • Janelas invisíveis. A visualização raiz da janela é GONE ou INVISIBLE.

  • Janelas totalmente transparentes. A propriedade alpha da janela é 0.0.

  • Janelas de alerta do sistema translúcidas o suficiente. O sistema considera que um conjunto de janelas de alerta do sistema é translúcido o suficiente quando a opacidade combinada é menor ou igual à opacidade máxima de ofuscação do sistema para toques. Na Visualização do desenvolvedor 1, essa opacidade máxima é 0,8, mas esse valor pode mudar posteriormente na Visualização do desenvolvedor.

Detectar quando um toque não confiável está bloqueado

Se uma ação de toque for bloqueada pelo sistema, o Logcat registrará a seguinte mensagem:

Untrusted touch due to occlusion by PACKAGE_NAME

Testar a mudança

Os toques não confiáveis são bloqueados por padrão em dispositivos com a Visualização do desenvolvedor 1 do Android 12. Para permitir toques não confiáveis, execute o seguinte comando ADB em uma janela de terminal:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

Para reverter o comportamento para o padrão (toques não confiáveis bloqueados), execute o seguinte comando:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Apps não podem fechar caixas de diálogo do sistema

Para melhorar o controle do usuário ao interagir com apps e com o sistema, a ação da intent ACTION_CLOSE_SYSTEM_DIALOGS foi suspensa a partir do Android 12. Com a exceção de alguns casos específicos, quando seu app tenta invocar uma intent que contém essa ação, o sistema realiza uma das seguintes ações, com base na versão do SDK de destino do app:

  • Se o app for destinado ao Android 12, ocorrerá uma SecurityException.
  • Se o app for destinado ao Android 11 (API de nível 30) ou versões anteriores, a intent não será executada e a seguinte mensagem aparecerá no Logcat:

    E ActivityTaskManager Permission Denial: \
    android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
    com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
    dropping broadcast.
    

Exceções

O app ainda pode fechar caixas de diálogo do sistema no Android 12 nos seguintes casos:

  • O app está executando um teste de instrumentação.
  • O app é destinado ao Android 11 ou versões anteriores e está exibindo uma janela que sobrepõe a gaveta de notificações.

  • O app é destinado ao Android 11 ou versões anteriores. Além disso, o usuário interagiu com uma notificação, possivelmente usando os botões de ação da notificação, e o app está processando um serviço ou broadcast receiver em resposta à ação do usuário.

Restrições da interface não SDK

O Android 12 inclui listas atualizadas de interfaces não SDK restritas, que têm como base a colaboração com desenvolvedores Android e os 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 12, é 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 12. Para saber mais sobre interfaces não SDK em geral, consulte Restrições para interfaces não SDK.