Visão geral de recursos e APIs

O Android 12 introduz ótimos novos recursos e APIs para desenvolvedores. As seções abaixo ajudam você a conhecer os recursos disponíveis para os apps e a começar a usar as APIs relacionadas.

Para uma lista detalhada das APIs novas, modificadas e removidas, leia o Relatório de diferenças da API. Para ver detalhes sobre as novas APIs, acesse a Referência da API do Android. As APIs novas estão em destaque para melhor visibilidade. Além disso, para saber mais sobre as áreas em que as mudanças na plataforma podem afetar seus apps, consulte as mudanças de comportamento do Android 12 para apps destinados ao Android 12 e para todos os apps.

Novas experiências

Melhorias nos widgets

O Android 12 reformula a API Widgets existente para melhorar a experiência do usuário e do desenvolvedor tanto na plataforma e nas telas de início. Criamos um guia para ajudar você a garantir que seu widget seja compatível com o Android 12 e para atualizá-lo com novos recursos.

Consulte Melhorias nos widgets do Android 12 para ver mais informações.

Efeito tátil acoplado ao áudio

Os apps no Android 12 podem gerar retorno tátil de uma sessão de áudio usando a vibração do smartphone. Isso possibilita experiências mais imersivas para jogos e áudio. Por exemplo, toques com efeito tátil podem ajudar a identificar autores de chamadas ou jogos de carros podem simular a sensação de dirigir em um terreno irregular.

Consulte a documentação de referência do HapticGenerator para ver mais informações.

API Splash screen

O Android 12 apresenta uma nova animação de inicialização para todos os apps que inclui um movimento do ponto de inicialização do app, uma tela de apresentação mostrando o ícone dele e uma transição para o próprio app. Consulte API Splash screen para mais detalhes.

Novas notificações de chamadas telefônicas que possibilitam a classificação da importância das chamadas recebidas

O Android 12 adiciona o novo estilo de notificação Notification.CallStyle para chamadas telefônicas. O uso desse modelo possibilita que o app indique a importância das chamadas ativas exibindo um chip em destaque que mostra o tempo da chamada na barra de status. O usuário pode tocar nesse ícone para retornar à chamada.

Como as chamadas recebidas e contínuas são as mais importantes para os usuários, essas notificações recebem a melhor classificação da aba. Essa classificação também possibilita que o sistema encaminhe essas chamadas prioritárias para outros dispositivos.

Implemente o código a seguir para todos os tipos de chamada.

Kotlin

// Create a new call with the user as caller.
val incoming_caller = Person.Builder()
    .setName("Jane Doe")
    .setImportant(true)
    .build()

Java

// Create a new call with the user as caller.
Person incoming_caller = new Person.Builder()
    .setName("Jane Doe")
    .setImportant(true)
    .build();

Use forIncomingCall() para criar uma notificação de estilo para uma chamada recebida.

Kotlin

// Create a call style notification for an incoming call.
val builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
         Notification.CallStyle.forIncomingCall(caller, declineIntent, answerIntent))
    .addPerson(incoming_caller)

Java

// Create a call style notification for an incoming call.
Notification.Builder builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
        Notification.CallStyle.forIncomingCall(caller, declineIntent, answerIntent))
    .addPerson(incoming_caller);

Use forOngoingCall() para criar uma notificação de estilo para uma chamada em andamento.

Kotlin

// Create a call style notification for an ongoing call.
val builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
         Notification.CallStyle.forOnGoingCall(caller, hangupIntent))
    .addPerson(second_caller)

Java

// Create a call style notification for an ongoing call.
Notification.Builder builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
        Notification.CallStyle.forOnGoingCall(caller, hangupIntent))
    .addPerson(second_caller);

Use forScreeningCall() para criar uma notificação de estilo de chamada para filtrar uma chamada.

Kotlin

// Create a call style notification for screening a call.
val builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
         Notification.CallStyle.forScreeningCall(caller, hangupIntent, answerIntent))
    .addPerson(second_caller)

