Visão geral de recursos e APIs

O Android 11 introduz ótimos novos recursos e APIs para desenvolvedores. As seções abaixo ajudam você a conhecer os recursos dos seus 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 conhecer as áreas em que as mudanças na plataforma podem afetar seus apps, confira as mudanças de comportamento do Android 11 para apps voltados para o Android R e para todos os apps, e as mudanças de privacidade.

Novas experiências

Telas

Melhor compatibilidade com exibições em cascata

O Android 11 fornece várias APIs para oferecer compatibilidade com as exibições em cascata, que aparecem ao redor da borda do dispositivo. Essas exibições são tratadas como uma variante de exibição, com cortes de tela. Os métodos existentes DisplayCutout.getSafeInset…() agora retornam o encarte seguro para evitar áreas de cascata, além dos recortes. Para renderizar o conteúdo do app na área da cascata, faça o seguinte:

  • Chame DisplayCutout.getWaterfallInsets() para ver as dimensões exatas do encarte em cascata.

  • Defina o atributo de layout de janela layoutInDisplayCutoutMode para LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS para permitir que a janela se estenda até as áreas de recorte e cascata em todas as bordas da tela. Verifique se nenhum conteúdo essencial está nas áreas de recorte ou cascata.

Sensor de ângulo de dobradiça e dobráveis

O Android 11 possibilita que apps executados em dispositivos com configurações de tela com dobradiça determinem o ângulo da dobradiça por meio de um novo sensor TYPE_HINGE_ANGLE e um novo SensorEvent que pode monitorar o ângulo da dobradiça e fornece uma medida em graus entre duas partes integrais do dispositivo. É possível usar essas medidas brutas para realizar animações granulares à medida que o usuário manipula o dispositivo.

Embora alguns tipos de apps (como telas de início e planos de fundo) possam achar útil saber o ângulo exato da dobradiça, a maioria dos apps precisa usar o gerenciador de janelas da biblioteca do Jetpack para recuperar a postura do dispositivo chamando DeviceState.getPosture().

Como alternativa, o app pode chamar registerDeviceStateChangeCallback() para ser informado quando o DeviceState mudar e reagir quando a postura mudar.

Responder à postura do dispositivo é mais seguro e confiável, devido às diferentes configurações de janelas e dispositivos disponíveis no mercado atualmente e no futuro.

Conversas

Melhorias para conversas

O Android 11 traz uma série de melhorias na maneira como as conversas são tratadas. As conversas são comunicações bidirecionais em tempo real entre duas ou mais pessoas. Essas conversas recebem destaque especial, e os usuários têm várias novas opções para interagir com elas.

Para obter mais informações sobre as conversas e como seu app pode oferecer compatibilidade com elas, consulte Conversas.

Bolhas de bate-papo

Agora, há Bolhas disponíveis para os desenvolvedores darem vida às conversas em todo o sistema. As bolhas são um recurso experimental do Android 10, ativado por meio de uma opção de desenvolvedor. No Android 11, isso não é mais necessário.

Há uma série de melhorias no desempenho das bolhas. Agora os usuários têm mais flexibilidade para ativar e desativar as bolhas de cada app. Para os desenvolvedores que implementaram a compatibilidade experimental, há algumas mudanças nas APIs no Android 11:

Rich media em respostas rápidas

A partir do Android 11, os usuários podem inserir imagens e outros conteúdos de rich media em respostas rápidas. Para oferecer compatibilidade com esse recurso, os apps precisam adicionar informações às notificações de RemoteInput especificando os tipos MIME que elas podem gerenciar. Para fazer isso, chame RemoteInput.Builder.setAllowDataType(). O app também precisa verificar transmissões RemoteInput recebidas para ver se elas incluem algum conteúdo nesses tipos. Use RemoteInput.getDataResultsFromIntent() para fazer isso.

Compartilhamento de dados com serviço de captura de conteúdo

A partir do Android 11, seu app pode compartilhar dados com o serviço de captura de conteúdo do dispositivo. Esse recurso faz com que seja mais fácil para o dispositivo mostrar informações contextuais, como mostrar o nome de uma música que está sendo reproduzida no ambiente do usuário ou mostrar informações relevantes de viagem quando o usuário está perto de uma parada ou do aeroporto.

Para disponibilizar dados do seu app para o serviço de captura de conteúdo, chame o método shareData() em uma instância de ContentCaptureManager. Se o sistema aceitar a solicitação de compartilhamento de dados, seu app receberá um descritor de arquivo somente gravação para compartilhar com o serviço de captura de conteúdo.

