Como nas versões anteriores, o Android 12 inclui mudanças de comportamento que podem afetar seu app. As seguintes mudanças de comportamento se aplicam exclusivamente a apps destinados ao Android 12 ou versão mais recente. Caso seu app seja destinado ao Android 12, faça modificações para torná-lo compatível com esses comportamentos, quando aplicável.
Consulte também a lista de mudanças de comportamento que afetam todos os apps executados no Android 12.
Experiência do usuário
Notificações personalizadas
O Android 12 muda a aparência e o comportamento das notificações personalizadas. Antes, as notificações personalizadas podiam usar toda a área de notificações e utilizar layouts e estilos próprios. Isso gerava uma falta de padrão que podia confundir o usuário ou causar problemas de compatibilidade de layout em dispositivos diferentes.
Em apps destinados ao Android 12, as notificações com visualizações de conteúdo personalizadas deixarão de
usar toda a área da notificação. Em vez disso, o sistema aplicará um modelo
padrão. Esse modelo garante que as notificações personalizadas tenham o mesmo
estilo que outras notificações em todos os estados, como o ícone
da notificação e os recursos de expansão (no estado recolhido) e o ícone,
o nome do app e o recurso de recolhimento da notificação (no estado expandido). Esse comportamento é
quase idêntico ao comportamento de
Notification.DecoratedCustomViewStyle
.
Dessa forma, o Android 12 torna todas as notificações visualmente consistentes e fáceis de verificar, com uma expansão de notificação reconhecível e familiar para os usuários.
A ilustração a seguir mostra uma notificação personalizada no modelo padrão:
Os exemplos a seguir mostram como as notificações personalizadas são renderizadas no estado recolhido e expandido:
![](https://developer.android.com/static/images/about/versions/12/custom-collapsed-view.png?authuser=5&hl=pt)
![](https://developer.android.com/static/images/about/versions/12/custom-expanded-view.png?authuser=5&hl=pt)
A mudança no Android 12 afeta os apps que definem subclasses personalizadas de
Notification.Style
ou que usam os métodos
setCustomContentView(RemoteViews)
,
setCustomBigContentView(RemoteViews)
e setCustomHeadsUpContentView(RemoteViews)
de Notification.Builder
.
Se o app usa notificações totalmente personalizadas, recomendamos testar com o novo modelo o quanto antes.
Ative a mudança nas notificações personalizadas:
- Mude a
targetSdkVersion
do app paraS
para ativar o novo comportamento. - Recompile.
- Instale o app em um dispositivo ou emulador com o Android 12.
- Mude a
Teste todas as notificações que usam visualizações personalizadas, verificando se elas apresentam a aparência esperada. Ao testar, considere o seguinte e faça as mudanças necessárias:
As dimensões das visualizações personalizadas mudaram. Em geral, a altura permitida para notificações personalizadas é menor do que a anterior. No estado recolhido, a altura máxima do conteúdo personalizado diminuiu de 106 dp para 48 dp. Além disso, há menos espaço na horizontal.
Todas as notificações podem ser expandidas em apps direcionados ao Android 12. Normalmente, isso significa que, se você estiver usando o método
setCustomContentView
, também convém usarsetBigCustomContentView
para garantir que os estados recolhido e expandido sejam consistentes.Para garantir que o estado "Atenção" tenha a aparência esperada, não se esqueça de aumentar a importância do canal de notificações para "ALTA" (exibir na tela).
Mudanças na verificação de Links do app Android
Em apps direcionados ao Android 12 ou mais recente, o sistema faz várias mudanças na forma como os Links do app Android são verificados. Essas mudanças melhoram a confiabilidade da experiência de vinculação de apps e oferecem mais controle para os desenvolvedores e usuários finais.
Se você depende da verificação do Links do app Android para abrir links da Web no seu app,
verifique se está usando o formato correto ao adicionar filtros
de intent para
a verificação do Links do app Android. Especificamente, verifique se esses filtros
de intent incluem a categoria BROWSABLE
e oferecem suporte ao esquema https
.
Também é possível verificar manualmente os links do seu app para testar a confiabilidade das declarações.
Melhorias no comportamento do picture-in-picture
O Android 12 introduz melhorias de comportamento para o modo picture-in-picture (PiP), e melhorias cosméticas recomendadas para animações de transição para gestos e navegação baseada em elementos.
Consulte Picture-in-picture e melhorias para informações imprecisas ou inadequadas.
Novo design para avisos
No Android 12, a visualização de avisos foi reformulada. Agora, os avisos são limitados a duas linhas de texto e exibem o ícone do aplicativo ao lado do texto.
![Imagem do dispositivo Android mostrando um pop-up de aviso
"Enviando mensagem" ao lado de um ícone do app](https://developer.android.com/static/images/toast.png?authuser=5&hl=pt)
Para ver mais detalhes, consulte Visão geral dos avisos.
Segurança e privacidade
Local aproximado
Em dispositivos com o Android 12 ou versões mais recentes, os usuários podem solicitar que o app tenha acesso apenas ao local aproximado.
Cookies SameSite modernos no WebView
O componente WebView do Android é baseado no Chromium (link em inglês),
o projeto de código aberto que é a base do navegador Chrome do Google. O Chromium introduziu
mudanças no gerenciamento de cookies de terceiros para proporcionar mais segurança e
privacidade e oferecer aos usuários mais transparência e controle. A partir do Android 12,
essas mudanças também estão incluídas no WebView
quando os apps são direcionados
ao Android 12 (nível 31 da API) ou mais recente.
O atributo SameSite
de um cookie controla se ele pode ser enviado com
qualquer solicitação ou apenas com solicitações do mesmo site. As mudanças de proteção de privacidade abaixo
melhoram o processamento padrão de cookies de terceiros e ajudam a proteger
contra o compartilhamento não intencional entre sites diferentes:
- Cookies sem um atributo
SameSite
são tratados comoSameSite=Lax
. - Cookies com
SameSite=None
também precisam especificar o atributoSecure
. Isso significa que eles exigem um contexto seguro e precisam ser enviados por HTTPS. - Os links entre versões HTTP e HTTPS de um site agora são tratados como solicitações entre diferentes sites.
Portanto, os cookies só serão enviados se estiverem marcados como
SameSite=None; Secure
.
Para desenvolvedores, a orientação geral é identificar as dependências de cookies entre sites
nos fluxos de usuários importantes e garantir que o atributo SameSite
seja definido explicitamente com os valores adequados, quando necessário. É preciso
especificar explicitamente os cookies que têm permissão para trabalhar entre diferentes sites ou
em navegações em um mesmo site que passam de HTTP para HTTPS.
Para ver orientações completas para desenvolvedores Web sobre essas mudanças, consulte SameSite Cookies Explained e Schemeful Scheme SameSite (links em inglês).
Testar comportamentos do SameSite no app
Se o seu app usa o WebView ou se você gerencia um site ou serviço que usa cookies, recomendamos testar seus fluxos no WebView do Android 12. Caso encontre problemas, pode ser necessário atualizar os cookies para oferecer compatibilidade com os novos comportamentos do SameSite.
Monitore problemas de login e conteúdo incorporado, bem como de fluxos de login, compras e outros fluxos de autenticação em que o usuário inicia em uma página não segura e passa para uma página segura.
Para testar um app com o WebView, é necessário ativar os novos comportamentos de SameSite para o app que será testado, seguindo uma destas etapas:
Ative manualmente os comportamentos do SameSite no dispositivo de teste alternando a sinalização de IU webview-enable-modern-cookie-same-site no devtools do WebView.
Essa abordagem permite que você faça testes em qualquer dispositivo com o Android 5.0 (nível 21 da API) ou versão mais recente, incluindo o Android 12, e com o WebView 89.0.4385.0 ou mais recente.
Compile o app para o destinar ao Android 12 (nível 31 da API) usando a
targetSdkVersion
.Caso você use essa abordagem, é necessário usar um dispositivo com o Android 12.
Para saber mais sobre a depuração remota do WebView no Android, consulte Primeiros passos com a depuração remota de dispositivos Android.
Outros recursos
Para ver mais informações sobre os comportamentos modernos do SameSite e o lançamento para o Chrome e o WebView, visite a página de atualizações do SameSite do Chromium (link em inglês). Caso encontre um bug no WebView ou no Chromium, relate o problema no Issue Tracker público do Chromium.
Limitação de taxa dos sensores de movimento
Para proteger informações potencialmente sensíveis sobre os usuários, se o app for direcionado ao Android 12 ou mais recente, o sistema estabelecerá um limite na taxa de atualização de dados de determinados sensores de movimento e sensores de posição.
Saiba mais sobre a limitação de taxa do sensor.
Hibernação do app
O Android 12 aprofunda o comportamento de redefinição automática de permissões introduzido no Android 11 (nível 30 da API). Se o app for direcionado ao Android 12 e o usuário não interagir com ele por alguns meses, o sistema redefinirá automaticamente todas as permissões concedidas e o colocará em um estado de hibernação.
Saiba mais no guia sobre hibernação de apps.
Declaração de atribuição na auditoria de acesso a dados
A API de auditoria de acesso a dados, introduzida no Android 11 (nível 30 da API), possibilita criar tags de atribuição com base nos casos de uso do app. Essas tags facilitam determinar qual parte do app executa um tipo específico de acesso a dados.
Caso o app seja destinado ao Android 12 ou mais recente, é necessário declarar as tags de atribuição no arquivo de manifesto do app.
Restrição de backup do ADB
Para ajudar a proteger os dados particulares do app, o Android 12 muda o comportamento
padrão do comando adb backup
. Em apps direcionados ao Android 12 (nível 31 da API) ou mais recente,
quando um usuário executa o comando adb backup
, os dados do app são excluídos de todos os outros
dados do sistema exportados do dispositivo.
Caso os fluxos de trabalho de teste ou desenvolvimento dependam de dados do app que usam adb backup
,
é possível exportar os dados do app, definindo
android:debuggable
como true
no arquivo de manifesto do app.
Exportar componentes de forma mais segura
Caso o app seja destinado ao Android 12 ou mais recente e contenha
atividades,
serviços ou broadcast
receivers que usam filtros de
intent, declare explicitamente
o atributo
android:exported
para esses
componentes do app.
Se o componente do app incluir a categoria
LAUNCHER
, defina
android:exported
como true
. Na maioria dos outros casos, defina android:exported
como
false
.
O snippet de código abaixo mostra um exemplo de um serviço que contém um filtro
de intent em que o atributo android:exported
está definido como false
:
<service android:name="com.example.app.backgroundService" android:exported="false"> <intent-filter> <action android:name="com.example.app.START_BACKGROUND" /> </intent-filter> </service>
Mensagens no Android Studio
Se o app tiver uma atividade, um serviço ou um broadcast receiver que usa
filtros de intent, mas não declarar android:exported
, as mensagens de aviso a seguir
serão exibidas, dependendo da versão do Android Studio que você usar:
Android Studio 2020.3.1 Canary 11 ou versões mais recentes
As mensagens a seguir são exibidas:
O aviso de lint a seguir é exibido no arquivo de manifesto:
When using intent filters, please specify android:exported as well
Ao tentar compilar o app, a mensagem de erro de compilação abaixo é exibida:
Manifest merger failed : Apps targeting Android 12 and higher are required \ to specify an explicit value for android:exported when the corresponding \ component has an intent filter defined.
Versões mais antigas do Android Studio
Se você tentar instalar o app, o Logcat exibirá a mensagem de erro a seguir:
Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'
Mutabilidade de intents pendentes
Caso o app seja destinado ao Android 12, especifique a
mutabilidade de cada
objeto PendingIntent
criado pelo app. Esse novo requisito melhora a segurança do app.
Testar a mudança de mutabilidade de intents pendentes
Para determinar se faltam declarações de mutabilidade no app, procure este aviso de lint no Android Studio:
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
Inicializações de intents não seguras
Para melhorar a segurança da plataforma, o Android 12 e versões mais recentes oferecem um recurso de depuração que detecta inicializações não seguras de intents. Quando o sistema detecta esse tipo de inicialização não segura, ocorre uma violação do StrictMode.
Desempenho
Restrições de inicialização de serviços em primeiro plano
Apps direcionados ao Android 12 ou mais recente não podem iniciar serviços em primeiro plano durante a execução em segundo plano, exceto em alguns casos específicos. Se um app tentar iniciar um serviço em primeiro plano durante a execução em segundo plano, uma exceção será gerada (exceto em alguns casos específicos).
Considere usar o WorkManager para programar e iniciar o trabalho acelerado enquanto o app é executado em segundo plano. Para concluir ações urgentes que o usuário solicita, inicie serviços em primeiro plano com um alarme exato.
Permissão de alarme exato
Para incentivar os apps a conservar os recursos do sistema, os apps direcionados ao Android 12 e versões mais recentes que definem alarmes exatos precisam ter acesso ao recurso "Alarmes e lembretes" que se encontra na tela de Acesso especial ao app nas configurações do sistema.
Para ter esse acesso especial no app, solicite a permissão
SCHEDULE_EXACT_ALARM
no manifesto.
Os alarmes exatos só podem ser usados por recursos do usuário. Saiba mais sobre os casos de uso aceitáveis para definir um alarme exato.
Desativar a mudança de comportamento
Ao preparar seu app para o destinar ao Android 12, você pode desativar temporariamente a mudança de comportamento na variante de build depurável para fins de teste. Para fazer isso, siga uma destas etapas:
- Nas configurações, na tela de Opções do desenvolvedor, selecione Mudanças na compatibilidade do app. Na tela exibida, toque no nome do app e desative a REQUIRE_EXACT_ALARM_PERMISSION.
Em uma janela do terminal na máquina de desenvolvimento, execute o comando abaixo:
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
Restrições de notificação em trampolim
Quando o usuário interage com notificações, alguns apps respondem ao toque na notificação iniciando um componente de app que iniciará a atividade que o usuário visualiza e com a qual interage. Esse componente de app é conhecido como notificação em trampolim.
Para melhorar o desempenho e a UX, apps direcionados ao Android 12 ou
mais recente não podem iniciar atividades em serviços ou
broadcast receivers usados como
notificação em trampolim. Em outras palavras, depois que o usuário toca em uma notificação
ou em um botão de ação na
notificação, o app não pode chamar
startActivity()
dentro de um serviço ou broadcast receiver.
Quando o app tentar iniciar uma atividade em um serviço ou broadcast receiver que atua como uma notificação em trampolim, o sistema impedirá que a atividade seja iniciada e a mensagem a seguir será exibida no Logcat:
Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.
Identificar quais componentes do app funcionam como trampolins de notificação
Ao testar o app, depois de tocar em uma notificação, você pode identificar qual serviço ou broadcast receiver atuou como o trampolim da notificação no app. Para fazer isso, observe a saída do comando do terminal a seguir:
adb shell dumpsys activity service \ com.android.systemui/.dump.SystemUIAuxiliaryDumpService
Uma seção da saída inclui o texto "NotifInteractionLog". Esta seção contém as informações necessárias para identificar o componente que é iniciado como resultado de um toque de notificação.
Atualizar o app
Se o app iniciar atividades em um serviço ou broadcast receiver que atua como uma notificação em trampolim, siga estas etapas de migração:
- Crie um objeto
PendingIntent
associado à atividade que os usuários veem depois de tocar na notificação. - Use o objeto
PendingIntent
criado na etapa anterior como parte da criação da notificação.
Para identificar a origem da atividade, de forma a executar a geração de registros, por exemplo,
use extras ao postar a notificação. Para geração de registros centralizada, use
ActivityLifecycleCallbacks
ou observadores do ciclo de vida do Jetpack.
Ativar ou desativar o comportamento
Ao testar uma versão depurável do app, você pode ativar e desativar essa
restrição usando a sinalização de compatibilidade do app NOTIFICATION_TRAMPOLINE_BLOCK
.
Backup e restauração
Há mudanças na forma como o backup e a restauração funcionam em apps executados e direcionados ao Android 12 (nível 31 da API). O backup e a restauração do Android têm duas formas:
- Backups na nuvem:os dados do usuário são armazenados no Google Drive do usuário para que pode ser restaurada nesse ou em um novo dispositivo mais tarde.
- Transferências de dispositivo para dispositivo (D2D):os dados do usuário são enviados diretamente para o um novo dispositivo do usuário a partir do dispositivo mais antigo, por exemplo, usando um cabo.
Para mais informações sobre como fazer backup e restaurar dados, consulte Fazer backup do usuário com o Backup automático e o Backup de pares de chave-valor usando o Android Backup Service.
Mudanças na funcionalidade das transferências D2D
Para apps executados no Android 12 e versões mais recentes:
Como especificar regras de inclusão e exclusão com o XML de configuração não afeta as transferências D2D, embora ainda afeta o backup e a restauração baseados na nuvem (como os backups do Google Drive). Para especificar regras para transferências D2D, use a nova configuração coberta na próxima seção.
Em dispositivos de alguns fabricantes, especificar O
android:allowBackup="false"
desativa os backups no Google Drive, mas não desativa as transferências D2D para o app.
Novo formato de inclusão e exclusão
Os apps executados no Android 12 e versões mais recentes usam um formato diferente para a configuração XML. Esse formato torna a diferença entre o backup do Google Drive e a transferência D2D explícita, exigindo que você especifique regras de inclusão e exclusão separadamente para backups na nuvem e para transferências D2D.
Opcionalmente, você também pode usá-lo para especificar regras para backup. Nesse caso, o a configuração usada anteriormente é ignorada em dispositivos com o Android 12 ou mais alto. A configuração mais antiga ainda é necessária para dispositivos com o Android 11 ou inferior.
Mudanças no formato XML
Este é o formato usado para a configuração de backup e restauração no Android 11 e versões anteriores:
<full-backup-content> <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] /> <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" /> </full-backup-content>
Veja abaixo, em negrito, as mudanças no formato.
<data-extraction-rules> <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]> ... <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... </cloud-backup> <device-transfer> ... <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... </device-transfer> </data-extraction-rules>
Para mais informações, consulte a seção correspondente na o guia para backup de dados de usuários com o Backup automático.
Sinalização do manifesto para apps
Aponte seus apps para a nova configuração XML usando o
Atributo android:dataExtractionRules
no manifesto
. Quando você aponta para a nova configuração XML,
O atributo android:fullBackupContent
que aponta para a configuração antiga será ignorado
em dispositivos com o Android 12 ou mais recente. O exemplo de código a seguir mostra a nova
entradas do arquivo de manifesto:
<application ... <!-- The below attribute is ignored. --> android:fullBackupContent="old_config.xml" <!-- You can point to your new configuration using the new dataExtractionRules attribute . --> android:dataExtractionRules="new_config.xml" ...> </application>
Conectividade
Permissões do Bluetooth
O Android 12 introduz
as permissões
BLUETOOTH_SCAN
,
BLUETOOTH_ADVERTISE
e
BLUETOOTH_CONNECT
. Essas permissões facilitam a interação de apps direcionados ao
Android 12 para interagir com dispositivos
Bluetooth, especialmente para apps que não
exigem acesso à localização do dispositivo.
A fim de preparar seu dispositivo para o Android 12 ou mais recente, atualize a lógica do app. Em vez de declarar um conjunto legado de permissões Bluetooth, declare um conjunto mais moderno.
Conexões ponto a ponto e de Internet simultâneas
Em apps direcionados ao Android 12 (nível 31 da API) ou mais recente, os dispositivos com suporte a conexões simultâneas de Internet e ponto a ponto podem manter conexões Wi-Fi simultâneas com o dispositivo conectado e a rede primária que fornece Internet, tornando a experiência do usuário mais integrada. Os apps destinados ao Android 11 (nível 30 da API) ou versões anteriores ainda apresentam o comportamento legado, em que a rede Wi-Fi principal é desconectada antes de se conectar ao dispositivo conectado.
Compatibilidade
O método WifiManager.getConnectionInfo()
pode retornar as WifiInfo
para
apenas uma rede. Por isso, o comportamento da API mudou
desta maneira no Android 12 e versões mais recentes:
- Se apenas uma rede Wi-Fi estiver disponível, as
WifiInfo
dela serão retornadas. - Se mais de uma rede Wi-Fi estiver disponível e o app de chamada tiver acionado uma
conexão ponto a ponto, as
WifiInfo
correspondentes ao dispositivo conectado ponto a ponto serão retornadas. - Se mais de uma rede Wi-Fi estiver disponível e o app de chamada não tiver
acionado uma conexão ponto a ponto, as
WifiInfo
da conexão de Internet principal serão retornadas.
Para oferecer uma melhor experiência do usuário em dispositivos compatíveis com duas redes
Wi-Fi simultâneas, recomendamos que todos os apps, especialmente os que acionam
conexões ponto a ponto, migrem da chamada
WifiManager.getConnectionInfo()
. Em vez dessa chamada, use
NetworkCallback.onCapabilitiesChanged()
para acessar todos os objetos WifiInfo
que correspondem à NetworkRequest
usada para registrar
o NetworkCallback
. O método getConnectionInfo()
foi descontinuado a partir do
Android 12.
O exemplo de código a seguir mostra como receber o WifiInfo
em uma
NetworkCallback
:
Kotlin
val networkCallback = object : ConnectivityManager.NetworkCallback() { ... override fun onCapabilitiesChanged( network : Network, networkCapabilities : NetworkCapabilities) { val transportInfo = networkCapabilities.getTransportInfo() if (transportInfo !is WifiInfo) return val wifiInfo : WifiInfo = transportInfo ... } }
Java
final NetworkCallback networkCallback = new NetworkCallback() { ... @Override public void onCapabilitiesChanged( Network network, NetworkCapabilities networkCapabilities) { final TransportInfo transportInfo = networkCapabilities.getTransportInfo(); if (!(transportInfo instanceof WifiInfo)) return; final WifiInfo wifiInfo = (WifiInfo) transportInfo; ... } ... };
API mDNSResponder nativa
O Android 12 muda quando os apps podem interagir com o daemon mDNSResponder usando
a API mDNSResponder nativa.
Antes, quando um app registrava um serviço na rede
e chamava o método getSystemService()
, o serviço NSD do sistema iniciava o daemon mDNSResponder, mesmo se o
aplicativo ainda não tivesse chamado nenhum método NsdManager
. Em seguida, o daemon inscrevia o
dispositivo nos grupos de multicast de todos os nós, fazendo com que o sistema fosse ativado com mais
frequência e usasse mais energia. Para minimizar o uso da bateria, no Android 12
e versões mais recentes, o sistema agora inicia o daemon mDNSResponder somente quando necessário para
eventos NSD e o interrompe após o término da operação.
Como essa mudança afeta quando o daemon mDNSResponder está disponível, os apps
que presumem que o daemon mDNSResponder será iniciado depois de chamar o método
getSystemService()
podem receber mensagens do sistema informando que
o daemon mDNSresponder não está disponível. Os apps que usam NsdManager
e que
não usam a API mDNSResponder nativa não são afetados por essa mudança.
Bibliotecas do fornecedor
Bibliotecas compartilhadas nativas oferecidas pelo fornecedor
As Bibliotecas compartilhadas nativas que não são do NDK
e oferecidas por fornecedores de componentes eletrônicos ou de dispositivos não poderão ser acessadas
por padrão se o app for direcionado ao Android 12 (nível 31 da API) ou mais recente. As
bibliotecas só poderão ser acessadas quando forem explicitamente solicitadas usando a
tag
<uses-native-library>
.
Se o app for direcionado ao Android 11 (nível 30 da API) ou a uma versão anterior, a
tag <uses-native-library>
não é obrigatória. Nesse caso, qualquer biblioteca
compartilhada nativa poderá ser acessada independentemente de ser uma biblioteca do NDK ou não.
Atualização das restrições não SDK
O Android 12 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 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.