Java

Notification.Builder builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
        Notification.CallStyle.forScreeningCall(caller, hangupIntent, answerIntent))
    .addPerson(second_caller);

Melhorias na compatibilidade de notificações com imagens

No Android 12, agora é possível enriquecer a experiência das notificações do app fornecendo imagens animadas nelas MessagingStyle() e BigPictureStyle(). Além disso, agora o app pode permitir que os usuários enviem mensagens com imagem quando responderem às mensagens pela aba de notificações.

APIs Rounded corner

O Android 12 introduz RoundedCorner e WindowInsets.getRoundedCorner(int position), que fornecem o raio e o ponto central para cantos arredondados. Com essas APIs, o app pode evitar que os elementos da IU sejam truncados em telas com cantos arredondados.

Quando implementadas no app, essas APIs não afetam dispositivos com telas não arredondadas.

Imagem mostrando cantos arredondados com raios e um ponto central

Para implementar esse recurso, acesse as informações do RoundedCorner usando WindowInsets.getRoundedCorner(int position) em relação aos limites do aplicativo. Se o app não ocupar toda a tela, a API aplicará o canto arredondado baseando o ponto central do canto arredondado nos limites da janela do app.

O snippet de código a seguir mostra um exemplo simples para um app evitar o truncamento da IU com a definição de uma margem para a visualização com base nas informações de RoundedCorner. Neste caso, a margem é o canto arredondado da parte superior direita.

// Get the top-right rounded corner from WindowInsets.
final WindowInsets insets = getRootWindowInsets();
final RoundedCorner topRight = insets.getRoundedCorner(POSITION_TOP_RIGHT);
if (topRight == null) {
   return;
}

// Get the location of the close button in window coordinates.
int [] location = new int[2];
closeButton.getLocationInWindow(location);
final int buttonRightInWindow = location[0] + closeButton.getWidth();
final int buttonTopInWindow = location[1];

// Find the point on the quarter circle with a 45 degree angle.
final int offset = (int) (topRight.getRadius() * Math.sin(Math.toRadians(45)));
final int topBoundary = topRight.getCenter().y - offset;
final int rightBoundary = topRight.getCenter().x + offset;

// Check whether the close button exceeds the boundary.
if (buttonRightInWindow < rightBoundary && buttonTopInWindow > topBoundary) {
   return;
}

// Set the margin to avoid truncating.
int [] parentLocation = new int[2];
getLocationInWindow(parentLocation);
FrameLayout.LayoutParams lp = (FrameLayout.LayoutParams) closeButton.getLayoutParams();
lp.rightMargin = Math.max(buttonRightInWindow - rightBoundary, 0);
lp.topMargin = Math.max(topBoundary - buttonTopInWindow, 0);
closeButton.setLayoutParams(lp);

Melhorias no modo picture-in-picture (PiP)

O Android 12 introduz novos recursos para o modo picture-in-picture (PiP). Consulte Melhorias do modo picture-in-picture para ver mais informações.

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:

Inserção de conteúdo avançado

Android 12 introduz uma nova API unificada que permite receber conteúdo avançado de qualquer fonte disponível: área de transferência, teclado ou recurso de arrastar e soltar.

Para ver mais informações, consulte API unificada para recebimento de conteúdo.

Câmera

Compatibilidade com o sensor de câmera Quad Bayer

Atualmente, muitos dispositivos Android oferecem sensores de câmera de alta resolução, geralmente com padrões Quad / Nona Bayer. Esses padrões oferecem grande flexibilidade em termos de qualidade de imagem e desempenho em lugares com pouca luz. O Android 12 introduz novas APIs de plataforma que permitem que apps de terceiros aproveitem ao máximo esses sensores versáteis. As novas APIs são compatíveis com o comportamento único desses sensores e consideram que podem oferecer diferentes configurações e combinações de fluxo ao operar em resolução máxima ou no modo "resolução máxima" ou no modo "padrão".

Gráficos e imagens