Indicadores visuais de 5G

No Android 11 (API de nível "R") ou mais recentes, os apps com a permissão android.Manifest.permission.READ_PHONE_STATE podem solicitar atualizações de informações de exibição de telefonia por meio de PhoneStateListener.onDisplayInfoChanged(). Isso inclui informações sobre a tecnologia de acesso à rádio para fins de branding e marketing.

Várias soluções de exibição de ícones 5G para diferentes operadoras são fornecidas por essa nova API. As tecnologias compatíveis incluem:

  • LTE
  • LTE com agregação de operadora (LTE+)
  • LTE Advanced pro (5Ge)
  • 5G NR
  • NR em ondas milimétricas (5G+)

Privacidade

O Android 11 introduz muitas mudanças e restrições para melhorar a privacidade do usuário. Para saber mais, consulte a página Privacidade.

Segurança

Atualizações de autenticação biométrica

Para ajudar você a controlar o nível de segurança dos dados do app, o Android 11 oferece várias melhorias para a autenticação biométrica.

Tipos de autenticação

O Android 11 introduz a interface BiometricManager.Authenticators, que define os tipos de autenticação compatíveis com a classe BiometricManager:

BIOMETRIC_STRONG
Autenticação usando um elemento de hardware que satisfaz o nível de força Forte, conforme definido na página Definição de compatibilidade.
BIOMETRIC_WEAK
Autenticação usando um elemento de hardware que satisfaz o nível de força Fraco, conforme definido na página Definição de compatibilidade.
DEVICE_CREDENTIAL
Autenticação usando uma credencial de bloqueio de tela: o PIN, o padrão ou a senha do usuário.

Para definir os tipos de autenticação biométrica que o app aceita, transmita um tipo de autenticação ou uma combinação bit a bit de tipos para o método setAllowedAuthenticators(). Por exemplo, se o app aceitar um elemento de hardware "forte" ou uma credencial de bloqueio de tela, transmita em BIOMETRIC_STRONG | DEVICE_CREDENTIAL.

Para verificar se os elementos de autenticação necessários estão disponíveis, transmita a mesma combinação bit a bit de tipos para o método canAuthenticate(). Se necessário, invoque a ação da intent ACTION_BIOMETRIC_ENROLL. Na intent extra, forneça o conjunto de autenticadores que o app aceita. Essa intent solicita que o usuário registre as credenciais de um autenticador aceito pelo app.

Depois de fazer a autenticação, é possível verificar se o usuário foi autenticado usando uma credencial de dispositivo ou uma credencial biométrica chamando getAuthenticationType().

Compatibilidade adicional com chaves de autenticação ao uso

O Android 11 oferece maior compatibilidade com chaves de autenticação ao uso na classe BiometricPrompt. Essas chaves exigem que o usuário apresente uma credencial biométrica, uma credencial do dispositivo ou outra credencial toda vez que o app precisar acessar os dados protegidos por essa chave. As chaves de autenticação ao uso são úteis para transações de alto valor, como efetuar um pagamento de alto valor ou atualizar os registros médicos de uma pessoa.

Para associar um objeto BiometricPrompt a uma chave de autenticação ao uso, adicione um código semelhante a este:

Kotlin

val authPerOpKeyGenParameterSpec =
        KeyGenParameterSpec.Builder("myKeystoreAlias", key-purpose)
    // Accept either a biometric credential or a device credential.
    // To accept only one type of credential, include only that type as the
    // 2nd argument.
    .setUserAuthenticationParameters(0 /* duration */,
            KeyProperties.AUTH_BIOMETRIC_STRONG or
            KeyProperties.AUTH_DEVICE_CREDENTIAL)
    .build()

Java

KeyGenParameterSpec authPerOpKeyGenParameterSpec =
        new KeyGenParameterSpec.Builder("myKeystoreAlias", key-purpose)
    // Accept either a biometric credential or a device credential.
    // To accept only one type of credential, include only that type as the
    // 2nd argument.
    .setUserAuthenticationParameters(0 /* duration */,
            KeyProperties.AUTH_BIOMETRIC_STRONG |
            KeyProperties.AUTH_DEVICE_CREDENTIAL)
    .build();

Métodos obsoletos

O Android 11 suspendeu o uso dos seguintes métodos:

  • O método setDeviceCredentialAllowed().
  • O método setUserAuthenticationValidityDurationSeconds().
  • A versão sobrecarregada de canAuthenticate() que não aceita argumentos.

