The Android 16 Beta is now available. Try it out today and let us know what you think!

Esta página foi traduzida pela API Cloud Translation.

Mudanças de comportamento: apps destinados ao Android 12
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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:

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:
1. Mude a targetSdkVersion do app para S para ativar o novo comportamento.
2. Recompile.
3. Instale o app em um dispositivo ou emulador com o Android 12.
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 usar setBigCustomContentView 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 nas animações de transição para navegação por gestos e baseada em elementos.

Consulte Melhorias do modo picture-in-picture para mais informações.

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

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 como SameSite=Lax.
Cookies com SameSite=None também precisam especificar o atributo Secure. 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 de 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 para que possam ser restaurados mais tarde no dispositivo atual ou em um novo.
Transferências de dispositivo para dispositivo (D2D, na sigla em inglês):os dados do usuário são enviados diretamente para o novo dispositivo do usuário, por exemplo, usando um cabo.

Para mais informações sobre como os dados são armazenados em backup e restaurados, consulte Fazer backup dos dados de usuários com o Backup automático e Fazer backup de pares de chave-valor com o Android Backup Service.

Mudanças na funcionalidade das transferências D2D

Para apps executados no Android 12 e versões mais recentes:

Especificar regras de inclusão e exclusão com o mecanismo de configuração XML não afeta as transferências D2D, mas ainda afeta o backup e a restauração na nuvem (como backups do Google Drive). Para especificar regras para transferências D2D, use a nova configuração explicada na próxima seção.
Em dispositivos de alguns fabricantes, especificar android:allowBackup="false" desativa backups para o 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.

Você também pode usá-lo para especificar regras de backup. Nesse caso, a configuração usada anteriormente é ignorada em dispositivos com o Android 12 ou mais recente. A configuração mais antiga ainda é necessária para dispositivos com o Android 11 ou versões anteriores.

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 saber mais, consulte a seção correspondente no guia de backup dos dados do usuário usando o Backup automático.

Sinalização do manifesto para apps

Use o atributo android:dataExtractionRules no arquivo do manifesto para apontar seus apps até a nova configuração do XML. Quando você aponta para a nova configuração XML, o atributo android:fullBackupContent que aponta para a configuração antiga é ignorado em dispositivos com o Android 12 ou mais recente. O exemplo de código abaixo mostra as novas 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.