Fornecer acesso direto aos rastros de tombstone

Com o Android 12, você pode acessar o Tombstone de falha nativa do app como um buffer de protocolo usando o método ApplicationExitInfo.getTraceInputStream(). O buffer de protocolo é serializado usando este esquema. Antes, a única maneira de acessar essas informações era pelo Android Debug Bridge (adb).

Veja um exemplo de como implementar esse comportamento no app:

ActivityManager activityManager: ActivityManager = getSystemService(Context.ACTIVITY_SERVICE);
MutableList<ApplicationExitInfo> exitReasons = activityManager.getHistoricalProcessExitReasons(/* packageName = */ null, /* pid = */ 0, /* maxNum = */ 5);
for ( ApplicationExitInfo aei: exitReasons ) {
    if ( aei.getReason() == REASON_CRASH_NATIVE ) {
        // Get the tombstone input stream.
        InputStream tombstoneInputStream = aei.getTraceInputStream();
        // The tombstone parser built with protoc uses the tombstone schema, then parses the trace.
        Tombstone tombstone = Tombstone.parseFrom(trace);
    }
}

Compatibilidade com imagens AVIF

O Android 12 introduz a compatibilidade com imagens que usam o formato de arquivo de imagem AV1 (AVIF). O AVIF é um formato de contêiner para imagens e sequências de imagens codificadas com AV1. Ele aproveita o conteúdo codificado nos frames da compactação de vídeo. Isso melhora muito a qualidade da imagem, mantendo o mesmo tamanho de arquivo que os formatos de imagem mais antigos, como JPEG. Para ver informações detalhadas sobre as vantagens desse formato, consulte a postagem do blog de Jake Archibald (link em inglês).

Mais facilidade ao desfocar, usar filtros de cores e outros efeitos

O Android 12 adiciona o novo RenderEffect, que aplica efeitos gráficos comuns, como desfoques, filtros de cores, efeitos de sombreador do Android e muito mais, às Views e hierarquias de renderização. Os efeitos podem ser combinados como efeitos em cadeia, que compõem um efeito interno e externo, ou combinados. Diferentes dispositivos Android podem ou não ser compatíveis com o recurso devido à capacidade de processamento limitada.

Os efeitos também podem ser aplicados ao RenderNode implícito para Views chamando View.setRenderEffect(RenderEffect).

Para implementar um RenderEffect:

view.setRenderEffect(RenderEffect.createBlurEffect(radiusX, radiusY, SHADER_TILE_MODE))

Decodificar imagens animadas nativas

No Android 12, a API ImageDecoder do NDK foi expandida para decodificar todos os frames e dados de tempo de imagens que usam os formatos de arquivo animados GIF (link em inglês) e WebP. Quando foi introduzida no Android 11, essa API decodificava somente a primeira imagem das animações nesses formatos.

Use ImageDecoder em vez de bibliotecas de terceiros para diminuir o tamanho do APK e aproveitar as atualizações futuras relacionadas à segurança e ao desempenho.

Para ver mais detalhes sobre a API, consulte a referência da API e o exemplo no GitHub (link em inglês).

Mídia

Transcodificação de mídia compatível

O Android 12 pode transcodificar automaticamente vídeos HEVC(H.265) e HDR (HDR10 e HDR10+) gravados no dispositivo no formato AVC (H.264), que é amplamente compatível com players padrão. Isso aproveitará os codecs modernos disponíveis sem sacrificar a compatibilidade com aplicativos mais antigos.

Consulte transcodificação de mídia compatível para ver mais detalhes.

Classe de desempenho

A partir do Android 12, o Android introduz um padrão chamado classe de desempenho. Uma classe de desempenho especifica recursos de hardware além dos valores de referência do Android. Cada dispositivo Android declara a classe de desempenho compatível. Os desenvolvedores podem conferir a classe de desempenho do dispositivo durante a execução e fornecer experiências atualizadas que aproveitam ao máximo os recursos do dispositivo.

Consulte Classe de desempenho para mais detalhes.