Compartilhamento seguro de grandes conjuntos de dados

Em alguns casos, como em aprendizado de máquina ou reprodução de mídia, o app pode usar o mesmo conjunto de dados grande que outro app. Nas versões anteriores do Android, tanto seu app quanto o outro app precisariam fazer o download de uma cópia separada do mesmo conjunto de dados.

Para ajudar a reduzir a redundância de dados, tanto na rede quanto no disco, o Android 11 permite que esses grandes conjuntos de dados sejam armazenados em cache no dispositivo usando blobs de dados compartilhados. Para saber mais sobre o compartilhamento de conjuntos de dados, consulte o guia detalhado sobre compartilhamento de grandes conjuntos de dados.

Desempenho e qualidade

Depuração por Wi-Fi

O Android 11 é compatível com a implantação e depuração por Wi-Fi do app na sua estação de trabalho via Android Debug Bridge (adb). Por exemplo, é possível implantar o app depurável em vários dispositivos remotos sem conectar fisicamente o dispositivo via USB e resolver problemas comuns de conexão USB, como a instalação do driver.

Para usar a depuração por Wi-Fi, é necessário parear seu dispositivo com a estação de trabalho usando um código de pareamento. A estação de trabalho e o dispositivo precisam estar conectados à mesma rede Wi-Fi. Para se conectar ao dispositivo, siga estas etapas:

Caixa de diálogo de pareamento por Wi-Fi do adb
  1. Na sua estação de trabalho, instale a versão mais recente do SDK Platform-Tools.
  2. No dispositivo, ative as opções do desenvolvedor.
  3. Ative a opção Wireless debugging.
  4. Na caixa de diálogo que diz Allow wireless debugging on this network?, clique em Allow.
  5. Selecione Pair device with pairing code. Anote o código de pareamento, o endereço IP e o número da porta exibidos no dispositivo (veja a imagem).
  6. Na estação de trabalho, abra um terminal e navegue até android_sdk/platform-tools.
  7. Execute adb pair ipaddr:port. Use o endereço IP e o número da porta que anotou na etapa 5.
  8. Quando solicitado, digite o código de pareamento que você anotou na etapa 5. O pareamento do dispositivo será confirmado com uma mensagem.

    Enter pairing code: 482924
    Successfully paired to 192.168.1.130:37099 [guid=adb-235XY]
    
  9. Apenas no Linux ou Microsoft Windows: execute adb connect ipaddr:port. Use o endereço IP e a porta exibidos em Wireless debugging (veja a imagem abaixo).

    IP e número da porta de adb por Wi-Fi

Instalação incremental de APK do ADB

A instalação de APKs grandes (2GB ou mais) em um dispositivo pode demorar, mesmo que apenas uma pequena mudança seja feita em um app. A instalação incremental de APK do ADB acelera esse processo instalando uma quantidade suficiente do APK para iniciar o app enquanto os dados restantes são transmitidos em segundo plano. O adb install usará este recurso automaticamente se for compatível com o dispositivo e a versão mais recente do SDK Platform-Tools estiver instalada. Se não for compatível, o método de instalação padrão será usado silenciosamente.

Use o seguinte comando adb para usar o recurso. Se o dispositivo não for compatível com a instalação incremental, o comando falhará e mostrará uma explicação detalhada.

adb install --incremental

Antes de executar uma instalação incremental de APK do ADB, é necessário assinar seu APK e criar um arquivo de esquema de assinatura de APK v4. O arquivo de assinatura v4 precisa ser colocado ao lado do APK para que esse recurso funcione.

Detecção de erros usando o alocador de memória nativo

O GWP-ASan é um recurso de alocação de memória nativo que ajuda a localizar os bugs use-after-free e heap-buffer-overflow. É possível ativar esse recurso globalmente ou para subprocessos específicos do app. Para saber mais, consulte o guia GWP-ASan.

API Neural Networks 1.3

O Android 11 amplia e melhora a API Neural Networks (NNAPI).

Novas operações

A NNAPI 1.3 introduz um novo tipo de operando, TENSOR_QUANT8_ASYMM_SIGNED, para compatibilidade com o novo esquema de quantização do TensorFlow Lite (link em inglês).

Além disso, a NNAPI 1.3 apresenta as novas operações a seguir:

  • QUANTIZED_LSTM
  • IF
  • WHILE
  • ELU
  • HARD_SWISH
  • FILL
  • RANK

Novos controles de ML