Melhorias na codificação de vídeo

O Android 12 define um conjunto padrão de chaves para controlar o valor do parâmetro de quantização (QP, na sigla em inglês) para codificação de vídeo, possibilitando que os desenvolvedores evitem códigos específicos do fornecedor.

As novas chaves estão disponíveis na API MediaFormat e também na biblioteca NDK Media.

Com codificadores de vídeo do Android 12, você impõe um limite mínimo de qualidade. Isso garante que os usuários não tenham uma qualidade extremamente baixa ao codificar vídeos com alta complexidade de cena.

Seleção de áudio

A partir do Android 12, quando um app solicita a seleção de áudio enquanto outro app está em foco e em reprodução, a biblioteca esmaece o app em execução.

Consulte as melhorias na seleção de áudio para mais detalhes.

Atualizações do MediaDrm

Para determinar se um componente decodificador seguro é necessário para as APIs MediaDrm atuais, siga estas etapas:

  1. Crie um MediaDrm.
  2. Abra uma sessão para receber um ID.
  3. Crie uma MediaCrypto usando o ID da sessão.
  4. Chame o método MediaCrypto.requiresSecureDecoderComponent(mimeType).

Com os novos métodos requiresSecureDecoder(@NonNull String mime) e requiresSecureDecoder(@NonNull String mime, @SecurityLevel int level), você pode determinar se o decodificador seguro é necessário assim que criar um MediaDrm.

Segurança e privacidade

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.

Saiba mais no guia sobre as novas permissões do Bluetooth.

Painel de privacidade

Uma linha do tempo vertical mostrando os diferentes apps que acessaram informações de localização e a que horas os acessos ocorreram
Figura 1. Uso da localização, parte do painel de privacidade.

Em dispositivos compatíveis que executam o Android 12, uma tela do painel de privacidade é exibida nas configurações do sistema. Nela, os usuários podem acessar telas separadas que mostram quando os apps acessam informações de localização, câmera e microfone. Cada tela mostra uma linha do tempo de quando diferentes apps acessaram um tipo específico de dados. A Figura 1 mostra a linha do tempo dos acessos aos dados de informação da localização.

O app pode fornecer uma justificativa para os usuários para ajudá-los a entender por que precisa acessar informações de localização, câmera ou microfone. Essa lógica pode ser exibida na nova tela do painel de privacidade, na tela de permissões do app ou em ambas.

Mostrar justificativa para acesso aos dados

Para explicar por que o app acessa as informações de localização, câmera e microfone, siga estas etapas:

  1. Adicione uma atividade que, quando iniciada, fornece uma justificativa para o motivo pelo qual o app executa um tipo específico de ação de acesso a dados.

    Se o app for direcionado ao Android 12 ou versões mais recentes, será necessário definir explicitamente um valor para o atributo android:exported.

  2. Adicione o filtro de intent a seguir à atividade recém-adicionada:

    <!-- android:exported required if you target Android 12. -->
<activity android:name=".DataAccessRationaleActivity"
          android:permission="android.permission.START_VIEW_PERMISSION_USAGE"
          android:exported="true">
       <!-- VIEW_PERMISSION_USAGE shows a selectable information icon on
            your app permission's page in system settings.
            VIEW_PERMISSION_USAGE_FOR_PERIOD shows a selectable information
            icon on the Privacy Dashboard screen. -->
    <intent-filter
       android:action="android.intent.action.VIEW_PERMISSION_USAGE"
       android:action="android.intent.action.VIEW_PERMISSION_USAGE_FOR_PERIOD" ... >
    </intent-filter>
</activity>

  3. Decida o que a atividade de lógica de acesso a dados exibirá. Por exemplo, você pode exibir o site do app ou um artigo da Central de Ajuda. Para fornecer uma explicação mais detalhada sobre os tipos de dados que o app acessa e quando isso ocorre, processe os extras que o sistema inclui ao invocar a intent de permissão de uso:

Dependendo dos filtros de intent adicionados, os usuários verão um ícone de informações ao lado do nome do app em algumas telas:

  • Se você adicionar o filtro de intent que contém a ação VIEW_PERMISSION_USAGE, os usuários verão o ícone na página de permissões do app nas configurações do sistema.
  • Se você adicionar o filtro de intent que contém a ação VIEW_PERMISSION_USAGE_FOR_PERIOD, os usuários verão o ícone ao lado do nome do app sempre que ele aparecer na tela do painel de privacidade.

Quando os usuários selecionarem esse ícone, a atividade da lógica do app será iniciada.

Ocultar as janelas de sobreposição de aplicativos

Para dar aos desenvolvedores mais controle sobre o que os usuários veem quando interagem com o app do desenvolvedor, o Android 12 introduz a capacidade de ocultar as janelas de sobreposição exibidas por apps que têm a permissão SYSTEM_ALERT_WINDOW.

Depois de declarar a permissão HIDE_OVERLAY_WINDOWS, um app pode chamar setHideOverlayWindows() para indicar que todas as janelas do tipo TYPE_APPLICATION_OVERLAY precisam estar ocultas quando a própria janela do app estiver visível. Os apps podem fazer isso com a exibição de telas sensíveis, como fluxos de confirmação de transações.

Os apps que mostram janelas do tipo TYPE_APPLICATION_OVERLAY precisam considerar alternativas que podem ser mais adequadas para o caso de uso deles, como picture-in-picture ou balões.

Sinalização de proteção da permissão de assinaturas conhecidas

O Android 12 introduz o atributo knownCerts para permissões no nível da assinatura. Esse atributo possibilita que você consulte os resumos de certificados de assinatura conhecidos durante a declaração.

O app pode declarar esse atributo e usar a nova sinalização knownSigner no atributo protectionLevel para uma permissão no nível da assinatura. Quando ele faz isso, o sistema concede a permissão a um app solicitante se qualquer signatário na linhagem de assinatura dele, incluindo o signatário atual, corresponder a um dos resumos declarados com a permissão no atributo knownCerts.

A sinalização knownSigner possibilita que dispositivos e apps concedam permissões de assinatura a outros apps sem precisar assinar os apps no momento da fabricação e do envio de dispositivos.

Atestar as propriedades do dispositivo

O Android 12 expande o conjunto de apps que podem verificar as propriedades do dispositivo incluídas em um certificado de atestado quando esses apps geram uma nova chave.

A partir do Android 9 (API de nível 28), os proprietários de políticas de dispositivos (DPOs, na sigla em inglês) que usam o Keymaster 4.0 ou versão mais recente podem verificar as propriedades do dispositivo nesses certificados de atestado. A partir do Android 12, qualquer app destinado ao Android 12 pode realizar essa verificação usando o método setDevicePropertiesAttestationIncluded().

As propriedades do dispositivo geradas incluem os campos Build a seguir:

  • BRAND
  • DEVICE
  • MANUFACTURER
  • MODEL
  • PRODUCT

Ações de notificação seguras na tela de bloqueio

O Android 12 oferece a nova sinalização setAuthenticationRequired ao Notification.Action.Builder. Essa sinalização possibilita adicionar uma camada extra de segurança às notificações em dispositivos bloqueados.

Quando essa sinalização é aplicada com um valor true para uma ação de notificação, quando um usuário invocar essa ação em um dispositivo bloqueado, sempre receberá uma solicitação de autenticação. Anteriormente, o sistema solicitava a autenticação em dispositivos bloqueados apenas se o usuário invocasse uma ação de notificação, iniciasse uma atividade ou fosse uma resposta direta.

Para implementar esse recurso, adicione setAuthenticationRequired a uma ação de notificação:

Notification n1 = new Notification.Builder(context, NotificationListenerVerifierActivity.TAG)
...
.addAction(new Notification.Action.Builder(R.drawable.ic_stat_charlie,
context.getString(R.string.action_test_title), makeBroadcastIntent(context))

// Make sure this notification action will always request authentication when
// invoked from a lock screen
.setAuthenticationRequired(true).build())

.build();

Conectividade

Melhorias na estimativa de largura de banda

No Android 12, os recursos de estimativa de largura de banda fornecidos por getLinkDownstreamBandwidthKbps() e getLinkUpstreamBandwidthKbps() foram melhorados para o Wi-Fi e a conectividade celular. Os valores retornados agora representam a capacidade média ponderada do usuário por operadora ou SSID (Identificador do conjunto de serviços) do Wi-Fi, tipo de rede e nível de sinal em todos os aplicativos no dispositivo. Isso pode retornar uma estimativa mais precisa e realista da capacidade esperada, fornecer estimativas em uma inicialização a frio do aplicativo e exige menos ciclos em comparação com o uso de outros métodos de estimativa de capacidade.

Como manter os aplicativos Companion ativados

Para que os aplicativos Companion continuem sendo executados para gerenciar o dispositivo, o Android 12 introduz APIs que fazem o seguinte:

  • Permitem que você ative um app quando um dispositivo complementar estiver no alcance.
  • Garantem que o processo continuará em execução enquanto o dispositivo estiver no alcance.

Para usar as APIs, os dispositivos precisam estar conectados usando o Gerenciador de dispositivos complementares. Para mais informações, consulte CompanionDeviceManager.startObservingDevicePresence() e CompanionDeviceService.onDeviceAppeared().

Perfis gerenciadores de dispositivos complementares

Apps de parceiros direcionados ao Android 12 e versões mais recentes agora podem usar perfis de dispositivos complementares ao se conectar a um smartwatch. O uso de um perfil simplifica o processo de inscrição, agrupando a concessão de um conjunto de permissões específicas do tipo de dispositivo em uma única etapa.

Captura de tela de um smartphone mostrando uma solicitação de concessão de permissões

As permissões do pacote são concedidas ao aplicativo Companion quando o dispositivo é conectado e duram apenas enquanto o dispositivo estiver associado. Excluir o app ou remover a associação, removerá as permissões.

Para saber mais, consulte AssociationRequest.Builder.setDeviceProfile().

Melhorias no Wi-Fi Aware (NAN)

O Android 12 inclui algumas melhorias no Wi-Fi Aware:

  • Em dispositivos com Android 12 e versões mais recentes, é possível usar o callback onServiceLost() para ser alertado quando o app perde um serviço descoberto porque esse serviço foi interrompido ou ficou fora de alcance.
  • A forma como vários caminhos de dados (caminhos de dados NAN) são configurados mudou para se tornar mais eficiente. As versões anteriores usavam mensagens L2 para trocar informações semelhantes dos iniciadores, o que causava latência. Em dispositivos com o Android 12 e versões mais recentes, o recurso de resposta (servidor) pode ser configurado para aceitar qualquer iniciador semelhante. Ou seja, não é necessário saber as informações do iniciador antecipadamente. Isso acelera a inicialização do caminho de dados e permite várias conexões de ponto a ponto com apenas uma solicitação de rede.
  • Para evitar que o framework rejeite solicitações de descoberta ou conexão devido à falta de recursos, é possível chamar WifiAwareManager.getAvailableAwareResources() em dispositivos com o Android 12 e versões mais recentes. O valor de retorno desse método informa o número de caminhos de dados disponíveis, o número de sessões de publicação disponíveis e o número de sessões de inscrição disponíveis.

Conexões ponto a ponto e de Internet simultâneas

Quando dispositivos destinados ao Android 12 e versões mais recentes forem executados em dispositivos com compatibilidade de hardware, o uso de conexões ponto a ponto não desconectará a conexão Wi-Fi existente ao criar a conexão no dispositivo conectado ponto a ponto. Para verificar a compatibilidade com esse recurso, use WifiManager.isMultiStaConcurrencySupported().

Memória

O Android 12 introduz várias mudanças nas APIs de gerenciamento de armazenamento, descritas nas seções a seguir.