A NNAPI 1.3 introduz novos controles para ajudar o aprendizado de máquina a funcionar sem problemas:

API Thermal do NDK

Quando os dispositivos ficam muito quentes, eles podem limitar a CPU e/ou a GPU, e isso pode afetar os apps de maneiras inesperadas. Apps ou jogos que incorporam gráficos complexos, computação pesada ou atividade de rede prolongada têm mais chances de encontrar problemas.

Use a API Thermal do NDK no Android 11 para monitorar mudanças de temperatura no dispositivo e, em seguida, tomar medidas para reduzir o uso de energia e manter a temperatura mais baixa no dispositivo. Essa API é semelhante à API Thermal Java. É possível usá-la para receber notificações sobre qualquer mudança de status de temperatura ou para verificar o status atual diretamente.

Texto e entrada

Transições com o IME melhoradas

O Android 11 introduz novas APIs para melhorar as transições para editores de método de entrada (IMEs, na sigla em inglês), como teclados na tela. Essas APIs facilitam o ajuste do conteúdo do app em sincronia com o aparecimento e o desaparecimento do IME e com outros elementos, como as barras de navegação e de status.

Para mostrar um IME quando qualquer EditText estiver em foco, chame view.getInsetsController().show(Type.ime()). É possível chamar esse método em qualquer visualização na mesma hierarquia que o EditText em foco, não é necessário chamá-lo no EditText especificamente. Para ocultar o IME, chame view.getInsetsController().hide(Type.ime()). É possível verificar se um IME está visível no momento chamando view.getRootWindowInsets().isVisible(Type.ime()).

Para sincronizar as visualizações do app com o aparecimento e o desaparecimento do IME, configure um listener em uma visualização, fornecendo um WindowInsetsAnimation.Callback para View.setWindowInsetsAnimationCallback(). É possível definir esse listener em qualquer visualização. Ele não precisa ser um EditText. O IME chama o método onPrepare() do seu listener, depois ele chama onStart() no início da transição. Em seguida, ele chama onProgress() em cada progresso na transição. Quando a transição terminar, o IME chamará onEnd(). A qualquer momento na transição, é possível descobrir o progresso da transição chamando WindowInsetsAnimation.getFraction().

Para ver um exemplo de como usar essas APIs, consulte a nova amostra de código WindowInsetsAnimation (link em inglês).

Controlar a animação do IME

Também é possível controlar a animação do IME ou a animação de outra barra de sistema, como a barra de navegação. Para fazer isso, primeiro chame setOnApplyWindowInsetsListener() para definir um novo listener para mudanças no encarte de janela:

Kotlin

rootView.setOnApplyWindowInsetsListener { rootView, windowInsets ->
    val barsIme = windowInsets.getInsets(Type.systemBars() or Type.ime())
    rootView.setPadding(barsIme.left, barsIme.top, barsIme.right,
                          barsIme.bottom)

      // We return the new WindowInsets.CONSUMED to stop the insets being
      // dispatched any further into the view hierarchy. This replaces the
      // deprecated WindowInsets.consumeSystemWindowInsets() and related
      // functions.
    WindowInsets.CONSUMED
}

Java

mRoot.setOnApplyWindowInsetsListener(new View.OnApplyWindowInsetsListener() {
   @Override
   public WindowInsets onApplyWindowInsets(View v, WindowInsets insets) {

       Insets barsIME = insets.getInsets(Type.systemBars() | Type.ime());
       mRootView.setPadding(barsIme.left, barsIme.top, barsIme.right,
                             barsIme.bottom);

      // We return the new WindowInsets.CONSUMED to stop the insets being
      // dispatched any further into the view hierarchy. This replaces the
      // deprecated WindowInsets.consumeSystemWindowInsets() and related
      // functions.
       return WindowInsets.CONSUMED;
   }
});

Para mover o IME ou outra barra de sistema, chame o método do controlador controlWindowInsetsAnimation():

Kotlin

view.windowInsetsController.controlWindowInsetsAnimation(
       Type.ime(),
       1000,
       LinearInterpolator(),
       cancellationSignal,
       object : WindowInsetsAnimationControlListener() {
           fun onReady(controller: WindowInsetsAnimationController,
                         types: Int) {
               // update IME inset
             controller.setInsetsAndAlpha(Insets.of(0, 0, 0, inset),
                           1f /* alpha */, 0.1 /* fraction progress */)
           }
       }
);

Java