Novo diretório para gravações de voz

O sistema reconhece os arquivos de áudio armazenados na nova pasta Environment.DIRECTORY_RECORDINGS como gravações. Quando o app realizar consultas no armazenamento de mídia do sistema, será possível acessar gravações usando a sinalização IS_RECORDING.

Acessar o gerenciamento de mídia

Os usuários podem confiar em um app específico para executar o gerenciamento de mídia, como fazer edições frequentes em arquivos de mídia. Se o app for direcionado ao Android 11 (nível 30 da API) ou a versões mais recentes e não for o app de galeria padrão do dispositivo, será necessário exibir uma caixa de diálogo de confirmação para o usuário sempre que ele tentar modificar ou excluir um arquivo.

Se o app for destinado ao Android 12, você poderá solicitar aos usuários que concedam a permissão correspondente a cada uma das ações a seguir sem precisar fazer uma solicitação ao usuário para cada operação de arquivo:

Para isso, siga os passos a seguir:

  1. Declare as novas permissões MANAGE_MEDIA e READ_EXTERNAL_STORAGE no arquivo de manifesto do app.

    Para chamar createWriteRequest() sem exibir uma caixa de diálogo de confirmação, declare também a permissão ACCESS_MEDIA_LOCATION.

  2. No app, exiba uma IU ao usuário para explicar por que ele pode querer conceder acesso de gerenciamento de mídia.

  3. Invoque a ação da intent ACTION_REQUEST_MANAGE_MEDIA. Ela levará os usuários para a tela Apps de gerenciamento de mídia nas configurações do sistema. Lá, os usuários poderão autorizar o acesso.

Acessar o armazenamento de apps

Um app pode declarar e criar uma atividade personalizada que, quando iniciada, permite ao usuário gerenciar os dados que o app armazenou no dispositivo. Os apps declaram essa atividade "gerenciar espaço" personalizada usando o atributo android:manageSpaceActivity no arquivo de manifesto. Os apps de gerenciamento de arquivos podem iniciar essa atividade de "gerenciar espaço", mesmo quando o app não exporta a atividade, ou seja, quando a atividade define android:exported como false.

No Android 12, os apps que têm a permissão MANAGE_EXTERNAL_STORAGE e QUERY_ALL_PACKAGES, como apps de gerenciamento de arquivos, podem usar o novo método getManageSpaceActivityIntent() para direcionar usuários para a atividade personalizada "gerenciar espaço" de outro app, se houver uma definida para ele.

O método getManageSpaceActivityIntent() recebe um nome de pacote e um código de solicitação, e ele retorna uma das opções a seguir:

  • Uma PendingIntent, se o app com o nome do pacote especificado tiver definido uma atividade de "gerenciar espaço" personalizada. O app que chamou o método getManageSpaceActivityIntent() pode invocar a intent retornada para enviar os usuários à atividade personalizada.
  • null, se o app com o nome de pacote especificado não definir uma atividade "gerenciar espaço".

Compatibilidade com o acesso a arquivos estendidos

O método getMediaUri() agora é compatível com URIs MediaDocumentsProvider, além da compatibilidade existente com URIs ExternalStorageProvider. O sistema agora concede esses URIs ao autor da chamada antes de retorná-los.

Além disso, os URIs de mídia concedidos pelo método createWriteRequest() agora são compatíveis com as APIs na classe File. Essas APIs permitem ler, gravar, renomear e excluir arquivos.

Funcionalidade principal

Atualizações automáticas de apps

O Android 12 introduz o método setRequireUserAction() para apps que usam a API PackageInstaller. Esse método possibilita que os apps instaladores realizem atualizações de apps sem exigir que o usuário confirme a ação.

Informações sobre o chipset do dispositivo

O Android 12 adiciona duas constantes ao método android.os.Build que expõem o fornecedor de chipset SoC e as informações do modelo usando o SDK. É possível extrair essas informações chamando Build.SOC_MANUFACTURER e Build.SOC_MODEL, respectivamente.