mRoot.getWindowInsetsController().controlWindowInsetsAnimation(
       Type.ime(), 1000, new LinearInterpolator(), cancellationSignal,
       new WindowInsetsAnimationControlListener() {
           @Override
           public void onReady(
                   @NonNull WindowInsetsAnimationController controller,
                   int types
                   ) {
                   // update IME inset
                   controller.setInsetsAndAlpha(Insets.of(0, 0, 0, inset),
                           1f /* alpha */, 0.1 /* fraction progress */);
           }

           @Override
           public void onCancelled() {}
       });

Atualizações nas bibliotecas de ICU

O Android 11 atualiza o pacote android.icu para usar a versão 66 da biblioteca ICU em comparação com a versão 63 no Android 10. A nova versão da biblioteca inclui dados de localidade CLDR atualizados e diversas melhorias no suporte à internacionalização no Android.

As mudanças notáveis nas novas versões da biblioteca incluem:

  • Muitas APIs de formatação agora são compatíveis com um novo tipo de objeto de retorno que estende FormattedValue.
  • A API LocaleMatcher foi melhorada com uma classe de builder, compatibilidade com o tipo java.util.Locale e uma classe de resultado com dados adicionais sobre uma correspondência.
  • Agora, o Unicode 13 é compatível.

Mídia

Alocar buffers do MediaCodec

O Android 11 inclui novas APIs MediaCodec que dão mais controle aos apps para alocar buffers de entrada e saída. Isso permite que o app gerencie a memória com mais eficiência.

Novas classes:

Novos métodos:

Além disso, o comportamento de dois métodos em MediaCodec.Callback() mudou:

onInputBufferAvailable()
Em vez de chamar MediaCodec.getInputBuffer() e MediaCodec.queueInputBuffer() com o índice, se configurado para usar a API Block Model, os apps precisam usar MediaCodec.getQueueRequest com o índice, anexando um LinearBlock/HardwareBuffer ao slot.
onOutputBufferAvailable()
Em vez de chamar MediaCodec.getOutputBuffer() com o índice, os apps podem usar MediaCodec.getOutputFrame() com o índice para receber o objeto OutputFrame com mais informações e buffers LinearBlock/HardwareBuffer.

Decodificação de baixa latência no MediaCodec

O Android 11 melhora MediaCodec para oferecer compatibilidade à decodificação de baixa latência em jogos e outros apps em tempo real. É possível verificar se um codec é compatível com a decodificação de baixa latência transmitindo FEATURE_LowLatency para MediaCodecInfo.CodecCapabilities.isFeatureSupported().

Para ativar ou desativar a decodificação de baixa latência, realize uma das seguintes ações:

O OpenSL ES foi suspenso

A partir do NDK r21b beta 2, a API OpenSL ES está obsoleta. Em vez disso, use o Oboe (link em inglês).

A plataforma ainda é compatível com o OpenSL ES para apps existentes. No entanto, um aviso de compilação é exibido ao usar o OpenSL ES com uma minSdkVersion de 30 ou mais recente.

Nova função AAudio AAudioStream_release()

A função AAudioStream_close() libera e fecha um stream de áudio ao mesmo tempo. Isso pode ser perigoso. Se outro processo tentar acessar o stream depois de ser fechado, resultará em falha.

A nova função AAudioStream_release() libera o stream, mas não o fecha. Isso libera os recursos e deixa o fluxo em um estado conhecido. O objeto persiste até que AAudioStream_close() seja chamado.

API MediaParser

MediaParser é uma nova API de nível inferior para extração de mídia. Ela é mais flexível que o MediaExtractor e fornece controle adicional sobre a funcionalidade de extração de mídia.

Conectividade

Aprimoramentos do Passpoint do Wi-Fi

O Passpoint permite que os apps executem a autenticação automática e silenciosamente e se conectem a pontos de acesso Wi-Fi seguros. Apps voltados para a API de nível "R" e mais recentes podem usar os seguintes recursos adicionais do Passpoint.

Notificação e aplicação da data de validade
A aplicação de datas de validade em perfis permite que o framework evite a conexão automática com pontos de acesso com credenciais inválidas, que falharão. Isso evita o uso do tempo de transmissão e economiza bateria e largura de banda de back-end. Ele exibe uma notificação para o usuário quando o perfil está no intervalo e expirou.
Correspondência de FQDN
Permite a configuração de um domínio AAA nomeado separadamente de um nome de domínio totalmente qualificado (FQDN, na sigla em inglês) do Access Network Query Protocol (ANQP), usando um nó de extensão/Android em um Objeto de gerenciamento PerProviderSubscription (PPS).
CAs particulares autoassinados.
Para perfis de Passpoint R1, o Android aceita CAs autoassinados privados para autenticação de conexão.
Permitir vários perfis com FQDNs idênticos
Permitir a instalação de vários perfis do Passpoint com FQDNs idênticos. O FQDN não é usado como uma chave para perfis. As APIs do Passpoint existentes que exigem o FQDN, como remove, aplicam a solicitação a todos os perfis correspondentes com o mesmo FQDN.
Permitir a instalação de perfis sem um certificado de CA raiz
Perfis sem um certificado de CA raiz são permitidos. Nesse caso, o sistema verifica os certificados do servidor AAA em relação aos certificados de CA raiz públicos instalados no armazenamento de confiança.
Correspondência melhorada com provedor doméstico e de roaming
O sistema faz a correspondência com as redes domésticas ou de Roaming, independentemente do método de autenticação anunciado. Além disso, compatibilidade com a correspondência doméstica em listas OtherHomePartners e HomeOIList foi adicionada.

A API Wi-Fi Suggestion foi expandida

O Android 11 expande a API Wi-Fi Suggestion para aumentar os recursos de gerenciamento de rede do seu app, incluindo:

  • Os apps de gerenciamento de conectividade podem gerenciar as próprias redes permitindo solicitações de desconexão.
  • As redes do Passpoint são integradas à API Suggestion e podem ser sugeridas ao usuário.
  • As APIs Analytics permitem que você tenha informações sobre a qualidade de suas redes.

Atualizações do CallScreeningService

A partir do Android 11, um CallScreeningService pode solicitar informações sobre o status de verificação de STIR/SHAKEN (verstat) para chamadas recebidas. Essas informações são fornecidas como parte dos detalhes da chamada para chamadas recebidas.

Se um CallScreeningService têm a permissão READ_CONTACTS, o app será notificado quando houver chamadas de, ou chamadas para um número nos contatos do usuário.

Compatibilidade com antena GNSS

O Android 11 introduz a classe GnssAntennaInfo, o que possibilita que o app faça mais uso do posicionamento de precisão de centímetros que o Sistema Global de Navegação por Satélite (GNSS, na sigla em inglês) pode fornecer. Depois que o usuário concede ao app a permissão ACCESS_FINE_LOCATION, o app pode acessar os seguintes detalhes relacionados à antena GNSS:

  • Coordenadas de deslocamento do centro da fase (PCO, na sigla em inglês)
  • Correções de variação de centro de fase (PCV, na sigla em inglês)
  • Correções de ganho de sinal

Para determinar se um dispositivo pode fornecer informações de antena GNSS para o app, chame hasGnssAntennaInfo().

Considerações sobre privacidade

  • A antena GNSS pode identificar apenas o modelo do dispositivo, não um dispositivo individual.
  • O uso da classe GnssAntennaInfo precisa da permissão ACCESS_FINE_LOCATION.

Gráficos

Decodificador de imagem NDK

A API NDK ImageDecoder fornece uma API padrão para apps Android C/C ++ para decodificar imagens diretamente. Os desenvolvedores de apps não precisam mais usar as APIs de framework (via JNI) ou agrupar bibliotecas de decodificação de imagens de terceiros. Para ver mais informações, consulte o guia do desenvolvedor do decodificador de imagens.

API Frame rate

O Android 11 oferece uma API que permite que os apps informem o sistema sobre o frame rate pretendido para reduzir a trepidação em dispositivos compatíveis com várias taxas de atualização. Para ver informações sobre como usar essa API, consulte o guia de frame rate.

Solicitação e verificação de compatibilidade de baixa latência

Certos tipos de monitores podem realizar pós-processamento gráfico, por exemplo, alguns monitores externos e TVs. Esse pós-processamento melhora os gráficos, mas pode aumentar a latência. Telas mais recentes compatíveis com HDMI 2.1 têm modo de baixa latência automática (ALLM, na sigla em inglês, também conhecido como modo jogo), que minimiza a latência desativando esse pós-processamento. Para ver mais detalhes sobre o ALLM, consulte a especificação HDMI 2.1.

Pode ser que uma janela solicite que o modo de baixa latência automática seja usado, se estiver disponível. O ALLM é particularmente útil para aplicativos como jogos e de videoconferências, em que a baixa latência é mais importante que ter os melhores gráficos possíveis.

Para ativar ou desativar o pós-processamento mínimo, chame Window.setPreferMinimalPostProcessing() ou defina o atributo preferMinimalPostProcessing da janela como true. Nem todos os monitores são compatíveis com o pós-processamento mínimo. Para descobrir se uma determinada tela oferece compatibilidade, chame o novo método Display.isMinimalPostProcessingSupported().

Injeção de camadas de depuração para gráficos de alto desempenho

Os apps agora podem carregar camadas gráficas externas (GLES, Vulkan) no código do aplicativo nativo para expor a mesma funcionalidade que um app depurável, mas sem incorrer na sobrecarga de desempenho. Esse recurso é importante especialmente na criação de perfil do seu app com ferramentas como o GAPID. Para criar um perfil para seu app, inclua o seguinte elemento de metadados no arquivo de manifesto do app em vez de tornar o app depurável:

<application ... >
    <meta-data android:name="com.android.graphics.injectLayers.enable"
                  android:value="true" />
</application>

ANGLE para OpenGL ES

É possível executar apps não principais usando o ANGLE para avaliar o desempenho e decidir se um app específico precisa ou não usar o ANGLE em vez dos drivers ES nativos do OpenGL. Para ver instruções, consulte Usar o ANGLE para OpenGL ES.

Imagens e câmera

Silenciar notificações e vibrações durante a captura ativa

A partir do Android 11, ao usar ativamente a câmera, o app pode desativar apenas vibrações, sons e vibrações, ou nenhum dos dois com setCameraAudioRestriction().

Compatibilidade com câmera expandida no emulador do Android

O Android 11 introduz os recursos aprimorados de câmera do Android Emulator. Os recursos adicionados incluem:

  • Captura RAW
  • Reprocessamento YUV
  • Dispositivos de nível 3
  • Compatibilidade lógica da câmera

Melhor compatibilidade com imagens HEIF com vários frames

A partir do Android 11, se você chamar ImageDecoder.decodeDrawable() e passar uma imagem HEIF contendo uma sequência de frames (como uma animação ou uma foto de burst), o método retorna um AnimatedImageDrawable contendo toda a sequência de imagens. Em versões anteriores do Android, o método retornava um BitmapDrawable de apenas um frame.

Se o gráfico de HEIF contiver vários frames que não estão em uma sequência, é possível recuperar um frame individual chamando MediaMetadataRetriever.getImageAtIndex().

Acessibilidade

Atualizações para desenvolvedores de serviços de acessibilidade

Ao criar um serviço de acessibilidade personalizado, é possível usar os seguintes recursos no Android 11:

  • A explicação para os usuários de um serviço de acessibilidade agora permite HTML e imagens, além de texto simples. Essa flexibilidade facilita explicar aos usuários finais o que o serviço faz e como ele pode ajudá-los.
  • Para trabalhar com uma descrição do estado de um elemento da IU que é mais semanticamente significativa do que contentDescription, chame o método getStateDescription().
  • Para solicitar que os eventos de toque ignorem o explorador de toque do sistema, chame setTouchExplorationPassthroughRegion(). Da mesma forma, para solicitar que os gestos ignorem o detector de gestos do sistema, chame setGestureDetectionPassthroughRegion().
  • É possível solicitar ações do IME, como "entrar" e "próximo", além de capturas de tela de janelas que não ativam a sinalização FLAG_SECURE.

Mais Recursos

Motivos de saída do processo do app

Queremos receber seu feedback. Responda a esta breve pesquisa para nos contar como você está usando o recurso (link em inglês). Especificamente, conte-nos sobre os casos de uso afetados por esse recurso.

O Android 11 introduz o método ActivityManager.getHistoricalProcessExitReasons(), que informa os motivos de qualquer encerramento recente do processo. Os apps podem usar esse método para coletar informações de diagnóstico de falhas, como se o encerramento de um processo foi causado por ANRs, problemas de memória ou outros motivos. Além disso, é possível usar o novo método setProcessStateSummary() para armazenar informações de estado personalizadas para análise posterior.

O método getHistoricalProcessExitReasons() retorna instâncias da classe ApplicationExitInfo, que contém informações relacionadas à morte do processo de um app. Chamando getReason() em uma instância dessa classe, é possível determinar por que o processo do app foi encerrado. Por exemplo, um valor de retorno REASON_CRASH indica que ocorreu uma exceção não tratada no seu app. Se o app precisar garantir exclusividade para eventos de saída, ele poderá manter um identificador específico do app, como um valor de hash com base no carimbo de data/hora do método getTimestamp().

Carregadores de recursos

Queremos receber seu feedback. Responda a esta breve pesquisa para nos contar como você está usando o recurso (link em inglês). Especificamente, conte-nos sobre os casos de uso afetados por esse recurso.

O Android 11 introduz uma nova API que permite aos apps estender dinamicamente a forma como os recursos são pesquisados e carregados. As novas classes de API ResourcesLoader e ResourcesProvider são as principais responsáveis por fornecer a nova funcionalidade. Juntas, elas oferecem a capacidade de fornecer mais recursos ou modificar os valores dos recursos existentes.

Objetos ResourcesLoader são contêineres que fornecem objetos ResourcesProvider a uma instância de Resources de um app. Por sua vez, objetos ResourcesProvider fornecem métodos para carregar dados de recursos de APKs e tabelas de recursos.

Um dos principais casos de uso para essa API é o carregamento personalizado de recursos. É possível usar loadFromDirectory() para criar um ResourcesProvider que redirecione a resolução de recursos baseados em arquivos, fazendo com que ele pesquise um diretório específico em vez do APK do aplicativo. Acesse esses recursos por meio da família de métodos open() da classe de API AssetManager, assim como com os recursos agrupados no APK.

Esquema de assinatura de APK v4

O Android 11 adiciona compatibilidade com o Esquema de assinatura de APK v4. Esse esquema produz um novo tipo de assinaturas em um arquivo diferente (apk-name.apk.idsig), mas é semelhante a v2 e v3. Nenhuma mudança é feita no APK. Esse esquema é compatível com a instalação incremental de APK do ADB, que acelera a instalação do APK.

Filtros de intent dinâmicos

Para receber intents, um app precisa declarar no tempo de compilação os tipos de dados que ele pode receber definindo um filtro de intents no manifesto do app. No Android 10 e versões anteriores, os apps não têm como mudar os filtros de intents no ambiente de execução. Esse é um problema para apps de virtualização (como máquinas virtuais e computadores remotos), porque eles não têm como saber exatamente qual software o usuário instalará dentro deles.

O Android 11 introduz grupos MIME, um novo elemento de manifesto que permite que um app declare um conjunto dinâmico de tipos MIME em um filtro de intent e o modifique programaticamente no momento da execução. Para usar um grupo MIME, inclua um elemento de dados no manifesto do app com o novo atributo android:mimeGroup:

<intent-filter>
  <action android:name="android.intent.action.SEND"/>
  <category android:name="android.intent.category.DEFAULT"/>
  <data android:mimeGroup="myMimeGroup"/>
</intent-filter>

O valor do atributo android:mimeGroup é um ID de string arbitrário que identifica o grupo MIME no ambiente de execução. É possível acessar e atualizar o conteúdo de um grupo MIME pela transmissão do ID do grupo para os novos métodos a seguir na classe de API PackageManager:

Quando um tipo MIME é adicionado programaticamente a um grupo MIME, ele funciona exatamente da mesma forma que um tipo MIME estático declarado explicitamente no manifesto.

Melhorias de preenchimento automático

O Android 11 introduz melhorias nos serviços de preenchimento automático.

Identificadores de dica no AssistStructureViewNode

Geralmente, os serviços de preenchimento automático calculam um hash de assinatura para uma visualização com base nas propriedades dela. A dica de visualização é uma propriedade particularmente boa para incluir ao calcular um hash de assinatura, mas a string de dica pode mudar com a localidade do telefone. Para resolver esse problema, o Android 11 expande AssistStructure.ViewNode com um novo método getHintIdEntry(), que retorna o identificador de recurso para o texto de dica de uma visualização. Esse método fornece um valor independente da localidade que pode ser usado para calcular hashes de assinatura.

Eventos exibidos de conjuntos de dados

Para ajudar os serviços de preenchimento automático a melhorar as sugestões, o Android 11 oferece uma maneira de identificar casos em que um serviço de preenchimento automático apresenta conjuntos de dados ao usuário, mas ele não seleciona nenhum. No Android 11, o FillEventHistory informa um novo tipo de evento TYPE_DATASETS_SHOWN. FillEventHistory registra um evento desse tipo sempre que o serviço de preenchimento automático apresenta um ou mais conjuntos de dados ao usuário. Os serviços de preenchimento automático podem usar esses eventos em conjunto com o evento TYPE_DATASET_SELECTED existente para determinar se o usuário selecionou alguma das opções de preenchimento automático oferecidas.