O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Definição de compatibilidade do Android 15

1. Introdução

Este documento enumera os requisitos que precisam ser atendidos para que os dispositivos sejam compatíveis com o Android 15.

O uso de "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" é conforme o padrão IETF definido na RFC2119.

Conforme usado neste documento, um "implementador de dispositivo" ou "implementador" é uma pessoa ou organização que desenvolve uma solução de hardware/software que executa o Android 15. Uma "implementação de dispositivo" ou "implementação" é a solução de hardware/software desenvolvida.

Para serem consideradas compatíveis com o Android 15, as implementações de dispositivos PRECISAM atender aos requisitos apresentados nesta definição de compatibilidade, incluindo todos os documentos incorporados por referência.

Quando essa definição ou os testes de software descritos na seção 10 forem silenciosos, ambíguos ou incompletos, será responsabilidade do implementador do dispositivo garantir a compatibilidade com implementações existentes.

Por esse motivo, o Android Open Source Project é a implementação de referência e preferida do Android. É ALTAMENTE RECOMENDÁVEL que os implementadores de dispositivos baseiem suas implementações o mais possível no código-fonte "upstream" disponível no Projeto de código aberto do Android. Embora alguns componentes possam ser substituídos por implementações alternativas, é ALTAMENTE RECOMENDADO não seguir essa prática, já que passar nos testes de software vai se tornar substancialmente mais difícil. É responsabilidade do implementador garantir a compatibilidade com o comportamento completo da implementação padrão do Android, incluindo e além do conjunto de teste de compatibilidade. Por fim, observe que algumas substituições e modificações de componentes são explicitamente proibidas por este documento.

Muitos dos recursos vinculados neste documento são derivados direta ou indiretamente do SDK do Android e são funcionalmente idênticos às informações na documentação do SDK. Em qualquer caso em que esta definição de compatibilidade ou o Compatibility Test Suite discordar da documentação do SDK, a documentação do SDK será considerada oficial. Todos os detalhes técnicos fornecidos nos recursos vinculados neste documento são considerados parte desta definição de compatibilidade.

1.1 Estrutura do documento

1.1.1. Requisitos por tipo de dispositivo

A seção 2 contém todos os requisitos que se aplicam a um tipo de dispositivo específico. Cada subseção da Seção 2 é dedicada a um tipo de dispositivo específico.

Todos os outros requisitos, que se aplicam universalmente a qualquer implementação de dispositivo Android, estão listados nas seções após a Seção 2. Esses requisitos são citados como "Requisitos principais" neste documento.

1.1.2. ID do requisito

O ID de requisito é atribuído para requisitos obrigatórios.

O ID é atribuído apenas para requisitos obrigatórios.
Os requisitos FORTEMENTE RECOMENDADOS são marcados como [SR], mas o ID não é atribuído.
O ID consiste em : ID do tipo de dispositivo - ID da condição - ID do requisito (por exemplo, C-0-1).

Cada ID é definido da seguinte forma:

ID do tipo de dispositivo (mais informações em 2. Tipos de dispositivo)
- C: Core (requisitos aplicados a todas as implementações de dispositivos Android)
- H: Dispositivo portátil Android
- T: dispositivo Android TV
- A: Implementação do Android Automotive
- W: Implementação do Android Watch
- Guia: implementação em tablets Android
ID da condição
- Quando o requisito é incondicional, esse ID é definido como 0.
- Quando o requisito é condicional, o valor 1 é atribuído à primeira condição, e o número é incrementado em 1 na mesma seção e no mesmo tipo de dispositivo.
ID do requisito
- Esse ID começa em 1 e aumenta em 1 na mesma seção e na mesma condição.

1.1.3. ID do requisito na seção 2

Os IDs de requisito na Seção 2 têm duas partes. O primeiro corresponde a um ID de seção, conforme descrito acima. A segunda parte identifica o fator de forma e o requisito específico do fator de forma.

ID da seção seguido pelo ID do requisito descrito acima.

O ID na Seção 2 consiste em: ID da seção / ID do tipo de dispositivo - ID da condição - ID do requisito (por exemplo, 7.4.3/A-0-1).

2. Tipos de dispositivo

O Android Open Source Project fornece uma pilha de software que pode ser usada para vários tipos e formatos de dispositivo. Para oferecer suporte à segurança em dispositivos, a pilha de software, incluindo qualquer SO substituto ou uma implementação alternativa do kernel, precisa ser executada em um ambiente seguro, conforme descrito na seção 9 e em outros lugares neste CDD. Há alguns tipos de dispositivos que têm um ecossistema de distribuição de aplicativos relativamente melhor estabelecido.

Esta seção descreve esses tipos de dispositivos e outros requisitos e recomendações aplicáveis a cada um deles.

Todas as implementações de dispositivos Android que não se encaixam em nenhum dos tipos de dispositivo descritos PRECISAM atender a todos os requisitos das outras seções desta definição de compatibilidade.

2.1 Configurações do dispositivo

Para saber as principais diferenças na configuração de hardware por tipo de dispositivo, consulte os requisitos específicos do dispositivo que aparecem nesta seção.

2.2. Requisitos para dispositivos portáteis

Um dispositivo Android portátil se refere a uma implementação de dispositivo Android que normalmente é usada segurando-o na mão, como um player de MP3, smartphone ou tablet.

As implementações de dispositivos Android são classificadas como portáteis se atenderem a todos os seguintes critérios:

Ter uma fonte de energia que ofereça mobilidade, como uma bateria.
Ter um tamanho físico de tela diagonal entre 4 e 8 polegadas.
Ter uma interface de entrada de tela touchscreen.

Os requisitos adicionais no restante desta seção são específicos para implementações de dispositivos portáteis Android.

Observação:os requisitos que não se aplicam a dispositivos tablet Android estão marcados com um asterisco.

2.2.1. Hardware

Implementações de dispositivos portáteis:

[7.1.1.1/H-0-1] É PRECISO ter pelo menos uma tela compatível com Android que meça pelo menos 2,2" na borda curta e 3,4" na borda longa.
[7.1.1.3/H-SR-1] É ALTAMENTE RECOMENDADO oferecer aos usuários uma capacidade de mudar o tamanho da tela (densidade da tela).
[7.1.1.1/H-0-2] É PRECISO oferecer suporte à composição de GPU de buffers gráficos com pelo menos o tamanho da resolução mais alta de qualquer tela integrada.
[7.1.1.1/H-0-3]* É PRECISO mapear cada tela UI_MODE_NORMAL disponibilizada para aplicativos de terceiros em uma área de exibição física desobstruída de pelo menos 2,2 polegadas na borda curta e 3,4 polegadas na borda longa.
[7.1.1.3/H-0-1]* PRECISA definir o valor de DENSITY_DEVICE_STABLE como 92% ou maior que a densidade física real da tela correspondente.

Se as implementações de dispositivos portáteis incluem suporte ao Vulkan, elas:

[7.1.4.2/H-1-1] É OBRIGATÓRIO atender aos requisitos especificados pelo perfil de referência do Android de 2021.

Se as implementações de dispositivos portáteis declararem suporte a telas de High Dynamic Range usando Configuration.isScreenHdr() , elas:

[7.1.4.5/H-1-1] É PRECISO anunciar suporte para as extensões EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace e VK_EXT_hdr_metadata.

Implementações de dispositivos portáteis:

[7.1.4.6/H-0-1] É PRECISO informar se o dispositivo oferece suporte ao recurso de criação de perfil de GPU por uma propriedade de sistema graphics.gpu.profiler.support.

Se as implementações de dispositivos portáteis declararem suporte por uma propriedade de sistema graphics.gpu.profiler.support, elas:

[7.1.4.6/H-1-1] É PRECISO informar como saída um rastro de protobuf que esteja em conformidade com o esquema para contadores de GPU e estágios de renderização de GPU definidos na documentação do Perfetto.
[7.1.4.6/H-1-2] É PRECISO informar valores de conformidade para os contadores de GPU do dispositivo seguindo o proto de pacote de rastreamento de contador de GPU.
[7.1.4.6/H-1-3] É PRECISO informar valores de conformidade para as etapas de renderização da GPU do dispositivo seguindo o proto de pacote de rastreamento de etapa de renderização.
[7.1.4.6/H-1-4] É PRECISO informar um ponto de rastreamento de frequência de GPU conforme especificado pelo formato: power/gpu_frequency.

Implementações de dispositivos portáteis:

[7.1.5/H-0-1] É PRECISO incluir suporte para o modo de compatibilidade de aplicativos legados conforme implementado pelo código aberto upstream do Android. Ou seja, as implementações de dispositivos NÃO PODEM alterar os gatilhos ou limites em que o modo de compatibilidade é ativado e NÃO PODEM alterar o comportamento do próprio modo de compatibilidade.
[7.2.1/H-0-1] É PRECISO incluir suporte a aplicativos de editores de método de entrada (IME) de terceiros.
[7.2.3/H-0-2] É PRECISO enviar o evento de pressionar normal e longo da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano. Esses eventos NÃO podem ser consumidos pelo sistema e PODEM ser acionados fora do dispositivo Android (por exemplo, um teclado externo conectado ao dispositivo Android).
[7.2.3/H-0-3] É OBRIGATÓRIO fornecer a função "Home" em todas as telas compatíveis com Android que fornecem a tela inicial.
[7.2.3/H-0-4] É PRECISO fornecer a função "Voltar" em todas as telas compatíveis com o Android e a função "Recentes" em pelo menos uma das telas compatíveis com o Android.
[7.2.4/H-0-1] É PRECISO oferecer suporte à entrada por touchscreen.
[7.2.4/H-SR-1] É ALTAMENTE RECOMENDADO iniciar o app de assistência selecionado pelo usuário, ou seja, o app que implementa o VoiceInteractionService, ou uma atividade que processa o ACTION_ASSIST ao tocar e pressionar KEYCODE_MEDIA_PLAY_PAUSE ou KEYCODE_HEADSETHOOK se a atividade em primeiro plano não processar esses eventos de toque e pressionar.
[7.3.1/H-SR-1] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

Se as implementações de dispositivos portáteis incluem um acelerômetro de três eixos, elas:

[7.3.1/H-1-1] É PRECISO que o dispositivo possa informar eventos com frequência de pelo menos 100 Hz.

Se as implementações de dispositivos portáteis incluírem um receptor de GPS/GNSS e informarem o recurso aos aplicativos usando a flag de recurso android.hardware.location.gps, elas:

[7.3.3/H-2-1] É OBRIGATÓRIO informar as medições do GNSS assim que elas forem encontradas, mesmo que um local calculado pelo GPS/GNSS ainda não tenha sido informado.
[7.3.3/H-2-2] É OBRIGATÓRIO informar pseudorragem e taxas de pseudorragem do GNSS que, em condições de céu aberto após a determinação do local, enquanto estão parados ou se movem com menos de 0, 2 metro por segundo ao quadrado de aceleração, são suficientes para calcular a posição em até 20 metros e a velocidade em até 0, 2 metro por segundo, pelo menos 95% do tempo.

Se as implementações de dispositivos portáteis incluem um giroscópio de três eixos, elas:

[7.3.4/H-3-1] PRECISA ser capaz de informar eventos com frequência de pelo menos 100 Hz.
[7.3.4/H-3-2] É PRECISO medir mudanças de orientação de até 1.000 graus por segundo.

Implementações de dispositivos portáteis que podem fazer uma chamada de voz e indicar qualquer valor diferente de PHONE_TYPE_NONE em getPhoneType:

[7.3.8/H] DEVE incluir um sensor de proximidade.

Implementações de dispositivos portáteis:

[7.3.11/H-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao sensor de pose com 6 graus de liberdade.

Início dos novos requisitos para o Android 15

~~[7.4.3/H] DEVE incluir suporte para Bluetooth e Bluetooth LE.~~

Implementações de dispositivos portáteis que incluem suporte para Bluetooth LE:

[7.4.3/H-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à extensão do comprimento do pacote de dados do Bluetooth LE.

Observação: este requisito [7.4.3/H-SR-1] será obrigatório em uma versão futura do Android.

Fim dos novos requisitos

Se os dispositivos oferecem suporte ao protocolo Rede de Reconhecimento de Vizinhos (NAN, na sigla em inglês) do Wi-Fi declarando PackageManager.FEATURE_WIFI_AWARE e a localização do Wi-Fi (tempo de retorno do Wi-Fi — RTT, na sigla em inglês) declarando PackageManager.FEATURE_WIFI_RTT, eles:

[7.4.2.5/H-1-1] É PRECISO informar o alcance com precisão, com uma margem de +/-1 metro na largura de banda de 160 MHz no percentil 68 (conforme calculado com a função de distribuição cumulativa), +/-2 metros na largura de banda de 80 MHz no percentil 68, +/-4 metros na largura de banda de 40 MHz no percentil 68 e +/-8 metros na largura de banda de 20 MHz no percentil 68 em distâncias de 10 cm, 1 m, 3 m e 5 m, conforme observado pela API Android WifiRttManager#startRanging.
[7.4.2.5/H-SR-1] É ALTAMENTE RECOMENDADO informar o alcance com precisão de +/-1 metro em uma largura de banda de 160 MHz no percentil 90 (conforme calculado com a função de distribuição cumulativa), +/-2 metros em uma largura de banda de 80 MHz no percentil 90, +/-4 metros em uma largura de banda de 40 MHz no percentil 90 e +/-8 metros em uma largura de banda de 20 MHz no percentil 90 a distâncias de 10 cm, conforme observado pela API Android WifiRttManager#startRanging.

É ALTAMENTE RECOMENDÁVEL seguir as etapas de configuração de medição especificadas em Calibração de presença.

Se as implementações de dispositivos portáteis declararem FEATURE_BLUETOOTH_LE, elas:

[7.4.3/H-1-3] É PRECISO medir e compensar o deslocamento de Rx para garantir que a média do RSSI do BLE seja -50 dBm +/-15 dB a 1 m de distância de um dispositivo de referência que transmite em ADVERTISE_TX_POWER_HIGH.
[7.4.3/H-1-4] É PRECISO medir e compensar o deslocamento de transmissão para garantir que a RSSI média do BLE seja -50 dBm +/-15 dB ao fazer a varredura de um dispositivo de referência posicionado a 1 m de distância e transmitindo em ADVERTISE_TX_POWER_HIGH.

Se as implementações de dispositivos portáteis incluírem um dispositivo de câmera lógico que lista os recursos usando CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, elas:

[7.5.4/H-1-1] É OBRIGATÓRIO ter um campo de visão (FOV) normal por padrão e ele PRECISA estar entre 50 e graus.

Implementações de dispositivos portáteis:

[7.6.1/H-0-1] É PRECISO ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecido como partição "/data").
[7.6.1/H-0-2] PRECISA retornar "true" para ActivityManager.isLowRamDevice() quando houver menos de 1 GB de memória disponível para o kernel e o espaço do usuário.

Se as implementações de dispositivos portáteis declararem suporte apenas a uma ABI de 32 bits:

[7.6.1/H-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 416 MB se a tela padrão usar resoluções de framebuffer de até qHD (por exemplo, FWVGA).
[7.6.1/H-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 592 MB se a tela padrão usar resoluções de framebuffer de até HD+ (por exemplo, HD, WSVGA).
[7.6.1/H-3-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se a tela padrão usar resoluções de framebuffer de até FHD (por exemplo, WSXGA+).
[7.6.1/H-4-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1344 MB se a tela padrão usar resoluções de framebuffer de até QHD (por exemplo, QWXGA).

Se as implementações de dispositivos portáteis declararem suporte a qualquer ABI de 64 bits (com ou sem ABI de 32 bits):

[7.6.1/H-5-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 816 MB se a tela padrão usar resoluções de framebuffer de até qHD (por exemplo, FWVGA).
[7.6.1/H-6-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 944 MB se a tela padrão usar resoluções de framebuffer até HD+ (por exemplo, HD, WSVGA).
[7.6.1/H-7-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB se a tela padrão usar resoluções de framebuffer de até FHD (por exemplo, WSXGA+).
[7.6.1/H-8-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1824 MB se a tela padrão usar resoluções de framebuffer de até QHD (por exemplo, QWXGA).

A "memória disponível para o kernel e o espaço do usuário" acima se refere ao espaço de memória fornecido, além de qualquer memória já dedicada a componentes de hardware, como rádio, vídeo e assim por diante, que não estão sob o controle do kernel nas implementações do dispositivo.

Se as implementações de dispositivos portáteis tiverem menos ou igual a 1 GB de memória disponível para o kernel e o espaço do usuário, elas:

[7.6.1/H-9-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.ram.low.
[7.6.1/H-9-2] É PRECISO ter pelo menos 1,1 GB de armazenamento não volátil para dados privados do aplicativo (também conhecidos como partição "/data").

Se as implementações de dispositivos portáteis incluírem mais de 1 GB de memória disponível para o kernel e o espaço do usuário, elas:

[7.6.1/H-10-1] É PRECISO ter pelo menos 4 GB de armazenamento não volátil disponível para dados particulares do aplicativo (também conhecidos como partição "/data").
DEVE declarar a flag de recurso android.hardware.ram.normal.

Se as implementações de dispositivos portáteis incluírem mais de 2 GB e menos de 4 GB de memória disponível para o kernel e o espaço do usuário, elas:

[7.6.1/H-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte apenas ao espaço do usuário de 32 bits (apps e código do sistema)

Se as implementações de dispositivos portáteis tiverem menos de 2 GB de memória disponível para o kernel e o espaço do usuário, elas:

[7.6.1/H-1-1] PRECISA oferecer suporte apenas a uma ABI (somente 64 bits ou somente 32 bits).

Implementações de dispositivos portáteis:

[7.6.2/H-0-1] NÃO é permitido fornecer um armazenamento compartilhado de aplicativo menor que 1 GiB.
[7.7.1/H] DEVE incluir uma porta USB com suporte ao modo periférico.

Início dos novos requisitos para o Android 15

Se as implementações de dispositivos portáteis incluem uma porta USB ~~com suporte~~ a um controlador operando no modo de periféricos, elas:

[7.7.1/H-1-1] É PRECISO implementar a API Android Open Accessory (AOA).

Fim dos novos requisitos

Se as implementações de dispositivos portáteis incluem uma porta USB com suporte ao modo host, elas:

[7.7.2/H-1-1] É OBRIGATÓRIO implementar a classe de áudio USB conforme documentado na documentação do SDK do Android.

Implementações de dispositivos portáteis:

[7.8.1/H-0-1] É necessário incluir um microfone.
[7.8.2/H-0-1] É PRECISO ter uma saída de áudio e declarar android.hardware.audio.output.

Se as implementações de dispositivos portáteis forem capazes de atender a todos os requisitos de desempenho para o modo de RV e incluírem suporte a ele, elas:

[7.9.1/H-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.vr.high_performance.
[7.9.1/H-1-2] É OBRIGATÓRIO incluir um aplicativo que implemente android.service.vr.VrListenerService e possa ser ativado por aplicativos de RV usando android.app.Activity#setVrModeEnabled.

Se as implementações de dispositivos portáteis incluírem uma ou mais portas USB-C no modo host e implementarem (classe de áudio USB), além dos requisitos da seção 7.7.2, elas:

[7.8.2.2/H-1-1] É PRECISO fornecer o seguinte mapeamento de software de códigos HID:

Função	Mapeamentos	Contexto	Comportamento
A	Página de uso de HID: 0x0C Uso de HID: 0x0CD Chave do kernel: `KEY_PLAYPAUSE` Chave do Android: `KEYCODE_MEDIA_PLAY_PAUSE`	Controles de mídia	Entrada: toque curto Saída: reproduzir ou pausar
		Controles de mídia	Entrada: pressione e mantenha pressionado Saída: inicia o comando de voz Envia: `android.speech.action.VOICE_SEARCH_HANDS_FREE` se o dispositivo estiver bloqueado ou a tela estiver desligada. Caso contrário, será enviado `android.speech.RecognizerIntent.ACTION_WEB_SEARCH`.
		Chamada recebida	Entrada: toque curto Saída: aceitar chamada
		Chamada recebida	Entrada: toque e pressione Saída: rejeitar chamada
		Chamada em andamento	Entrada: toque curto Saída: encerrar chamada
		Chamada em andamento	Entrada: toque e pressione Saída: ativar ou desativar o microfone
B	Página de uso de HID: 0x0C Uso de HID: 0x0E9 Chave do kernel: `KEY_VOLUMEUP` Chave do Android: `VOLUME_UP`	Reprodução de mídia, chamada em andamento	Entrada: toque curto ou longo Saída: aumenta o volume do sistema ou do headset
C	Página de uso de HID: 0x0C Uso de HID: 0x0EA Chave do kernel: `KEY_VOLUMEDOWN` Chave do Android: `VOLUME_DOWN`	Reprodução de mídia, chamada em andamento	Entrada: toque curto ou longo Saída: diminui o volume do sistema ou do fone de ouvido
D	Página de uso de HID: 0x0C Uso de HID: 0x0CF Chave do kernel: `KEY_VOICECOMMAND` Chave do Android: `KEYCODE_VOICE_ASSIST`	Todas. Pode ser acionado em qualquer instância.	Entrada: toque curto ou longo Saída: iniciar o comando de voz

[7.8.2.2/H-1-2] É PRECISO acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que as interfaces e os endpoints de áudio USB tenham sido enumerados corretamente para identificar o tipo de terminal conectado.

Quando os tipos de terminal de áudio USB 0x0302 são detectados, eles:

[7.8.2.2/H-2-1] É PRECISO transmitir a intent ACTION_HEADSET_PLUG com o extra "microphone" definido como 0.

Quando os tipos de terminal de áudio USB 0x0402 são detectados, eles:

[7.8.2.2/H-3-1] É PRECISO transmitir a Intent ACTION_HEADSET_PLUG com o extra "microphone" definido como 1.

Quando a API AudioManager.getDevices() é chamada enquanto o periférico USB está conectado, ela:

[7.8.2.2/H-4-1] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e a função isSink() se o campo de tipo de terminal de áudio USB for 0x0302.
[7.8.2.2/H-4-2] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e a função isSink() se o campo de tipo de terminal de áudio USB for 0x0402.
[7.8.2.2/H-4-3] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e a função isSource() se o campo de tipo de terminal de áudio USB for 0x0402.
[7.8.2.2/H-4-4] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e a função isSink() se o campo de tipo de terminal de áudio USB for 0x603.
[7.8.2.2/H-4-5] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e a função isSource() se o campo de tipo de terminal de áudio USB for 0x604.
[7.8.2.2/H-4-6] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e a função isSink() se o campo de tipo de terminal de áudio USB for 0x400.
[7.8.2.2/H-4-7] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e a função isSource() se o campo de tipo de terminal de áudio USB for 0x400.
[7.8.2.2/H-SR-1] É ALTAMENTE RECOMENDADO, após a conexão de um periférico de áudio USB-C, realizar a enumeração de descritores USB, identificar tipos de terminal e transmitir a Intent ACTION_HEADSET_PLUG em menos de 1.000 milissegundos.

Início dos novos requisitos para o Android 15

Se para implementações de dispositivos portáteis que declaram android.hardware.audio.output e android.hardware.microphone, ~~eles:~~ consulte os requisitos de RTL e TTL na seção 5.6.

[5.6/H-1-1] É OBRIGATÓRIO ter uma latência média contínua de ida e volta de 300 milissegundos ou menos em 5 medições, com uma média absoluta de desvio menor que 30 ms nos seguintes caminhos de dados: "alto-falante para microfone", adaptador de loopback de 3,5 mm (se houver suporte) e loopback USB (se houver suporte).

[5.6/H-1-2] É OBRIGATÓRIO ter uma latência média de Tap-to-Tone de 300 milissegundos ou menos em pelo menos 5 medições sobre o caminho de dados do microfone para o alto-falante.

Fim dos novos requisitos

Um atuador de ressonância linear (LRA, na sigla em inglês) é um sistema de mola de massa única que tem uma frequência de ressonância dominante em que a massa se traduz na direção do movimento desejado.

Se as implementações de dispositivos portáteis incluírem pelo menos um atuador de ressonância linear 7.10 de finalidade geral, elas:

[7.10/H] DEVE posicionar o atuador perto do local em que o dispositivo normalmente é segurado ou tocado pelas mãos.
[7.10/H] O atuador háptico precisa ser movido no eixo X (esquerda-direita) da orientação natural do dispositivo.

Se as implementações de dispositivos portáteis tiverem um atuador háptico de uso geral, que é um atuador de ressonância linear (LRA) do eixo X, elas:

[7.10/H] A frequência de ressonância do LRA do eixo X DEVE ser inferior a 200 Hz.

Se as implementações de dispositivos portáteis seguirem o mapeamento de constantes táteis, elas:

[7.10/H]* É necessário verificar o status da implementação executando android.os.Vibrator.areAllEffectsSupported() e as APIs android.os.Vibrator.arePrimitivesSupported().
[7.10/H]* DEVE realizar uma avaliação de qualidade para constantes hápticas.
[7.10/H]* DEVE verificar e atualizar, se necessário, a configuração substituta para primitivas sem suporte, conforme descrito nas orientações de implementação para constantes.

2.2.2. Multimídia

As implementações de dispositivos portáteis precisam oferecer suporte aos seguintes formatos de codificação e decodificação de áudio e disponibilizá-los para aplicativos de terceiros:

[5.1/H-0-1] AMR-NB
[5.1/H-0-2] AMR-WB
[5.1/H-0-3] Perfil MPEG-4 AAC (AAC LC)
[5.1/H-0-4] Perfil MPEG-4 HE AAC (AAC+).
[5.1/H-0-5] AAC ELD (AAC aprimorado com atraso baixo)

As implementações de dispositivos portáteis precisam oferecer suporte aos seguintes formatos de codificação de vídeo e disponibilizá-los para aplicativos de terceiros:

[5.2/H-0-1] H.264 AVC
[5.2/H-0-2] VP8
[5.2/H-0-3] AV1

As implementações de dispositivos portáteis precisam oferecer suporte aos seguintes formatos de decodificação de vídeo e disponibilizá-los para aplicativos de terceiros:

[5.3/H-0-1] H.264 AVC
[5.3/H-0-2] H.265 HEVC
[5.3/H-0-3] MPEG-4 SP
[5.3/H-0-4] VP8
[5.3/H-0-5] VP9
[5.3/H-0-6] AV1

2.2.3. Software

Implementações de dispositivos portáteis:

[3.2.3.1/H-0-1] É OBRIGATÓRIO ter um aplicativo que processe as intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE e ACTION_CREATE_DOCUMENT conforme descrito nos documentos do SDK e fornecer ao usuário a capacidade de acessar os dados do provedor de documentos usando a API DocumentsProvider.
[3.2.3.1/H-0-2]* É OBRIGATÓRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intent para todos os padrões de filtro de intent públicos definidos pelas intents do app listadas aqui.
[3.2.3.1/H-SR-1] É FORTEMENTE RECOMENDADO pré-carregar um aplicativo de e-mail que possa processar ACTION_SENDTO ou ACTION_SEND ou ACTION_SEND_MULTIPLE intents para enviar um e-mail.
[3.4.1/H-0-1] É necessário fornecer uma implementação completa da API android.webkit.Webview.
[3.4.2/H-0-1] É PRECISO incluir um aplicativo de navegador independente para navegação geral na Web do usuário.
[3.8.1/H-SR-1] É ALTAMENTE RECOMENDADO implementar um iniciador padrão que ofereça suporte à fixação de atalhos, widgets e widgetFeatures no app.
[3.8.1/H-SR-2] É ALTAMENTE RECOMENDÁVEL implementar um iniciador padrão que ofereça acesso rápido aos atalhos adicionais fornecidos por apps de terceiros pela API ShortcutManager.
[3.8.1/H-SR-3] É ALTAMENTE RECOMENDÁVEL incluir um app de inicialização padrão que mostre os selos dos ícones dos apps.
[3.8.2/H-SR-1] É ALTAMENTE RECOMENDÁVEL oferecer suporte a widgets de apps de terceiros.
[3.8.3/H-0-1] É PRECISO permitir que apps de terceiros notifiquem os usuários sobre eventos importantes usando as classes de API Notification e NotificationManager.
[3.8.3/H-0-2] É PRECISO oferecer suporte a notificações avançadas.
[3.8.3/H-0-3] É PRECISO oferecer suporte a notificações de aviso.
[3.8.3/H-0-4] É OBRIGATÓRIO incluir uma aba de notificações, permitindo que o usuário controle diretamente (por exemplo, responder, adiar, descartar, bloquear) as notificações por meio de recursos como botões de ação ou o painel de controle implementado no AOSP.
[3.8.3/H-0-5] É PRECISO mostrar as opções fornecidas por RemoteInput.Builder setChoices() na sombra de notificação.
[3.8.3/H-SR-1] É ALTAMENTE RECOMENDÁVEL exibir a primeira opção fornecida por RemoteInput.Builder setChoices() na sombra de notificação sem interação adicional do usuário.
[3.8.3/H-SR-2] É ALTAMENTE RECOMENDÁVEL exibir todas as opções fornecidas por RemoteInput.Builder setChoices() na aba de notificações quando o usuário expandir todas as notificações na aba de notificações.
[3.8.3.1/H-SR-1] É ALTAMENTE RECOMENDADO exibir ações para as quais Notification.Action.Builder.setContextual é definido como true em linha com as respostas exibidas por Notification.Remoteinput.Builder.setChoices.
[3.8.4/H-SR-1] É ALTAMENTE RECOMENDADO implementar um assistente no dispositivo para processar a ação de assistência.

Se as implementações de dispositivos portáteis oferecerem suporte a notificações do MediaStyle, elas:

[3.8.3.1/H-SR-2] É ALTAMENTE RECOMENDÁVEL fornecer uma capacidade do usuário (por exemplo, um seletor de saída) acessada pela interface do sistema, que permite aos usuários alternar entre rotas de mídia disponíveis (por exemplo, dispositivos Bluetooth e rotas fornecidas ao MediaRouter2Manager) quando um app envia uma notificação MediaStyle com um token MediaSession.

Se as implementações do dispositivo que incluem a tecla de navegação de função recente, conforme detalhado na seção 7.2.3, alterarem a interface, elas:

[3.8.3/H-1-1] É PRECISO implementar o comportamento de fixação da tela e fornecer ao usuário um menu de configurações para ativar o recurso.

Se as implementações de dispositivos portáteis oferecerem suporte à ação de assistência, elas:

[3.8.4/H-SR-2] É ALTAMENTE RECOMENDADO usar o toque longo na tecla HOME como a interação designada para iniciar o app de assistência, conforme descrito na seção 7.2.3. PRECISA iniciar o app de assistência selecionado pelo usuário, ou seja, o app que implementa VoiceInteractionService, ou uma atividade que processa a intent ACTION_ASSIST.

Se as implementações de dispositivos portáteis oferecerem suporte a conversation notifications e as agruparem em uma seção separada de notificações de alerta e não conversa silenciosas, elas:

[3.8.4/H-1-1]* É PRECISO mostrar notificações de conversa antes de notificações que não são de conversa, exceto notificações de serviço em primeiro plano em andamento e importance:high.

Se as implementações de dispositivos portáteis Android oferecerem suporte a uma tela de bloqueio, elas:

[3.8.10/H-1-1] É PRECISO mostrar as notificações na tela de bloqueio, incluindo o modelo de notificação de mídia.

Se as implementações de dispositivos portáteis oferecerem suporte a uma tela de bloqueio segura, elas:

[3.9/H-1-1] É OBRIGATÓRIO implementar toda a gama de políticas de administração de dispositivos definidas na documentação do SDK do Android.

Se as implementações de dispositivos portáteis incluírem suporte para as APIs ControlsProviderService e Control e permitirem que aplicativos de terceiros publiquem controles de dispositivo, elas:

[3.8.16/H-1-1] É PRECISO declarar a flag de recurso android.software.controls e defini-la como true.
[3.8.16/H-1-2] É PRECISO fornecer uma affordance ao usuário com a capacidade de adicionar, editar, selecionar e operar os controles favoritos do dispositivo do usuário entre os controles registrados pelos aplicativos de terceiros usando as APIs ControlsProviderService e Control.
[3.8.16/H-1-3] É PRECISO fornecer acesso a essa característica do usuário em três interações de uma tela de início padrão.
[3.8.16/H-1-4] É PRECISO renderizar com precisão o nome e o ícone de cada app de terceiros que oferece controles pela API ControlsProviderService e todos os campos especificados fornecidos pelas APIs Control.
[3.8.16/H-1-5] É PRECISO fornecer ao usuário uma capacidade de uso para desativar os controles de dispositivo simples de autenticação designados pelo app dos controles registrados pelos aplicativos de terceiros usando ControlsProviderService e a API Control.isAuthRequired Control.
[3.8.16/H-1-6] As implementações de dispositivos PRECISAM renderizar a affordance do usuário de forma precisa, conforme segue:
- Se o dispositivo tiver definido config_supportsMultiWindow=true e o app declarar os metadados META_DATA_PANEL_ACTIVITY na declaração ControlsProviderService, incluindo o ComponentName de uma atividade válida (conforme definido pela API), o app PRECISA incorporar essa atividade nesse recurso do usuário.
- Se o app não declarar metadados META_DATA_PANEL_ACTIVITY, ele PRECISA renderizar os campos especificados conforme fornecido pela API ControlsProviderService e também qualquer campo especificado fornecido pelas APIs Control.
[3.8.16/H-1-7] Se o app declarar os metadados META_DATA_PANEL_ACTIVITY, ele PRECISA transmitir o valor da configuração definida em [3.8.16/H-1-5] usando EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS ao iniciar a atividade incorporada.

Por outro lado, se as implementações de dispositivos portáteis não implementarem esses controles, elas:

[3.8.16/H-2-1] É PRECISO informar null para as APIs ControlsProviderService e Control.
[3.8.16/H-2-2] É PRECISO declarar a flag de recurso android.software.controls e defini-la como false.

Se as implementações de dispositivos portáteis não estiverem em execução no modo de bloqueio de tarefas, quando o conteúdo for copiado para a área de transferência, elas:

[3.8.17/H-1-1] É PRECISO apresentar ao usuário uma confirmação de que os dados foram copiados para a área de transferência (por exemplo, uma miniatura ou um alerta de "Conteúdo copiado"). Além disso, inclua aqui uma indicação se os dados da área de transferência serão sincronizados entre dispositivos.

Implementações de dispositivos portáteis:

[3.10/H-0-1] É PRECISO oferecer suporte a serviços de acessibilidade de terceiros.
[3.10/H-SR-1] É ALTAMENTE RECOMENDADO pré-carregar serviços de acessibilidade no dispositivo que sejam comparáveis ou superiores à funcionalidade do acesso com interruptor e do TalkBack (para idiomas com suporte ao mecanismo de conversão de texto em voz pré-instalado), conforme fornecido no projeto de código aberto do Talkback.
[3.11/H-0-1] É PRECISO oferecer suporte à instalação de motores de TTS de terceiros.
[3.11/H-SR-1] É ALTAMENTE RECOMENDADO incluir um motor de TTS que ofereça suporte aos idiomas disponíveis no dispositivo.
[3.13/H-SR-1] É ALTAMENTE RECOMENDADO incluir um componente de interface de configurações rápidas.

Se as implementações de dispositivos portáteis Android declararem suporte a FEATURE_BLUETOOTH ou FEATURE_WIFI, elas:

[3.16/H-1-1] É PRECISO oferecer suporte ao recurso de pareamento de dispositivo complementar.

Se a função de navegação for fornecida como uma ação baseada em gestos na tela:

[7.2.3/H] A zona de reconhecimento de gestos para a função "Início" NÃO PODE ter mais de 32 dp de altura a partir da parte de baixo da tela.

Se as implementações de dispositivos portáteis fornecerem uma função de navegação como um gesto em qualquer lugar nas bordas esquerda e direita da tela:

[7.2.3/H-0-1] A área de gesto da função de navegação PRECISA ter menos de 40 dp de largura em cada lado. A área de gestos DEVE ter 24 dp de largura por padrão.

Se as implementações de dispositivos portáteis oferecerem suporte a uma tela de bloqueio segura e tiverem mais ou igual a 2 GB de memória disponível para o kernel e o espaço do usuário, elas:

[3.9/H-1-2] É PRECISO declarar o suporte a perfis gerenciados usando a flag de recurso android.software.managed_users.

Se as implementações de dispositivos portáteis Android declararem o suporte à câmera por android.hardware.camera.any, elas:

[7.5.4/H-1-1] É PRECISO honrar a intent android.media.action.STILL_IMAGE_CAMERA e android.media.action.STILL_IMAGE_CAMERA_SECURE e iniciar a câmera no modo de imagem estática, conforme descrito no SDK.
[7.5.4/H-1-2] É PRECISO honrar a intent android.media.action.VIDEO_CAMERA para iniciar a câmera no modo de vídeo, conforme descrito no SDK.

Se o aplicativo de configurações da implementação do dispositivo implementar uma funcionalidade dividida, usando a incorporação de atividades, ele:

[3.2.3.1/ H-1-1] É PRECISO ter uma atividade que processe a intenção Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY quando a funcionalidade de divisão estiver ativada. A atividade PRECISA ser protegida por android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK e PRECISA iniciar a atividade da intent analisada de Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

Se as implementações de dispositivos permitirem que os usuários façam ligações de qualquer tipo,

[7.4.1.2/H-0-1] É PRECISO declarar a flag de recurso android.software.telecom.
[7.4.1.2/H-0-2] É OBRIGATÓRIO implementar o framework de telecomunicações.

2.2.4. Desempenho e bateria

[8.1/H-0-1] Latência consistente de frames. A latência inconsistente de frames ou um atraso na renderização de frames NÃO PODE acontecer mais frequentemente do que 5 frames por segundo e DEVE estar abaixo de 1 frame por segundo.
[8.1/H-0-2] Latência da interface do usuário. As implementações de dispositivos precisam garantir uma experiência do usuário com baixa latência rolando uma lista de 10 mil entradas, conforme definido pelo Conjunto de teste de compatibilidade do Android (CTS, na sigla em inglês) em menos de 36 segundos.
[8.1/H-0-3] Troca de tarefas. Quando vários aplicativos são iniciados, a reabertura de um aplicativo que já está em execução após a inicialização PRECISA levar menos de um segundo.

Implementações de dispositivos portáteis:

[8.2/H-0-1] É PRECISO garantir um desempenho de gravação sequencial de pelo menos 5 MB/s.
[8.2/H-0-2] É PRECISO garantir um desempenho de gravação aleatória de pelo menos 0,5 MB/s.
[8.2/H-0-3] É PRECISO garantir um desempenho de leitura sequencial de pelo menos 15 MB/s.
[8.2/H-0-4] É PRECISO garantir um desempenho de leitura aleatória de pelo menos 3,5 MB/s.

Se as implementações de dispositivos portáteis incluírem recursos para melhorar o gerenciamento de energia do dispositivo que estão incluídos no AOSP ou estenderem os recursos incluídos no AOSP, elas:

[8.3/H-1-1] É OBRIGATÓRIO fornecer ao usuário a capacidade de ativar e desativar o recurso de economia de bateria.
[8.3/H-1-2] É OBRIGATÓRIO fornecer ao usuário a capacidade de exibir todos os apps que estão isentos dos modos de economia de energia do App Standby e da Soneca.

Implementações de dispositivos portáteis:

[8.4/H-0-1] É obrigatório fornecer um perfil de energia por componente que defina o valor de consumo atual para cada componente de hardware e o consumo aproximado de bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.
[8.4/H-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliamperes-hora (mAh).
[8.4/H-0-3] É OBRIGATÓRIO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito pela implementação do módulo do kernel uid_cputime.
[8.4/H-0-4] É OBRIGATÓRIO disponibilizar esse uso de energia pelo comando de shell adb shell dumpsys batterystats para o desenvolvedor do app.
[8.4/H] DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.

Se as implementações de dispositivos portáteis incluírem uma tela ou saída de vídeo, elas:

[8.4/H-1-1] É NECESSÁRIO honrar a intent android.intent.action.POWER_USAGE_SUMMARY e mostrar um menu de configurações que mostre esse uso de energia.

Implementações de dispositivos portáteis:

[8.5/H-0-1] É obrigatório fornecer uma capacidade do usuário para ver todos os apps com serviços em primeiro plano ativos ou jobs iniciados pelo usuário, incluindo a duração de cada um desses serviços desde o início, conforme descrito no documento do SDK.
[8.5/H-0-2]É OBRIGATÓRIO fornecer uma ação do usuário para interromper um app que está executando um serviço em primeiro plano ou um job iniciado pelo usuário.

2.2.5. Modelo de segurança

Implementações de dispositivos portáteis:

[9/H-0-1] É PRECISO declarar o recurso android.hardware.security.model.compatible.
[9.1/H-0-1] É PRECISO permitir que apps de terceiros acessem as estatísticas de uso pela permissão android.permission.PACKAGE_USAGE_STATS e forneçam um mecanismo acessível ao usuário para conceder ou revogar o acesso a esses apps em resposta à intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Início dos novos requisitos para o Android 15

As implementações de dispositivos precisam declarar suporte a android.software.credentials e:

[9/H-0-2] É PRECISO honrar a intent android.settings.CREDENTIAL_PROVIDER para permitir a seleção de um provedor preferencial para o Gerenciador de credenciais. Esse provedor será ativado para o preenchimento automático e também será o local padrão para salvar novas credenciais digitadas pelo Gerenciador de credenciais.
[9/H-0-3] É necessário oferecer suporte a pelo menos dois provedores de credenciais simultâneos e fornecer uma capacidade de uso do usuário no app Configurações para ativar ou desativar provedores.

Fim dos novos requisitos

Se as implementações de dispositivos declararem suporte a android.hardware.telephony, elas:

[9.5/H-1-1] NÃO DEFINIR UserManager.isHeadlessSystemUserMode como true.

Implementações de dispositivos portáteis:

[9.11/H-0-2] É PRECISO fazer backup da implementação do keystore com um ambiente de execução isolado.
[9.11/H-0-3] É PRECISO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash da família MD5, SHA-1 e SHA-2 para oferecer suporte adequado aos algoritmos suportados pelo sistema do Keystore do Android em uma área isolada com segurança do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais em que o kernel ou o código do espaço do usuário pode acessar o estado interno do ambiente isolado, incluindo o DMA. O upstream do Android Open Source Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
[9.11/H-0-4] É PRECISO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e, somente quando bem-sucedida, permitir que as chaves vinculadas à autenticação sejam usadas. As credenciais da tela de bloqueio precisam ser armazenadas de uma maneira que permita que apenas o ambiente de execução isolado realize a autenticação da tela de bloqueio. O upstream do Android Open Source Project fornece a camada de abstração de hardware (HAL, na sigla em inglês) do gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.

Início dos novos requisitos para o Android 15

[9.11/H-0-5] É PRECISO oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser ~~compartilhadas em um número suficiente de dispositivos para impedir que as chaves~~ sejam impedidas de serem usadas como identificadores de dispositivo permanentes. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de uma SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

Observação: para atender a esse requisito, você precisa compartilhar a mesma chave de atestado para um determinado SKU,a menos que pelo menos 100.000 unidades desse SKU sejam produzidas. Se mais de 100.000 unidades desse SKU forem produzidas, uma chave diferente poderá ser usada para cada grupo de 100.000 unidades depois disso. Como alternativa, a solução de provisionamento de chave remota pode ser usada para provisionar chaves de atestado de curta duração no dispositivo.

Fim dos novos requisitos

Se uma implementação de dispositivo já tiver sido lançada em uma versão anterior do Android, esse dispositivo será isento do requisito de ter um keystore apoiado por um ambiente de execução isolado e oferecer suporte à confirmação de chave, a menos que ele declare o recurso android.hardware.fingerprint, que exige um keystore apoiado por um ambiente de execução isolado.

Quando as implementações de dispositivos portáteis oferecem suporte a uma tela de bloqueio segura, elas:

[9.11/H-1-1] É OBRIGATÓRIO permitir que o usuário escolha o tempo limite de inatividade mais curto, que é um tempo de transição do estado desbloqueado para o bloqueado, de 15 segundos ou menos.
[9.11/H-1-2] É PRECISO fornecer ao usuário a capacidade de ocultar notificações e desativar todas as formas de autenticação, exceto a principal descrita em 9.11.1 Tela de bloqueio segura. O AOSP atende ao requisito como modo de bloqueio total.

Se as implementações de dispositivo tiverem uma tela de bloqueio segura e incluirem um ou mais agentes de confiança, que implementam a API do sistema TrustAgentService, elas:

[9.11.1/H-1-1] É OBRIGATÓRIO solicitar ao usuário um dos métodos de autenticação principal recomendados (por exemplo, PIN, padrão, senha) com mais frequência do que uma vez a cada 72 horas.

Se as implementações de dispositivos portáteis incluem vários usuários e não declaram a flag de recurso android.hardware.telephony, elas:

[9.5/H-2-1] É PRECISO oferecer suporte a perfis restritos, um recurso que permite aos proprietários de dispositivos gerenciar outros usuários e os recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.

Se as implementações de dispositivos portáteis incluírem vários usuários e declararem a flag de recurso android.hardware.telephony, elas:

[9.5/H-3-1] NÃO é necessário oferecer suporte a perfis restritos, mas é necessário se alinhar à implementação de controles do AOSP para permitir /desativar o acesso de outros usuários às chamadas de voz e SMS.

Se as implementações de dispositivos portáteis definirem UserManager.isHeadlessSystemUserMode como true, elas

[9.5/H-4-1] NÃO deve incluir suporte para eUICCs nem para eSIMs com capacidade de chamada.
[9.5/H-4-2] NÃO É PERMITIDO declarar suporte para android.hardware.telephony.

O Android, por meio do VoiceInteractionService da API System, oferece suporte a um mecanismo para detecção segura de hotword sempre ativada sem indicação de acesso ao microfone e detecção de consulta sempre ativada, sem indicação de acesso ao microfone ou à câmera.

Início dos novos requisitos para o Android 15

Configurações restritas

As configurações restritas mostram avisos visíveis e solicitam a confirmação do usuário para conceder permissões para cada aplicativo que seja:

Ser instalado após o download por um aplicativo (por exemplo, um aplicativo de mensagens ou um navegador) que não seja um aplicativo de "app store" identificado por PackageManager como PACKAGE_DOWNLOADED_FILE.
Ser instalado de um arquivo local (por exemplo, o aplicativo foi transferido por sideload) identificado por PackageManager como PACKAGE_SOURCE_LOCAL_FILE.

Para qualquer uma das permissões aplicadas e os identificadores associados listados em [9.8/H-0-5] abaixo.

Essas inscrições são rotuladas como "Aplicativos cobertos" para os requisitos listados nesta seção.

Implementações de dispositivos:

[9.8/H-0-1] É OBRIGATÓRIO implementar as configurações restritas conforme descrito acima para o seguinte:
- Permissões especiais
  - Acessibilidade (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - Listener de notificações (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - Apps de administração de dispositivos (Manifest.permission.BIND_DEVICE_ADMIN)
  - Mostrar sobre outros apps (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - Acesso de uso (AppOpsManager.OPSTR_GET_USAGE_STATS)
- Funções (apps padrão)
  - Discador (RoleManager.ROLE_DIALER)
  - SMS (RoleManager.ROLE_SMS)
- Permissões de execução
  - Tempo de execução de SMS (Manifest.permission_group.SMS)
[9.8/H-0-2] É OBRIGATÓRIO ativar as configurações restritas como padrão e É ALTAMENTE RECOMENDADO que não haja nenhuma característica que permita ao usuário desativar as configurações restritas para todos os aplicativos.
[9.8/H-0-3] É OBRIGATÓRIO garantir que a confirmação do usuário seja obtida para cada aplicativo coberto antes que qualquer uma das permissões obrigatórias possa ser concedida.
[9.8/H-0-4] SOMENTE a confirmação do usuário deve ser permitida para permitir que as configurações restritas sejam obtidas na página AppInfo do aplicativo coberto, usando a API EnhancedConfirmationManager.
[9.8/H-0-5] É ALTAMENTE RECOMENDADO integrar e chamar o EnhancedConfirmationManager para todas as permissões especiais para determinar dinamicamente se elas são uma configuração restrita.
- Alarmes e lembretes: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Acesso a todos os arquivos: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Sobrepor a outros apps: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Instalar apps desconhecidos: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Gerenciar mídia: AppOpsManager.OPSTR_MANAGE_MEDIA
- Modificar configurações do sistema: AppOpsManager.OPSTR_WRITE_SETTINGS
- Picture-in-picture: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Ligar a tela: AppOpsManager.OPSTR_TURN_SCREEN_ON
- Notificações em tela cheia: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- Controle de Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Acessibilidade: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Listener de notificações: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Acesso de uso: AppOpsManager.OPSTR_GET_USAGE_STATS
- Administrador do dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
- Não perturbe: Manifest.permission.MANAGE_NOTIFICATIONS

Fim dos novos requisitos

Se as implementações de dispositivos portáteis oferecerem suporte à API do sistema HotwordDetectionService ou a outro mecanismo para detecção de palavras-chave sem indicação de acesso ao microfone, elas:

[9.8/H-1-1] É PRECISO garantir que o serviço de detecção de palavras-chave possa transmitir dados apenas para o sistema, ContentCaptureService ou o serviço de reconhecimento de fala no dispositivo criado por SpeechRecognizer#createOnDeviceSpeechRecognizer().
[9.8/H-1-2] É OBRIGATÓRIO garantir que o serviço de detecção de palavras-chave possa transmitir apenas dados de áudio do microfone ou dados derivados dele para o servidor do sistema pela API HotwordDetectionService ou para ContentCaptureService pela API ContentCaptureManager.
[9.8/H-1-3] NÃO é permitido fornecer áudio do microfone com mais de 30 segundos para uma solicitação individual acionada por hardware ao serviço de detecção de palavras-chave.
[9.8/H-1-4] NÃO é permitido fornecer áudio de microfone em buffer com mais de 8 segundos para uma solicitação individual ao serviço de detecção de hotword.
[9.8/H-1-5] NÃO é permitido fornecer áudio de microfone em buffer com mais de 30 segundos para o serviço de interação por voz ou entidade semelhante.
[9.8/H-1-6] MAIS DE 100 BYTES DE DADOS (EXCETO STREAMS DE ÁUDIO) NÃO PODEM SER TRANSMITIDOS DO SERVIÇO DE DETECÇÃO DE PALAVRAS-CHAVE EM CADA RESULTADO DE PALAVRA-CHAVE.
[9.8/H-1-7] NÃO É PERMITIDO que mais de 5 bits de dados sejam transmitidos do serviço de detecção de palavras-chave em cada resultado negativo.
[9.8/H-1-8] SOMENTE é permitido permitir a transmissão de dados para fora do serviço de detecção de palavras-chave em uma solicitação de validação de palavras-chave do servidor do sistema.
[9.8/H-1-9] NÃO é permitido que um app instalável pelo usuário forneça o serviço de detecção de palavras-chave.
[9.8/H-1-10] NÃO É PERMITIDO mostrar na interface dados quantitativos sobre o uso do microfone pelo serviço de detecção de palavras-chave.
[9.8/H-1-11] É OBRIGATÓRIO registrar o número de bytes incluídos em cada transmissão do serviço de detecção de palavras-chave para permitir a inspeção por pesquisadores de segurança.
[9.8/H-1-12] É PRECISO oferecer suporte a um modo de depuração que registre o conteúdo bruto de cada transmissão do serviço de detecção de palavras-chave para permitir a inspeção por pesquisadores de segurança.
[9.8/H-1-14] É PRECISO mostrar o indicador do microfone, conforme descrito na seção 9.8.2, quando um resultado de palavra de ativação bem-sucedida é transmitido ao serviço de interação por voz ou entidade semelhante.
[9.8/H-1-15] É PRECISO garantir que os streams de áudio fornecidos em resultados de hotword bem-sucedidos sejam transmitidos em uma direção do serviço de detecção de hotword para o serviço de interação por voz.
[9.8/H-SR-1] É ALTAMENTE RECOMENDADO notificar os usuários antes de definir um aplicativo como o provedor do serviço de detecção de palavras-chave.
[9.8/H-SR-2] É ALTAMENTE RECOMENDADO não permitir a transmissão de dados não estruturados do serviço de detecção de hotword.
[9.8/H-SR-3] É ALTAMENTE RECOMENDADO reiniciar o processo que hospeda o serviço de detecção de palavras-chave pelo menos uma vez a cada hora ou a cada 30 eventos de gatilho de hardware, o que ocorrer primeiro.

Se as implementações do dispositivo incluírem um app que usa a API System HotwordDetectionService ou um mecanismo semelhante para detecção de palavras-chave sem indicação de uso do microfone, o app:

[9.8/H-2-1] É PRECISO fornecer uma notificação explícita ao usuário para cada frase de ativação compatível.
[9.8/H-2-2] NÃO É PERMITIDO preservar dados de áudio brutos ou dados derivados deles pelo serviço de detecção de palavras-chave.
[9.8/H-2-3] NÃO É PERMITIDO transmitir do serviço de detecção de palavras-chave, dados de áudio, dados que possam ser usados para reconstruir (total ou parcialmente) o áudio ou conteúdos de áudio não relacionados à palavra-chave, exceto para o ContentCaptureService ou o serviço de reconhecimento de fala no dispositivo.

Se as implementações de dispositivos portáteis oferecerem suporte à API do sistema VisualQueryDetectionService ou a outro mecanismo para detecção de consultas sem indicação de acesso ao microfone e/ou à câmera, elas:

[9.8/H-3-1] É PRECISO garantir que o serviço de detecção de consultas só possa transmitir dados para o sistema, ContentCaptureService ou serviço de reconhecimento de fala no dispositivo (criado por SpeechRecognizer#createOnDeviceSpeechRecognizer()).
[9.8/H-3-2] NÃO É PERMITIDO transmitir informações de áudio ou vídeo fora do VisualQueryDetectionService, exceto para ContentCaptureService ou o serviço de reconhecimento de fala no dispositivo.
[9.8/H-3-3] É OBRIGATÓRIO mostrar uma notificação do usuário na interface do sistema quando o dispositivo detecta a intenção do usuário de interagir com o aplicativo de assistente digital (por exemplo, detectando a presença do usuário pela câmera).
[9.8/H-3-4] É OBRIGATÓRIO mostrar um indicador de microfone e a consulta do usuário detectada na interface logo após a detecção.
[9.8/H-3-5] NÃO é permitido que um aplicativo instalável pelo usuário forneça o serviço de detecção de consultas visuais.

Se as implementações de dispositivos portáteis declararem android.hardware.microphone, elas:

[9.8.2/H-4-1] É PRECISO mostrar o indicador do microfone quando um app estiver acessando dados de áudio do microfone, mas não quando o microfone for acessado apenas por HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService ou apps com as funções mencionadas na seção 9.1 com o identificador CDD [C-4-X].
[9.8.2/H-4-2] É PRECISO mostrar a lista de apps recentes e ativos usando o microfone conforme retornado por PermissionManager.getIndicatorAppOpUsageData(), junto com as mensagens de atribuição associadas a eles.
[9.8.2/H-4-3] O indicador do microfone NÃO PODE ser ocultado para apps do sistema que têm interfaces do usuário visíveis ou interação direta do usuário.
[9.8.2/H-4-4] É PRECISO mostrar a lista de apps recentes e ativos usando o microfone conforme retornado de PermissionManager.getIndicatorAppOpUsageData(), junto com as mensagens de atribuição associadas a eles.

Se as implementações de dispositivos portáteis declararem android.hardware.camera.any, elas:

[9.8.2/H-5-1] É OBRIGATÓRIO mostrar o indicador da câmera quando um app estiver acessando dados da câmera ao vivo, mas não quando a câmera estiver sendo acessada apenas por apps que tenham as funções mencionadas na seção 9.1 com o identificador CDD [C-4-X].
[9.8.2/H-5-2] É PRECISO mostrar os apps recentes e ativos usando a câmera conforme retornado de PermissionManager.getIndicatorAppOpUsageData(), junto com todas as mensagens de atribuição associadas a eles.
[9.8.2/H-5-3] É obrigatório não ocultar o indicador da câmera para apps do sistema que tenham interfaces do usuário visíveis ou interação direta do usuário.

Início dos novos requisitos para o Android 15

A inicialização verificada é um recurso que garante a integridade do software do dispositivo. Se as implementações de dispositivos oferecerem suporte ao recurso, elas:

[9.10/H-1-1] É OBRIGATÓRIO verificar todas as partições somente leitura montadas durante a sequência de inicialização do Android, e o resumo do VBMeta precisa incluir todas essas partições verificadas no cálculo.

Fim dos novos requisitos

2.2.6. Compatibilidade de ferramentas e opções para desenvolvedores

Implementações de dispositivos portáteis (* não aplicável a tablets):

[6.1/H-0-1]* TEM QUE oferecer suporte ao comando de shell cmd testharness.

Início dos novos requisitos para o Android 15

Implementações de dispositivos portáteis ~~(* Não aplicável a tablets)~~:

Perfetto
- [6.1/H-0-2]* É PRECISO expor um binário /system/bin/perfetto ao usuário do shell que o cmdline obedece à documentação do perfetto.
- [6.1/H-0-3]* O binário do perfetto PRECISA aceitar como entrada uma configuração protobuf que esteja em conformidade com o esquema definido na documentação do perfetto.
- [6.1/H-0-4]* O binário do perfetto PRECISA gravar como saída um rastro protobuf que obedeça ao esquema definido na documentação do perfetto.
- [6.1/H-0-5]* PRECISA fornecer, pelo binário do perfetto, pelo menos as origens de dados descritas na documentação do perfetto.
- [6.1/H-0-6]* O daemon de rastreamento do perfetto PRECISA ser ativado por padrão (propriedade do sistema persist.traced.enable).

Fim dos novos requisitos

2.2.7. Classe de desempenho de mídia portátil

Consulte a Seção 7.11 para a definição de classe de desempenho de mídia.

2.2.7.1. Mídia

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

DEVE atender aos requisitos de mídia listados na seção 2.2.7.1 do CDD do Android 14.

Início dos novos requisitos para o Android 15

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

Fim dos novos requisitos

[5.1/H-1-1] É PRECISO anunciar o número máximo de sessões de decodificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().

Início dos novos requisitos para o Android 15

[5.1/H-1-2] É PRECISO oferecer suporte a seis instâncias de sessões de decodificador de vídeo de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente com três sessões em resolução 1080p a 30 fps e três sessões em resolução 4K a 30 fps. Em todas as sessões, NÃO pode haver mais de um frame perdido por segundo. Os codecs AV1 só precisam oferecer suporte à resolução de 1080p, mas ainda precisam oferecer suporte a seis instâncias a 1080p30fps.

Fim dos novos requisitos

[5.1/H-1-3] É OBRIGATÓRIO anunciar o número máximo de sessões de codificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().

Início dos novos requisitos para o Android 15

[5.1/H-1-4] É PRECISO oferecer suporte a 6 instâncias de sessões de codificador de vídeo de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente com 4 sessões em resolução 1080p a 30 fps e 2 sessões em resolução 4K a 30 fps. Em todas as sessões, NÃO pode haver mais de um frame perdido por segundo. Os codecs AV1 são necessários apenas para oferecer suporte à resolução de 1080p, mas ainda são necessários para oferecer suporte a seis instâncias a 1080p30fps.

Fim dos novos requisitos

[5.1/H-1-5] É OBRIGATÓRIO anunciar o número máximo de sessões de codificador e decodificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().

Início dos novos requisitos para o Android 15

[5.1/H-1-6] É PRECISO oferecer suporte a seis instâncias de decodificador de vídeo de hardware de 8 bits (SDR) e sessões de codificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente com três sessões em resolução 4K a 30 fps, sendo que no máximo duas são sessões de codificador e três em resolução 1080p. Em todas as sessões, NÃO pode haver mais de um frame perdido por segundo. Os codecs AV1 são necessários apenas para oferecer suporte à resolução de 1080p, mas ainda são necessários para oferecer suporte a seis instâncias a 1080p30fps.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

[5.1/H-1-19] É PRECISO ter suporte a três instâncias de decodificador de vídeo de hardware de 10 bits (HDR) e sessões de codificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 4K a 30 fps, sendo que no máximo uma é uma sessão de codificador, que pode ser configurada no formato de entrada RGBA_1010102 por uma superfície GL. Em todas as sessões, NÃO pode haver mais de um frame perdido por segundo. A geração de metadados HDR pelo codificador não é necessária se a codificação for feita pela superfície GL. As sessões de codec AV1 são necessárias apenas para oferecer suporte à resolução de 1080p, mesmo quando esse requisito exige 4K.

Fim dos novos requisitos

[5.1/H-1-7] É PRECISO ter uma latência de inicialização de codec de 40 ms ou menos para uma sessão de codificação de vídeo de 1080p ou menor para todos os codificadores de vídeo de hardware quando sob carga. O carregamento aqui é definido como uma sessão de transcodificação de vídeo de 1080p para 720p simultânea usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo de 1080p. Para o codec Dolby Vision, a latência de inicialização do codec PRECISA ser de 50 ms ou menos.
[5.1/H-1-8] É PRECISO ter uma latência de inicialização do codec de 30 ms ou menos para uma sessão de codificação de áudio de 128 kbps ou menos para todos os codificadores de áudio quando sob carga. O carregamento aqui é definido como uma sessão de transcodificação de vídeo de 1080p para 720p simultânea usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo de 1080p.

Início dos novos requisitos para o Android 15

[5.1/H-1-9] É PRECISO oferecer suporte a duas instâncias de sessões de decodificador de vídeo de hardware seguras (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 1080p a 30 fps para conteúdo HDR de 8 bits (SDR) e 10 bits. Para todas as sessões, NÃO pode haver mais de um frame descartado por segundo.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

[5.1/H-1-10] É PRECISO oferecer suporte a três instâncias de sessões de decodificador de vídeo de hardware não seguras com uma instância de sessão de decodificador de vídeo de hardware segura (4 instâncias no total) (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente com três sessões em resolução 4K a 30 fps que inclui uma sessão de decodificador segura e uma sessão não segura em resolução 1080p a 30 fps, em que no máximo duas sessões podem estar em HDR de 10 bits. Em todas as sessões, NÃO pode haver mais de um frame perdido por segundo. As sessões de codec AV1 só precisam oferecer suporte à resolução de 1080p, mesmo quando esse requisito exige 4K.

Fim dos novos requisitos

[5.1/H-1-11] É PRECISO oferecer suporte a um decodificador seguro para cada decodificador AVC, HEVC, VP9 ou AV1 de hardware no dispositivo.
[5.1/H-1-12] É PRECISO ter uma latência de inicialização de codec de 40 ms ou menos para uma sessão de decodificação de vídeo de 1080p ou menor para todos os decodificadores de vídeo de hardware quando em carga. O carregamento aqui é definido como uma sessão de transcodificação de vídeo simultânea de 1080p para 720p usando codecs de vídeo de hardware com a inicialização de reprodução de áudio e vídeo de 1080p. Para o codec Dolby Vision, a latência de inicialização do codec PRECISA ser de 50 ms ou menos.
[5.1/H-1-13] É OBRIGATÓRIO ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de decodificação de áudio de 128 kbps ou menos para todos os decodificadores de áudio durante o carregamento. O carregamento aqui é definido como uma sessão de transcodificação de vídeo concorrente de 1080p para 720p usando codecs de vídeo de hardware com a inicialização de reprodução de áudio-vídeo de 1080p.

Início dos novos requisitos para o Android 15

[5.1/H-1-14] É PRECISO oferecer suporte ao decodificador de hardware AV1 Main 10, nível 4.1 ~~e granulação~~ com efeito de granulação na composição da GPU.

Fim dos novos requisitos

[5.1/H-1-15] É PRECISO ter pelo menos 1 decodificador de vídeo de hardware compatível com 4K60.
[5.1/H-1-16] É PRECISO ter pelo menos 1 codificador de vídeo de hardware compatível com 4K60.

Início dos novos requisitos para o Android 15

[5.1/H-1-21] É PRECISO oferecer suporte a FEATURE_DynamicColorAspect para todos os decodificadores de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recentes). Observação: isso significa que os aplicativos podem atualizar os aspectos de cor do conteúdo de vídeo durante a sessão de decodificação. Os decodificadores que oferecem suporte a conteúdo de 10 e 8 bits precisam oferecer suporte à troca dinâmica entre conteúdo de 8 e 10 bits no modo de superfície. Os decodificadores que oferecem suporte à função de transferência HDR precisam oferecer suporte à troca dinâmica entre conteúdo SDR e HDR.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

[5.1/H-1-22] É PRECISO oferecer suporte à codificação, decodificação, edição de GPU e exibição de conteúdo de vídeo na proporção de retrato, independentemente dos metadados de rotação para a maior resolução com suporte da câmera ou 4K, o que for menor. Observação: isso inclui perfis HDR se o codec tiver suporte a HDR. Os codecs AV1 só precisam oferecer suporte à resolução de 1080p. Esse requisito é válido apenas para codecs de hardware, GPU e DPU.

Fim dos novos requisitos

[5.3/H-1-1] NÃO PODE haver mais de 1 frame em 10 segundos (ou seja, menos de 0,167% de queda de frames) para uma sessão de vídeo 4K a 60 fps durante o carregamento.
[5.3/H-1-2] NÃO é permitido perder mais de um frame em 10 segundos durante uma mudança de resolução de vídeo em uma sessão de vídeo de 60 fps sob carga para uma sessão de 4K.
[5.6/H-1-1] É PRECISO ter uma latência de toque para tom de 80 milissegundos ou menos usando o teste de toque para tom do verificador do CTS.
[5.6/H-1-2] É PRECISO ter uma latência de áudio de ida e volta de 80 milissegundos ou menos em pelo menos um caminho de dados compatível.
[5.6/H-1-3] É PRECISO oferecer suporte a áudio de 24 bits para saída estéreo por meio de conectores de áudio de 3,5 mm, se presentes, e por áudio USB, se houver suporte em todo o caminho de dados para configurações de baixa latência e streaming. Para a configuração de baixa latência, a AAudio precisa ser usada pelo app no modo de callback de baixa latência. Para a configuração de streaming, o app precisa usar um AudioTrack Java. Nas configurações de baixa latência e streaming, o destino de saída do HAL precisa aceitar AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT ou AUDIO_FORMAT_PCM_FLOAT como formato de saída de destino.

Início dos novos requisitos para o Android 15

[5.6/H-1-4] É PRECISO oferecer suporte a dispositivos de áudio USB de 4 canais ou mais. ~~(Isso é usado por controladores de DJ para pré-visualizar músicas.)~~

Fim dos novos requisitos

[5.6/H-1-5] É PRECISO oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar a flag de recurso MIDI.
[5.6/H-1-9] É PRECISO ter suporte a pelo menos 12 canais de mixagem. Isso implica a capacidade de abrir um AudioTrack com máscara de canal 7.1.4 e espacializar ou downmixar todos os canais para estéreo.
[5.6/H-SR] É ALTAMENTE RECOMENDADO oferecer suporte à mixagem de 24 canais com pelo menos suporte a máscaras de canal 9.1.6 e 22.2.
[5.7/H-1-2] É PRECISO oferecer suporte a MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL com os recursos de descriptografia de conteúdo abaixo.

Tamanho mínimo da amostra	4 MiB
Número mínimo de subamostras: H264 ou HEVC	32
Número mínimo de subamostras: VP9	9
Número mínimo de subamostras: AV1	288
Tamanho mínimo do buffer de subamostragem	1 MiB
Tamanho mínimo do buffer de criptografia genérica	500 KiB
Número mínimo de sessões simultâneas	30
Número mínimo de chaves por sessão	20
Número total mínimo de chaves (todas as sessões)	80
Número total mínimo de chaves DRM (todas as sessões)	6
Tamanho da mensagem	16 KiB
Frames descriptografados por segundo	60 fps

[5.1/H-1-17] É PRECISO ter pelo menos um decodificador de imagem de hardware com suporte ao perfil de referência AVIF.
[5.1/H-1-18] É PRECISO ter suporte ao codificador AV1, que pode codificar até a resolução de 480p a 30 fps e 1 Mbps.

Início dos novos requisitos para o Android 15

[5.1/H-1-20] É PRECISO oferecer suporte ao recurso Feature_HdrEditing para todos os codificadores AV1 e HEVC de hardware presentes no dispositivo com resolução 4K ou a maior resolução com suporte da câmera, o que for menor.

Fim dos novos requisitos

[5.12/H-SR] É altamente recomendável oferecer suporte ao recurso Feature_HdrEditing para todos os codificadores AV1 e HEVC de hardware presentes no dispositivo.
[5.12/H-1-2] É PRECISO oferecer suporte ao formato de cor RGBA_1010102 para todos os codificadores AV1 e HEVC de hardware presentes no dispositivo.
[5.12/H-1-3] É PRECISO anunciar o suporte à extensão EXT_YUV_target para amosar texturas YUV em 8 e 10 bits.
[7.1.4/H-1-1] É PRECISO ter pelo menos seis sobreposições de hardware na unidade de processamento de tela (DPU, na sigla em inglês), sendo que pelo menos duas delas precisam exibir conteúdo de vídeo de 10 bits.

Início dos novos requisitos para o Android 15

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS e incluírem suporte a um codificador AVC ou HEVC de hardware, elas:

Fim dos novos requisitos

[5.2/H-2-1] É PRECISO atender à meta mínima de qualidade definida pelas curvas de distorção de taxa do codificador de vídeo para codecs AVC e HEVC de hardware, conforme definido em Executar testes de qualidade de codificação de vídeo (VEQ) da classe de desempenho 14 (PC14).

2.2.7.2. Câmera

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

PRECISA atender aos requisitos de mídia listados na seção 2.2.7.2 do CDD do Android 14.

Início dos novos requisitos para o Android 15

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

[7.5/H-1-1] É PRECISO ter uma câmera traseira principal com uma resolução de pelo menos 12 megapixels que ofereça suporte à gravação de vídeo em 4K a 30 QPS, 1080p a 60 QPS e 720p a 60 QPS. A câmera traseira principal é a câmera traseira com o ID mais baixo.

Fim dos novos requisitos

[7.5/H-1-2] É OBRIGATÓRIO ter uma câmera frontal principal com uma resolução de pelo menos 6 megapixels e suporte para gravação de vídeo em 1080p a 30 fps. A câmera frontal principal é a que tem o ID mais baixo.
[7.5/H-1-3] É PRECISO oferecer suporte à propriedade android.info.supportedHardwareLevel como FULL ou melhor para a câmera principal traseira e LIMITED ou melhor para a câmera principal frontal.
[7.5/H-1-4] É PRECISO oferecer suporte a CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para as duas câmeras principais.
[7.5/H-1-5] É OBRIGATÓRIO ter latência de captura de JPEG da camera2 de menos de 1000 ms para resolução de 1080p, conforme medido pelo PerformanceTest da câmera do CTS sob condições de iluminação ITS (3000K) para as duas câmeras principais.
[7.5/H-1-6] É PRECISO ter a latência de inicialização da camera2 (abrir a câmera para o primeiro frame de visualização) < 500 ms, conforme medido pelo PerformanceTest da câmera CTS sob as condições de iluminação do ITS (3000K) para as duas câmeras principais.
[7.5/H-1-8] É PRECISO ter suporte a CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW e android.graphics.ImageFormat.RAW_SENSOR para a câmera traseira principal.
[7.5/H-1-9] É OBRIGATÓRIO ter uma câmera principal traseira com suporte para 720p ou 1080p a 240 fps.
[7.5/H-1-10] É PRECISO ter ZOOM_RATIO mínimo < 1,0 para as câmeras principais se houver uma câmera RGB ultralarga voltada para a mesma direção.
[7.5/H-1-11] É PRECISO implementar o streaming frontal e traseiro simultâneo nas câmeras principais.
[7.5/H-1-12] É PRECISO ter suporte a CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para a câmera frontal principal e a câmera traseira principal.
[7.5/H-1-13] É PRECISO oferecer suporte ao recurso LOGICAL_MULTI_CAMERA para a câmera traseira principal se houver mais de uma câmera RGB traseira.
[7.5/H-1-14] É NECESSÁRIO oferecer suporte ao recurso STREAM_USE_CASE para a câmera frontal principal e a câmera traseira principal.
[7.5/H-1-15] É PRECISO oferecer suporte a extensões do modo noturno usando extensões do CameraX e Camera2 para câmeras principais.
[7.5/H-1-16] É PRECISO oferecer suporte ao recurso DYNAMIC_RANGE_TEN_BIT para as câmeras principais.
[7.5/H-1-17] É PRECISO oferecer suporte a CONTROL_SCENE_MODE_FACE_PRIORITY e à detecção de rosto (STATISTICS_FACE_DETECT_MODE_SIMPLE ou STATISTICS_FACE_DETECT_MODE_FULL) para as câmeras principais.

Início dos novos requisitos para o Android 15

[7.5/H-1-18] É NECESSÁRIO oferecer suporte a JPEG_R para as câmeras traseira e frontal principais.
[7.5/H-1-19] É PRECISO ter suporte a CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para visualização de HLG10 de 1080p com JPEG de proporção 16:9 de tamanho máximo e para visualização de HLG10 de 720p com combinações de fluxo de JPEG de proporção 16:9 de tamanho máximo para a câmera traseira principal.
[7.5/H-1-20] É OBRIGATÓRIO que a saída JPEG_R seja padrão para as câmeras traseira e frontal principais no app de câmera nativo.

Fim dos novos requisitos

2.2.7.3. Hardware

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

PRECISA atender aos requisitos de mídia listados na seção 2.2.7.3 do CDD do Android 14.

Início dos novos requisitos para o Android 15

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

Fim dos novos requisitos

[7.1.1.1/H-2-1] É PRECISO ter uma resolução de tela de pelo menos 1080p.

Início dos novos requisitos para o Android 15

[7.1.1.3/H-2-1] É PRECISO ter uma densidade de tela de pelo menos 400 dpi se a largura da tela do dispositivo for < 600 dp.

Fim dos novos requisitos

[7.1.1.3/H-3-1] É PRECISO ter uma tela HDR com suporte a pelo menos 1.000 nits de média.

Início dos novos requisitos para o Android 15

[7.6.1/H-2-1] É PRECISO ter pelo menos 8 GB de memória física, com pelo menos 6,64 GB disponíveis para o kernel, conforme informado por android.app.ActivityManager.MemoryInfo.totalMem.

Fim dos novos requisitos

2.2.7.4. Desempenho

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

É PRECISO atender aos requisitos de desempenho listados na seção 2.2.7.4 do CDD do Android 14.

Início dos novos requisitos para o Android 15

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

Fim dos novos requisitos

[8.2/H-1-1] É PRECISO garantir um desempenho de gravação sequencial de pelo menos 150 MB/s.
[8.2/H-1-2] É PRECISO garantir um desempenho de gravação aleatória de pelo menos 10 MB/s.
[8.2/H-1-3] É PRECISO garantir um desempenho de leitura sequencial de pelo menos 250 MB/s.
[8.2/H-1-4] É PRECISO garantir um desempenho de leitura aleatória de pelo menos 100 MB/s.
[8.2/H-1-5] É PRECISO garantir um desempenho de leitura e gravação sequencial paralelo com desempenho de leitura 2x e gravação 1x de pelo menos 50 MB/s.

Início dos novos requisitos para o Android 15

2.2.7.5. Gráficos

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

[7.1.4.1/H-1-2] É PRECISO oferecer suporte às extensões EGL_IMG_context_priority e EGL_EXT_protected_content.
[7.1.4.1/H-1-3] É PRECISO ter suporte a VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_KHR_global_priority.

Fim dos novos requisitos

2.3. Requisitos de televisão

Um dispositivo Android TV se refere a uma implementação de dispositivo Android que é uma interface de entretenimento para consumir mídia digital, filmes, jogos, apps e/ou TV ao vivo para usuários sentados a cerca de três metros de distância (uma "interface de usuário leanback" ou "10 pés").

As implementações de dispositivos Android são classificadas como uma televisão se atenderem a todos os seguintes critérios:

Fornecer um mecanismo para controlar remotamente a interface do usuário renderizada na tela, que pode estar a 3 metros de distância do usuário.
Ter uma tela incorporada com comprimento diagonal maior que 24 polegadas OU incluir uma porta de saída de vídeo, como VGA, HDMI, DisplayPort ou uma porta sem fio para exibição.

Os requisitos adicionais no restante desta seção são específicos para implementações de dispositivos Android TV.

2.3.1. Hardware

Implementações de dispositivos de TV:

[7.2.2/T-0-1] É PRECISO ter suporte a D-pad.
[7.2.3/T-0-1] É OBRIGATÓRIO fornecer as funções "Início" e "Voltar".
[7.2.3/T-0-2] É PRECISO enviar o evento de pressionamento normal e longo da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano.
[7.2.6.1/T-0-1] É PRECISO incluir suporte a controles de jogos e declarar a flag de recurso android.hardware.gamepad.
[7.2.7/T] DEVE fornecer um controle remoto em que os usuários possam acessar as entradas de navegação sem toque e chaves de navegação principais.

Se as implementações de dispositivos de TV incluem um giroscópio de três eixos, elas:

[7.3.4/T-1-1] PRECISA ser capaz de informar eventos com frequência de pelo menos 100 Hz.
[7.3.4/T-1-2] É PRECISO medir mudanças de orientação de até 1.000 graus por segundo.

Implementações de dispositivos de TV:

[7.4.3/T-0-1] É PRECISO ter suporte a Bluetooth e Bluetooth LE.
[7.6.1/T-0-1] É PRECISO ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecido como partição "/data").

Se as implementações de dispositivos de TV incluírem uma porta USB compatível com o modo host, elas:

[7.5.3/T-1-1] É PRECISO incluir suporte a uma câmera externa que se conecte por essa porta USB, mas não necessariamente esteja sempre conectada.

Se as implementações do dispositivo de TV forem de 32 bits:

[7.6.1/T-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se qualquer uma das densidades a seguir for usada:
- 400 dpi ou mais em telas pequenas/normais
- xhdpi ou superior em telas grandes
- tvdpi ou superior em telas extragrandes

Se as implementações do dispositivo de TV forem de 64 bits:

[7.6.1/T-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB se qualquer uma das densidades a seguir for usada:
- 400 dpi ou mais em telas pequenas/normais
- xhdpi ou superior em telas grandes
- tvdpi ou superior em telas extragrandes

Implementações de dispositivos de TV:

[7.8.1/T] DEVE incluir um microfone.
[7.8.2/T-0-1] É PRECISO ter uma saída de áudio e declarar android.hardware.audio.output.

2.3.2. Multimídia

As implementações de dispositivos de TV precisam oferecer suporte aos seguintes formatos de codificação e decodificação de áudio e disponibilizá-los para aplicativos de terceiros:

[5.1/T-0-1] Perfil MPEG-4 AAC (AAC LC)
[5.1/T-0-2] Perfil MPEG-4 HE AAC (AAC+)
[5.1/T-0-3] AAC ELD (AAC aprimorado com atraso baixo)

As implementações de dispositivos de TV precisam oferecer suporte aos seguintes formatos de codificação de vídeo e disponibilizá-los para aplicativos de terceiros:

[5.2/T-0-1] H.264
[5.2/T-0-2] VP8
[5.2/T-0-3] AV1

Implementações de dispositivos de TV:

[5.2.2/T-SR-1] É ALTAMENTE RECOMENDÁVEL oferecer suporte à codificação H.264 de vídeos com resolução de 720p e 1080p a 30 quadros por segundo.

As implementações de dispositivos de TV precisam oferecer suporte aos seguintes formatos de decodificação de vídeo e disponibilizá-los para aplicativos de terceiros:

[5.3.3/T-0-1] MPEG-4 SP
[5.3.4/T-0-2] H.264 AVC
[5.3.5/T-0-3] H.265 HEVC
[5.3.6/T-0-4] VP8
[5.3.7/T-0-5] VP9
[5.3.1/T-0-6] MPEG-2
[5.3.2/T-0-7] AV1

As implementações de dispositivos de TV precisam oferecer suporte à decodificação MPEG-2, conforme detalhado na Seção 5.3.1, em frame rates e resoluções de vídeo padrão até e incluindo:

[5.3.1/T-1-1] HD 1080p a 29,97 quadros por segundo com perfil principal de alto nível.
[5.3.1/T-1-2] HD 1080i a 59,94 fps com perfil principal de alto nível. Eles precisam desentrelaçar o vídeo MPEG-2 entrelaçado e disponibilizá-lo para aplicativos de terceiros.

As implementações de dispositivos de TV precisam oferecer suporte à decodificação H.264, conforme detalhado na Seção 5.3.4, com frame rates e resoluções de vídeo padrão até o seguinte:

[5.3.4/T-1-1] HD 1080p a 60 frames por segundo com perfil de referência
[5.3.4/T-1-2] HD 1080p a 60 frames por segundo com perfil principal
[5.3.4/T-1-3] HD 1080p a 60 frames por segundo com o perfil de alta definição de nível 4.2

As implementações de dispositivos de TV com decodificadores de hardware H.265 precisam oferecer suporte à decodificação H.265, conforme detalhado na seção 5.3.5, em frame rates de vídeo padrão e resoluções até e incluindo:

[5.3.5/T-1-1] HD 1080p a 60 frames por segundo com nível 4.1 do perfil principal

Se as implementações de dispositivos de TV com decodificadores de hardware H.265 forem compatíveis com a decodificação H.265 e o perfil de decodificação UHD, elas:

[5.3.5/T-2-1] É PRECISO oferecer suporte ao perfil de decodificação UHD a 60 frames por segundo com o perfil de nível principal Main10 de nível 5

As implementações de dispositivos de TV precisam oferecer suporte à decodificação VP8, conforme detalhado na Seção 5.3.6, em frame rates e resoluções de vídeo padrão até o seguinte:

[5.3.6/T-1-1] Perfil de decodificação de 1080p HD a 60 frames por segundo

As implementações de dispositivos de TV com decodificadores de hardware VP9 precisam oferecer suporte à decodificação VP9, conforme detalhado na seção 5.3.7, em taxas de quadros de vídeo padrão e resoluções até:

[5.3.7/T-1-1] HD 1080p a 60 frames por segundo com perfil 0 (profundidade de cor de 8 bits)

Se as implementações de dispositivos de TV com decodificadores de hardware VP9 oferecerem suporte à decodificação VP9 e ao perfil de decodificação UHD, elas:

[5.3.7/T-2-1] É PRECISO oferecer suporte ao perfil de decodificação UHD a 60 frames por segundo com o perfil 0 (profundidade de cor de 8 bits).
[5.3.7/T-SR1] É ALTAMENTE RECOMENDADO oferecer suporte ao perfil de decodificação UHD a 60 frames por segundo com o perfil 2 (profundidade de cor de 10 bits).

Implementações de dispositivos de TV:

[5.5/T-0-1] É OBRIGATÓRIO incluir suporte para o Volume principal do sistema e a atenuação do volume de saída de áudio digital nas saídas com suporte, exceto para a saída de passagem de áudio compactado (em que nenhuma decodificação de áudio é feita no dispositivo).

Se as implementações de dispositivos de TV não tiverem uma tela integrada, mas oferecerem suporte a uma tela externa conectada por HDMI, elas:

[5.8/T-0-1] É PRECISO definir o modo de saída HDMI para a maior resolução do formato de pixel escolhido que funcione com a taxa de atualização de 50 Hz ou 60 Hz para a tela externa, dependendo da taxa de atualização de vídeo da região em que o dispositivo é vendido.
[5.8/T-SR-1] É ALTAMENTE RECOMENDADO fornecer um seletor de taxa de atualização HDMI configurável pelo usuário.
[5.8] A taxa de atualização do modo de saída HDMI deve ser definida como 50 Hz ou 60 Hz, dependendo da taxa de atualização de vídeo da região em que o dispositivo é vendido.

Se as implementações de dispositivos de TV não tiverem uma tela integrada, mas oferecerem suporte a uma tela externa conectada por HDMI, elas:

[5.8/T-1-1] É PRECISO ter suporte a HDCP 2.2.

Se as implementações de dispositivos de TV não oferecerem suporte à decodificação UHD, mas oferecerem suporte a uma tela externa conectada por HDMI, elas:

[5.8/T-2-1] É PRECISO ter suporte a HDCP 1.4.

2.3.3. Software

Implementações de dispositivos de TV:

[3/T-0-1] É OBRIGATÓRIO declarar os recursos android.software.leanback e android.hardware.type.television.
[3.2.3.1/T-0-1] É OBRIGATÓRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intents públicos definidos pelas seguintes intents do app listadas aqui.
[3.4.1/T-0-1] É necessário fornecer uma implementação completa da API android.webkit.Webview.

Se as implementações de dispositivos Android TV oferecerem suporte a uma tela de bloqueio,elas:

[3.8.10/T-1-1] É OBRIGATÓRIO mostrar as notificações da tela de bloqueio, incluindo o modelo de notificação de mídia.

Implementações de dispositivos de TV:

[3.8.14/T-SR-1] É ALTAMENTE RECOMENDÁVEL oferecer suporte ao modo picture-in-picture (PIP) com várias janelas.
[3.10/T-0-1] É PRECISO oferecer suporte a serviços de acessibilidade de terceiros.
[3.10/T-SR-1] É ALTAMENTE RECOMENDÁVEL carregar previamente os serviços de acessibilidade no dispositivo com funcionalidade semelhante ou superior ao Acesso com interruptor e ao TalkBack (para idiomas compatíveis com o mecanismo de conversão de texto em voz pré-instalado), conforme fornecido no projeto de código aberto do TalkBack.

Se as implementações de dispositivos de TV informarem o recurso android.hardware.audio.output, elas:

[3.11/T-SR-1] É ALTAMENTE RECOMENDADO incluir um motor de TTS que ofereça suporte aos idiomas disponíveis no dispositivo.
[3.11/T-1-1] É PRECISO oferecer suporte à instalação de motores de TTS de terceiros.

Início dos novos requisitos para o Android 15

Implementações de dispositivos de TV:

[3.12/T-0-1] É necessário oferecer suporte ao TV Input Framework.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

Implementações de dispositivos de TV:

[3/T-0-2] É OBRIGATÓRIO declarar o recurso da plataforma android.software.live_tv.
[3/T-0-3] É PRECISO oferecer suporte a todas as APIs TIF para que um aplicativo que use essas APIs e o serviço de entradas de terceiros baseado em TIF possa ser instalado e usado no dispositivo.

O Android TV Tuner Framework (TF) unifica o processamento de conteúdo ao vivo do sintonizador com o streaming de conteúdo de IP em dispositivos Android TV. O Tuner Framework fornece uma API padrão para criar serviços de entrada que usam o sintonizador de TV Android.

Se as implementações de dispositivos oferecem suporte ao Tuner, elas:

[3/T-1-1] É PRECISO oferecer suporte a todas as APIs do Tuner Framework para que um aplicativo que use essas APIs possa ser instalado e usado no dispositivo.

Fim dos novos requisitos

2.3.4. Desempenho e bateria

[8.1/T-0-1] Latência consistente de frames. A latência inconsistente de frames ou um atraso na renderização de frames NÃO PODE acontecer mais frequentemente do que 5 frames por segundo e DEVE estar abaixo de 1 frame por segundo.
[8.2/T-0-1] É PRECISO garantir um desempenho de gravação sequencial de pelo menos 5 MB/s.
[8.2/T-0-2] É PRECISO garantir um desempenho de gravação aleatória de pelo menos 0,5 MB/s.
[8.2/T-0-3] É PRECISO garantir um desempenho de leitura sequencial de pelo menos 15 MB/s.
[8.2/T-0-4] É NECESSÁRIO garantir um desempenho de leitura aleatória de pelo menos 3,5 MB/s.

Se as implementações de dispositivos de TV incluírem recursos para melhorar o gerenciamento de energia do dispositivo que estão incluídos no AOSP ou estenderem os recursos incluídos no AOSP, elas:

[8.3/T-1-1] É PRECISO fornecer ao usuário a capacidade de ativar e desativar o recurso de economia de bateria.

Se as implementações de dispositivos de TV não tiverem uma bateria, elas:

[8.3/T-1-2] É PRECISO registrar o dispositivo como um dispositivo sem bateria, conforme descrito em Suporte a dispositivos sem bateria.

Se as implementações de dispositivos de televisão tiverem uma bateria, elas:

[8.3/T-1-3] É PRECISO fornecer ao usuário a capacidade de exibir todos os apps que estão isentos dos modos de economia de energia do App Standby e da Soneca.

Implementações de dispositivos de TV:

[8.4/T-0-1] É OBRIGATÓRIO fornecer um perfil de energia por componente que defina o valor de consumo atual para cada componente de hardware e o consumo de bateria aproximado causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.
[8.4/T-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliamperes-hora (mAh).
[8.4/T-0-3] É OBRIGATÓRIO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito pela implementação do módulo do kernel uid_cputime.
[8.4/T] DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
[8.4/T-0-4] É OBRIGATÓRIO disponibilizar esse uso de energia pelo comando de shell adb shell dumpsys batterystats ao desenvolvedor do app.

2.3.5. Modelo de segurança

Implementações de dispositivos de TV:

[9/T-0-1] É PRECISO declarar o recurso android.hardware.security.model.compatible.
[9.11/T-0-1] É PRECISO fazer backup da implementação do keystore com um ambiente de execução isolado.
[9.11/T-0-2] É OBRIGATÓRIO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash da família MD5, SHA-1 e SHA-2 para oferecer suporte adequado aos algoritmos suportados pelo sistema do Keystore do Android em uma área isolada com segurança do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais em que o código do kernel ou do espaço do usuário pode acessar o estado interno do ambiente isolado, incluindo o DMA. O upstream do Android Open Source Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
[9.11/T-0-3] É PRECISO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e, somente quando for bem-sucedida, permitir que as chaves vinculadas à autenticação sejam usadas. As credenciais da tela de bloqueio precisam ser armazenadas de uma maneira que permita que apenas o ambiente de execução isolado realize a autenticação da tela de bloqueio. O upstream do Android Open Source Project fornece a camada de abstração de hardware (HAL, na sigla em inglês) do gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.

Início dos novos requisitos para o Android 15

[9.11/T-0-4] É PRECISO oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser ~~compartilhadas em um número suficiente de dispositivos para impedir que as chaves~~ sejam impedidas de serem usadas como identificadores de dispositivo permanentes. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de uma SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

Observação: para atender a esse requisito, você precisa compartilhar a mesma chave de atestado para um determinado SKU,a menos que pelo menos 100.000 unidades desse SKU sejam produzidas. Se mais de 100.000 unidades desse SKU forem produzidas, uma chave diferente poderá ser usada para cada grupo de 100.000 unidades depois disso. Como alternativa, a solução de provisionamento de chave remota pode ser usada para provisionar chaves de atestado de curta duração no dispositivo.

Fim dos novos requisitos

Se as implementações de dispositivos de TV oferecem suporte a uma tela de bloqueio segura, elas:

[9.11/T-1-1] É OBRIGATÓRIO permitir que o usuário escolha o tempo limite de suspensão para a transição do estado desbloqueado para o bloqueado, com um tempo limite mínimo permitido de até 15 segundos ou menos.

Se as implementações de dispositivo de TV incluírem vários usuários e não declararem a flag de recurso android.hardware.telephony, elas:

[9.5/T-2-1] É PRECISO oferecer suporte a perfis restritos, um recurso que permite aos proprietários de dispositivos gerenciar outros usuários e os recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.

Se as implementações de dispositivos de TV incluírem vários usuários e declararem a flag de recurso android.hardware.telephony, elas:

[9.5/T-3-1] NÃO é necessário oferecer suporte a perfis restritos, mas é necessário se alinhar à implementação de controles do AOSP para permitir /desabilitar o acesso de outros usuários às chamadas de voz e aos SMS.

Se as implementações de dispositivos de TV declararem android.hardware.microphone, elas:

[9.8.2/T-4-1] É OBRIGATÓRIO mostrar o indicador do microfone quando um app estiver acessando dados de áudio do microfone, mas não quando o microfone for acessado apenas por HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou apps que tenham as funções mencionadas na seção 9.1 Permissões com identificador CDD C-3-X.
[9.8.2/T-4-2] O indicador do microfone NÃO PODE ser ocultado para apps do sistema que têm interfaces do usuário visíveis ou interação direta do usuário.

Se as implementações de dispositivos de TV declararem android.hardware.camera.any, elas:

[9.8.2/T-5-1] É OBRIGATÓRIO mostrar o indicador da câmera quando um app estiver acessando dados da câmera ao vivo, mas não quando a câmera estiver sendo acessada apenas por apps que têm as funções mencionadas na seção 9.1 Permissões com identificador CDD [C-3-X].
[9.8.2/T-5-2] Não é permitido ocultar o indicador da câmera em apps do sistema que têm interfaces do usuário visíveis ou interação direta do usuário.

2.3.6. Compatibilidade de ferramentas e opções para desenvolvedores

Início dos novos requisitos para o Android 15

Implementações de dispositivos de TV:

Perfetto
- [6.1/T-0-1] É PRECISO expor um binário /system/bin/perfetto ao usuário do shell que o cmdline obedece à documentação do perfetto.
- [6.1/T-0-2] O binário do perfetto PRECISA aceitar como entrada uma configuração protobuf que obedeça ao esquema definido na documentação do perfetto.
- [6.1/T-0-3] O binário do perfetto PRECISA gravar como saída um trace de protobuf que obedeça ao esquema definido na documentação do perfetto.
- [6.1/T-0-4] É OBRIGATÓRIO fornecer, pelo binário do perfetto, pelo menos as origens de dados descritas na documentação do perfetto.
- [6.1/T-0-5] O daemon do perfetto precisa ser ativado por padrão (propriedade do sistema persist.traced.enable).

Fim dos novos requisitos

2.4. Requisitos do relógio

Um dispositivo Android Watch se refere a uma implementação de dispositivo Android destinada a ser usada no corpo, talvez no pulso.

As implementações de dispositivos Android são classificadas como um relógio se atenderem a todos os seguintes critérios:

Ter uma tela com o comprimento físico da diagonal na faixa de 1,1 a 2,5 polegadas.
Ter um mecanismo para ser usado no corpo.

Os requisitos adicionais no restante desta seção são específicos para implementações de dispositivos Android Watch.

2.4.1. Hardware

Implementações de dispositivos de relógio:

[7.1.1.1/W-0-1] PRECISA ter uma tela com o tamanho físico da diagonal no intervalo de 1,1 a 2,5 polegadas.
[7.2.3/W-0-1] A função "Início" e a função "Voltar" precisam estar disponíveis para o usuário, exceto quando estiverem em UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] É PRECISO oferecer suporte à entrada por touchscreen.
[7.3.1/W-SR-1] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

Se as implementações de dispositivos de relógio incluírem um receptor de GPS/GNSS e informarem o recurso para os aplicativos usando a flag de recurso android.hardware.location.gps, elas:

[7.3.3/W-1-1] É OBRIGATÓRIO informar as medições do GNSS assim que elas forem encontradas, mesmo que um local calculado pelo GPS/GNSS ainda não tenha sido informado.
[7.3.3/W-1-2] É OBRIGATÓRIO informar pseudorrages e taxas de pseudorragem do GNSS que, em condições de céu aberto após a determinação do local, enquanto estão parados ou se movem com menos de 0, 2 metro por segundo ao quadrado de aceleração, são suficientes para calcular a posição em até 20 metros e a velocidade em até 0, 2 metro por segundo, pelo menos 95% do tempo.

Se as implementações do dispositivo de relógio incluírem um giroscópio de três eixos, elas:

[7.3.4/W-2-1] É PRECISO medir mudanças de orientação de até 1.000 graus por segundo.

Implementações de dispositivos de relógio:

[7.4.3/W-0-1] É PRECISO ter suporte a Bluetooth.
[7.6.1/W-0-1] É PRECISO ter pelo menos 1 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecidos como partição "/data").
[7.6.1/W-0-2] É PRECISO ter pelo menos 416 MB de memória disponível para o kernel e o espaço do usuário.
[7.8.1/W-0-1] É OBRIGATÓRIO incluir um microfone.
[7.8.2/W] PODE ter saída de áudio.

2.4.2. Multimídia

Nenhum requisito extra.

2.4.3. Software

Implementações de dispositivos de relógio:

[3/W-0-1] É OBRIGATÓRIO declarar o recurso android.hardware.type.watch.
[3/W-0-2] É NECESSÁRIO oferecer suporte a uiMode = UI_MODE_TYPE_WATCH.
[3.2.3.1/W-0-1] É OBRIGATÓRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intent para todos os padrões de filtro de intent públicos definidos pelas seguintes intents do aplicativo listadas aqui.

Implementações de dispositivos de relógio:

[3.8.4/W-SR-1] É ALTAMENTE RECOMENDADO implementar um assistente no dispositivo para processar a ação de assistência.

Observe as implementações de dispositivos que declaram a flag de recurso android.hardware.audio.output:

[3.10/W-1-1] É PRECISO oferecer suporte a serviços de acessibilidade de terceiros.
[3.10/W-SR-1] É ALTAMENTE RECOMENDADO pré-carregar serviços de acessibilidade no dispositivo que sejam comparáveis ou superiores à funcionalidade do acesso com interruptor e do TalkBack (para idiomas com suporte ao mecanismo de conversão de texto em voz pré-instalado), conforme fornecido no projeto de código aberto do Talkback.

Se as implementações do dispositivo de relógio informarem o recurso android.hardware.audio.output, elas:

[3.11/W-SR-1] É ALTAMENTE RECOMENDADO incluir um motor de TTS que ofereça suporte aos idiomas disponíveis no dispositivo.
[3.11/W-0-1] É PRECISO oferecer suporte à instalação de motores de TTS de terceiros.

2.4.4. Desempenho e bateria

Se as implementações de dispositivos Watch incluírem recursos para melhorar o gerenciamento de energia do dispositivo que estão incluídos no AOSP ou estenderem os recursos incluídos no AOSP, elas:

[8.3/W-SR-1] É ALTAMENTE RECOMENDADO fornecer aos usuários a capacidade de exibir todos os apps que estão isentos dos modos de suspensão e economia de bateria do app.
[8.3/W-SR-2] É ALTAMENTE RECOMENDADO fornecer aos usuários a capacidade de ativar e desativar o recurso de economia de bateria.

Implementações de dispositivos de relógio:

[8.4/W-0-1] É obrigatório fornecer um perfil de energia por componente que defina o valor de consumo atual para cada componente de hardware e o consumo de bateria aproximado causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.
[8.4/W-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliamperes-hora (mAh).
[8.4/W-0-3] É OBRIGATÓRIO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito pela implementação do módulo do kernel uid_cputime.
[8.4/W-0-4] É OBRIGATÓRIO disponibilizar esse uso de energia ao desenvolvedor do app pelo comando de shell adb shell dumpsys batterystats.
[8.4/W] DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente a um aplicativo.

2.4.5. Modelo de segurança

Implementações de dispositivos de relógio:

[9/W-0-1] É PRECISO declarar o recurso android.hardware.security.model.compatible.

Se as implementações do dispositivo do relógio incluírem vários usuários e não declararem a flag de recurso android.hardware.telephony, elas:

[9.5/W-1-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite aos proprietários de dispositivos gerenciar outros usuários e os respectivos recursos no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.

Se as implementações de dispositivos de relógio incluírem vários usuários e declararem a flag de recurso android.hardware.telephony, elas:

[9.5/W-2-1] NÃO é necessário oferecer suporte a perfis restritos, mas é necessário se alinhar à implementação de controles do AOSP para permitir /desabilitar o acesso de outros usuários às chamadas de voz e SMS.

Se as implementações de dispositivo tiverem uma tela de bloqueio segura e incluirem um ou mais agentes de confiança, que implementam a API do sistema TrustAgentService, elas:

[9.11.1/W-1-1] É OBRIGATÓRIO solicitar ao usuário um dos métodos de autenticação primária recomendados (por exemplo, PIN, padrão, senha) com mais frequência do que uma vez a cada 72 horas.

2.5. Requisitos automotivos

A implementação do Android Automotive se refere a uma unidade principal de veículo que executa o Android como um sistema operacional para parte ou todo o sistema e/ou a funcionalidade de infoentretenimento.

As implementações de dispositivos Android são classificadas como Automotive se declararem o recurso android.hardware.type.automotive ou atenderem a todos os seguintes critérios.

São incorporados ou podem ser conectados a um veículo automotivo.
Estão usando uma tela na fileira do banco do motorista como tela principal.

Os requisitos adicionais no restante desta seção são específicos para implementações de dispositivos Android Automotive.

2.5.1. Hardware

Implementações de dispositivos automotivos:

[7.1.1.1/A-0-1] É PRECISO ter uma tela com pelo menos 6 polegadas de tamanho físico na diagonal.
[7.1.1.1/A-0-2] É PRECISO ter um layout de tamanho de tela de pelo menos 750 dp x 480 dp.

Início dos novos requisitos para o Android 15

Se as implementações de dispositivos automotivos oferecerem suporte a vários usuários simultâneos (em que vários usuários do Android podem interagir com o dispositivo ao mesmo tempo, cada um usando a própria tela quando config_multiuserVisibleBackgroundUsers está ativado), eles:

[7.1.1.1/A-1-1] É PRECISO ter uma tela separada de pelo menos 15 cm de tamanho físico diagonal para cada zona de ocupante para a tela principal. Ele precisa ser marcado como CarOccupantZoneManager.DISPLAY_TYPE_MAIN para cada zona de ocupante.
[7.1.1.1/A-1-2] É PRECISO ter um layout de tamanho de tela de pelo menos 750 dp x 480 dp para cada tela principal.

Fim dos novos requisitos

Se as implementações de dispositivos automotivos forem compatíveis com o OpenGL ES 3.1, elas:

[7.1.4.1/A-0-1] É PRECISO declarar OpenGL ES 3.1 ou mais recente.
[7.1.4.1/A-0-2] É PRECISO ter suporte a Vulkan 1.1.
[7.1.4.1/A-0-3] É PRECISO incluir o carregador do Vulkan e exportar todos os símbolos.

Implementações de dispositivos automotivos:

Início dos novos requisitos para o Android 15

[7.1.7/A-0-1] É OBRIGATÓRIO configurar telas secundárias na linha de visão do motorista como FLAG_PRIVATE.

Fim dos novos requisitos

[7.2.3/A-0-1] É OBRIGATÓRIO fornecer a função "Início" e OPCIONALMENTE as funções "Voltar" e "Recentes".
[7.2.3/A-0-2] É PRECISO enviar o evento de pressionamento normal e longo da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano.
[7.3/A-0-1] É OBRIGATÓRIO implementar e informar GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.
[7.3/A-0-2] O valor da flag NIGHT_MODE PRECISA ser consistente com o modo dia/noite do painel e DEVE ser baseado na entrada do sensor de luz ambiente. O sensor de luz ambiente pode ser o mesmo que o fotômetro.
[7.3/A-0-3] É OBRIGATÓRIO fornecer o campo de informações adicionais do sensor TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor fornecido.
[7.3/A-SR1] PODE estimar a localização combinando o GPS/GNSS com outros sensores. Se o local for calculado, é ALTAMENTE RECOMENDADO implementar e informar os tipos de sensor correspondentes e/ou os IDs de propriedade do veículo usados.
[7.3/A-0-4] O local solicitado por LocationManager#requestLocationUpdates() NÃO PODE ser associado ao mapa.
[7.3.1/A-0-4] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor do carro do Android.
[7.3/A-SR-1] É _RECOMENDADO_INCLUSIVO incluir um acelerômetro de três eixos e um giroscópio de três eixos.
[7.3/A-SR-2] É STRONGLY_RECOMMENDED implementar e informar o sensor TYPE_HEADING.

Início dos novos requisitos para o Android 15

[7.3/A-1-1] É OBRIGATÓRIO definir o valor da flag NIGHT_MODE de forma consistente com o modo dia/noite do painel em todas as telas, incluindo as telas do banco traseiro.

Fim dos novos requisitos

Se as implementações de dispositivos automotivos incluírem um acelerômetro, elas:

[7.3.1/A-1-1] PRECISA ser capaz de informar eventos com frequência de pelo menos 100 Hz.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos, elas:

[7.3.1/A-SR-1] É ALTAMENTE RECOMENDADO implementar o sensor composto para acelerômetro de eixos limitados.

Se as implementações de dispositivos automotivos incluírem um acelerômetro com menos de três eixos, elas:

[7.3.1/A-1-3] É OBRIGATÓRIO implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
[7.3.1/A-1-4] É OBRIGATÓRIO implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Se as implementações de dispositivos automotivos incluírem um giroscópio, elas:

[7.3.4/A-2-1] É PRECISO que o dispositivo consiga informar eventos com frequência de pelo menos 100 Hz.
[7.3.4/A-2-3] PRECISA ser capaz de medir mudanças de orientação de até 250 graus por segundo.
[7.3.4/A-SR-1] É ALTAMENTE RECOMENDADO configurar o intervalo de medição do giroscópio para +/-250dps para maximizar a resolução possível.

Se as implementações de dispositivos automotivos incluírem um giroscópio de três eixos, elas:

[7.3.4/A-SR-2] É ALTAMENTE RECOMENDADO implementar o sensor composto para giroscópio de eixos limitados.

Se as implementações de dispositivos automotivos incluírem um giroscópio com menos de três eixos, elas:

[7.3.4/A-4-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES.
[7.3.4/A-4-2] É OBRIGATÓRIO implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Se as implementações de dispositivos automotivos incluírem um receptor de GPS/GNSS, mas não incluírem conectividade de dados baseada na rede celular, elas:

[7.3.3/A-3-1] É PRECISO determinar a localização na primeira vez em que o receptor de GPS/GNSS é ativado ou após 4 dias ou mais em até 60 segundos.
[7.3.3/A-3-2] É PRECISO atender aos critérios de tempo até a primeira correção, conforme descrito em 7.3.3/C-1-2 e 7.3.3/C-1-6 para todas as outras solicitações de localização (ou seja, solicitações que não são a primeira vez ou após mais de 4 dias). O requisito 7.3.3/C-1-2 geralmente é atendido em veículos sem conectividade de dados baseada em rede celular, usando previsões de órbita GNSS calculadas no receptor ou usando a última localização conhecida do veículo com a capacidade de estimativa de posição por pelo menos 60 segundos com uma precisão de posição que atenda a 7.3.3/C-1-3 ou uma combinação de ambos.

Se as implementações de dispositivos automotivos incluírem um sensor TYPE_HEADING, elas:

[7.3.4/A-4-3] É PRECISO que o dispositivo consiga informar eventos com uma frequência de pelo menos 1 Hz.
[7.3.4/A-SR-3] É FORTEMENTE_RECOMENDADO informar eventos com frequência de pelo menos 10 Hz.
DEVE estar em referência ao norte verdadeiro.
DEVE estar disponível mesmo quando o veículo estiver parado.
DEVE ter uma resolução de pelo menos 1 grau.

Implementações de dispositivos automotivos:

[7.4.3/A-0-1] É PRECISO oferecer suporte a Bluetooth e É RECOMENDÁVEL oferecer suporte a Bluetooth LE.
[7.4.3/A-0-2] As implementações do Android Automotive PRECISAM oferecer suporte aos seguintes perfis Bluetooth:
- Chamadas telefônicas pelo perfil viva-voz (HFP).
- Reprodução de mídia pelo perfil de distribuição de áudio (A2DP).
- Controle de reprodução de mídia pelo perfil de controle remoto (AVRCP).
- Compartilhamento de contatos usando o perfil de acesso à agenda telefônica (PBAP).

Início dos novos requisitos para o Android 15

[7.4.3/A-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao perfil de acesso a mensagens (MAP, na sigla em inglês) se o dispositivo tiver a zona do ocupante do motorista.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

[7.4.3/A-1-1] PRECISA ser independente e NÃO interferir na experiência de outros usuários com o BT.

Fim dos novos requisitos

Implementações de dispositivos automotivos:

[7.4.5/A] DEVE incluir suporte para conectividade de dados celular baseada em rede.
[7.4.5/A] PODE usar a constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID da API do sistema para redes que precisam estar disponíveis para apps do sistema.

Se as implementações do dispositivo incluírem suporte a rádio AM/FM e exporem a funcionalidade a qualquer aplicativo, elas:

[7.4/A-1-1] É PRECISO declarar suporte para FEATURE_BROADCAST_RADIO.

Uma câmera traseira é uma câmera que pode ser localizada em qualquer lugar do veículo e está voltada para fora da cabine. Ou seja, ela mostra cenas no lado externo da carroceria do veículo, como a câmera de ré.

Uma câmera frontal é uma câmera voltada para o usuário que pode ser localizada em qualquer local do veículo e voltada para dentro da cabine, ou seja, ela captura imagens do usuário, como em videoconferências e aplicativos semelhantes.

Implementações de dispositivos automotivos:

[7.5/A-SR-1] É ALTAMENTE RECOMENDADO incluir uma ou mais câmeras frontais.
PODE incluir uma ou mais câmeras voltadas ao usuário.
[7.5/A-SR-2] É ALTAMENTE RECOMENDADO oferecer suporte ao streaming simultâneo de várias câmeras.

Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera frontal, para essa câmera, elas:

[7.5/A-1-1] PRECISA estar orientado de forma que a dimensão longa da câmera se alinhe com o plano XY dos eixos do sensor automotivo do Android.
[7.5/A-SR-3] É ALTAMENTE RECOMENDADO ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
[7.5/A-1-2] A câmera principal precisa ser a câmera voltada para o ambiente com o ID mais baixo.

Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera voltada para o usuário, para essa câmera:

[7.5/A-2-1] A câmera principal do usuário PRECISA ser a câmera do usuário com o ID mais baixo.
PODE ser orientado de forma que a dimensão longa da câmera se alinhe ao plano XY dos eixos do sensor automotivo do Android.

Se as implementações de dispositivos automotivos incluírem uma câmera acessível pela API android.hardware.Camera ou android.hardware.camera2, elas:

[7.5/A-3-1] É OBRIGATÓRIO obedecer aos requisitos básicos da câmera na seção 7.5.

Se as implementações de dispositivos automotivos incluírem uma câmera que não pode ser acessada pela API android.hardware.Camera ou android.hardware.camera2, elas:

[7.5/A-4-1] PRECISA ser acessível pelo serviço do sistema de visualização estendida.

Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras acessíveis pelo serviço do sistema de visualização estendida, elas:

[7.5/A-5-1] A visualização da câmera NÃO pode ser girada nem espelhada horizontalmente.
[7.5/A-SR-4] É ALTAMENTE RECOMENDADO ter uma resolução de pelo menos 1,3 megapixel.

Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras que podem ser acessadas pelo serviço do sistema de visualização estendida e pela API android.hardware.Camera ou android.hardware.Camera2, para essa câmera, elas:

[7.5/A-6-1] É OBRIGATÓRIO informar o mesmo ID da câmera.

Se as implementações de dispositivos automotivos fornecerem uma API de câmera reservada, elas:

[7.5/A-7-1] É OBRIGATÓRIO implementar essa API da câmera usando a API android.hardware.camera2 ou a API Extended View System.

Implementações de dispositivos automotivos:

[7.6.1/A-0-1] É PRECISO ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do aplicativo (partição /data).
[7.6.1/A] DEVE formatar a partição de dados para oferecer melhor desempenho e longevidade no armazenamento em flash (por exemplo, usando o sistema de arquivos f2fs).

Se as implementações de dispositivos automotivos oferecerem armazenamento externo compartilhado por meio de uma parte do armazenamento interno não removível, elas:

[7.6.1/A-SR-1] É ALTAMENTE RECOMENDADO reduzir a sobrecarga de E/S em operações realizadas no armazenamento externo, por exemplo, usando SDCardFS.

Início dos novos requisitos para o Android 15

[7.6.1/A-1-1] É PRECISO ter, em uma única instância do AAOS, pelo menos 4 GB para cada usuário do Android simultâneo de armazenamento não volátil disponível para dados privados do aplicativo (partição /data).

Fim dos novos requisitos

Se as implementações de dispositivos automotivos forem de 64 bits:

Início dos novos requisitos para o Android 15

[7.6.1/A-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 816 MB por tela principal se qualquer uma das densidades a seguir for usada:
- 280 dpi ou menos em telas pequenas/normais
- ldpi ou menor em telas extragrandes
- mdpi ou menor em telas grandes
[7.6.1/A-2-2] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 944 MB por tela principal se qualquer uma das densidades a seguir for usada:
- xhdpi ou superior em telas pequenas/normais
- hdpi ou superior em telas grandes
- mdpi ou superior em telas extragrandes
[7.6.1/A-2-3] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1280 MB por tela principal se alguma das densidades a seguir for usada:
- 400 dpi ou mais em telas pequenas/normais
- xhdpi ou superior em telas grandes
- tvdpi ou superior em telas extragrandes
[7.6.1/A-2-4] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1824 MB por tela principal se qualquer uma das densidades a seguir for usada:
- 560 dpi ou mais em telas pequenas/normais
- 400 dpi ou mais em telas grandes
- xhdpi ou superior em telas extragrandes

Fim dos novos requisitos

Implementações de dispositivos automotivos:

[7.7.1/A] DEVE incluir uma porta USB com suporte ao modo periférico.

Implementações de dispositivos automotivos:

[7.8.1/A-0-1] É OBRIGATÓRIO incluir um microfone.

Implementações de dispositivos automotivos:

[7.8.2/A-0-1] É PRECISO ter uma saída de áudio e declarar android.hardware.audio.output.

Início dos novos requisitos para o Android 15

[7.8.2/A-1-1] É OBRIGATÓRIO ter um dispositivo de saída de áudio para cada tela principal para sistemas de vários usuários simultâneos.
[7.8.2/A-1-2] É OBRIGATÓRIO ter uma zona de áudio do motorista que cubra o alto-falante global da cabine. A zona do passageiro da frente pode compartilhar a zona de áudio do motorista ou ter a própria saída de áudio.

Fim dos novos requisitos

2.5.2. Multimídia

As implementações de dispositivos automotivos precisam oferecer suporte aos seguintes formatos de codificação e decodificação de áudio e disponibilizá-los para aplicativos de terceiros:

[5.1/A-0-1] Perfil MPEG-4 AAC (AAC LC)
[5.1/A-0-2] Perfil MPEG-4 HE AAC (AAC+).
[5.1/A-0-3] AAC ELD (AAC aprimorado com atraso baixo)

As implementações de dispositivos automotivos precisam oferecer suporte aos seguintes formatos de codificação de vídeo e disponibilizá-los para aplicativos de terceiros:

[5.2/A-0-1] H.264 AVC
[5.2/A-0-2] VP8

As implementações de dispositivos automotivos precisam oferecer suporte aos seguintes formatos de decodificação de vídeo e disponibilizá-los para aplicativos de terceiros:

[5.3/A-0-1] H.264 AVC
[5.3/A-0-2] MPEG-4 SP
[5.3/A-0-3] VP8
[5.3/A-0-4] VP9

É ALTAMENTE RECOMENDÁVEL que as implementações de dispositivos automotivos ofereçam suporte à decodificação de vídeo a seguir:

[5.3/A-SR-1] H.265 HEVC

Início dos novos requisitos para o Android 15

[5.5.3/A-1-1] É OBRIGATÓRIO definir curvas de volume idênticas para todos os fluxos de saída de áudio que mapeiam para o mesmo grupo de volume definido no arquivo de configuração de áudio do carro.

Fim dos novos requisitos

2.5.3. Software

Implementações de dispositivos automotivos:

[3/A-0-1] É OBRIGATÓRIO declarar o recurso android.hardware.type.automotive.
[3/A-0-2] É necessário oferecer suporte a uiMode = UI_MODE_TYPE_CAR.
[3/A-0-3] É PRECISO oferecer suporte a todas as APIs públicas no namespace android.car.*.

Se as implementações de dispositivos automotivos fornecerem uma API reservada usando android.car.CarPropertyManager com android.car.VehiclePropertyIds, elas:

[3/A-1-1] NÃO É PERMITIDO anexar privilégios especiais ao uso de propriedades do aplicativo do sistema ou impedir que aplicativos de terceiros usem essas propriedades.
[3/A-1-2] NÃO REPRODUZA uma propriedade de veículo que já exista no SDK.

Implementações de dispositivos automotivos:

[3.2.1/A-0-1] É PRECISO oferecer suporte e aplicar todas as constantes de permissão, conforme documentado na página de referência de permissões automotivas.
[3.2.3.1/A-0-1] É OBRIGATÓRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intent pública definidos pelas seguintes intents do app listadas aqui.
[3.4.1/A-0-1] É PRECISO fornecer uma implementação completa da API android.webkit.Webview.

Início dos novos requisitos para o Android 15

~~[3.8/A-0-1] NÃO é permitido que usuários secundários completos que não sejam o usuário em primeiro plano atual iniciem atividades e tenham acesso à interface em nenhuma tela.~~

[3.8/A-1-1] É PRECISO implementar a lista predefinida de UserRestrictions a seguir para usuários secundários completos que não são o usuário atual em primeiro plano, mas têm acesso à interface da tela atribuída a eles. A lista de UserRestrictions é DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE e DISALLOW_MICROPHONE_TOGGLE.
[3.8/A-1-2] NÃO É PERMITIDO que usuários secundários completos que não sejam o usuário atual em primeiro plano, mas tenham acesso à IU da tela atribuída a eles, mudem o modo dia/noite, a localidade, a data, a hora, o fuso horário ou os recursos de cor da tela (incluindo brilho, luz noturna, bem-estar digital em tons de cinza e redução de cores brilhantes) para qualquer outro usuário nas Configurações ou em uma API.

Fim dos novos requisitos

Implementações de dispositivos automotivos:

[3.8.3/A-0-1] É PRECISO mostrar notificações que usam a API Notification.CarExtender quando solicitadas por aplicativos de terceiros.
[3.8.4/A-SR-1] É altamente recomendável implementar um assistente no dispositivo para processar a ação de assistência.

Se as implementações de dispositivos automotivos incluem um botão de push-to-talk, elas:

[3.8.4/A-1-1] É OBRIGATÓRIO usar um toque curto do botão de push-to-talk como a interação designada para iniciar o app de assistência selecionado pelo usuário, ou seja, o app que implementa VoiceInteractionService.

Implementações de dispositivos automotivos:

[3.8.3.1/A-0-1] É NECESSÁRIO renderizar corretamente os recursos conforme descrito na documentação do SDK Notifications on Automotive OS.
[3.8.3.1/A-0-2] É PRECISO mostrar PLAY e MUTE para ações de notificação no lugar daquelas fornecidas por Notification.Builder.addAction().
[3.8.3.1/A] DEVE restringir o uso de tarefas de gerenciamento avançadas, como controles por canal de notificação. PODE usar a affordance da interface por aplicativo para reduzir os controles.

Se as implementações de dispositivos automotivos oferecerem suporte às propriedades HAL do usuário, elas:

[3.9.3/A-1-1] É PRECISO implementar todas as propriedades do ciclo de vida do usuário
- INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

Implementações de dispositivos automotivos:

[3.14/A-0-1] É OBRIGATÓRIO incluir uma estrutura de interface para oferecer suporte a apps de terceiros que usam as APIs de mídia, conforme descrito na seção 3.14.
[3.14/A-0-2] É OBRIGATÓRIO permitir que o usuário interaja com segurança com aplicativos de mídia enquanto dirige.
[3.14/A-0-3] É PRECISO oferecer suporte à ação de intent implícita CAR_INTENT_ACTION_MEDIA_TEMPLATE com o extra CAR_EXTRA_MEDIA_PACKAGE.
[3.14/A-0-4] É necessário fornecer uma capacidade para navegar até a atividade de preferência de um aplicativo de mídia, mas só é necessário ativá-la quando as restrições de UX para carros não estiverem em vigor.
[3.14/A-0-5] É PRECISO mostrar mensagens de erro definidas por aplicativos de mídia e oferecer suporte aos extras opcionais ERROR_RESOLUTION_ACTION_LABEL e ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] É PRECISO oferecer suporte a uma ação de pesquisa no app para apps que oferecem suporte à pesquisa.
[3.14/A-0-7] É PRECISO respeitar as definições de CONTENT_STYLE_BROWSABLE_HINT e CONTENT_STYLE_PLAYABLE_HINT ao exibir a hierarquia do MediaBrowser.

Se as implementações de dispositivos automotivos incluírem um app de tela de início padrão, elas:

[3.14/A-1-1] É PRECISO incluir serviços de mídia e abri-los com a intent CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implementações de dispositivos automotivos:

[3.8/A] PODE restringir as solicitações do aplicativo para entrar em um modo de tela cheia, conforme descrito em immersive documentation.
[3.8/A] PODE manter a barra de status e a barra de navegação visíveis o tempo todo.
[3.8/A] PODE restringir as solicitações do aplicativo para mudar as cores por trás dos elementos da interface do sistema, para garantir que esses elementos fiquem claramente visíveis o tempo todo.

2.5.4. Desempenho e bateria

Implementações de dispositivos automotivos:

[8.2/A-0-1] É OBRIGATÓRIO informar o número de bytes lidos e gravados no armazenamento não volátil por UID de cada processo para que as estatísticas fiquem disponíveis para os desenvolvedores pela API System android.car.storagemonitoring.CarStorageMonitoringManager. O Android Open Source Project atende ao requisito pelo módulo do kernel uid_sys_stats.
[8.3/A-1-3] É PRECISO ter suporte ao Modo garagem.
[8.3/A] DEVE estar no modo Garage por pelo menos 15 minutos após cada percurso, a menos que:
- A bateria está descarregada.
- Nenhum job ocioso é programado.
- O motorista sai do modo Garagem.
[8.4/A-0-1] É OBRIGATÓRIO fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo de bateria aproximado causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.
[8.4/A-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliamperes-hora (mAh).
[8.4/A-0-3] É OBRIGATÓRIO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito pela implementação do módulo do kernel uid_cputime.
[8.4/A] DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
[8.4/A-0-4] É OBRIGATÓRIO disponibilizar esse uso de energia ao desenvolvedor do app pelo comando de shell adb shell dumpsys batterystats.

2.5.5. Modelo de segurança

Se as implementações de dispositivos automotivos oferecerem suporte a vários usuários, elas:

[9.5/A-1-1] NÃO É PERMITIDO que os usuários interajam com ou mudem para o usuário do sistema sem cabeça, exceto para provisionamento de dispositivo.
[9.5/A-1-2] É PRECISO mudar para um usuário secundário antes de BOOT_COMPLETED.
[9.5/A-1-3] É PRECISO oferecer suporte à capacidade de criar um usuário convidado, mesmo quando o número máximo de usuários em um dispositivo for atingido.

Se as implementações de dispositivos automotivos declararem android.hardware.microphone, elas:

[9.8.2/A-1-1] É OBRIGATÓRIO mostrar o indicador do microfone quando um app estiver acessando dados de áudio do microfone, mas não quando o microfone for acessado apenas por HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou apps que tenham as funções mencionadas na seção 9.1 com o identificador CDD [C-4-X].
[9.8.2/A-1-2] O indicador do microfone NÃO PODE ser ocultado para apps do sistema que têm interfaces do usuário visíveis ou interação direta do usuário.
[9.8.2/A-1-3] É OBRIGATÓRIO fornecer uma capacidade de uso do usuário para alternar o microfone no app Configurações.

Se as implementações de dispositivos automotivos declararem android.hardware.camera.any, elas:

[9.8.2/A-2-1] É OBRIGATÓRIO mostrar o indicador da câmera quando um app estiver acessando dados da câmera ao vivo, mas não quando a câmera estiver sendo acessada apenas por apps que têm as funções conforme definido na seção 9.1 Permissões com identificador CDD [C-4-X].
[9.8.2/A-2-2] Não é permitido ocultar o indicador da câmera para apps do sistema que têm interfaces do usuário visíveis ou interação direta do usuário.
[9.8.2/A-2-3] É OBRIGATÓRIO fornecer uma característica para o usuário ativar a câmera no app Configurações.
[9.8.2/A-2-4] É PRECISO mostrar os apps recentes e ativos usando a câmera conforme retornado de PermissionManager.getIndicatorAppOpUsageData(), junto com as mensagens de atribuição associadas a eles.

Implementações de dispositivos automotivos:

[9/A-0-1] É PRECISO declarar o recurso android.hardware.security.model.compatible.
[9.11/A-0-1] É PRECISO fazer backup da implementação do keystore com um ambiente de execução isolado.
[9.11/A-0-2] É OBRIGATÓRIO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash da família MD5, SHA-1 e SHA-2 para oferecer suporte adequado aos algoritmos aceitos pelo sistema do Keystore do Android em uma área isolada com segurança do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais em que o kernel ou o código do espaço do usuário pode acessar o estado interno do ambiente isolado, incluindo o DMA. O upstream do Android Open Source Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
[9.11/A-0-3] É PRECISO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e, somente quando bem-sucedida, permitir que as chaves vinculadas à autenticação sejam usadas. As credenciais da tela de bloqueio precisam ser armazenadas de uma maneira que permita que apenas o ambiente de execução isolado realize a autenticação da tela de bloqueio. O upstream do Android Open Source Project fornece a camada de abstração de hardware (HAL, na sigla em inglês) do gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.

Início dos novos requisitos para o Android 15

[9.11/A-0-4] É PRECISO oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser ~~compartilhadas em um número suficiente de dispositivos para impedir que as chaves~~ sejam impedidas de serem usadas como identificadores de dispositivo permanentes. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de uma SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

Observação: para atender a esse requisito, você precisa compartilhar a mesma chave de atestado para um determinado SKU,a menos que pelo menos 100.000 unidades desse SKU sejam produzidas. Se mais de 100.000 unidades desse SKU forem produzidas, uma chave diferente poderá ser usada para cada grupo de 100.000 unidades depois disso. Como alternativa, a solução de provisionamento de chave remota pode ser usada para provisionar chaves de atestado de curta duração no dispositivo.

Fim dos novos requisitos

Implementações de dispositivos automotivos:

[9.14/A-0-1] É NECESSÁRIO controlar as mensagens de subsistemas de veículos do framework do Android, por exemplo, permitir a inclusão de tipos e origens de mensagens.
[9.14/A-0-2] É PRECISO monitorar ataques de negação de serviço do framework do Android ou de apps de terceiros. Isso protege contra softwares maliciosos que inundam a rede do veículo com tráfego, o que pode levar a falhas nos subsistemas do veículo.

2.5.6. Compatibilidade de ferramentas e opções para desenvolvedores

Início dos novos requisitos para o Android 15

Implementações de dispositivos automotivos:

Perfetto
- [6.1/A-0-1] É PRECISO expor um binário /system/bin/perfetto ao usuário do shell que o cmdline obedece à documentação do perfetto.
- [6.1/A-0-2] O binário do perfetto PRECISA aceitar como entrada uma configuração protobuf que obedeça ao esquema definido na documentação do perfetto.
- [6.1/A-0-3] O binário do perfetto PRECISA gravar como saída um trace de protobuf que obedeça ao esquema definido na documentação do perfetto.
- [6.1/A-0-4] É PRECISO fornecer, pelo binário do perfetto, pelo menos as origens de dados descritas na documentação do perfetto.
- [6.1/A-0-5] O daemon de rastreamento do perfetto PRECISA ser ativado por padrão (propriedade do sistema persist.traced.enable).

Fim dos novos requisitos

2.6. Requisitos para tablets

Um dispositivo tablet Android se refere a uma implementação de dispositivo Android que normalmente atende a todos os seguintes critérios:

É usado segurando com as duas mãos.
Não tem uma configuração de concha ou conversível.
Implementações de teclado físico usadas com a conexão do dispositivo por meio de uma conexão padrão (por exemplo, USB, Bluetooth).
Tem uma fonte de energia que oferece mobilidade, como uma bateria.
Tem uma tela de exibição maior que 7" e menor que 18", medida na diagonal.

As implementações de dispositivos tablet têm requisitos semelhantes às implementações de dispositivos portáteis. As exceções são indicadas por um * nessa seção e mencionadas para referência nesta seção.

2.6.1. Hardware

Giroscópio

Se as implementações de dispositivos tablet incluírem um giroscópio de três eixos, elas:

[7.3.4/Tab-1-1] É PRECISO medir as mudanças de orientação de até 1.000 graus por segundo.

Memória e armazenamento mínimos (seção 7.6.1)

As densidades de tela listadas para telas pequenas/normais nos requisitos de dispositivos portáteis não são aplicáveis a tablets.

Início dos novos requisitos para o Android 15

Modo de periférico USB (seção 7.7.1)

Se as implementações de dispositivos de tablet incluírem uma porta USB com suporte ao modo periférico, elas:

[7.7.1/Tab] PODE implementar a API Android Open Accessory (AOA).

Fim dos novos requisitos

Modo de realidade virtual (seção 7.9.1)

Realidade virtual de alto desempenho (seção 7.9.2)

Os requisitos de realidade virtual não se aplicam a tablets.

2.6.2. Modelo de segurança

Chaves e credenciais (seção 9.11)

Consulte a seção [9.11].

Se as implementações de dispositivos de tablet incluírem vários usuários e não declararem a flag de recurso android.hardware.telephony, elas:

[9.5/T-1-1] É PRECISO oferecer suporte a perfis restritos, um recurso que permite aos proprietários de dispositivos gerenciar outros usuários e os recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.

Se as implementações de dispositivos Tablet incluírem vários usuários e declararem a flag de recurso android.hardware.telephony, elas:

[9.5/T-2-1] NÃO é necessário oferecer suporte a perfis restritos, mas é necessário se alinhar à implementação de controles do AOSP para permitir /desabilitar o acesso de outros usuários às chamadas de voz e SMS.

2.6.2. Software

[3.2.3.1/Tab-0-1] É PRECISO carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intent pública definidos pelas seguintes intents do app listadas aqui.

3. Software

3.1. Compatibilidade com a API gerenciada

O ambiente de execução de bytecode Dalvik gerenciado é o veículo principal para aplicativos Android. A interface de programação do aplicativo (API) do Android é o conjunto de interfaces da plataforma Android exposto a aplicativos executados no ambiente de execução gerenciado.

Implementações de dispositivos:

[C-0-1] É necessário fornecer implementações completas, incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo SDK do Android ou qualquer API decorada com o marcador "@SystemApi" no código-fonte do Android upstream.
[C-0-2] É PRECISO oferecer suporte/preservar todas as classes, métodos e elementos associados marcados pela anotação TestApi (@TestApi).
[C-0-3] NÃO PODE omitir APIs gerenciadas, alterar interfaces ou assinaturas de API, desviar do comportamento documentado ou incluir no-ops, exceto quando especificamente permitido por esta definição de compatibilidade.
[C-0-4] AS APIs ainda precisam estar presentes e se comportar de maneira razoável, mesmo quando alguns recursos de hardware para os quais o Android inclui APIs são omitidos. Consulte a seção 7 para ver os requisitos específicos deste cenário.
[C-0-5] NÃO É PERMITIDO que apps de terceiros usem interfaces que não sejam do SDK, que são definidas como métodos e campos nos pacotes de linguagem Java que estão no caminho de classe de inicialização no AOSP e que não fazem parte do SDK público. Isso inclui APIs decoradas com a anotação @hide, mas não com uma @SystemAPI, conforme descrito nos documentos do SDK e nos membros de classe privados e de pacote-privado.
[C-0-6] É OBRIGATÓRIO enviar todas as interfaces não SDK nas mesmas listas restritas, conforme fornecido pelas flags provisórias e de negação na pasta prebuilts/runtime/appcompat/hiddenapi-flags.csv do branch de nível de API apropriado no AOSP.
[C-0-7] É PRECISO oferecer suporte ao mecanismo de atualização dinâmica de configuração assinada para remover interfaces que não sejam do SDK de uma lista restrita incorporando a configuração assinada em qualquer APK, usando as chaves públicas presentes no AOSP.

No entanto, eles:
- PODE, se uma API oculta estiver ausente ou implementada de maneira diferente na implementação do dispositivo, mover a API oculta para a lista de bloqueio ou omiti-la de todas as listas restritas.
- PODE, se uma API oculta ainda não existir no AOSP, adicionar a API oculta a qualquer uma das listas restritas.

Início dos novos requisitos para o Android 15

[C-0-8] NÃO é possível instalar aplicativos com destino a um nível de API menor que 23 24.

Fim dos novos requisitos

3.1.1. Extensões Android

O Android oferece suporte à extensão da plataforma de API gerenciada de um nível de API específico atualizando a versão da extensão para esse nível. A API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) retorna a versão de extensão do apiLevel fornecido, se houver extensões para esse nível de API.

Implementações de dispositivos Android:

[C-0-1] É OBRIGATÓRIO pré-carregar a implementação do AOSP da biblioteca compartilhada ExtShared e dos serviços ExtServices com versões maiores ou iguais às versões mínimas permitidas para cada nível de API. Por exemplo, implementações de dispositivos do Android 7.0 com o nível 24 da API precisam incluir pelo menos a versão 1.
[C-0-2] SOMENTE deve retornar o número da versão da extensão válida que foi definido pelo AOSP.
[C-0-3] É PRECISO oferecer suporte a todas as APIs definidas pelas versões de extensão retornadas por android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) da mesma maneira que outras APIs gerenciadas são compatíveis, seguindo os requisitos da seção 3.1.

3.1.2. Biblioteca Android

Devido à suspensão de uso do cliente Apache HTTP, as implementações de dispositivos:

[C-0-1] NÃO COLOQUE a biblioteca org.apache.http.legacy no bootclasspath.
[C-0-2] É PRECISO adicionar a biblioteca org.apache.http.legacy ao caminho de classe do aplicativo somente quando o app atender a uma das seguintes condições:
- Destina-se ao nível 28 da API ou versões anteriores.
- Declara no manifesto que precisa da biblioteca definindo o atributo android:name de <uses-library> como org.apache.http.legacy.

A implementação do AOSP atende a esses requisitos.

3.2. Compatibilidade de API flexível

Além das APIs gerenciadas da seção 3.1, o Android também inclui uma API "soft" significativa somente para execução, na forma de intents, permissões e aspectos semelhantes de apps Android que não podem ser aplicados no momento da compilação do aplicativo.

3.2.1. Permissões

[C-0-1] Os implementadores de dispositivos precisam oferecer suporte e aplicar todas as constantes de permissão, conforme documentado na página de referência de permissões. A seção 9 lista outros requisitos relacionados ao modelo de segurança do Android.

3.2.2. Parâmetros do build

As APIs do Android incluem várias constantes na classe android.os.Build que descrevem o dispositivo atual.

[C-0-1] Para fornecer valores consistentes e significativos em todas as implementações de dispositivos, a tabela abaixo inclui outras restrições aos formatos desses valores, aos quais as implementações de dispositivos PRECISAM se conformar.

Parâmetro	Detalhes
VERSION.RELEASE	A versão do sistema Android em execução no momento, em formato legível por humanos. Esse campo PRECISA ter um dos valores de string definidos em Strings de versão permitidas para o Android 15.
VERSION.SDK	A versão do sistema Android em execução no momento, em um formato acessível para o código de aplicativos de terceiros. Para o Android 15, esse campo PRECISA ter o valor inteiro 15_INT.
VERSION.SDK&lowbar;INT	A versão do sistema Android em execução no momento, em um formato acessível para o código de aplicativos de terceiros. Para o Android 15, esse campo PRECISA ter o valor inteiro 15&lowbar;INT.
VERSION.INCREMENTAL	Um valor escolhido pelo implementador do dispositivo que designa o build específico do sistema Android em execução no momento, em um formato legível por humanos. Esse valor NÃO PODE ser reutilizado para builds diferentes disponibilizados aos usuários finais. Um uso típico desse campo é indicar qual número de build ou identificador de mudança de controle de origem foi usado para gerar o build. O valor desse campo PRECISA ser codificável como ASCII imprimível de 7 bits e corresponder à expressão regular `^[^ :\/~]+$`.
TABULEIRO	Um valor escolhido pelo implementador do dispositivo que identifica o hardware interno específico usado pelo dispositivo em um formato legível por humanos. Um possível uso desse campo é indicar a revisão específica da placa que alimenta o dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9_-]+$`.
MARCA	Um valor que reflete o nome da marca associado ao dispositivo, conforme conhecido pelos usuários finais. PRECISA estar em um formato legível por humanos e REPRESENTAR o fabricante do dispositivo ou a marca da empresa sob a qual o dispositivo é comercializado. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9_-]+$`.
ABIs&lowbar;SUPORTADAS	O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
SUPPORTED&lowbar;32&lowbar;BIT&lowbar;ABIS	O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
ABIs&lowbar;64&lowbar;BIT&lowbar;SUPORTADAS	O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade nativa com a API.
CPU&lowbar;ABI	O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade de API nativa.
CPU&lowbar;ABI2	O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade nativa com a API.
DISPOSITIVO	Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o nome de código que identifica a configuração dos recursos de hardware e do design industrial do dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9_-]+$`. O nome do dispositivo NÃO PODE mudar durante a vida útil do produto.
FINGERPRINT	Uma string que identifica exclusivamente esse build. Ele DEVE ser razoavelmente legível por humanos. Ele PRECISA seguir este modelo: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Exemplo: acme/myproduct/ mydevice:15/LMYXX/3359:userdebug/test-keys A impressão digital NÃO pode incluir caracteres de espaço em branco. O valor desse campo precisa ser codificável como ASCII de 7 bits.
HARDWARE	O nome do hardware (da linha de comando do kernel ou /proc). Ele PRECISA ser razoavelmente legível por humanos. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9_-]+$`.
HOST	Uma string que identifica de maneira exclusiva o host em que o build foi criado, em formato legível por humanos. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
ID	Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão específica, em um formato legível por humanos. Esse campo pode ser o mesmo que android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficientemente significativo para que os usuários finais distingam entre builds de software. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9._-]+$`.
FABRICANTE	O nome comercial do fabricante de equipamento original (OEM) do produto. Não há requisitos para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia (""). Esse campo NÃO PODE mudar durante a vida útil do produto.
SOC&lowbar;MANUFACTURER	O nome comercial do fabricante do sistema principal em chip (SOC) usado no produto. Dispositivos com o mesmo fabricante de SOC precisam usar o mesmo valor constante. Pergunte ao fabricante do SOC qual é a constante correta a ser usada. O valor desse campo PRECISA ser codificável como ASCII de 7 bits, PRECISA corresponder à expressão regular `^([0-9A-Za-z ]+)`, PRECISA NÃO começar ou terminar com espaço em branco e PRECISA NÃO ser igual a "unknown". Esse campo NÃO PODE mudar durante a vida útil do produto.
SOC&lowbar;MODEL	O nome do modelo do sistema principal em um chip (SOC) usado no produto. Dispositivos com o mesmo modelo de SOC precisam usar o mesmo valor constante. Pergunte ao fabricante do SOC qual é a constante correta a ser usada. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^([0-9A-Za-z ._/+-]+)$`. Ele NÃO PODE começar ou terminar com espaço em branco e PRECISA ser igual a "unknown". Esse campo NÃO PODE ser alterado durante a vida útil do produto.
MODEL	Um valor escolhido pelo implementador do dispositivo que contém o nome do dispositivo conhecido pelo usuário final. Ele DEVE ser o mesmo nome usado para comercializar e vender o dispositivo para os usuários finais. Não há requisitos para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a cadeia vazia (""). Esse campo NÃO PODE mudar durante a vida útil do produto.
PRODUTO	Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o nome de código do produto específico (SKU) que PRECISA ser exclusivo na mesma marca. PRECISA ser legível por humanos, mas não necessariamente para visualização por usuários finais. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9_-]+$`. Esse nome NÃO PODE ser alterado durante a vida útil do produto.
ODM&lowbar;SKU	Um valor opcional escolhido pelo implementador do dispositivo que contém SKU (Unidade de Manutenção de Estoque) usado para rastrear configurações específicas do dispositivo, por exemplo, qualquer periférico incluído com o dispositivo quando vendido. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^([0-9A-Za-z.,_-]+)$`.
SERIAL	PRECISA retornar "UNKNOWN".
TAGS	Uma lista de tags separadas por vírgulas escolhidas pelo implementador do dispositivo que diferencia ainda mais o build. As tags precisam ser codificadas como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9._-]+`. Elas também precisam ter um dos valores correspondentes às três configurações de assinatura típicas da plataforma Android: chaves de lançamento, chaves de desenvolvimento e chaves de teste.
HORÁRIO	Um valor que representa o carimbo de data/hora de quando o build ocorreu.
MÁQUINA	Um valor escolhido pelo implementador do dispositivo que especifica a configuração do ambiente de execução do build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas de ambiente de execução do Android: user, userdebug ou eng.
USUÁRIO	Um nome ou ID do usuário (ou usuário automatizado) que gerou o build. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
SECURITY&lowbar;PATCH	Um valor que indica o nível do patch de segurança de um build. Ele PRECISA indicar que o build não é de forma alguma vulnerável a nenhum dos problemas descritos no boletim de segurança público do Android designado. Ele PRECISA estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no boletim de segurança pública do Android ou no aviso de segurança do Android, por exemplo, "2015-11-01".
BASE&lowbar;OS	Um valor que representa o parâmetro FINGERPRINT do build, que é idêntico a esse build, exceto pelos patches fornecidos no boletim de segurança pública do Android. Ele PRECISA informar o valor correto e, se esse build não existir, informe uma string vazia ("").
BOOTLOADER (link em inglês)	Um valor escolhido pelo implementador do dispositivo que identifica a versão específica do carregador de inicialização interno usada no dispositivo em um formato legível por humanos. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9._-]+$`.
getRadioVersion()	PRECISA ser ou retornar um valor escolhido pelo implementador do dispositivo que identifica a versão específica do rádio/modem interno usada no dispositivo, em um formato legível por humanos. Se um dispositivo não tiver nenhum rádio/modem interno, ele PRECISA retornar NULL. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9._-,]+$`.
getSerial()	DEVE (ser ou retornar) um número de série de hardware, que DEVE estar disponível e ser exclusivo em dispositivos com o mesmo MODELO e FABRICANTE. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9]+$`.

3.2.3. Compatibilidade de intents

3.2.3.1. Intents comuns de apps

As intents do Android permitem que os componentes do aplicativo solicitem a funcionalidade de outros componentes do Android. O projeto upstream do Android inclui uma lista de aplicativos que implementam vários padrões de intent para realizar ações comuns.

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intents públicos definidos pelas seguintes intents do aplicativo listadas aqui e fornecer a realização, ou seja, atender à expectativa do desenvolvedor para essas intents comuns do aplicativo, conforme descrito no SDK.

Consulte a Seção 2 para ver as intents obrigatórias do aplicativo para cada tipo de dispositivo.

3.2.3.2. Resolução de intents

[C-0-1] Como o Android é uma plataforma extensível, as implementações de dispositivos PRECISAM permitir que cada padrão de intent referenciado na seção 3.2.3.1, exceto Configurações, seja substituído por aplicativos de terceiros. A implementação de código aberto upstream do Android permite isso por padrão.
[C-0-2] Os implementadores de dispositivos PRECISAM NÃO anexar privilégios especiais ao uso de aplicativos do sistema desses padrões de intent ou impedir que aplicativos de terceiros se associem e assumam o controle desses padrões. Essa proibição inclui especificamente, mas não se limita a, desativar a interface do usuário "Chooser", que permite ao usuário selecionar entre vários aplicativos que processam o mesmo padrão de intent.
[C-0-3] As implementações de dispositivo precisam fornecer uma interface do usuário para que os usuários modifiquem a atividade padrão para intents.
No entanto, as implementações de dispositivos PODEM fornecer atividades padrão para padrões específicos de URI (por exemplo, http://play.google.com) quando a atividade padrão fornece um atributo mais específico para o URI de dados. Por exemplo, um padrão de filtro de intent que especifica o URI de dados "http://www.android.com" é mais específico que o padrão de intent principal do navegador para "http://".

O Android também inclui um mecanismo para que apps de terceiros declarem um comportamento de vinculação de app padrão autorizado para determinados tipos de intents de URI da Web. Quando essas declarações oficiais são definidas nos padrões de filtro de intent de um app, as implementações do dispositivo:

[C-0-4] É PRECISO tentar validar todos os filtros de intent executando as etapas de validação definidas na especificação do Digital Asset Links conforme implementado pelo Gerenciador de pacotes no projeto upstream do Android Open Source.
[C-0-5] É OBRIGATÓRIO tentar a validação dos filtros de intent durante a instalação do aplicativo e definir todos os filtros de intent de URI validados com sucesso como gerenciadores de apps padrão para os URIs.
PODE definir filtros de intent de URI específicos como processadores de apps padrão para os URIs, se eles forem verificados com sucesso, mas outros filtros de URI candidatos falharem na verificação. Se uma implementação de dispositivo fizer isso, ela PRECISA fornecer as substituições de padrão por URI adequadas ao usuário no menu de configurações.
DEVE fornecer ao usuário controles de links de app por app nas configurações da seguinte maneira:
- [C-0-6] O usuário PRECISA poder substituir de forma holística o comportamento padrão dos links de um app para que ele seja: sempre aberto, sempre perguntado ou nunca aberto, que precisa ser aplicado igualmente a todos os filtros de intent de URI candidatos.
- [C-0-7] O usuário PRECISA ter acesso a uma lista dos filtros de intent de URI indicados.
- A implementação do dispositivo PODE permitir que o usuário substitua filtros de intent de URI de candidato específicos que foram verificados com sucesso, por filtro de intent.
- [C-0-8] A implementação do dispositivo PRECISA oferecer aos usuários a capacidade de visualizar e substituir filtros de intent de URI de candidato específicos se a implementação do dispositivo permitir que alguns filtros de intent de URI de candidato tenham sucesso na verificação, enquanto outros podem falhar.

3.2.3.3. Namespaces de intent

[C-0-1] As implementações de dispositivos NÃO PODEM incluir nenhum componente do Android que honre qualquer nova intent ou padrões de intent de transmissão usando uma ACTION, CATEGORY ou outra string de chave no namespace android.* ou com.android.*.
[C-0-2] Os implementadores de dispositivos NÃO PODEM incluir componentes do Android que cumpram padrões de intent ou broadcast novos usando uma string de chave ACTION, CATEGORY ou outra em um espaço de pacote pertencente a outra organização.
[C-0-3] Os implementadores de dispositivos NÃO PODEM alterar ou estender nenhum dos padrões de intent listados na seção 3.2.3.1.
As implementações de dispositivos PODEM incluir padrões de intent usando namespaces claramente e obviamente associados à própria organização. Essa proibição é análoga à especificada para classes da linguagem Java na seção 3.6.

3.2.3.4. Intents de transmissão

Os aplicativos de terceiros dependem da plataforma para transmitir determinadas intents e notificar as mudanças no ambiente de hardware ou software.

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO transmitir as intents de transmissão pública listadas aqui em resposta a eventos do sistema apropriados, conforme descrito na documentação do SDK. Esse requisito não entra em conflito com a seção 3.5, porque a limitação para aplicativos em segundo plano também é descrita na documentação do SDK. Além disso, algumas intents de transmissão dependem do suporte ao hardware. Se o dispositivo oferece suporte ao hardware necessário, ele PRECISA transmitir as intents e fornecer o comportamento inline de acordo com a documentação do SDK.

3.2.3.5. Intents de aplicativo condicionais

O Android inclui configurações que oferecem aos usuários uma maneira fácil de selecionar os aplicativos padrão, por exemplo, para a tela inicial ou SMS.

Quando apropriado, as implementações de dispositivos precisam fornecer um menu de configurações semelhante e ser compatível com o padrão de filtro de intent e os métodos de API descritos na documentação do SDK, conforme abaixo.

Se as implementações de dispositivos informarem android.software.home_screen, elas:

[C-1-1] É OBRIGATÓRIO honrar a intent android.settings.HOME_SETTINGS para mostrar um menu de configurações padrão do app para a tela inicial.

Se as implementações de dispositivos informarem android.hardware.telephony.calling, elas:

[C-2-1] É necessário fornecer um menu de configurações que chame a intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar uma caixa de diálogo para mudar o app de SMS padrão.
[C-2-2] É PRECISO honrar a intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar uma caixa de diálogo que permita ao usuário mudar o aplicativo de telefone padrão.
- É OBRIGATÓRIO usar a interface do app Telefone padrão selecionada pelo usuário para chamadas recebidas e realizadas, exceto para chamadas de emergência, que usam o app Telefone pré-instalado.
[C-2-3] É PRECISO honrar a intent android.telecom.action.CHANGE_PHONE_ACCOUNTS para fornecer ao usuário a capacidade de configurar o ConnectionServices associado ao PhoneAccounts, bem como uma PhoneAccount padrão que o provedor de serviços de telecomunicações usará para fazer chamadas. A implementação do AOSP atende a esse requisito incluindo uma opção "Calling Accounts" no menu de configurações "Calls".
[C-2-4] É PRECISO permitir android.telecom.CallRedirectionService para um app que tenha o papel android.app.role.CALL_REDIRECTION.
[C-2-5] É OBRIGATÓRIO fornecer ao usuário a capacidade de escolher um app que tenha a função android.app.role.CALL_REDIRECTION.
[C-2-6] É OBRIGATÓRIO honrar as intents android.intent.action.SENDTO e android.intent.action.VIEW e fornecer uma atividade para enviar/exibir mensagens SMS.
[C-SR-1] É ALTAMENTE RECOMENDADO honrar as intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL com um aplicativo de discagem pré-carregado, que pode processar essas intents e oferecer o fulfillment conforme descrito no SDK.

Se as implementações de dispositivos informarem android.hardware.nfc.hce, elas:

[C-3-1] É PRECISO honrar a intent android.settings.NFC_PAYMENT_SETTINGS para mostrar um menu de configurações padrão do app para pagamentos por aproximação.
[C-3-2] É NECESSÁRIO honrar a intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT para mostrar uma atividade que abre uma caixa de diálogo para pedir que o usuário mude o serviço de emulação de cartão padrão de uma determinada categoria, conforme descrito no SDK.

Se as implementações de dispositivos informarem android.hardware.nfc, elas:

[C-4-1] DEVE honrar estas intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, para mostrar uma atividade que atenda às expectativas do desenvolvedor para essas intents, conforme descrito no SDK.

Se as implementações de dispositivos informarem android.hardware.bluetooth, elas:

[C-5-1] É NECESSÁRIO honrar a intent 'android.bluetooth.adapter.action.REQUEST_ENABLE' e mostrar uma atividade do sistema para permitir que o usuário ative o Bluetooth.
[C-5-2] É NECESSÁRIO honrar a intent 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' e mostrar uma atividade do sistema que solicite o modo detectável.

Se as implementações de dispositivos oferecerem suporte ao recurso Não perturbe, elas:

[C-6-1] É PRECISO implementar uma atividade que responda à intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, que, para implementações com UI_MODE_TYPE_NORMAL, PRECISA ser uma atividade em que o usuário possa conceder ou negar o acesso do app às configurações da política de DND.

Se as implementações de dispositivo permitirem que os usuários usem métodos de entrada de terceiros no dispositivo, eles:

[C-7-1] É OBRIGATÓRIO fornecer um mecanismo acessível ao usuário para adicionar e configurar métodos de entrada de terceiros em resposta à intent android.settings.INPUT_METHOD_SETTINGS.

Se as implementações de dispositivos oferecem suporte a serviços de acessibilidade de terceiros, elas:

[C-8-1] É OBRIGATÓRIO honrar a intent android.settings.ACCESSIBILITY_SETTINGS para fornecer um mecanismo acessível ao usuário para ativar e desativar os serviços de acessibilidade de terceiros com os serviços de acessibilidade pré-carregados.

Se as implementações de dispositivos incluírem suporte ao Wi-Fi Easy Connect e exporem a funcionalidade a apps de terceiros, elas:

[C-9-1] É PRECISO implementar as APIs de intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI conforme descrito na documentação do SDK.

Se as implementações do dispositivo oferecerem o modo de Economia de dados, elas:

[C-10-1] É OBRIGATÓRIO fornecer uma interface do usuário nas configurações que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, permitindo que os usuários adicionem ou removam aplicativos da lista de permissões.

Se as implementações do dispositivo não oferecerem o modo de economia de dados, elas:

[C-11-1] É PRECISO ter uma atividade que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mas ELA PODE ser implementada como uma operação nula.

Se as implementações do dispositivo declararem suporte à câmera por meio de android.hardware.camera.any, elas:

[C-12-3] É OBRIGATÓRIO processar e permitir apenas que aplicativos Android pré-instalados processem as seguintes intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE e MediaStore.ACTION_VIDEO_CAPTURE, conforme descrito no documento do SDK.

Se as implementações de dispositivos informarem android.software.device_admin, elas:

[C-13-1] É OBRIGATÓRIO honrar a intent android.app.action.ADD_DEVICE_ADMIN para invocar uma interface que ajude o usuário a adicionar o administrador do dispositivo ao sistema (ou permitir que ele o rejeite).
[C-13-2] É PRECISO honrar as intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION e ter uma atividade para fornecer a realização dessas intents, conforme descrito no SDK neste link.

Se as implementações do dispositivo declararem a flag de recurso android.software.autofill, elas:

[C-14-1] É PRECISO implementar totalmente as APIs AutofillService e AutofillManager e respeitar a intent android.settings.REQUEST_SET_AUTOFILL_SERVICE para mostrar um menu de configurações padrão do app para ativar e desativar o preenchimento automático e mudar o serviço de preenchimento automático padrão para o usuário.

Se as implementações do dispositivo incluírem um app pré-instalado ou quiserem permitir que apps de terceiros acessem as estatísticas de uso, elas:

[C-SR-2] É ALTAMENTE RECOMENDADO fornecer um mecanismo acessível ao usuário para conceder ou revogar o acesso às estatísticas de uso em resposta à intent android.settings.ACTION_USAGE_ACCESS_SETTINGS para apps que declaram a permissão android.permission.PACKAGE_USAGE_STATS.

Se as implementações de dispositivos quiserem impedir que apps, incluindo os pré-instalados, acessem as estatísticas de uso, elas:

[C-15-1] AINDA É NECESSÁRIO ter uma atividade que processe o padrão de intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mas PRECISA ser implementado como uma operação nula, ou seja, ter um comportamento equivalente ao que ocorre quando o usuário é recusado para acesso.

Se as implementações do dispositivo mostrarem links para as atividades especificadas por AutofillService_passwordsActivity nas Configurações ou links para senhas de usuário por um mecanismo semelhante, elas:

[C-16-1] É OBRIGATÓRIO mostrar esses links para todos os serviços de preenchimento automático instalados.

Se as implementações do dispositivo forem compatíveis com a VoiceInteractionService e tiverem mais de um aplicativo usando essa API instalada por vez, elas:

[C-18-1] É OBRIGATÓRIO honrar a intent android.settings.ACTION_VOICE_INPUT_SETTINGS para mostrar um menu de configurações padrão do app para entrada por voz e assistente.

Se as implementações do dispositivo informarem o recurso android.hardware.audio.output, elas:

[C-SR-3] É ALTAMENTE RECOMENDADO honrar android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT intents têm uma atividade para fornecer o cumprimento dessas intents, conforme descrito no SDK neste link.

O Android inclui suporte para protetores de tela interativos, anteriormente chamados de "Dreams". Os protetores de tela permitem que os usuários interajam com aplicativos quando um dispositivo conectado a uma fonte de energia está ocioso ou acoplado a uma base de mesa. Implementações de dispositivos:

DEVE incluir suporte a protetores de tela e oferecer uma opção de configurações para que os usuários configurem protetores de tela em resposta à intent android.settings.DREAM_SETTINGS.

Se as implementações do dispositivo informarem android.hardware.nfc.uicc ou android.hardware.nfc.ese, elas:

[C-19-1] É PRECISO implementar a API Intent NfcAdapter.ACTION_TRANSACTION_DETECTED (como "EVT_TRANSACTION" definido pela especificação técnica da Associação GSM TS.26 - Requisitos de aparelhos NFC).

3.2.4. Atividades em telas secundárias/várias telas

Se as implementações de dispositivos permitirem o lançamento de atividades do Android normais em mais de uma tela, elas:

[C-1-1] É OBRIGATÓRIO definir a flag de recurso android.software.activities_on_secondary_displays.
[C-1-2] PRECISA garantir a compatibilidade da API de forma semelhante a uma atividade executada na tela principal.
[C-1-3] É OBRIGATÓRIO que a nova atividade seja exibida na mesma tela que a atividade que a iniciou, quando a nova atividade for iniciada sem especificar uma tela de destino pela API ActivityOptions.setLaunchDisplayId().
[C-1-4] É OBRIGATÓRIO destruir todas as atividades quando uma tela com a flag Display.FLAG_PRIVATE for removida.
[C-1-5] É OBRIGATÓRIO ocultar com segurança o conteúdo em todas as telas quando o dispositivo estiver bloqueado com uma tela de bloqueio segura, a menos que o app ative a exibição na parte de cima da tela de bloqueio usando a API Activity#setShowWhenLocked().
DEVE ter android.content.res.Configuration, que corresponde a essa tela para ser exibida, funcionar corretamente e manter a compatibilidade se uma atividade for iniciada na tela secundária.

Se as implementações do dispositivo permitirem a inicialização de atividades normais do Android em telas secundárias e uma tela secundária tiver a flag android.view.Display.FLAG_PRIVATE,

[C-3-1] Somente o proprietário da tela, do sistema e das atividades que já estão nela PODE iniciar atividades nela. Todos podem iniciar em uma tela que tenha a flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilidade com a API nativa

A compatibilidade com o código nativo é desafiadora. Por esse motivo, os implementadores de dispositivos são:

[C-SR-1] É ALTAMENTE RECOMENDADO usar as implementações das bibliotecas listadas abaixo do Projeto de código aberto do Android upstream.

3.3.1. Interfaces binárias do aplicativo

O bytecode Dalvik gerenciado pode chamar o código nativo fornecido no arquivo .apk do aplicativo como um arquivo ELF .so compilado para a arquitetura de hardware do dispositivo apropriado. Como o código nativo é altamente dependente da tecnologia do processador, o Android define várias interfaces binárias de aplicativos (ABIs) no Android NDK.

Implementações de dispositivos:

[C-0-1] PRECISA ser compatível com uma ou mais ABIs do Android NDK definidas.
[C-0-2] É necessário incluir suporte para código executado no ambiente gerenciado para chamar código nativo usando a semântica padrão da Java Native Interface (JNI).
[C-0-3] PRECISA ser compatível com a origem (ou seja, compatível com o cabeçalho) e com o binário (para a ABI) com cada biblioteca necessária na lista abaixo.
[C-0-5] É OBRIGATÓRIO informar com precisão a interface binária do aplicativo (ABI) nativa aceita pelo dispositivo usando os parâmetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, cada um deles uma lista de ABIs separadas por vírgulas e ordenadas da mais para a menos preferida.

Início dos novos requisitos para o Android 15

[C-0-6] É OBRIGATÓRIO informar, pelos parâmetros acima, um subconjunto da lista de ABIs abaixo e NÃO informar nenhuma ABI que não esteja na lista.
- armeabi (não é mais compatível como destino do NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64

Fim dos novos requisitos

[C-0-7] É OBRIGATÓRIO disponibilizar todas as bibliotecas a seguir, que fornecem APIs nativas, para apps que incluem código nativo:
- libaaudio.so (suporte de áudio nativo do AAudio)
- libamidi.so (suporte MIDI nativo, se o recurso android.software.midi for reivindicado conforme descrito na seção 5.9)
- libandroid.so (suporte nativo à atividade do Android)
- libc (biblioteca C)
- libcamera2ndk.so
- libdl (vinculador dinâmico)
- libEGL.so (gerenciamento de superfície OpenGL nativa)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (geração de registros do Android)
- libmediandk.so (suporte a APIs de mídia nativas)
- libm (biblioteca matemática)
- libneuralnetworks.so (API Neural Networks)
- libOpenMAXAL.so (suporte ao OpenMAX AL 1.0.1)
- libOpenSLES.so (suporte a áudio do OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (suporte mínimo para C++)
- libvulkan.so (Vulkan)
- libz (compactação Zlib)
- Interface JNI
[C-0-8] NÃO é permitido adicionar ou remover as funções públicas das bibliotecas nativas listadas acima.
[C-0-9] É OBRIGATÓRIO listar outras bibliotecas que não são do AOSP expostas diretamente a apps de terceiros em /vendor/etc/public.libraries.txt.
[C-0-10] NÃO EXPORÃO NENHUM OUTRO TIPO DE BIBLIOTECA NATIVA, IMPLEMENTADA E OFERECIDA NO AOSP COMO BIBLIOTECAS DO SISTEMA, PARA APLICATIVOS DE TERCEIROS DIRIGIDOS AO NÍVEL 24 DA API OU SUPERIOR, POIS ELAS ESTÃO RESERVADAS.
[C-0-11] É OBRIGATÓRIO exportar todos os símbolos de função do OpenGL ES 3.1 e do Android Extension Pack, conforme definido no NDK, pela biblioteca libGLESv3.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.1 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
[C-0-12] É PRECISO exportar símbolos de função para os símbolos de função do Vulkan 1.1, bem como as extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 pela biblioteca libvulkan.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.2 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
DEVEM ser criados usando o código-fonte e os arquivos de cabeçalho disponíveis no projeto upstream do Android Open Source.

Versões futuras do Android podem oferecer suporte a outras ABIs.

3.3.2. Compatibilidade com código nativo ARM de 32 bits

Se as implementações do dispositivo informarem o suporte à ABI armeabi, elas:

[C-3-1] PRECISA ter suporte a armeabi-v7a e informar esse suporte, já que armeabi é apenas para compatibilidade com versões anteriores de apps mais antigos.

Se as implementações do dispositivo informarem o suporte da ABI armeabi-v7a, para apps que usam essa ABI, eles:

[C-2-1] PRECISA incluir as linhas a seguir em /proc/cpuinfo e NÃO alterar os valores no mesmo dispositivo, mesmo quando eles são lidos por outras ABIs.
- Features:, seguido por uma lista de recursos opcionais de CPU ARMv7 compatíveis com o dispositivo.
- CPU architecture:, seguido por um número inteiro que descreve a arquitetura ARM mais recente com suporte do dispositivo (por exemplo, "8" para dispositivos ARMv8).
[C-2-2] É PRECISO manter as operações abaixo disponíveis, mesmo quando a ABI é implementada em uma arquitetura ARMv8, seja com suporte a CPU nativa ou emulação de software:
- Instruções SWP e SWPB.
- Operações de barreira CP15ISB, CP15DSB e CP15DMB.
[C-2-3] É PRECISO incluir suporte para a extensão Advanced SIMD (também conhecida como NEON).

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView

Se as implementações do dispositivo fornecerem uma implementação completa da API android.webkit.Webview, elas:

[C-1-1] É OBRIGATÓRIO informar android.software.webview.
[C-1-2] É PRECISO usar o build do projeto Chromium do upstream do Android Open Source Project na versão 15 do Android para a implementação da API android.webkit.WebView.
[C-1-3] A string do user agent informada pela WebView PRECISA estar neste formato:

Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, como Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
- A string $(MODEL) PODE estar vazia, mas, se não estiver, ela PRECISA ter o mesmo valor de android.os.Build.MODEL.
- "Build/$(BUILD)" PODE ser omitido, mas, se estiver presente, a string $(BUILD) PRECISA ser igual ao valor de android.os.Build.ID.
- O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium no projeto de código aberto do Android upstream.
- As implementações de dispositivos PODEM omitir "Mobile" na string do user agent.
O componente WebView PRECISA incluir suporte para o maior número possível de recursos HTML5 e, se ele oferecer suporte ao recurso, PRECISA estar em conformidade com a especificação HTML5.
[C-1-4] É NECESSÁRIO renderizar o conteúdo fornecido ou o conteúdo do URL remoto em um processo que seja diferente do aplicativo que instancia a WebView. Especificamente, o processo de renderizador separado PRECISA ter privilégios mais baixos, ser executado como um ID de usuário separado, não ter acesso ao diretório de dados do app, não ter acesso direto à rede e ter acesso apenas aos serviços do sistema necessários mínimos pelo Binder. A implementação do AOSP da WebView atende a esse requisito.

Se as implementações do dispositivo forem de 32 bits ou declararem a flag de recurso android.hardware.ram.low, elas serão isentas da C-1-3.

3.4.2. Compatibilidade de navegadores

Se as implementações de dispositivos incluírem um aplicativo de navegador independente para navegação geral na Web, elas:

[C-1-1] É PRECISO oferecer suporte a cada uma das APIs associadas ao HTML5:
[C-1-2] É PRECISO oferecer suporte à API webstorage do HTML5/W3C e PODE oferecer suporte à API IndexedDB do HTML5/W3C. Como os órgãos de padrões de desenvolvimento da Web estão fazendo a transição para favorecer o IndexedDB em vez do IndexedDB, espera-se que ele se torne um componente obrigatório em uma versão futura do Android.
PODE enviar uma string de user agent personalizada no aplicativo de navegador independente.
PRECISA implementar suporte para o maior número possível de HTML5 no aplicativo de navegador autônomo (seja baseado no aplicativo de navegador WebKit upstream ou em uma substituição de terceiros).

No entanto, se as implementações de dispositivos não incluírem um aplicativo de navegador independente, elas:

[C-2-1] PRECISA continuar a oferecer suporte aos padrões de intent pública, conforme descrito na seção 3.2.3.1.

3.5. Compatibilidade comportamental da API

Implementações de dispositivos:

[C-0-9] É PRECISO garantir que a compatibilidade comportamental da API seja aplicada a todos os apps instalados, a menos que eles sejam restritos conforme descrito na Seção 3.5.1.
[C-0-10] NÃO IMPLEMENTE a abordagem de lista de permissões que garante a compatibilidade com o comportamento da API apenas para apps selecionados pelos implementadores do dispositivo.

O comportamento de cada um dos tipos de API (gerenciada, soft, nativa e da Web) precisa ser consistente com a implementação preferencial do Android Open Source Project upstream. Algumas áreas específicas de compatibilidade são:

[C-0-1] Os dispositivos NÃO PODEM mudar o comportamento ou a semântica de uma intent padrão.
[C-0-2] Os dispositivos NÃO PODEM alterar o ciclo de vida ou a semântica do ciclo de vida de um tipo específico de componente do sistema (como serviço, atividade, ContentProvider etc.).
[C-0-3] Os dispositivos NÃO PODEM mudar a semântica de uma permissão padrão.
Os dispositivos NÃO podem alterar as limitações aplicadas aos aplicativos em segundo plano. Mais especificamente, para apps em segundo plano:
- [C-0-4] Eles PRECISAM parar de executar callbacks registrados pelo app para receber saídas do GnssMeasurement e GnssNavigationMessage.
- [C-0-5] Eles PRECISAM limitar a taxa de atualizações fornecidas ao app pela classe de API LocationManager ou pelo método WifiManager.startScan().
- [C-0-6] Se o app for destinado ao nível 25 da API ou mais recente, ele NÃO PODE permitir o registro de broadcast receivers para as transmissões implícitas de intents padrão do Android no manifesto do app, a menos que a intent de transmissão exija uma permissão "signature" ou "signatureOrSystem" protectionLevel ou esteja na lista de isenção.
- [C-0-7] Se o app for destinado ao nível 25 da API ou mais recente, ele PRECISA interromper os serviços em segundo plano do app, como se ele tivesse chamado o método stopSelf() dos serviços, a menos que o app seja colocado em uma lista de permissões temporária para processar uma tarefa que esteja visível para o usuário.
- [C-0-8] Se o app for destinado ao nível 25 da API ou mais recente, ele PRECISA liberar os wakelocks que o app mantém.
[C-0-11] Os dispositivos PRECISAM retornar os seguintes provedores de segurança como os primeiros sete valores de matriz do método Security.getProviders(), na ordem e com os nomes fornecidos (como retornados por Provider.getName()) e classes, a menos que o app tenha modificado a lista por insertProviderAt() ou removeProvider(). Os dispositivos PODEM retornar outros provedores após a lista especificada de provedores abaixo.
1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
2. AndroidOpenSSL: com.android.org.conscrypt.OpenSSLProvider
3. CertPathProvider: sun.security.provider.CertPathProvider
4. AndroidKeyStoreBCWorkaround: android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE: com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore: android.security.keystore.AndroidKeyStoreProvider

A lista acima não está completa. O conjunto de teste de compatibilidade (CTS) testa partes significativas da plataforma para compatibilidade comportamental, mas não todas. É responsabilidade do implementador garantir a compatibilidade comportamental com o Android Open Source Project. Por esse motivo, os implementadores de dispositivos DEVEM usar o código-fonte disponível no Android Open Source Project sempre que possível, em vez de reimplementar partes significativas do sistema.

3.5.1. Restrição de aplicativo

Se as implementações de dispositivo implementarem um mecanismo reservado para restringir apps (por exemplo, alterar ou restringir comportamentos de API que são descritos no SDK) e esse mecanismo for mais restritivo do que o Bucket de espera de apps restritos, eles:

[C-1-1] É PRECISO permitir que o usuário veja a lista de apps restritos.
[C-1-2] É PRECISO oferecer ao usuário a capacidade de ativar / desativar todas essas restrições exclusivas em cada app.
[C-1-3] É PROIBIDO aplicar automaticamente essas restrições reservadas sem evidências de comportamento de integridade do sistema ruim, mas é PERMITIDO aplicar as restrições em apps após a detecção de comportamento de integridade do sistema ruim, como bloqueios de desbloqueio travados, serviços de execução longa e outros critérios. Os critérios podem ser determinados pelos implementadores do dispositivo, mas precisam estar relacionados ao impacto do app na integridade do sistema. Outros critérios que não estejam relacionados exclusivamente à integridade do sistema, como a falta de popularidade do app no mercado, NÃO devem ser usados como critérios.
[C-1-4] NÃO é permitido aplicar automaticamente essas restrições reservadas a apps quando um usuário desativou as restrições de apps manualmente e PODE sugerir ao usuário que aplique essas restrições reservadas.
[C-1-5] É OBRIGATÓRIO informar aos usuários se essas restrições de propriedade intelectual são aplicadas a um app automaticamente. Essas informações precisam ser fornecidas no período de 24 horas anterior à aplicação dessas restrições reservadas.
[C-1-6] PRECISA retornar "true" para o método ActivityManager.isBackgroundRestricted() em todas as chamadas de API de um app.
[C-1-7] NÃO DEVE restringir o app em primeiro plano que é usado explicitamente pelo usuário.
[C-1-8] É OBRIGATÓRIO suspender essas restrições proprietárias em um app sempre que um usuário começar a usá-lo explicitamente, tornando-o o aplicativo em primeiro plano principal.
[C-1-10] É OBRIGATÓRIO fornecer um documento ou site público e claro que descreva como as restrições de propriedade são aplicadas. Esse documento ou site PRECISA ser vinculado nos documentos do SDK do Android e PRECISA incluir:
- Acionar condições para restrições de propriedade.
- O que e como um app pode ser restrito.
- Como um app pode ser isento dessas restrições.
- Como um app pode solicitar uma isenção de restrições de propriedade, se elas oferecerem essa isenção para apps que o usuário pode instalar.

Se um app estiver pré-instalado no dispositivo e nunca tiver sido usado explicitamente por um usuário por mais de 30 dias, [C-1-3] [C-1-5] serão isentos.

Se as implementações do dispositivo estenderem as restrições de app implementadas no AOSP, elas:

[C-2-1]PRECISA seguir a implementação descrita neste documento.

3.5.2. Hibernação do app

Se as implementações do dispositivo incluírem a hibernação de apps incluída no AOSP ou estenderem o recurso incluído no AOSP, elas:

[C-1-1] É OBRIGATÓRIO atender a todos os requisitos da seção 3.5.1, exceto [C-1-6] e [C-1-3].
[C-1-2] A restrição no app só pode ser aplicada a um usuário quando há evidências de que o usuário não usou o app por um período. É ALTAMENTE RECOMENDADO que essa duração seja de um mês ou mais. O uso PRECISA ser definido por uma interação explícita do usuário pela API UsageStats#getLastTimeVisible() ou qualquer coisa que faça com que um app saia do estado de parada forçada, incluindo vinculações de serviço, vinculações de provedor de conteúdo, transmissões explícitas etc., que serão rastreadas por uma nova API UsageStats#getLastTimeAnyComponentUsed().
[C-1-3] SOMENTE restrinjam os usuários de todos os dispositivos quando houver evidências de que o pacote não foi usado por NENHUM usuário por um período de tempo. É ALTAMENTE RECOMENDADO que essa duração seja de um mês ou mais.
[C-1-4] NÃO PODE impedir que o app responda a intents de atividade, vinculações de serviço, solicitações de provedores de conteúdo ou transmissões explícitas.

A hibernação de apps no AOSP atende aos requisitos acima.

3.6. Namespaces de API

O Android segue as convenções de namespace de pacote e classe definidas pela linguagem de programação Java. Para garantir a compatibilidade com aplicativos de terceiros, os implementadores de dispositivos NÃO PODEM fazer modificações proibidas (confira abaixo) nestes namespaces de pacotes:

java.*
javax.*
sun.*
android.*
androidx.*
com.android.*

Ou seja, eles:

[C-0-1] NÃO É PERMITIDO modificar as APIs expostas publicamente na plataforma Android mudando assinaturas de método ou classe ou removendo classes ou campos de classe.
[C-0-2] NÃO É PERMITIDO adicionar elementos expostos publicamente (como classes ou interfaces, ou campos ou métodos a classes ou interfaces existentes) ou APIs de teste ou do sistema às APIs nos namespaces acima. Um "elemento exposto publicamente" é qualquer construção que não seja decorada com o marcador "@hide", como usado no código-fonte upstream do Android.

Os implementadores de dispositivos PODEM modificar a implementação subjacente das APIs, mas essas modificações:

[C-0-3] NÃO DEVE afetar o comportamento declarado e a assinatura do idioma Java de qualquer API exposta publicamente.
[C-0-4] NÃO PODE ser anunciado ou exposto aos desenvolvedores.

No entanto, os implementadores de dispositivos PODEM adicionar APIs personalizadas fora do namespace padrão do Android, mas as APIs personalizadas:

[C-0-5] NÃO PODE estar em um namespace de propriedade ou referência a outra organização. Por exemplo, os implementadores de dispositivos NÃO PODEM adicionar APIs ao namespace com.google.* ou semelhante: somente o Google pode fazer isso. Da mesma forma, o Google NÃO PODE adicionar APIs aos namespaces de outras empresas.
[C-0-6] PRECISA ser empacotado em uma biblioteca compartilhada do Android para que apenas os apps que as usam explicitamente (pelo mecanismo <uses-library>) sejam afetados pelo aumento do uso de memória dessas APIs.

Os implementadores de dispositivos PODEM adicionar APIs personalizadas em idiomas nativos, fora das APIs do NDK, mas as APIs personalizadas:

[C-1-1] NÃO PODE estar em uma biblioteca do NDK ou em uma biblioteca de outra organização, conforme descrito aqui.

Se um implementador de dispositivo propor a melhoria de um dos namespaces de pacote acima (por exemplo, adicionando uma nova funcionalidade útil a uma API existente ou adicionando uma nova API), ele PRECISA acessar source.android.com e iniciar o processo de contribuição de mudanças e código, de acordo com as informações nesse site.

As restrições acima correspondem a convenções padrão para nomear APIs na linguagem de programação Java. Esta seção tem como objetivo apenas reforçar essas convenções e torná-las obrigatórias pela inclusão nesta definição de compatibilidade.

3.7. Compatibilidade com o ambiente de execução

Implementações de dispositivos:

[C-0-1] É PRECISO oferecer suporte ao formato completo do Dalvik Executable (DEX) e à especificação e semântica do bytecode do Dalvik.
[C-0-2] É OBRIGATÓRIO configurar os ambientes de execução do Dalvik para alocar memória de acordo com a plataforma upstream do Android e conforme especificado na tabela a seguir. Consulte a seção 7.1.1 para definições de tamanho e densidade da tela.
DEVE usar o Android RunTime (ART), a implementação upstream de referência do formato executável Dalvik e o sistema de gerenciamento de pacotes da implementação de referência.
EXECUTAR testes de fuzz em vários modos de execução e arquiteturas de destino para garantir a estabilidade do ambiente de execução. Consulte JFuzz e DexFuzz no site do Android Open Source Project.

Os valores de memória especificados abaixo são considerados mínimos, e as implementações de dispositivos podem alocar mais memória por aplicativo.

Layout da tela	Densidade da tela	Memória mínima do aplicativo
Relógio Android	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)	36MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)	48MB
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
pequeno/normal	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)	80MB
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
grande	120 dpi (ldpi)	32MB
	140 dpi (140dpi)	48MB
	160 dpi (mdpi)	48MB
	180 dpi (180dpi)	80MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512 MB
extra grande	120 dpi (ldpi)	48MB
	140 dpi (140dpi)	80MB
	160 dpi (mdpi)	80MB
	180 dpi (180dpi)	96MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. Compatibilidade com a interface do usuário

3.8.1. Acesso rápido (tela inicial)

O Android inclui um aplicativo de acesso rápido (tela inicial) e oferece suporte a aplicativos de terceiros para substituir o acesso rápido do dispositivo (tela inicial).

Se as implementações de dispositivos permitirem que aplicativos de terceiros substituam a tela inicial do dispositivo, elas:

[C-1-1] É PRECISO declarar o recurso da plataforma android.software.home_screen.
[C-1-2] PRECISA retornar o objeto AdaptiveIconDrawable quando o aplicativo de terceiros usar a tag <adaptive-icon> para fornecer o ícone e os métodos PackageManager para recuperar ícones forem chamados.

Se as implementações do dispositivo incluírem uma tela de início padrão compatível com a fixação de atalhos no app, elas:

[C-2-1] É OBRIGATÓRIO informar true para ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] É PRECISO ter uma affordance do usuário pedindo ao usuário antes de adicionar um atalho solicitado por apps pelo método da API ShortcutManager.requestPinShortcut().
[C-2-3] PRECISA oferecer suporte a atalhos fixados e dinâmicos e estáticos, conforme documentado na página de atalhos do app.

Por outro lado, se as implementações de dispositivos não oferecerem suporte à fixação de atalhos no app, elas:

[C-3-1] É OBRIGATÓRIO informar false para ShortcutManager.isRequestPinShortcutSupported().

Se as implementações de dispositivos implementarem uma tela de início padrão que ofereça acesso rápido aos atalhos adicionais fornecidos por apps de terceiros pela API ShortcutManager, elas:

[C-4-1] PRECISA oferecer suporte a todos os recursos de atalho documentados (por exemplo, atalhos estáticos e dinâmicos, fixação de atalhos) e implementar totalmente as APIs da classe ShortcutManager.

Se as implementações do dispositivo incluírem um app de inicialização padrão que mostre badges para os ícones do app, elas:

[C-5-1] É PRECISO respeitar o método da API NotificationChannel.setShowBadge(). Em outras palavras, mostre uma affordance visual associada ao ícone do app se o valor for definido como true e não mostre nenhum esquema de badging de ícone do app quando todos os canais de notificação do app tiverem definido o valor como false.
PODE substituir os selos de ícone do app pelo esquema de badging proprietário quando aplicativos de terceiros indicam suporte ao esquema de badging proprietário pelo uso de APIs proprietárias, mas PRECISA usar os recursos e valores fornecidos pelas APIs de selos de notificação descritas no SDK, como a Notification.Builder.setNumber() e a API Notification.Builder.setBadgeIconType().

Se as implementações do dispositivo oferecerem suporte a ícones monocromáticos, eles:

[C-6-1] SOMENTE quando um usuário as ativar explicitamente (por exemplo, nas Configurações ou no menu do seletor de plano de fundo).

3.8.2. Widgets

O Android oferece suporte a widgets de apps de terceiros ao definir um tipo de componente e o ciclo de vida correspondente que permite que os aplicativos exponham um "AppWidget" ao usuário final.

Se as implementações de dispositivos oferecerem suporte a widgets de apps de terceiros, elas:

[C-1-1] É PRECISO declarar suporte ao recurso de plataforma android.software.app_widgets.
[C-1-2] É PRECISO incluir suporte integrado a AppWidgets e expor affordances da interface do usuário para adicionar, configurar, visualizar e remover AppWidgets.
[C-1-3] PRECISA ser capaz de renderizar widgets de 4 x 4 no tamanho padrão da grade. Consulte as Diretrizes de design para widgets de app na documentação do SDK do Android para saber mais.
PODE oferecer suporte a widgets de apps na tela de bloqueio.

Se as implementações de dispositivos oferecerem suporte a widgets de apps de terceiros e fixação de atalhos no app, elas:

[C-2-1] É OBRIGATÓRIO informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] É PRECISO ter uma affordance do usuário pedindo ao usuário antes de adicionar um atalho solicitado por apps pelo método da API AppWidgetManager.requestPinAppWidget().

3.8.3. Notificações

O Android inclui as APIs Notification e NotificationManager que permitem que desenvolvedores de apps de terceiros notifiquem os usuários sobre eventos importantes e atraiam a atenção deles usando os componentes de hardware (por exemplo, som, vibração e luz) e recursos de software (por exemplo, painel de notificações, barra de sistema) do dispositivo.

3.8.3.1. Apresentação das notificações

Se as implementações de dispositivos permitirem que apps de terceiros notifiquem os usuários sobre eventos importantes, elas:

[C-1-1] PRECISA oferecer suporte a notificações que usam recursos de hardware, conforme descrito na documentação do SDK e, na medida do possível, com o hardware de implementação do dispositivo. Por exemplo, se uma implementação de dispositivo incluir um vibrador, ela PRECISA implementar corretamente as APIs de vibração. Se uma implementação de dispositivo não tiver hardware, as APIs correspondentes PRECISAM ser implementadas como no-ops. Esse comportamento é detalhado na seção 7.
[C-1-2] É PRECISO renderizar corretamente todos os recursos (ícones, arquivos de animação etc.) fornecidos nas APIs ou no guia de estilo de ícones da barra de status/sistema, embora eles POSSAM oferecer uma experiência do usuário alternativa para notificações diferente da fornecida pela implementação de referência do Android Open Source.
[C-1-3] É PRECISO honrar e implementar corretamente os comportamentos descritos para as APIs atualizar, remover e agrupar notificações.
[C-1-4] É necessário fornecer o comportamento completo da API NotificationChannel documentada no SDK.
[C-1-5] É OBRIGATÓRIO fornecer uma capacidade de uso do usuário para bloquear e modificar uma determinada notificação de um app de terceiros por cada canal e nível de pacote de app.
[C-1-6] É necessário fornecer uma capacidade do usuário para mostrar canais de notificação excluídos.
[C-1-7] É PRECISO renderizar corretamente todos os recursos (imagens, adesivos, ícones etc.) fornecidos por Notification.MessagingStyle com o texto da notificação sem interação adicional do usuário. Por exemplo, é PRECISO mostrar todos os recursos, incluindo ícones fornecidos por android.app.Person em uma conversa em grupo definida por setGroupConversation.
[C-SR-1] É ALTAMENTE RECOMENDADO fornecer uma capacidade para que o usuário controle as notificações que são expostas a apps que receberam a permissão do Notification Listener. A granularidade precisa ser suficiente para que o usuário possa controlar, para cada listener de notificação, quais tipos de notificação são associados a esse listener. Os tipos precisam incluir "conversas", "alertas", "silenciosas" e "notificações contínuas importantes".
[C-SR-2] É ALTAMENTE RECOMENDADO oferecer uma capacidade para que os usuários especifiquem apps para excluir a notificação de qualquer listener de notificação específico.
[C-SR-3] É ALTAMENTE RECOMENDADO mostrar automaticamente uma capacidade do usuário para bloquear a notificação de um determinado app de terceiros por cada canal e nível de pacote de apps depois que o usuário dispensar essa notificação várias vezes.
DEVE oferecer suporte a notificações avançadas.
DEVE apresentar algumas notificações de prioridade mais alta como notificações de alerta.
DEVE ter uma capacidade do usuário de adiar notificações.
PODE gerenciar apenas a visibilidade e o momento em que os apps de terceiros podem notificar os usuários sobre eventos importantes para reduzir problemas de segurança, como distração do motorista.

O Android 11 oferece suporte a notificações de conversa, que são notificações que usam MessagingStyle e fornecem um ID de atalho Pessoas publicado.

Implementações de dispositivos:

[C-SR-4] É ALTAMENTE RECOMENDÁVEL agrupar e exibir conversation notifications antes das notificações que não são de conversa, com exceção das notificações de serviço em primeiro plano em andamento e das notificações importance:high.

Se as implementações do dispositivo oferecerem suporte a conversation notifications e o app fornecer os dados necessários para bubbles, eles:

[C-SR-5] É ALTAMENTE RECOMENDADO mostrar esta conversa como um balão. A implementação do AOSP atende a esses requisitos com a interface do sistema padrão, as configurações e o iniciador.

Se as implementações de dispositivos oferecerem suporte a notificações avançadas, elas:

[C-2-1] É OBRIGATÓRIO usar os recursos exatos conforme fornecidos pela classe de API Notification.Style e suas subclasses para os elementos de recurso apresentados.
DEVE apresentar todos os elementos de recurso (por exemplo, ícone, título e texto de resumo) definidos na classe da API Notification.Style e nas subclasses dela.

As notificações de alerta são apresentadas ao usuário conforme chegam, independentemente da plataforma em que ele está. Se as implementações do dispositivo oferecerem suporte a notificações de alerta, elas:

[C-3-1] É OBRIGATÓRIO usar a visualização e os recursos de notificação de alerta conforme descrito na classe de API Notification.Builder quando as notificações de alerta são apresentadas.
[C-3-2] É OBRIGATÓRIO mostrar as ações fornecidas pelo Notification.Builder.addAction() com o conteúdo da notificação sem interação adicional do usuário, conforme descrito no SDK.

3.8.3.2. Serviço de listener de notificações

O Android inclui as APIs NotificationListenerService que permitem que os apps (uma vez ativados explicitamente pelo usuário) recebam uma cópia de todas as notificações à medida que são publicadas ou atualizadas.

Implementações de dispositivos:

[C-0-1] É PRECISO atualizar as notificações de forma correta e imediata em todos os serviços de listener instalados e ativados pelo usuário, incluindo todos os metadados anexados ao objeto Notification.
[C-0-2] É OBRIGATÓRIO respeitar a chamada de API snoozeNotification(), dispensar a notificação e fazer um callback após a duração de suspensão definida na chamada de API.

Se as implementações de dispositivos tiverem uma capacidade do usuário de adiar notificações, elas:

[C-1-1] É NECESSÁRIO refletir o status da notificação adiada corretamente usando as APIs padrão, como NotificationListenerService.getSnoozedNotifications().
[C-1-2] É OBRIGATÓRIO disponibilizar essa capacidade do usuário para adiar notificações de cada app de terceiros instalado, a menos que sejam de serviços persistentes/em primeiro plano.

3.8.3.3. Modo "Não perturbe" / Modo de prioridade

Se as implementações do dispositivo oferecerem suporte ao recurso Não perturbe (também chamado de modo de prioridade), elas:

[C-1-1] É OBRIGATÓRIO, quando a implementação do dispositivo forneceu uma forma para o usuário conceder ou negar o acesso de apps de terceiros à configuração da política de DND, mostrar as regras automáticas de DND criadas por aplicativos, além das regras criadas pelo usuário e predefinidas.
[C-1-3] É OBRIGATÓRIO honrar os valores suppressedVisualEffects transmitidos pelo NotificationManager.Policy. Se um app tiver definido qualquer uma das flags SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, ele PRECISA indicar ao usuário que os efeitos visuais foram suprimidos no menu de configurações do DND.

Início dos novos requisitos para o Android 15

3.8.3.4. Proteção de notificações sensíveis

Informações sensíveis de notificação incluem conteúdo como senhas únicas, códigos de confirmação únicos e códigos de redefinição ou autenticação semelhantes que podem aparecer em notificações para os usuários.

Se as implementações de dispositivos permitirem que apps de terceiros notifiquem os usuários sobre eventos importantes, eles:

[C-1-1] É PRECISO impedir que informações sensíveis de notificação sejam transmitidas para listeners de notificação, a menos que o serviço de listener seja um dos seguintes:
- Apps assinados pelo sistema com uid < 10000
- IU do sistema
- Concha
- App complementar de dispositivo designado (definido por CompanionDeviceManager)
- Papel SYSTEM_AUTOMOTIVE_PROJECTION
- Papel SYSTEM_NOTIFICATION_INTELLIGENCE
- Papel HOME

A implementação do AOSP de NotificationAssistantServices exemplifica e atende a esses requisitos. Confira android.ext.services.notification para conferir um exemplo.

Fim dos novos requisitos

3.8.4. APIs Assist

O Android inclui as APIs Assist para permitir que os aplicativos escolham quantas informações do contexto atual são compartilhadas com o assistente no dispositivo.

Se as implementações do dispositivo oferecerem suporte à ação de assistência, elas:

[C-2-1] É PRECISO indicar claramente ao usuário final quando o contexto é compartilhado, fazendo o seguinte:
- Sempre que o app de assistência acessar o contexto, uma luz branca vai aparecer ao redor das bordas da tela, que vai atender ou exceder a duração e o brilho da implementação do Projeto Android Open Source.
- Para o app de assistência pré-instalado, forneça uma capacidade do usuário a menos de duas navegações de distância da entrada de voz padrão e do menu de configurações do app de assistência, e compartilhe o contexto somente quando o app de assistência for invocado explicitamente pelo usuário por meio de uma palavra de ativação ou entrada de tecla de navegação de assistência.
[C-2-2] A interação designada para iniciar o app de assistência, conforme descrito na seção 7.2.3, PRECISA iniciar o app de assistência selecionado pelo usuário, ou seja, o app que implementa VoiceInteractionService, ou uma atividade que processa a intent ACTION_ASSIST.

3.8.5. Alertas e avisos

Os aplicativos podem usar a API Toast para mostrar strings não modais curtas ao usuário final que desaparecem após um curto período de tempo e usar a API de tipo de janela TYPE_APPLICATION_OVERLAY para mostrar janelas de alerta como uma sobreposição em outros apps.

Se as implementações do dispositivo incluem uma saída de tela ou vídeo, elas:

[C-1-1] É OBRIGATÓRIO fornecer uma característica para o usuário bloquear um app de exibir janelas de alerta que usam o TYPE_APPLICATION_OVERLAY. A implementação do AOSP atende a esse requisito com controles na sombra de notificação.
[C-1-2] É OBRIGATÓRIO honrar a API Toast e exibir notificações do aplicativo para os usuários finais de maneira muito visível.

3.8.6. Temas

O Android oferece "temas" como um mecanismo para que os aplicativos apliquem estilos em toda uma atividade ou aplicativo.

O Android inclui uma família de temas "Holo" e "Material" como um conjunto de estilos definidos para que os desenvolvedores de aplicativos os usem se quiserem corresponder à aparência e a sensação do tema Holo conforme definido pelo SDK do Android.

Se as implementações do dispositivo incluem uma saída de tela ou vídeo, elas:

[C-1-1] NENHUM dos atributos do tema Holo expostos aos aplicativos PODE SER ALTERADO.
[C-1-2] PRECISA oferecer suporte à família de temas "Material" e NÃO pode alterar nenhum dos atributos do tema do Material Design ou os recursos expostos aos aplicativos.
[C-1-3] É OBRIGATÓRIO definir a família de fontes "sans-serif" como Roboto versão 2.x para os idiomas com suporte a Roboto ou fornecer uma característica para o usuário mudar a fonte usada para a família de fontes "sans-serif" como Roboto versão 2.x para os idiomas com suporte a Roboto.
[C-1-4] É OBRIGATÓRIO gerar paletas de tons de cores dinâmicas, conforme especificado na documentação do AOSP de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.system_palette e android.theme.customization.theme_style).
[C-1-5] É NECESSÁRIO gerar paletas de tons de cores dinâmicas usando estilos de tema de cores enumerados na documentação Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.theme_styles), ou seja, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD e MONOCHROMATIC.

"Cor de origem" usada para gerar paletas de tons de cores dinâmicas quando enviada com android.theme.customization.system_palette (como documentado em Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).
[C-1-6] É PRECISO ter um valor de croma CAM16 de 5 ou maior.
- DEVEM ser derivados do plano de fundo por meio de com.android.systemui.monet.ColorScheme#getSeedColors, que fornece várias cores de origem válidas para escolher uma.
- DEVE usar o valor 0xFF1B6EF3 se nenhuma das cores fornecidas atender ao requisito de cor de origem acima.

O Android também inclui uma família de temas "Padrão do dispositivo" como um conjunto de estilos definidos para que os desenvolvedores de aplicativos os usem se quiserem combinar a aparência do tema do dispositivo conforme definido pelo implementador do dispositivo.

As implementações de dispositivos PODEM modificar os atributos de tema padrão do dispositivo expostos aos apps.

O Android oferece suporte a um tema variante com barras do sistema translúcidas, o que permite que os desenvolvedores de aplicativos preencham a área atrás da barra de status e navegação com o conteúdo do app. Para oferecer uma experiência consistente aos desenvolvedores nessa configuração, é importante manter o estilo do ícone da barra de status em diferentes implementações de dispositivo.

Se as implementações do dispositivo incluírem uma barra de status do sistema, elas:

[C-2-1] É OBRIGATÓRIO usar a cor branca para ícones de status do sistema (como intensidade do sinal e nível da bateria) e notificações emitidas pelo sistema, a menos que o ícone esteja indicando um status problemático ou um app solicite uma barra de status clara usando a flag WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
[C-2-2] As implementações de dispositivos Android precisam mudar a cor dos ícones de status do sistema para preto (para mais detalhes, consulte R.style) quando um app solicita uma barra de status clara.

3.8.7. Planos fundo interativos

O Android define um tipo de componente e a API e o ciclo de vida correspondentes que permitem que os apps exponham um ou mais "Wallpapers animados" ao usuário final. Planos de fundo interativos são animações, padrões ou imagens semelhantes com recursos de entrada limitados que aparecem como um plano de fundo, atrás de outros aplicativos.

O hardware é considerado capaz de executar planos de fundo interativos de forma confiável se puder executar todos os planos de fundo interativos, sem limitações de funcionalidade, a uma taxa de frames razoável, sem efeitos adversos em outros aplicativos. Se as limitações no hardware causarem falhas em planos de fundo e/ou aplicativos, mal funcionamento, consumo excessivo de CPU ou bateria ou execução com taxas de frames inaceitáveis, o hardware será considerado incapaz de executar o plano de fundo em tempo real. Por exemplo, alguns planos de fundo animados podem usar um contexto OpenGL 2.0 ou 3.x para renderizar o conteúdo. O papel de parede animado não será executado de forma confiável em hardware que não oferece suporte a vários contextos OpenGL, porque o uso de um contexto OpenGL pelo papel de parede animado pode entrar em conflito com outros aplicativos que também usam um contexto OpenGL.

As implementações de dispositivos capazes de executar planos de fundo interativos de maneira confiável, conforme descrito acima, DEVEM implementar planos de fundo interativos.

Se as implementações de dispositivos implementarem planos de fundo interativos, elas:

[C-1-1] É PRECISO informar a flag de recurso da plataforma android.software.live_wallpaper.

3.8.8. Troca de atividades

O código-fonte upstream do Android inclui a tela de visão geral, uma interface do usuário no nível do sistema para alternar tarefas e mostrar atividades e tarefas acessadas recentemente usando uma imagem em miniatura do estado gráfico do aplicativo no momento em que o usuário saiu dele pela última vez.

As implementações de dispositivos, incluindo a tecla de navegação de funções recentes, conforme detalhado na seção 7.2.3, PODEM alterar a interface.

Se as implementações do dispositivo, incluindo a tecla de navegação de função recente, conforme detalhado na seção 7.2.3, alterarem a interface, elas:

[C-1-1] É PRECISO oferecer suporte a pelo menos sete atividades exibidas.
DEVE mostrar pelo menos o título de quatro atividades por vez.
DEVE mostrar a cor de destaque, o ícone e o título da tela em "Recentes".
DEVE mostrar um recurso de fechamento ("x"), mas PODE atrasar isso até que o usuário interaja com as telas.
DEVE implementar um atalho para alternar facilmente para a atividade anterior.
DEVE acionar a ação de troca rápida entre os dois apps mais usados recentemente, quando a tecla de função de apps recentes for tocada duas vezes.
DEVE acionar o modo de várias janelas de tela dividida, se houver suporte, quando a chave de funções recentes for pressionada por muito tempo.
PODE exibir afiliadas recentes como um grupo que se move junto.
[C-SR-1] É ALTAMENTE RECOMENDADO usar a interface do usuário do Android upstream (ou uma interface semelhante baseada em miniaturas) para a tela de visão geral.

3.8.9. Gerenciamento de entrada

O Android inclui suporte para gerenciamento de entrada e para editores de método de entrada de terceiros.

Se as implementações de dispositivo permitirem que os usuários usem métodos de entrada de terceiros no dispositivo, eles:

[C-1-1] É OBRIGATÓRIO declarar o recurso da plataforma android.software.input_methods e oferecer suporte a APIs IME, conforme definido na documentação do SDK do Android.

3.8.10. Controle de mídia na tela de bloqueio

A API de cliente de controle remoto foi descontinuada no Android 5.0 em favor do modelo de notificação de mídia, que permite que aplicativos de mídia sejam integrados aos controles de reprodução exibidos na tela de bloqueio.

3.8.11. Protetores de tela (antes chamados de Sonhos)

Consulte a seção 3.2.3.5 para saber como configurar a intent de configurações para definir protetores de tela.

3.8.12. Local

Se as implementações do dispositivo incluírem um sensor de hardware (por exemplo, GPS) capaz de fornecer as coordenadas de localização, elas

[C-1-2] É PRECISO mostrar o status atual do local no menu "Local" em "Configurações".
[C-1-3] Modos de local não podem ser mostrados no menu "Local" das Configurações.

3.8.13. Unicode e fonte

O Android inclui suporte aos caracteres emoji definidos no Unicode 10.0.

Se as implementações do dispositivo incluem uma saída de tela ou vídeo, elas:

[C-1-1] É PRECISO renderizar esses caracteres emoji em glifos coloridos.
[C-1-2] É PRECISO incluir suporte para:
- Fonte Roboto 2 com pesos diferentes: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light para os idiomas disponíveis no dispositivo.
- Cobertura completa do Unicode 7.0 para latim, grego e cirílico, incluindo os intervalos latino estendido A, B, C e D e todos os glifos no bloco de símbolos de moeda do Unicode 7.0.
[C-1-3] NÃO é permitido remover ou modificar o NotoColorEmoji.tff na imagem do sistema. É aceitável adicionar uma nova fonte de emoji para substituir o emoji em NotoColorEmoji.tff.
PRECISA oferecer suporte a tons de pele e emojis de famílias diversas, conforme especificado no Relatório técnico do Unicode 51.

Se as implementações do dispositivo incluírem um IME, elas:

DEVE fornecer um método de entrada para esses caracteres de emoji ao usuário.

O Android inclui suporte para renderizar fontes de Myanmar. Mianmar tem várias fontes que não são compatíveis com Unicode, comumente conhecidas como "Zawgyi", para renderizar línguas de Mianmar.

Se as implementações de dispositivos incluem suporte ao birmanês, elas:

[C-2-1] É NECESSÁRIO renderizar texto com uma fonte compatível com Unicode por padrão. Uma fonte que não seja compatível com Unicode NÃO PODE ser definida como padrão, a menos que o usuário a escolha no seletor de idioma.
[C-2-2] É PRECISO oferecer suporte a uma fonte Unicode e a uma fonte que não seja compatível com Unicode, se o dispositivo oferecer suporte a uma fonte que não seja compatível com Unicode. A fonte que não é compatível com Unicode NÃO PODE remover ou substituir a fonte Unicode.
[C-2-3] É NECESSÁRIO renderizar texto com uma fonte que não seja compatível com Unicode SOMENTE SE um código de idioma com código de script Qaag for especificado (por exemplo, my-Qaag). Nenhum outro código de idioma ou região ISO (atribuído, não atribuído ou reservado) pode ser usado para se referir a uma fonte não Unicode compatível com o Mianmar. Os desenvolvedores de apps e autores de páginas da Web podem especificar my-Qaag como o código de idioma designado, como fariam para qualquer outro idioma.

3.8.14. Várias janelas

Se as implementações de dispositivo tiverem a capacidade de mostrar várias atividades ao mesmo tempo, elas:

[C-1-1] É OBRIGATÓRIO implementar esses modos de várias janelas de acordo com os comportamentos do aplicativo e as APIs descritas na documentação de suporte ao modo de várias janelas do SDK do Android e atender aos seguintes requisitos:
[C-1-2] É PRECISO honrar o android:resizeableActivity definido por um app no arquivo AndroidManifest.xml, conforme descrito no SDK.
[C-1-3] NÃO é permitido oferecer o modo de tela dividida ou de forma livre se a altura da tela for menor que 440 dp e a largura da tela for menor que 440 dp.
[C-1-4] Uma atividade NÃO PODE ser redimensionada para um tamanho menor que 220 dp em modos de várias janelas, exceto picture-in-picture.
As implementações de dispositivos com tamanho de tela xlarge DEVEM oferecer suporte ao modo de forma livre.

Se as implementações do dispositivo oferecerem suporte a modos de várias janelas e ao modo de tela dividida, elas:

[C-2-2] É PRECISO cortar a atividade acoplada de uma janela múltipla de tela dividida, mas DEVE mostrar algum conteúdo dela, se o app de inicialização for a janela em foco.
[C-2-3] É OBRIGATÓRIO honrar os valores declarados de AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight do aplicativo de inicialização de terceiros e não substituir esses valores ao mostrar algum conteúdo da atividade acoplada.

Se as implementações do dispositivo oferecerem suporte a modos de várias janelas e ao modo de várias janelas picture-in-picture, elas:

[C-3-1] É OBRIGATÓRIO iniciar atividades no modo picture-in-picture em várias janelas quando o app: * Segmenta o nível 26 da API ou mais recente e declara android:supportsPictureInPicture * Segmenta o nível 25 da API ou versões anteriores e declara android:resizeableActivity e android:supportsPictureInPicture.
[C-3-2] É OBRIGATÓRIO expor as ações no SystemUI conforme especificado pela atividade PIP atual pela API setActions().
[C-3-3] É PRECISO oferecer suporte a proporções maiores ou iguais a 1:2,39 e menores ou iguais a 2,39:1, conforme especificado pela atividade PIP pela API setAspectRatio().
[C-3-4] É OBRIGATÓRIO usar KeyEvent.KEYCODE_WINDOW para controlar a janela PIP. Se o modo PIP não for implementado, a chave PRECISA estar disponível para a atividade em primeiro plano.
[C-3-5] É necessário fornecer uma affordance do usuário para impedir que um app seja exibido no modo PIP. A implementação do AOSP atende a esse requisito com controles na sombra de notificação.
[C-3-6] É NECESSÁRIO alocar a seguinte largura e altura mínima para a janela PIP quando um aplicativo não declarar nenhum valor para AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight:
- Dispositivos com o Configuration.uiMode definido como diferente de UI_MODE_TYPE_TELEVISION PRECISAM alocar uma largura e altura mínimas de 108 dp.
- Dispositivos com o Configuration.uiMode definido como UI_MODE_TYPE_TELEVISION PRECISAM alocar uma largura mínima de 240 dp e uma altura mínima de 135 dp.

Início dos novos requisitos para o Android 15

Se as implementações de dispositivos incluírem mais de uma área de exibição compatível com o Android e disponibilizarem essas áreas para apps, elas:

[C-4-1] É PRECISO oferecer suporte ao modo de várias janelas.

Se as implementações de dispositivos oferecerem suporte a modos de várias janelas, elas:

[C-5-1] É PRECISO implementar a versão correta do nível da API das extensões do gerenciador de janelas, conforme descrito em Extensões WindowManager.

Fim dos novos requisitos

3.8.15. Corte de tela

O Android oferece suporte a um recorte de tela, conforme descrito no documento do SDK. A API DisplayCutout define uma área na borda da tela que pode não ser funcional para um aplicativo devido a um corte ou uma tela curva na borda.

Se as implementações do dispositivo incluírem recortes na tela, elas:

[C-1-5] NÃO PODE haver recortes se a proporção do dispositivo for 1,0 (1:1).
[C-1-2] NÃO pode ter mais de um corte por borda.
[C-1-3] É OBRIGATÓRIO respeitar as flags de recorte de exibição definidas pelo app pela API WindowManager.LayoutParams, conforme descrito no SDK.
[C-1-4] É PRECISO informar os valores corretos para todas as métricas de recorte definidas na API DisplayCutout.

3.8.16. Controles do dispositivo

O Android inclui as APIs ControlsProviderService e Control para permitir que apps de terceiros publiquem controles de dispositivo para status e ações rápidas dos usuários.

Consulte a seção 2_2_3 para conferir os requisitos específicos do dispositivo.

3.8.17. Área de transferência

Implementações de dispositivos:

[C-0-1] NÃO PODE enviar dados da área de transferência para nenhum componente, atividade, serviço ou em qualquer conexão de rede, sem uma ação explícita do usuário (por exemplo, pressionar um botão na sobreposição) ou uma indicação de que o conteúdo está sendo enviado, exceto para os serviços mencionados em 9.8.6 Captura de conteúdo e pesquisa de apps.

Se as implementações do dispositivo gerarem uma visualização visível para o usuário quando o conteúdo for copiado para a área de transferência em qualquer item ClipData em que ClipData.getDescription().getExtras() contenha android.content.extra.IS_SENSITIVE, elas:

[C-1-1] É OBRIGATÓRIO redigir a visualização visível para o usuário

A implementação de referência do AOSP atende a esses requisitos da área de transferência.

3.9. Administração do dispositivo

Início dos novos requisitos para o Android 15

O Android inclui recursos que ~~permitem a segurança~~ ativar aplicativos de controle de política de dispositivo para realizar funções de administração de dispositivos no nível do sistema, como aplicar políticas de senha ou realizar a exclusão remota, usando a ~~API Android Device Administration~~ APIs Device Policy Manager.

Se as implementações de dispositivo implementarem a gama completa de políticas de administração de dispositivo definidas na documentação do SDK do Android, elas:

[C-1-1] É OBRIGATÓRIO declarar android.software.device_admin.

[C-1-2] É PRECISO oferecer suporte ao provisionamento de proprietários de dispositivos, conforme descrito na seção 3.9.1 e seção 3.9.1.1.

Fim dos novos requisitos

3.9.1. Provisionamento de dispositivo

3.9.1.1. Provisionamento de proprietário do dispositivo

Se as implementações do dispositivo declararem android.software.device_admin, elas:

[C-1-1] É PRECISO oferecer suporte à inscrição de um cliente de política de dispositivo (DPC, na sigla em inglês) como um app de proprietário do dispositivo conforme descrito abaixo:
- Quando a implementação do dispositivo não tem nem usuários nem dados do usuário configurados, ela:
  - [C-1-5] É PRECISO registrar o aplicativo DPC como o app proprietário do dispositivo ou permitir que o app DPC escolha se ele vai se tornar um proprietário do dispositivo ou do perfil, se o dispositivo declarar suporte à comunicação de campo próximo (NFC) usando a flag de recurso android.hardware.nfc e receber uma mensagem NFC que contenha um registro com o tipo MIME MIME_TYPE_PROVISIONING_NFC.
  - [C-1-8] É PRECISO enviar a intent ACTION_GET_PROVISIONING_MODE depois que o provisionamento do proprietário do dispositivo for acionado para que o app DPC possa escolher se vai se tornar um proprietário do dispositivo ou do perfil, dependendo dos valores de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, a menos que seja possível determinar pelo contexto que há apenas uma opção válida.
  - [C-1-9] É OBRIGATÓRIO enviar a intent ACTION_ADMIN_POLICY_COMPLIANCE para o app proprietário do dispositivo se um proprietário do dispositivo for estabelecido durante o provisionamento, independentemente do método de provisionamento usado. O usuário não pode prosseguir no assistente de configuração até que o app de proprietário do dispositivo seja concluído.
- Quando a implementação do dispositivo tem usuários ou dados do usuário, ela:
  - [C-1-7] Não é mais permitido registrar nenhum aplicativo DPC como o app proprietário do dispositivo.

Início dos novos requisitos para o Android 15

[C-1-2] É OBRIGATÓRIO mostrar um aviso de divulgação adequado (conforme referenciado no AOSP) e receber o consentimento afirmativo do usuário final antes que um app seja definido como proprietário do dispositivo, a menos que o dispositivo seja configurado programaticamente para o Modo de demonstração de varejo antes da interação do usuário final na tela. Se as implementações do dispositivo declararem android.software.device_admin, mas também incluírem uma solução de gerenciamento de dispositivo proprietária e fornecerem um mecanismo para promover um aplicativo configurado na solução como um "equivalente ao proprietário do dispositivo" ao "proprietário do dispositivo" padrão, conforme reconhecido pelas APIs DevicePolicyManager padrão do Android, elas:

[C-2-1] É PRECISO ter um processo em vigor para verificar se o app específico que está sendo promovido pertence a uma solução legítima de gerenciamento de dispositivos corporativos e foi configurado na solução proprietária para ter direitos equivalentes como "proprietário do dispositivo".

[C-2-2] É PRECISO mostrar a mesma declaração de consentimento do proprietário do dispositivo do AOSP que o fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o aplicativo DPC como "proprietário do dispositivo".

[C-2-3] O consentimento não pode ser codificado rigidamente nem impedir o uso de outros apps de proprietário do dispositivo.

Fim dos novos requisitos

3.9.1.2. Provisionamento de perfil gerenciado

Se as implementações do dispositivo declararem android.software.managed_users, elas:

[C-1-1] É PRECISO implementar as APIs que permitem que um aplicativo de controlador de políticas de dispositivo (DPC) se torne o proprietário de um novo perfil gerenciado.

Início dos novos requisitos para o Android 15

[C-1-2] O processo de provisionamento de perfil gerenciado (o fluxo iniciado pelo DPC usando o android.app.action.PROVISION_MANAGED_PROFILE) ou pela plataforma), a tela de consentimento e a experiência do usuário precisam estar alinhadas com a implementação do AOSP.

Fim dos novos requisitos

[C-1-3] É OBRIGATÓRIO fornecer as seguintes características de usuário nas Configurações para indicar ao usuário quando uma função específica do sistema foi desativada pelo Controlador de política de dispositivo (DPC):
- Um ícone consistente ou outra característica de uso (por exemplo, o ícone de informações do AOSP upstream) para representar quando uma configuração específica é restrita por um administrador de dispositivos.
- Uma mensagem de explicação curta, fornecida pelo administrador do dispositivo pelo setShortSupportMessage.
- O ícone do aplicativo DPC.
[C-1-4] É OBRIGATÓRIO iniciar o gerenciador da intent ACTION_PROVISIONING_SUCCESSFUL no perfil de trabalho se um proprietário de perfil for estabelecido quando o provisionamento for iniciado pela intent android.app.action.PROVISION_MANAGED_PROFILE e o DPC tiver implementado o gerenciador.
[C-1-5] É PRECISO enviar a transmissão ACTION_PROFILE_PROVISIONING_COMPLETE para o DPC do perfil de trabalho quando o provisionamento for iniciado pela intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] É PRECISO enviar a intent ACTION_GET_PROVISIONING_MODE depois que o provisionamento do proprietário do perfil for acionado para que o app DPC possa escolher se quer se tornar um proprietário do dispositivo ou do perfil, exceto quando o provisionamento for acionado pela intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] É PRECISO enviar a intent ACTION_ADMIN_POLICY_COMPLIANCE para o perfil de trabalho quando um proprietário de perfil é estabelecido durante o provisionamento, independentemente do método de provisionamento usado, exceto quando o provisionamento é acionado pela intent android.app.action.PROVISION_MANAGED_PROFILE. O usuário não pode prosseguir no assistente de configuração até que o app de proprietário de perfil seja concluído.
[C-1-8] É PRECISO enviar a transmissão ACTION_MANAGED_PROFILE_PROVISIONED para o DPC do perfil pessoal quando um proprietário de perfil for estabelecido, independentemente do método de provisionamento usado.

3.9.2. Suporte a perfis gerenciados

Se as implementações do dispositivo declararem android.software.managed_users, elas:

[C-1-1] É PRECISO oferecer suporte a perfis gerenciados pelas APIs android.app.admin.DevicePolicyManager.
[C-1-2] É PRECISO permitir que apenas um perfil gerenciado seja criado.
[C-1-3] É OBRIGATÓRIO usar um selo de ícone (semelhante ao selo de trabalho upstream do AOSP) para representar os aplicativos e widgets gerenciados e outros elementos de interface com selo, como "Recentes" e "Notificações".
[C-1-4] É OBRIGATÓRIO mostrar um ícone de notificação (semelhante ao selo de trabalho upstream do AOSP) para indicar quando o usuário está em um aplicativo de perfil gerenciado.
[C-1-5] É PRECISO mostrar um aviso indicando que o usuário está no perfil gerenciado se e quando o dispositivo for ativado (ACTION_USER_PRESENT) e o aplicativo em primeiro plano estiver no perfil gerenciado.
[C-1-6] Quando um perfil gerenciado existir, ele PRECISA mostrar uma característica visual no seletor de intent para permitir que o usuário encaminhe a intent do perfil gerenciado para o usuário principal ou vice-versa, se ativado pelo Device Policy Controller.
[C-1-7] Quando um perfil gerenciado existe, ele PRECISA expor os seguintes recursos do usuário para o usuário principal e o perfil gerenciado:
- Contabilização separada para bateria, local, dados móveis e uso de armazenamento do usuário principal e do perfil gerenciado.
- Gerenciamento independente de aplicativos de VPN instalados no perfil principal ou gerenciado do usuário.
- Gerenciamento independente de aplicativos instalados no perfil gerenciado ou do usuário principal.
- Gerenciamento independente de contas no perfil do usuário principal ou gerenciado.
[C-1-8] É OBRIGATÓRIO garantir que os apps de discagem, contatos e mensagens pré-instalados possam pesquisar e consultar as informações de identificação do autor da chamada do perfil gerenciado (se houver) junto com as do perfil principal, se o Device Policy Controller permitir.
[C-1-9] É PRECISO garantir que ele atenda a todos os requisitos de segurança aplicáveis a um dispositivo com vários usuários ativados (consulte a seção 9.5), mesmo que o perfil gerenciado não seja contado como outro usuário além do principal.
[C-1-10] É PRECISO garantir que os dados da captura de tela sejam salvos no armazenamento do perfil de trabalho quando uma captura de tela for feita com uma janela topActivity que tenha foco (a que o usuário interagiu por último entre todas as atividades) e pertence a um app de perfil de trabalho.
[C-1-11] NÃO É PERMITIDO capturar nenhum outro conteúdo da tela (barra de sistema, notificações ou qualquer conteúdo do perfil pessoal), exceto a janela/janelas do aplicativo do perfil de trabalho ao salvar uma captura de tela no perfil de trabalho para garantir que os dados do perfil pessoal não sejam salvos no perfil de trabalho.

Se as implementações do dispositivo declararem android.software.managed_users e android.software.secure_lock_screen, elas:

[C-2-1] PRECISA oferecer suporte à capacidade de especificar uma tela de bloqueio separada que atenda aos requisitos a seguir para conceder acesso apenas a apps executados em um perfil gerenciado.
- As implementações de dispositivo precisam honrar a intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrar uma interface para configurar uma credencial de tela de bloqueio separada para o perfil gerenciado.
- As credenciais da tela de bloqueio do perfil gerenciado PRECISAM usar os mesmos mecanismos de armazenamento e gerenciamento de credenciais do perfil pai, conforme documentado no site do projeto de código aberto do Android.
- As políticas de senha do DPC precisam ser aplicadas apenas às credenciais da tela de bloqueio do perfil gerenciado, a menos que sejam chamadas na instância DevicePolicyManager retornada por getParentProfileInstance.
Quando os contatos do perfil gerenciado são mostrados no registro de chamadas pré-instalado, na IU de chamada, nas notificações de chamadas em andamento e perdidas, nos apps de contatos e mensagens, eles DEVEM ter o mesmo selo usado para indicar aplicativos de perfil gerenciado.

3.9.3. Suporte para usuários gerenciados

Se as implementações do dispositivo declararem android.software.managed_users, elas:

[C-1-1] É PRECISO fornecer uma capacidade para o usuário sair da sessão do usuário atual e voltar para o usuário principal em uma sessão de vários usuários quando isLogoutEnabled retornar true. A affordance do usuário PRECISA ser acessível na tela de bloqueio sem desbloquear o dispositivo.

Se as implementações do dispositivo declararem android.software.device_admin e fornecerem uma affordance do usuário no dispositivo para adicionar mais usuários secundários, elas:

[C-SR-1] É ALTAMENTE RECOMENDADO mostrar as mesmas divulgações de consentimento do proprietário do dispositivo AOSP que foram mostradas no fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE, antes de permitir que as contas sejam adicionadas ao novo usuário secundário, para que os usuários entendam que o dispositivo é gerenciado.

3.9.4. Requisitos da função de gerenciamento de políticas de dispositivos

Se as implementações do dispositivo informarem android.software.device_admin ou android.software.managed_users, elas:

[C-1-1] PRECISA oferecer suporte à função de gerenciamento de políticas de dispositivos, conforme definido na seção 9.1. O aplicativo que tem o papel de gerenciamento de políticas do dispositivo pode ser definido definindo config_devicePolicyManagement como o nome do pacote. O nome do pacote PRECISA ser seguido por : e o certificado de assinatura, a menos que o aplicativo seja pré-carregado.

Se um nome de pacote não for definido para config_devicePolicyManagement, conforme descrito acima:

[C-2-1] As implementações de dispositivo precisam oferecer suporte ao provisionamento sem um aplicativo de detentor de função de gerenciamento de política de dispositivo (o AOSP oferece uma implementação de referência).

Se um nome de pacote for definido para config_devicePolicyManagement, conforme descrito acima:

[C-3-1] O aplicativo PRECISA ser instalado em todos os perfis de um usuário.
[C-3-2] As implementações de dispositivos PODEM definir um aplicativo que atualiza o titular do papel de gerenciamento de políticas de dispositivos antes do provisionamento, definindo config_devicePolicyManagementUpdater.

Se um nome de pacote for definido para config_devicePolicyManagementUpdater, conforme descrito acima:

[C-4-1] O aplicativo PRECISA estar pré-instalado no dispositivo.
[C-4-2] O aplicativo PRECISA implementar um filtro de intent que resolva android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

3.9.5. Framework da resolução de políticas do dispositivo

Se as implementações do dispositivo informarem android.software.device_admin ou android.software.managed_users, elas:

[C-1-1] É OBRIGATÓRIO resolver conflitos de políticas do dispositivo, conforme documentado no Framework da resolução de políticas do dispositivo.

3.10. Acessibilidade

O Android oferece uma camada de acessibilidade que ajuda usuários com deficiência a navegar pelos dispositivos com mais facilidade. Além disso, o Android oferece APIs da plataforma que permitem que as implementações de serviços de acessibilidade recebam callbacks para eventos do usuário e do sistema e gerem mecanismos de feedback alternativos, como text-to-speech, feedback tátil e navegação por trackball/d-pad.

Se as implementações de dispositivos oferecem suporte a serviços de acessibilidade de terceiros, elas:

[C-1-1] É OBRIGATÓRIO fornecer uma implementação do framework de acessibilidade do Android, conforme descrito na documentação do SDK das APIs de acessibilidade.
[C-1-2] É NECESSÁRIO gerar eventos de acessibilidade e fornecer o AccessibilityEvent apropriado para todas as implementações AccessibilityService registradas, conforme documentado no SDK.
[C-1-4] É necessário fornecer uma capacidade do usuário para controlar serviços de acessibilidade que declaram o AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Para implementações de dispositivos com uma barra de navegação do sistema, É NECESSÁRIO permitir que o usuário tenha a opção de um botão na barra de navegação do sistema para controlar esses serviços.

Se as implementações do dispositivo incluírem serviços de acessibilidade pré-instalados, elas:

[C-2-1] É PRECISO implementar esses serviços de acessibilidade pré-instalados como apps Direct Boot Aware quando o armazenamento de dados for criptografado com criptografia baseada em arquivos (FBE).
DEVE fornecer um mecanismo no fluxo de configuração pronto para uso para que os usuários ativem serviços de acessibilidade relevantes, além de opções para ajustar o tamanho da fonte, o tamanho da tela e os gestos de ampliação.

3.11. Conversão de texto em voz

O Android inclui APIs que permitem que os aplicativos usem serviços de conversão de texto em fala (TTS) e que os provedores de serviços forneçam implementações de serviços TTS.

Se as implementações do dispositivo informarem o recurso android.hardware.audio.output, elas:

[C-1-1] É PRECISO oferecer suporte às APIs do framework TTS do Android.

Se as implementações de dispositivos oferecerem suporte à instalação de mecanismos de TTS de terceiros, elas:

[C-2-1] É PRECISO fornecer ao usuário a capacidade de selecionar um mecanismo de TTS para uso no nível do sistema.

Início dos novos requisitos para o Android 15

3.12. TV Input Framework

O Android TV Input Framework (TIF) simplifica o envio de conteúdo ao vivo para dispositivos Android TV. O TIF oferece uma API padrão para criar módulos de entrada que controlam dispositivos Android TV.

Se as implementações de dispositivos oferecem suporte a TIF, elas:

[C-1-1] É PRECISO declarar o recurso da plataforma android.software.live_tv.

[C-1-2] É PRECISO oferecer suporte a todas as APIs TIF para que um aplicativo que use essas APIs e o serviço de entradas de terceiros baseadas em TIF possa ser instalado e usado no dispositivo.

Fim dos novos requisitos

3.13. Configurações rápidas

O Android oferece um componente de interface de Configurações Rápidas que permite acesso rápido a ações usadas com frequência ou necessárias com urgência.

Se as implementações do dispositivo incluírem um componente de interface de configurações rápidas e oferecerem suporte a configurações rápidas de terceiros, elas:

[C-1-1] É PRECISO permitir que o usuário adicione ou remova os blocos fornecidos pelas APIs quicksettings de um app de terceiros.
[C-1-2] NÃO é permitido adicionar automaticamente um bloco de um app de terceiros diretamente às Configurações rápidas.
[C-1-3] É OBRIGATÓRIO mostrar todos os blocos adicionados pelo usuário de apps de terceiros com os blocos de configurações rápidas fornecidos pelo sistema.

3.14. Interface de mídia

Se as implementações do dispositivo incluírem aplicativos não ativados por voz (os apps) que interagem com aplicativos de terceiros por meio de MediaBrowser ou MediaSession, os apps:

[C-1-2] É PRECISO mostrar claramente os ícones recebidos por getIconBitmap() ou getIconUri() e os títulos recebidos por getTitle(), conforme descrito em MediaDescription. Pode encurtar títulos para obedecer a regulamentações de segurança (por exemplo, distração do motorista).
[C-1-3] É OBRIGATÓRIO mostrar o ícone do aplicativo de terceiros sempre que conteúdo fornecido por esse aplicativo for exibido.
[C-1-4] É OBRIGATÓRIO permitir que o usuário interaja com toda a hierarquia de MediaBrowser. PODE restringir o acesso a parte da hierarquia para obedecer a regulamentos de segurança (por exemplo, distração do motorista), mas NÃO PODE dar tratamento preferencial com base no conteúdo ou no provedor de conteúdo.
[C-1-5] É PRECISO considerar o toque duplo de KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent.

3.15. Instant Apps

Se as implementações do dispositivo oferecerem suporte a apps instantâneos, elas PRECISAM atender aos seguintes requisitos:

[C-1-1] Os apps instantâneos PRECISAM receber apenas permissões com o android:protectionLevel definido como "instant".
[C-1-2] Os apps instantâneos NÃO PODEM interagir com apps instalados por meio de intenções implícitas a menos que uma das seguintes condições seja verdadeira:
- O filtro de padrão de intent do componente é exposto e tem CATEGORY_BROWSABLE
- A ação é uma das seguintes: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE.
- O destino é exposto explicitamente com android:visibleToInstantApps
[C-1-3] Os apps instantâneos NÃO PODEM interagir explicitamente com apps instalados, a menos que o componente seja exposto por android:visibleToInstantApps.
[C-1-4] Os apps instalados NÃO PODEM ver detalhes sobre apps instantâneos no dispositivo, a menos que o app instantâneo se conecte explicitamente ao aplicativo instalado.
As implementações de dispositivos precisam fornecer as seguintes características para o usuário interagir com os apps instantâneos. O AOSP atende aos requisitos com a interface do sistema, as configurações e o iniciador padrão. Implementações de dispositivos:
- [C-1-5] É OBRIGATÓRIO fornecer uma ação do usuário para visualizar e excluir apps instantâneos armazenados em cache localmente para cada pacote de app individual.
- [C-1-6] É necessário fornecer uma notificação persistente do usuário que possa ser reduzida enquanto um app instantâneo está em execução em primeiro plano. Essa notificação precisa incluir que os apps instantâneos não exigem instalação e fornecer um affordance que direcione o usuário para a tela de informações do aplicativo nas Configurações. Para apps instantâneos iniciados por intents da Web, conforme definido usando uma intent com a ação definida como Intent.ACTION_VIEW e com um esquema de "http" ou "https", uma característica adicional do usuário DEVE permitir que o usuário não inicie o app instantâneo e abra o link associado com o navegador da Web configurado, se um navegador estiver disponível no dispositivo.
- [C-1-7] É PRECISO permitir que os apps instantâneos em execução sejam acessados pela função Recentes se ela estiver disponível no dispositivo.
[C-1-8] É OBRIGATÓRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para as intents listadas no SDK aqui e tornar as intents visíveis para apps instantâneos.

3.16. Pareamento de dispositivo complementar

O Android inclui suporte ao pareamento de dispositivos secundários para gerenciar de maneira mais eficaz a associação com dispositivos secundários e oferece a API CompanionDeviceManager para que os apps acessem esse recurso.

Se as implementações de dispositivo oferecerem suporte ao recurso de pareamento do dispositivo complementar, elas:

[C-1-1] É PRECISO declarar a flag de recurso FEATURE_COMPANION_DEVICE_SETUP .
[C-1-2] É OBRIGATÓRIO garantir que as APIs no pacote android.companion sejam totalmente implementadas.

Início dos novos requisitos para o Android 15

[C-1-3] É PRECISO fornecer recursos para o usuário selecionar/confirmar se um dispositivo complementar está presente e operacional, que PRECISA usar a mesma mensagem implementada no AOSP sem adição ou modificação.

Fim dos novos requisitos

3.17. Apps pesados

Se as implementações do dispositivo declararem o recurso FEATURE_CANT_SAVE_STATE, elas:

[C-1-1] É necessário ter apenas um app instalado que especifique cantSaveState em execução no sistema por vez. Se o usuário sair de um app sem sair dele explicitamente (por exemplo, pressionando a tela inicial enquanto sai de uma atividade ativa do sistema, em vez de pressionar "Voltar" sem atividades ativas restantes no sistema), as implementações do dispositivo precisam priorizar esse app na RAM, assim como fazem para outras coisas que devem permanecer em execução, como serviços em primeiro plano. Enquanto esse app estiver em segundo plano, o sistema ainda poderá aplicar recursos de gerenciamento de energia a ele, como limitar o acesso à CPU e à rede.
[C-1-2] É necessário fornecer uma capacidade da interface para escolher o app que não vai participar do mecanismo de salvar/restaurar o estado normal quando o usuário iniciar um segundo app declarado com o atributo cantSaveState.
[C-1-3] NÃO É PERMITIDO aplicar outras mudanças na política a apps que especificam cantSaveState, como alterar a performance da CPU ou a priorização da programação.

Se as implementações do dispositivo não declararem o recurso FEATURE_CANT_SAVE_STATE, elas:

[C-1-1] É OBRIGATÓRIO ignorar o atributo cantSaveState definido pelos apps e NÃO MUDAR o comportamento do app com base nesse atributo.

3.18. Contatos

O Android inclui APIs Contacts Provider para permitir que os aplicativos gerenciem as informações de contato armazenadas no dispositivo. Os dados de contato inseridos diretamente no dispositivo geralmente são sincronizados com um serviço da Web, mas os dados também podem residir localmente no dispositivo. Os contatos armazenados apenas no dispositivo são chamados de locais.

Os RawContacts são "associados a" ou "armazenados em" uma Conta quando as colunas ACCOUNT_NAME e ACCOUNT_TYPE dos contatos brutos correspondem aos campos Account.name e Account.type correspondentes da conta.

Conta local padrão: uma conta para contatos brutos que são armazenados apenas no dispositivo e não associados a uma conta no AccountManager, que são criados com valores null para as colunas ACCOUNT_NAME e ACCOUNT_TYPE.

Conta local personalizada: uma conta para contatos brutos que são armazenados apenas no dispositivo e não associados a uma conta no AccountManager, que são criadas com pelo menos um valor não nulo para as colunas ACCOUNT_NAME e ACCOUNT_TYPE.

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO não criar contas locais personalizadas.

Se as implementações do dispositivo usarem uma conta local personalizada:

[C-1-1] O ACCOUNT_NAME, da conta local personalizada, PRECISA ser retornado por ContactsContract.RawContacts.getLocalAccountName
[C-1-2] O ACCOUNT_TYPE, da conta local personalizada, PRECISA ser retornado por ContactsContract.RawContacts.getLocalAccountType.
[C-1-3] Contatos brutos inseridos por aplicativos de terceiros com a conta local padrão (ou seja, definindo valores nulos para ACCOUNT_NAME e ACCOUNT_TYPE) PRECISAM ser inseridos na conta local personalizada.
[C-1-4] Os contatos brutos inseridos na conta local personalizada não podem ser removidos quando as contas são adicionadas ou removidas.
[C-1-5] As operações de exclusão realizadas na conta local personalizada precisam resultar na eliminação imediata de contatos brutos, como se o parâmetro CALLER_IS_SYNCADAPTER fosse definido como verdadeiro, mesmo que o parâmetro CALLER\_IS\_SYNCADAPTER tenha sido definido como falso ou não especificado.

Início dos novos requisitos para o Android 15

3.19. Configurações de idioma

Implementações de dispositivos:

[C-0-1] NÃO é permitido fornecer ao usuário a possibilidade de selecionar tratamento de idioma específico de gênero para idiomas que não oferecem suporte a traduções específicas de gênero. Consulte Recursos gramaticais para mais informações.

Fim dos novos requisitos

4. Compatibilidade de empacotamento de apps

Implementações de dispositivos:

[C-0-1] PRECISA ser capaz de instalar e executar arquivos ".apk" do Android conforme gerados pela ferramenta "aapt" incluída no SDK oficial do Android.
- Como o requisito acima pode ser desafiador, é RECOMENDADO que as implementações de dispositivos usem o sistema de gerenciamento de pacotes da implementação de referência do AOSP.
[C-0-2] É obrigatório oferecer suporte à verificação de arquivos ".apk" usando o esquema de assinatura de APK v3.1, esquema de assinatura de APK v3, esquema de assinatura de APK v2 e assinatura JAR.
[C-0-3] NÃO É PERMITIDO estender os formatos .apk, Android Manifest, bytecode do Dalvik ou bytecode do RenderScript de forma que impeça a instalação e a execução correta desses arquivos em outros dispositivos compatíveis.
[C-0-4] NÃO É PERMITIDO que apps, exceto o "instalador de registro" atual do pacote, desinstalem o app silenciosamente sem nenhuma confirmação do usuário, conforme documentado no SDK para a permissão DELETE_PACKAGE. As únicas exceções são o app verificador de pacotes do sistema que processa a intent PACKAGE_NEEDS_VERIFICATION e o app gerenciador de armazenamento que processa a intent ACTION_MANAGE_STORAGE.
[C-0-5] PRECISA ter uma atividade que processe a intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] NÃO PODE instalar pacotes de aplicativos de origens desconhecidas, a menos que o app que solicita a instalação cumpra todos os requisitos a seguir:
- Ele PRECISA declarar a permissão REQUEST_INSTALL_PACKAGES ou ter o android:targetSdkVersion definido como 24 ou menos.
- O usuário precisa ter concedido permissão para instalar apps de fontes desconhecidas.
DEVE fornecer uma capacidade do usuário para conceder/revogar a permissão para instalar apps de fontes desconhecidas por aplicativo, mas PODE escolher implementar isso como uma operação nula e retornar RESULT_CANCELED para startActivityForResult(), se a implementação do dispositivo não quiser permitir que os usuários tenham essa escolha. No entanto, mesmo nesses casos, eles DEVEM indicar ao usuário por que essa opção não está sendo apresentada.
[C-0-7] É OBRIGATÓRIO mostrar uma caixa de diálogo de aviso com a string de aviso que é fornecida pelo PackageManager.setHarmfulAppWarning da API do sistema ao usuário antes de iniciar uma atividade em um aplicativo que foi marcado pela mesma API do sistema PackageManager.setHarmfulAppWarning como potencialmente prejudicial.
DEVE fornecer uma capacidade para o usuário escolher desinstalar ou iniciar um aplicativo na caixa de diálogo de aviso.
[C-0-8] É PRECISO implementar suporte para o sistema de arquivos incrementais, conforme documentado aqui.
[C-0-9] PRECISA oferecer suporte à verificação de arquivos .apk usando o Esquema de assinatura de APK v4 e o Esquema de assinatura de APK v4.1.

5. Compatibilidade com multimídia

Implementações de dispositivos:

[C-0-1] É PRECISO oferecer suporte aos formatos de mídia, codificadores, decodificadores, tipos de arquivo e formatos de contêiner definidos na seção 5.1 para todos os codecs declarados por MediaCodecList.
[C-0-2] É OBRIGATÓRIO declarar e informar o suporte dos codificadores e decodificadores disponíveis para aplicativos de terceiros por meio de MediaCodecList.
[C-0-3] PRECISA ser capaz de decodificar e disponibilizar corretamente para apps de terceiros todos os formatos que pode codificar. Isso inclui todos os bitstreams que os codificadores geram e os perfis informados no CamcorderProfile.

Implementações de dispositivos:

DEVE ter como objetivo a latência mínima do codec. Em outras palavras, eles
- NÃO deve consumir e armazenar buffers de entrada e retornar buffers de entrada apenas após o processamento.
- NÃO DEVE manter buffers decodificados por mais tempo do que o especificado pelo padrão (por exemplo, SPS).
- NÃO segure buffers codificados por mais tempo do que o necessário pela estrutura GOP.

Todos os codecs listados na seção abaixo são fornecidos como implementações de software na implementação preferida do Android do Android Open Source Project.

Nem o Google nem a Open Handset Alliance fazem qualquer representação de que esses codecs estão livres de patentes de terceiros. Aqueles que pretendem usar esse código-fonte em produtos de hardware ou software são informados de que as implementações desse código, incluindo em software de código aberto ou shareware, podem exigir licenças de patente dos detentores de patente relevantes.

5.1. Codecs de mídia

5.1.1. Codificação de áudio

Confira mais detalhes em 5.1.3. Detalhes dos codecs de áudio.

Se as implementações do dispositivo declararem android.hardware.microphone, elas PRECISAM oferecer suporte à codificação dos seguintes formatos de áudio e disponibilizá-los para apps de terceiros:

[C-1-1] PCM/WAVE
[C-1-2] FLAC
[C-1-3] Opus

Todos os codificadores de áudio precisam ter suporte a:

[C-3-1] Frames de áudio de ordem de bytes nativa de 16 bits do PCM pela API android.media.MediaCodec.

5.1.2. Decodificação de áudio

Confira mais detalhes em 5.1.3. Detalhes dos codecs de áudio.

Se as implementações do dispositivo declararem suporte ao recurso android.hardware.audio.output, elas precisarão oferecer suporte à decodificação dos seguintes formatos de áudio:

[C-1-1] Perfil MPEG-4 AAC (AAC LC)
[C-1-2] Perfil MPEG-4 HE AAC (AAC+).
[C-1-3] Perfil MPEG-4 HE AACv2 (AAC+ aprimorado)
[C-1-4] AAC ELD (AAC aprimorado com atraso baixo)
[C-1-11] xHE-AAC (perfil HE AAC estendido ISO/IEC 23003-3, que inclui o perfil de referência USAC e o perfil de controle de alcance dinâmico ISO/IEC 23003-4)
[C-1-5] FLAC
[C-1-6] MP3
[C-1-7] MIDI
[C-1-8] Vorbis
[C-1-9] PCM/WAVE, incluindo formatos de áudio de alta resolução de até 24 bits, taxa de amostragem de 192 kHz e 8 canais. Esse requisito é apenas para decodificação, e um dispositivo pode reduzir a amostragem e o downmix durante a fase de reprodução.
[C-1-10] Opus

Se as implementações do dispositivo oferecerem suporte à decodificação de buffers de entrada AAC de streams multicanais (ou seja, mais de dois canais) para PCM pelo decodificador de áudio AAC padrão na API android.media.MediaCodec, é necessário ter suporte ao seguinte:

[C-2-1] A decodificação PRECISA ser realizada sem downmix. Por exemplo, um stream AAC 5.0 precisa ser decodificado para cinco canais de PCM, e um stream AAC 5.1 precisa ser decodificado para seis canais de PCM.
[C-2-2] Os metadados do intervalo dinâmico precisam ser definidos conforme "Controle de intervalo dinâmico (DRC)" na ISO/IEC 14496-3 e nas chaves DRC android.media.MediaFormat para configurar os comportamentos relacionados ao intervalo dinâmico do decodificador de áudio. As chaves AAC DRC foram introduzidas na API 21 e são: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_ENCODED_TARGET_LEVEL.
[C-SR-1] É ALTAMENTE RECOMENDADO que os requisitos C-2-1 e C-2-2 acima sejam satisfeitos por todos os decodificadores de áudio AAC.

Ao decodificar áudio USAC, MPEG-D (ISO/IEC 23003-4):

[C-3-1] Os metadados de loudness e DRC precisam ser interpretados e aplicados de acordo com o perfil de nível 1 do controle dinâmico de alcance MPEG-D DRC.
[C-3-2] O decodificador PRECISA se comportar de acordo com o conjunto de configuração com as seguintes chaves android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_DRC_EFFECT_TYPE.

Decodificadores de perfil MPEG-4 AAC, HE AAC e HE AACv2:

PODE oferecer suporte ao controle de volume e de faixa dinâmica usando o perfil de controle de faixa dinâmica ISO/IEC 23003-4.

Se a ISO/IEC 23003-4 tiver suporte e se os metadados ISO/IEC 23003-4 e ISO/IEC 14496-3 estiverem presentes em um fluxo de bits decodificado, então:

Os metadados ISO/IEC 23003-4 terão precedência.

Todos os decodificadores de áudio precisam ter suporte à saída:

[C-6-1] Frames de áudio de ordem de bytes nativa de 16 bits do PCM pela API android.media.MediaCodec.

[C-7-1] É PRECISO que o aplicativo possa configurar a decodificação com a chave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar se o conteúdo é downmixado para estéreo (quando se usa um valor de 2) ou é enviado usando o número nativo de canais (quando se usa um valor igual ou maior que esse número). Por exemplo, um valor de 6 ou mais configuraria um decodificador para gerar 6 canais ao receber conteúdo 5.1.
[C-7-2] Ao decodificar, o decodificador PRECISA anunciar a máscara de canal usada no formato de saída com a chave KEY_CHANNEL_MASK, usando as constantes android.media.AudioFormat (exemplo: CHANNEL_OUT_5POINT1).

Se as implementações do dispositivo forem compatíveis com decodificadores de áudio diferentes do decodificador de áudio AAC padrão e forem capazes de gerar áudio multicanal (ou seja, mais de dois canais) quando alimentados com conteúdo multicanal comprimido, então:

[C-SR-2] É ALTAMENTE RECOMENDADO que o decodificador possa ser configurado pelo aplicativo usando a decodificação com a chave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar se o conteúdo é downmixado para estéreo (ao usar um valor de 2) ou é enviado usando o número nativo de canais (ao usar um valor igual ou maior que esse número). Por exemplo, um valor de 6 ou mais configuraria um decodificador para gerar 6 canais ao receber conteúdo 5.1.
[C-SR-3] Ao decodificar, é ALTAMENTE RECOMENDADO que o decodificador anuncie a máscara de canal usada no formato de saída com a chave KEY_CHANNEL_MASK, usando as constantes android.media.AudioFormat (exemplo: CHANNEL_OUT_5POINT1).

5.1.3. Detalhes dos codecs de áudio

Formato/codec	Detalhes	Tipos de arquivo/formatos de contêiner com suporte
Perfil MPEG-4 AAC (AAC LC)	Compatível com conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC bruto ADTS (.aac, ADIF não é compatível) MPEG-TS (.ts, não pesquisável, apenas decodificação) Matroska (.mkv, somente decodificação)
Perfil MPEG-4 HE AAC (AAC+)	Compatível com conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
Perfil MPEG-4 HE AACv2 (AAC+ aprimorado)	Compatível com conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC aprimorado com atraso baixo)	Suporte a conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Suporte a conteúdo mono/estéreo com taxas de amostragem padrão de 7,35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 a 12,2 kbps com amostragem a 8 kHz.	3GPP (.3gp)
AMR-WB	9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz, conforme definido em AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec	3GPP (.3gp)
FLAC	Para o codificador e o decodificador: pelo menos os modos mono e estéreo precisam ter suporte. Taxas de amostragem de até 192 kHz precisam ser compatíveis; resolução de 16 e 24 bits precisa ser compatível. O processamento de dados de áudio de 24 bits do FLAC PRECISA estar disponível com a configuração de áudio de ponto flutuante.	FLAC (.flac) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv, somente decodificação)
MP3	Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8-320 kbps.	MP3 (.mp3) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv, somente decodificação)
MIDI	MIDI tipos 0 e 1. DLS versões 1 e 2. XMF e XMF para celular. Compatível com formatos de toque RTTTL/RTX, OTA e iMelody.	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Decodificação: compatibilidade com conteúdo mono, estéreo, 5.0 e 5.1 com taxas de amostragem de 8000, 12000, 16000, 24000 e 48000 Hz. Codificação: compatibilidade com conteúdo mono e estéreo com taxas de amostragem de 8000, 12000, 16000, 24000 e 48000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv) WebM (.webm)
PCM/WAVE	O codec PCM precisa ter suporte a PCM linear de 16 bits e ponto flutuante de 16 bits. O extrator WAVE precisa oferecer suporte a PCM linear de 16, 24 e 32 bits e ponto flutuante de 32 bits (taxas até o limite do hardware). As taxas de amostragem precisam ter suporte de 8 kHz a 192 kHz.	WAVE (.wav)
Opus	Decodificação: compatibilidade com conteúdo mono, estéreo, 5.0 e 5.1 com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz. Codificação: compatibilidade com conteúdo mono e estéreo com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv) WebM (.webm)

5.1.4. Codificação de imagem

Confira mais detalhes em 5.1.6. Detalhes dos codecs de imagem.

As implementações de dispositivos precisam oferecer suporte à codificação da seguinte imagem:

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP
[C-0-4] AVIF
- Os dispositivos precisam oferecer suporte a BITRATE_MODE_CQ e ao perfil de referência.

Se as implementações de dispositivos oferecerem suporte à codificação HEIC por android.media.MediaCodec para o tipo de mídia MIMETYPE_IMAGE_ANDROID_HEIC, elas:

[C-1-1] É NECESSÁRIO fornecer um codec de codificador HEVC com aceleração de hardware que ofereça suporte ao modo de controle de taxa de bits BITRATE_MODE_CQ, ao perfil HEVCProfileMainStill e ao tamanho de quadro de 512 x 512 px.

5.1.5. Decodificação de imagem

Confira mais detalhes em 5.1.6. Detalhes dos codecs de imagem.

As implementações de dispositivos precisam oferecer suporte à decodificação da seguinte codificação de imagem:

[C-0-1] JPEG
[C-0-2] GIF
[C-0-3] PNG
[C-0-4] BMP
[C-0-5] WebP
[C-0-6] Bruto
[C-0-7] AVIF (perfil de referência)

Se as implementações do dispositivo oferecem suporte à decodificação de vídeo HEVC, elas:

[C-1-1] PRECISA oferecer suporte à decodificação de imagens HEIF (HEIC).

Decodificadores de imagem compatíveis com um formato de alta profundidade de bits (9 bits ou mais por canal):

[C-2-1] PRECISA oferecer suporte à saída de um formato equivalente de 8 bits, se solicitado pelo aplicativo, por exemplo, pela configuração ARGB_8888 de android.graphics.Bitmap.

5.1.6. Detalhes dos codecs de imagem

Formato/codec	Detalhes	Tipos de arquivo/formatos de contêiner compatíveis
JPEG	Básico+progressivo	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
bruto		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Imagem, coleção de imagens, sequência de imagens	HEIF (.heif), HEIC (.heic)
AVIF (perfil de referência)	Imagem, coleção de imagens, perfil de referência de sequência de imagens	Contêiner HEIF (.avif)

Codificadores e decodificadores de imagem expostos pela API MediaCodec

[C-1-1] É PRECISO oferecer suporte ao formato de cor flexível YUV420 8:8:8 (COLOR_FormatYUV420Flexible) por meio de CodecCapabilities.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao formato de cor RGB888 para o modo de entrada da Surface.
[C-1-3] É OBRIGATÓRIO oferecer suporte a pelo menos um formato de cor planar ou semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). É ALTAMENTE RECOMENDÁVEL oferecer suporte a ambos.

5.1.7. Codecs de vídeo

Para uma qualidade aceitável de streaming de vídeo da Web e serviços de videoconferência, as implementações de dispositivos precisam usar um codec VP8 de hardware que atenda aos requisitos.

Se as implementações do dispositivo incluírem um decodificador ou codificador de vídeo:

[C-1-1] Os codecs de vídeo precisam ter suporte a tamanhos de buffer de bytes de saída e entrada que aceitem o maior frame possível compactado e descompactado, conforme determinado pelo padrão e pela configuração, mas sem alocar em excesso.
[C-1-2] Os codificadores e decodificadores de vídeo PRECISAM oferecer suporte aos formatos de cor flexível YUV420 8:8:8 (COLOR_FormatYUV420Flexible) por meio de CodecCapabilities.
[C-1-3] Os codificadores e decodificadores de vídeo PRECISAM oferecer suporte a pelo menos um formato de cor planar ou semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). É ALTAMENTE RECOMENDÁVEL que eles ofereçam suporte a ambos.
[C-SR-1] É ALTAMENTE RECOMENDÁVEL que os codificadores e decodificadores de vídeo ofereçam suporte a pelo menos um dos formatos de cor planar ou semiplanar YUV420 8:8:8 otimizado para hardware (YV12, NV12, NV21 ou formato otimizado para o fornecedor equivalente).
[C-1-5] Os decodificadores de vídeo que oferecem suporte a um formato de alta profundidade de bits (9 bits ou mais por canal) PRECISAM oferecer suporte à saída de um formato equivalente de 8 bits, se solicitado pelo aplicativo. Isso PRECISA ser refletido com suporte a um formato de cor YUV420 8:8:8 por android.media.MediaCodecInfo.

Se as implementações de dispositivos anunciarem suporte ao perfil HDR por meio de Display.HdrCapabilities, elas:

[C-2-1] É PRECISO oferecer suporte à análise e ao processamento de metadados estáticos HDR.

Se as implementações de dispositivo anunciarem suporte à atualização interna usando FEATURE_IntraRefresh na classe MediaCodecInfo.CodecCapabilities, elas:

[C-3-1] É PRECISO oferecer suporte aos períodos de atualização no intervalo de 10 a 60 frames e operar com precisão em até 20% do período de atualização configurado.

A menos que o aplicativo especifique o contrário usando a chave de formato KEY_COLOR_FORMAT, as implementações de decodificador de vídeo:

[C-4-1] É OBRIGATÓRIO usar o formato de cor otimizado para exibição de hardware se configurado usando a saída da Surface.
[C-4-2] É OBRIGATÓRIO usar um formato de cor YUV420 8:8:8 como padrão, otimizado para leitura de CPU, se configurado para não usar a saída da Surface.

5.1.8. Lista de codecs de vídeo

Formato/codec	Detalhes	Tipos de arquivo/formatos de contêiner com suporte
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, somente decodificação)
H.264 AVC	Consulte as seções 5.2 e 5.3 para mais detalhes.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, não pesquisável) Matroska (.mkv, somente decodificação)
H.265 HEVC	Consulte a seção 5.3 para mais detalhes.	MPEG-4 (.mp4) Matroska (.mkv, somente decodificação)
MPEG-2	Perfil principal	MPEG2-TS (.ts, não pesquisável) MPEG-4 (.mp4, apenas decodificação) Matroska (.mkv, somente decodificação)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, somente decodificação)
VP8	Consulte as seções 5.2 e 5.3 para mais detalhes.	WebM (.webm) Matroska (.mkv)
VP9	Consulte a seção 5.3 para mais detalhes.	WebM (.webm) Matroska (.mkv)
AV1	Consulte as seções 5.2 e 5.3 para mais detalhes.	MPEG-4 (.mp4) Matroska (.mkv, somente decodificação)

5.1.9. Segurança do codec de mídia

As implementações de dispositivos precisam garantir a conformidade com os recursos de segurança do codec de mídia, conforme descrito abaixo.

O Android inclui suporte a OMX, uma API de aceleração multimídia multiplataforma, e ao Codec 2.0, uma API de aceleração multimídia de baixo overhead.

Se as implementações de dispositivos oferecerem suporte a multimídia, elas:

[C-1-1] É OBRIGATÓRIO oferecer suporte a codecs de mídia por APIs OMX ou Codec 2.0 (ou ambas), como no Projeto de código aberto do Android, e não desativar ou evitar as proteções de segurança. Isso não significa que todos os codecs precisam usar a API OMX ou Codec 2.0, apenas que o suporte a pelo menos uma dessas APIs precisa estar disponível, e o suporte às APIs disponíveis precisa incluir as proteções de segurança presentes.
[C-SR-1] É ALTAMENTE RECOMENDADO incluir suporte à API Codec 2.0.

Se as implementações do dispositivo não forem compatíveis com a API Codec 2.0, elas:

[C-2-1] É PRECISO incluir o codec de software OMX correspondente do Projeto de código aberto do Android (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) aceito pelo dispositivo.
[C-2-2] Codecs com nomes que começam com "OMX.google." PRECISAM ser baseadas no código-fonte do Projeto Android Open Source.
[C-SR-2] É ALTAMENTE RECOMENDADO que os codecs de software OMX sejam executados em um processo de codec que não tenha acesso a drivers de hardware, exceto mapeadores de memória.

Se as implementações do dispositivo oferecem suporte à API Codec 2.0, elas:

[C-3-1] É OBRIGATÓRIO incluir o codec de software Codec 2.0 correspondente do Projeto de código aberto do Android (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) aceito pelo dispositivo.
[C-3-2] É OBRIGATÓRIO hospedar os codecs de software Codec 2.0 no processo de codec de software, conforme fornecido no Projeto de código aberto do Android, para permitir o acesso mais restrito a codecs de software.
[C-3-3] Codecs que têm nomes que começam com "c2.android". PRECISAM ser baseadas no código-fonte do Projeto Android Open Source.

5.1.10. Caracterização do codec de mídia

Se as implementações do dispositivo oferecerem suporte a codecs de mídia, elas:

[C-1-1] PRECISA retornar valores corretos de caracterização do codec de mídia pela API MediaCodecInfo.

Especificamente, as seguintes:

[C-1-2] Codecs com nomes que começam com "OMX." É OBRIGATÓRIO usar as APIs OMX e ter nomes que estejam em conformidade com as diretrizes de nomenclatura do OMX IL.
[C-1-3] Codecs com nomes que começam com "c2". PRECISA usar a API Codec 2.0 e ter nomes que estejam em conformidade com as diretrizes de nomenclatura do Codec 2.0 para Android.
[C-1-4] Codecs com nomes que começam com "OMX.google." ou "c2.android." NÃO pode ser caracterizado como fornecedor ou com aceleração de hardware.
[C-1-5] Codecs executados em um processo de codec (fornecedor ou sistema) que tenham acesso a drivers de hardware, exceto alocadores de memória e mapeadores, NÃO podem ser caracterizados como somente software.
[C-1-6] Os codecs que não estão presentes no Android Open Source Project ou não são baseados no código-fonte desse projeto PRECISAM ser caracterizados como fornecedor.
[C-1-7] Os codecs que usam aceleração de hardware precisam ser caracterizados como acelerados por hardware.
[C-1-8] Os nomes dos codecs NÃO podem ser enganosos. Por exemplo, codecs com o nome "decoders" precisam ter suporte à decodificação, e aqueles com o nome "encoders" precisam ter suporte à codificação. Os codecs com nomes que contêm formatos de mídia precisam ter suporte a esses formatos.

Se as implementações do dispositivo oferecerem suporte a codecs de vídeo:

[C-2-1] Todos os codecs de vídeo precisam publicar dados de taxa de frames alcançáveis para os seguintes tamanhos, se o codec oferecer suporte:

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (codificador MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (outro)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (codificador MPEG4) 720 x 480 px (outro, AV1)	1408 x 1152 px (H263) 1280 x 720 px (outro, AV1)	1920 x 1080 px (exceto MPEG4, AV1)	3840 x 2160 px (HEVC, VP9, AV1)

[C-2-2] Os codecs de vídeo caracterizados como acelerados por hardware precisam publicar informações de pontos de desempenho. Elas PRECISAM listar todos os pontos de desempenho padrão com suporte (listados na API PerformancePoint), a menos que sejam cobertos por outro ponto de desempenho padrão com suporte.
Além disso, eles precisam publicar pontos de performance estendidos se oferecerem suporte a performance de vídeo sustentada diferente de um dos padrões listados.

5.2. Codificação de vídeo

Se as implementações do dispositivo oferecerem suporte a qualquer codificador de vídeo e o disponibilizarem para apps de terceiros, defina o
MediaFormat.KEY_BITRATE_MODE como BITRATE_MODE_VBR para que o codificador opere no modo de taxa de bits variável. Assim, desde que não afete o nível mínimo de qualidade, a taxa de bits codificada :

NÃO deve ser, em uma janela deslizante, mais de 15% sobre a taxa de bits entre intervalos intraframe (I-frame).
NÃO pode ser mais de 100% do que o bitrate em uma janela deslizante de 1 segundo.

Se as implementações de dispositivos oferecerem suporte a qualquer codificador de vídeo e o disponibilizarem para apps de terceiros, definindo o MediaFormat.KEY_BITRATE_MODE como BITRATE_MODE_CBR para que o codificador opere no modo de taxa de bits constante, a taxa de bits codificada:

[C-SR-2] É ALTAMENTE RECOMENDADO que a taxa de bits de destino não seja mais de 15% em uma janela deslizante de 1 segundo.

Se as implementações do dispositivo incluírem uma tela incorporada com o comprimento diagonal de pelo menos 2,5 polegadas ou incluírem uma porta de saída de vídeo ou declararem o suporte a uma câmera usando a flag de recurso android.hardware.camera.any, elas:

[C-1-1] É PRECISO incluir o suporte a pelo menos um dos codificadores de vídeo VP8 ou H.264 e disponibilizá-lo para aplicativos de terceiros.
DEVE oferecer suporte aos codificadores de vídeo VP8 e H.264 e disponibilizá-los para aplicativos de terceiros.

Se as implementações de dispositivos oferecerem suporte a qualquer um dos codificadores de vídeo H.264, VP8, VP9 ou HEVC e disponibilizá-los para aplicativos de terceiros, elas:

[C-2-1] É PRECISO oferecer suporte a taxas de bits configuráveis dinamicamente.
DEVE oferecer suporte a taxas de frames variáveis, em que o codificador de vídeo DEVE determinar a duração instantânea do frame com base nos carimbos de data/hora dos buffers de entrada e alocar o bucket de bits com base nessa duração.

Se as implementações de dispositivos oferecerem suporte ao codificador de vídeo MPEG-4 SP e o disponibilizarem para apps de terceiros, elas:

DEVE oferecer suporte a taxas de bits configuráveis dinamicamente para o codificador compatível.

Se as implementações do dispositivo oferecem codificadores de vídeo ou imagem com aceleração de hardware e oferecem suporte a uma ou mais câmeras de hardware anexadas ou conectadas expostas pelas APIs android.camera:

[C-4-1] Todos os codificadores de vídeo e imagem com aceleração de hardware precisam oferecer suporte à codificação de frames das câmeras de hardware.
DEVE oferecer suporte à codificação de frames das câmeras de hardware em todos os codificadores de vídeo ou imagem.

Se as implementações do dispositivo oferecerem codificação HDR, elas:

[C-SR-1] É ALTAMENTE RECOMENDADO fornecer um plug-in para a API de transcodificação perfeita para converter do formato HDR para SDR.

5.2.1. H.263

Se as implementações de dispositivos oferecerem suporte a codificadores H.263 e os disponibilizarem para apps de terceiros, elas:

[C-1-1] PRECISA oferecer suporte à resolução QCIF (176 x 144) usando o nível 45 do perfil de referência. A resolução SQCIF é opcional.

5.2.2. H.264

Se as implementações de dispositivos oferecerem suporte ao codec H.264, elas:

[C-1-1] É PRECISO oferecer suporte ao perfil de referência de nível 3. No entanto, o suporte a ASO (ordenação arbitrária de fatias), FMO (ordenação flexível de macroblocos) e RS (fatias redundantes) é OPCIONAL. Além disso, para manter a compatibilidade com outros dispositivos Android, é RECOMENDÁVEL que ASO, FMO e RS não sejam usados para o perfil de referência pelos codificadores.
[C-1-2] É PRECISO oferecer suporte aos perfis de codificação de vídeo SD (definição padrão) na tabela a seguir.
DEVE oferecer suporte ao nível 4 do perfil principal.
DEVE oferecer suporte aos perfis de codificação de vídeo em HD (alta definição), conforme indicado na tabela a seguir.

Se as implementações de dispositivos informarem suporte à codificação H.264 para vídeos de resolução 720p ou 1080p pelas APIs de mídia, elas:

[C-2-1] É PRECISO oferecer suporte aos perfis de codificação na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 240 px	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	20 qps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

Se as implementações de dispositivos forem compatíveis com o codec VP8, elas:

[C-1-1] PRECISA oferecer suporte aos perfis de codificação de vídeo SD.
DEVE oferecer suporte aos seguintes perfis de codificação de vídeo em HD (alta definição).
[C-1-2] É PRECISO oferecer suporte à gravação de arquivos WebM do Matroska.
DEVEM fornecer um codec VP8 de hardware que atenda aos requisitos de codificação de hardware do RTC do projeto WebM, para garantir qualidade aceitável de streaming de vídeo na Web e serviços de videoconferência.

Se as implementações de dispositivos informarem suporte à codificação VP8 para vídeos com resolução de 720p ou 1080p pelas APIs de mídia, elas:

[C-2-1] É PRECISO oferecer suporte aos perfis de codificação na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 180 px	640 x 360 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	800 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.4. VP9

Se as implementações de dispositivos forem compatíveis com o codec VP9, elas:

[C-1-2] É PRECISO oferecer suporte ao perfil 0 de nível 3.
[C-1-1] É PRECISO oferecer suporte à gravação de arquivos WebM do Matroska.
[C-1-3] É PRECISO gerar dados CodecPrivate.
DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.
[C-SR-1] RECOMENDA-SE FORTEMENTE o suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.

	SD	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se as implementações do dispositivo afirmarem oferecer suporte ao Perfil 2 ou 3 pelas APIs de mídia:

O suporte ao formato de 12 bits é OPCIONAL.

5.2.5. H.265

Se as implementações de dispositivos oferecerem suporte ao codec H.265, elas:

[C-1-1] É PRECISO oferecer suporte ao perfil principal de nível 3 até resolução de 512 x 512.
[C-SR-1] é ALTAMENTE RECOMENDADO que ofereça suporte ao perfil SD de 720 x 480 e aos perfis de codificação em HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.

	SD	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.2.6. AV1

Se as implementações do dispositivo oferecem suporte ao codec AV1, elas:

[C-1-1] É PRECISO oferecer suporte ao perfil principal, incluindo conteúdo de 8 e 10 bits.
[C-1-2] É OBRIGATÓRIO publicar dados de desempenho, ou seja, informar dados de desempenho usando as APIs getSupportedFrameRatesFor() ou getSupportedPerformancePoints() para as resoluções compatíveis na tabela abaixo.
[C-1-3] É PRECISO aceitar metadados HDR e gerar a saída para o fluxo de bits

Se o codificador AV1 tiver aceleração de hardware, ele:

[C-2-1] PRECISA oferecer suporte ao perfil de codificação HD1080p e até o perfil da tabela abaixo:

	SD	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	5 Mbps	8 Mbps	16 Mbps	50 Mbps

5.3. Decodificação de vídeo

Se as implementações de dispositivos oferecerem suporte aos codecs VP8, VP9, H.264 ou H.265, elas:

[C-1-1] É NECESSÁRIO oferecer suporte à resolução dinâmica de vídeo e à alternância de frame rate por meio das APIs padrão do Android no mesmo fluxo para todos os codecs VP8, VP9, H.264 e H.265 em tempo real e com a resolução máxima compatível com cada codec no dispositivo.

5.3.1. MPEG-2

Se as implementações de dispositivos oferecerem suporte a decodificadores MPEG-2, elas:

[C-1-1] PRECISA oferecer suporte ao nível alto do perfil principal.

5.3.2. H.263

Se as implementações de dispositivos oferecerem suporte a decodificadores H.263, elas:

[C-1-1] É necessário oferecer suporte ao nível 30 do perfil de referência (resoluções CIF, QCIF e SQCIF a 30 fps 384 kbps) e ao nível 45 (resoluções QCIF e SQCIF a 30 fps 128 kbps).

5.3.3. MPEG-4

Se as implementações do dispositivo tiverem decodificadores MPEG-4, elas:

[C-1-1] É PRECISO oferecer suporte ao perfil simples de nível 3.

5.3.4. H.264

Se as implementações de dispositivos forem compatíveis com decodificadores H.264, elas:

[C-1-1] É PRECISO oferecer suporte ao perfil principal de nível 3.1 e ao perfil de referência. O suporte para ASO (ordenação arbitrária de fatias), FMO (ordenação flexível de macroblocos) e RS (fatias redundantes) é OPCIONAL.
[C-1-2] PRECISA ser capaz de decodificar vídeos com os perfis SD (definição padrão) listados na tabela a seguir e codificados com o perfil de referência e o perfil principal de nível 3.1 (incluindo 720p30).
DEVE ser capaz de decodificar vídeos com os perfis de alta definição (HD, na sigla em inglês) conforme indicado na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, as implementações do dispositivo:

[C-2-1] É PRECISO oferecer suporte aos perfis de decodificação de vídeo HD 720p na tabela a seguir.
[C-2-2] É PRECISO oferecer suporte aos perfis de decodificação de vídeo HD 1080p na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 240 px	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	30 fps	30 fps	60 qps	30 qps (60 qps^televisão)
Taxa de bits do vídeo	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

Se as implementações de dispositivos oferecerem suporte ao codec H.265, elas:

[C-1-1] É PRECISO oferecer suporte ao nível principal do perfil principal de nível 3 e aos perfis de decodificação de vídeo SD conforme indicado na tabela a seguir.
DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.
[C-1-2] É PRECISO oferecer suporte aos perfis de decodificação em HD conforme indicado na tabela abaixo, se houver um decodificador de hardware.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, faça o seguinte:

[C-2-1] As implementações de dispositivos precisam oferecer suporte a pelo menos uma das decodificações H.265 ou VP9 dos perfis 720p, 1080p e UHD.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	352 x 288 px	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30/60 fps (60 fps^{TV com decodificador de hardware H.265})	60 qps
Taxa de bits do vídeo	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se as implementações do dispositivo afirmarem que oferecem suporte a um perfil HDR pelas APIs de mídia:

[C-3-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR necessários do aplicativo, além de oferecer suporte à extração e saída dos metadados HDR necessários do fluxo de bits e/ou contêiner.
[C-3-2] As implementações de dispositivos PRECISAM exibir conteúdo HDR corretamente na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

5.3.6. VP8

Se as implementações de dispositivos forem compatíveis com o codec VP8, elas:

[C-1-1] É PRECISO oferecer suporte aos perfis de decodificação SD na tabela a seguir.
DEVE usar um codec VP8 de hardware que atenda aos requisitos.
DEVE oferecer suporte aos perfis de decodificação em HD na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, faça o seguinte:

[C-2-1] As implementações de dispositivos precisam oferecer suporte a perfis de 720p na tabela a seguir.
[C-2-2] As implementações de dispositivos precisam oferecer suporte a perfis de 1080p na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 180 px	640 x 360 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	30 fps	30 fps	30 qps (60 qps^televisão)	30 (60 fps^Televisão)
Taxa de bits do vídeo	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

Se as implementações de dispositivos forem compatíveis com o codec VP9, elas:

[C-1-1] PRECISA oferecer suporte aos perfis de decodificação de vídeo SD conforme indicado na tabela a seguir.
DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.

Se as implementações de dispositivos forem compatíveis com o codec VP9 e um decodificador de hardware:

[C-2-1] É PRECISO oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, faça o seguinte:

[C-3-1] As implementações de dispositivos precisam oferecer suporte a pelo menos um dos decodificadores VP9 ou H.265 dos perfis 720p, 1080p e UHD.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	320 x 180 px	640 x 360 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps (60 fps^{TV com decodificação de hardware VP9})	60 qps
Taxa de bits do vídeo	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se as implementações do dispositivo afirmarem que oferecem suporte a VP9Profile2 ou VP9Profile3 pelas APIs de mídia CodecProfileLevel, faça o seguinte:

O suporte ao formato de 12 bits é OPCIONAL.

Se as implementações do dispositivo afirmarem ter suporte a um perfil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) pelas APIs de mídia:

[C-4-1] As implementações de dispositivos precisam aceitar os metadados HDR necessários (KEY_HDR_STATIC_INFO para todos os perfis HDR, bem como 'KEY_HDR10_PLUS_INFO' para perfis HDR10Plus) do aplicativo. Eles também precisam oferecer suporte à extração e saída dos metadados HDR necessários do fluxo de bits e/ou contêiner.
[C-4-2] As implementações de dispositivos PRECISAM mostrar conteúdo HDR corretamente na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

5.3.8. Dolby Vision

Se as implementações de dispositivos declararem suporte ao decodificador Dolby Vision usando HDR_TYPE_DOLBY_VISION, elas:

[C-1-1] É PRECISO fornecer um extrator com tecnologia Dolby Vision.

Início dos novos requisitos para o Android 15

[C-1-2] PRECISA exibir corretamente o conteúdo do Dolby Vision na tela do dispositivo ou em uma tela externa conectada via uma porta de saída de vídeo padrão (por exemplo, HDMI.

Fim dos novos requisitos

[C-1-3] É PRECISO definir o ID da faixa das camadas básicas compatíveis com versões anteriores (se houver) para que ele seja igual ao ID da faixa da camada Dolby Vision combinada.

5.3.9. AV1

Se as implementações de dispositivos oferecerem suporte ao codec AV1 e o disponibilizarem para aplicativos de terceiros, elas:

[C-1-1] É PRECISO oferecer suporte ao perfil principal, incluindo conteúdo de 8 e 10 bits.

Se as implementações do dispositivo oferecerem suporte ao codec AV1 com um decodificador acelerado por hardware, elas:

[C-2-1] É PRECISO decodificar pelo menos perfis de decodificação de vídeo em HD 720p da tabela abaixo quando a altura informada pelo método Display.getSupportedModes() for igual ou maior que 720p.
[C-2-2] É PRECISO decodificar pelo menos perfis de decodificação de vídeo HD 1080p da tabela abaixo quando a altura informada pelo método Display.getSupportedModes() for igual ou maior que 1080p.

	SD	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	5 Mbps	8 Mbps	16 Mbps	50 Mbps

Se as implementações do dispositivo oferecerem suporte ao perfil HDR pelas APIs de mídia, elas:

[C-3-1] É PRECISO oferecer suporte à extração e saída de metadados HDR do bitstream e/ou contêiner.
[C-3-2] É NECESSÁRIO exibir conteúdo HDR corretamente na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI).

5.4. Gravação em áudio

Embora alguns dos requisitos descritos nesta seção sejam listados como DEVE desde o Android 4.3, a definição de compatibilidade para versões futuras está planejada para mudar para OBRIGATÓRIO. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos listados como "DEVE", ou não será possível alcançar a compatibilidade com o Android quando eles forem atualizados para a versão futura.

5.4.1. Captura de áudio bruto e informações do microfone

Se as implementações do dispositivo declararem android.hardware.microphone, elas:

[C-1-1] É OBRIGATÓRIO permitir a captura de conteúdo de áudio bruto para qualquer stream de ENTRADA AudioRecord ou AAudio que seja aberto com sucesso. No mínimo, as seguintes características precisam ser compatíveis:
- Formato:PCM linear, 16 bits
- Taxas de amostragem:8.000, 11.025, 16.000, 44.100, 48.000 Hz
- Canais:mono
- Fontes de áudio:DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. Isso também se aplica às predefinições de entrada equivalentes em AAudio, por exemplo, AAUDIO_INPUT_PRESET_CAMCORDER.
DEVE permitir a captura de conteúdo de áudio bruto com as seguintes características:
- Formato: PCM linear, de 16 e 24 bits
- Taxas de amostragem: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 Hz
- Canais: o mesmo número de canais que o número de microfones no dispositivo.
[C-1-2] É NECESSÁRIO capturar acima das taxas de amostragem sem upsampling.
[C-1-3] É necessário incluir um filtro anti-aliasing adequado quando as taxas de amostragem fornecidas acima forem capturadas com redução de amostragem.
DEVE permitir a captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, o que significa as seguintes características:
- Formato: PCM linear, 16 bits
- Taxas de amostragem: 22.050, 48.000 Hz
- Canais: estéreo
[C-1-4] É PRECISO honrar a API MicrophoneInfo e preencher corretamente as informações dos microfones disponíveis no dispositivo acessíveis aos aplicativos de terceiros pela API AudioManager.getMicrophones(), para AudioRecord ativo usando MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. Se as implementações de dispositivos permitirem a captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, elas:
[C-2-1] É PRECISO capturar sem upsampling em qualquer proporção maior que 16000:22050 ou 44100:48000.
[C-2-2] É OBRIGATÓRIO incluir um filtro anti-aliasing adequado para qualquer upsampling ou downsampling.

5.4.2. Captura para reconhecimento de voz

Se as implementações do dispositivo declararem android.hardware.microphone, elas:

[C-1-1] É OBRIGATÓRIO capturar a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION em uma das taxas de amostragem, 44100 e 48000.
[C-1-2] É OBRIGATÓRIO desativar, por padrão, qualquer processamento de áudio de redução de ruído ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
[C-1-3] É OBRIGATÓRIO desativar por padrão qualquer controle de ganho automático ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
DEVEM apresentar características aproximadamente planas de amplitude versus frequência na faixa de frequência média: especificamente ±3dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
[C-SR-1] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de frequência baixa: especificamente de ±20 dB de 30 Hz a 100 Hz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
[C-SR-2] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de frequência alta: especificamente de ±30 dB de 4.000 Hz a 22 KHz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
DEVERÁ definir a sensibilidade de entrada de áudio de modo que uma fonte de tom senoidal de 1000 Hz tocada a 90 dB de nível de pressão sonora (SPL, na sigla em inglês) (medido ao lado do microfone) produza uma resposta ideal de RMS 2500 em um intervalo de 1770 e 3530 para 16 amostras de bits (ou -22,35 dB ±3dB de escala completa para ponto flutuante/amostras de precisão dupla) para cada microfone usado para gravar a fonte de áudio do reconhecimento de voz.
DEVE gravar o stream de áudio de reconhecimento de voz para que os níveis de amplitude PCM acompanhem linearmente as mudanças de SPL de entrada em pelo menos um intervalo de 30 dB de -18 dB a +12 dB em relação a 90 dB SPL no microfone.
DEVE gravar o fluxo de áudio de reconhecimento de voz com distorção harmônica total (THD, na sigla em inglês) menor que 1% para 1 kHz em 90 dB SPL de nível de entrada no microfone.

Se as implementações do dispositivo declararem tecnologias de supressão de android.hardware.microphone e ruído (redução) ajustadas para reconhecimento de fala, elas:

[C-2-1] PRECISA permitir que esse efeito de áudio seja controlável com a API android.media.audiofx.NoiseSuppressor.
[C-2-2] É OBRIGATÓRIO identificar exclusivamente cada implementação de tecnologia de supressão de ruído pelo campo AudioEffect.Descriptor.uuid.

5.4.3. Captura para redirecionamento da reprodução

A classe android.media.MediaRecorder.AudioSource inclui a fonte de áudio REMOTE_SUBMIX.

Se as implementações do dispositivo declararem android.hardware.audio.output e android.hardware.microphone, elas:

[C-1-1] É PRECISO implementar corretamente a fonte de áudio REMOTE_SUBMIX para que, quando um aplicativo use a API android.media.AudioRecord para gravar dessa fonte de áudio, ele capture uma mistura de todos os streams de áudio, exceto os seguintes:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. Cancelamento de eco acústico

Se as implementações do dispositivo declararem android.hardware.microphone, elas:

DEVE implementar uma tecnologia de cancelamento de eco acústico (AEC) ajustada para comunicação por voz e aplicada ao caminho de captura ao capturar usando AudioSource.VOICE_COMMUNICATION.

Se as implementações do dispositivo oferecerem um Acoustic Echo Canceler que seja inserido no caminho de áudio de captura quando AudioSource.VOICE_COMMUNICATION for selecionado, elas:

[C-SR-1] É _RECOMENDADO_ declarar isso pelo método da API AcousticEchoCanceler AcousticEchoCanceler.isAvailable().
[C-SR-2] são STRONGLY_RECOMMENDED para permitir que esse efeito de áudio seja controlável com a API AcousticEchoCanceler.
[C-SR-3] É FORTEMENTE_RECOMENDADO identificar de forma exclusiva cada implementação de tecnologia AEC pelo campo AudioEffect.Descriptor.uuid.

5.4.5. Captura simultânea

Se as implementações do dispositivo declararem android.hardware.microphone, elas PRECISAM implementar a captura simultânea, conforme descrito neste documento. Especificamente:

[C-1-1] É PRECISO permitir o acesso simultâneo ao microfone por um serviço de acessibilidade que capture com AudioSource.VOICE_RECOGNITION e pelo menos uma captura de aplicativo com qualquer AudioSource.
[C-1-2] É PRECISO permitir o acesso simultâneo ao microfone por um app pré-instalado que tenha uma função do Google Assistente e pelo menos um app capturando com qualquer AudioSource, exceto AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
[C-1-3] A captura de áudio de qualquer outro aplicativo, exceto um serviço de acessibilidade, precisa ser silenciada enquanto um aplicativo está capturando com AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. No entanto, quando um app está capturando via AudioSource.VOICE_COMMUNICATION, outro app pode capturar a chamada de voz se ele for privilegiado (pré-instalado) com permissão CAPTURE_AUDIO_OUTPUT.
[C-1-4] Se dois ou mais aplicativos estiverem capturando simultaneamente e se nenhum deles tiver uma IU na parte de cima, o que tiver iniciado a captura mais recentemente vai receber o áudio.

5.5. Reprodução de áudio

O Android inclui suporte para permitir que os apps reproduzam áudio pelo periférico de saída de áudio, conforme definido na seção 7.8.2.

5.5.1. Reprodução de áudio bruto

Se as implementações do dispositivo declararem android.hardware.audio.output, elas:

[C-1-1] É PRECISO permitir a reprodução de conteúdo de áudio bruto com as seguintes características:
- Formatos de origem: PCM linear, 16 bits, 8 bits, ponto flutuante
- Canais: mono, estéreo, configurações válidas de multicanal com até 8 canais
- Taxas de amostragem (em Hz):
  - 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 nas configurações do canal listadas acima
  - 96000 em mono e estéreo

5.5.2. Efeitos sonoros

O Android oferece uma API para efeitos de áudio para implementações de dispositivos.

Se as implementações do dispositivo declararem o recurso android.hardware.audio.output, elas:

[C-1-1] PRECISA oferecer suporte às implementações EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controláveis pelas subclasses Equalizer e LoudnessEnhancer do AudioEffect.
[C-1-2] PRECISA oferecer suporte à implementação da API do visualizador, controlável pela classe Visualizer.
[C-1-3] PRECISA oferecer suporte à implementação de EFFECT_TYPE_DYNAMICS_PROCESSING controlável pela subclasse AudioEffect DynamicsProcessing.

Início dos novos requisitos para o Android 15

[C-1-4] PRECISA oferecer suporte a efeitos de áudio com entrada e saída de ponto flutuante, quando os resultados do efeito são retornados para o pipeline de áudio do framework. Isso se refere a inserções típicas ou efeitos auxiliares, como o equalizador. O comportamento equivalente é altamente recomendado quando os resultados do efeito não são visíveis pelo pipeline de áudio do framework (como efeitos de pós-processamento ou descarregados).

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

[C-1-5] É OBRIGATÓRIO garantir que os efeitos de áudio ofereçam suporte a vários canais até a contagem de canais do mixer, também conhecida como FCC_LIMIT, quando os resultados do efeito são retornados ao pipeline de áudio do framework. Isso se refere a efeitos de inserção ou auxiliares típicos, mas exclui efeitos especiais, como downmix, upmix e efeitos de espacialização que mudam a contagem de canais. O comportamento equivalente é recomendado quando os efeitos não são visíveis pelo pipeline de áudio do framework (como efeitos de pós-processamento ou descarregados).

Fim dos novos requisitos

DEVE oferecer suporte às implementações EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controláveis pelas subclasses AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte a efeitos em ponto flutuante e multicanal.

5.5.3. Volume de saída de áudio

Implementações de dispositivos automotivos:

DEVE permitir ajustar o volume do áudio separadamente para cada stream de áudio usando o tipo de conteúdo ou uso conforme definido por AudioAttributes e o uso de áudio no carro conforme definido publicamente em android.car.CarAudioManager.

5.5.4. Offload de áudio

Se as implementações do dispositivo oferecerem suporte à reprodução de transferência de áudio, elas:

[C-SR-1] É ALTAMENTE RECOMENDADO cortar o conteúdo de áudio sem intervalos entre dois clipes com o mesmo formato quando especificado pela API AudioTrack gapless e pelo contêiner de mídia do MediaPlayer.

5.6. Latência de áudio

A latência de áudio é o tempo de atraso enquanto um sinal de áudio passa por um sistema. Muitas classes de aplicativos dependem de latências curtas para conseguir efeitos sonoros em tempo real.

Para os fins desta seção, use as seguintes definições:

Latência de saída. O intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e o momento em que o som correspondente é apresentado ao ambiente em um transdutor no dispositivo ou o sinal sai do dispositivo por uma porta e pode ser observado externamente.
Latência de saída fria. O tempo entre o início de um stream de saída e o tempo de apresentação do primeiro frame com base em carimbos de data/hora, quando o sistema de saída de áudio estava inativo e desligado antes da solicitação.
latência de saída contínua. A latência de saída para frames subsequentes, depois que o dispositivo estiver reproduzindo áudio.
latência de entrada. O intervalo entre o momento em que um som é apresentado pelo ambiente ao dispositivo em um transdutor no dispositivo ou o sinal entra no dispositivo por uma porta e o momento em que um aplicativo lê o frame correspondente de dados codificados em PCM.
perda de entrada. A parte inicial de um sinal de entrada que é inutilizável ou indisponível.
Latência de entrada fria. O tempo entre o início da transmissão e o momento em que o primeiro frame válido é recebido, quando o sistema de entrada de áudio está inativo e desligado antes da solicitação.
latente de entrada contínua. A latência de entrada para frames subsequentes, enquanto o dispositivo está capturando áudio.
latência de ida e volta contínua. A soma da latência de entrada contínua mais a latência de saída contínua mais um período de buffer. O período de buffer permite tempo para o app processar o sinal e tempo para o app reduzir a diferença de fase entre os streams de entrada e saída.
API da fila de buffer de PCM do OpenSL ES. O conjunto de APIs OpenSL ES relacionadas ao PCM no Android NDK.
API de áudio nativa AAudio. O conjunto de APIs AAudio no Android NDK.
Carimbo de data/hora. Um par que consiste em uma posição de frame relativa em um stream e o tempo estimado em que esse frame entra ou sai do pipeline de processamento de áudio no endpoint associado. Consulte também AudioTimestamp.
glitch. Uma interrupção temporária ou valor de amostra incorreto no sinal de áudio, normalmente causada por um buffer underrun para saída, buffer overrun para entrada ou qualquer outra fonte de ruído digital ou analógico.
Desvio médio absoluto (MAD). A média do valor absoluto dos desvios da média de um conjunto de valores.

Início dos novos requisitos para o Android 15

A latência de toque a tom (TTL), medida pelo CTS Verifier, é o tempo entre o toque na tela e a reprodução de um tom gerado como resultado desse toque no alto-falante. O valor é uma média de cinco medições usando a API de áudio nativa do AAudio para saída.
A latência de ida e volta (RTL, na sigla em inglês), conforme medida pelo CTS Verifier, é a latência contínua média em cinco medições, medida em um caminho de loopback que alimenta a saída de volta à entrada, usando a API de áudio nativa AAudio. Os caminhos de loopback são:
- Alto-falante/microfone: alto-falante integrado para microfone integrado.
- Analógico: entrada analógica de 3,5 mm e um adaptador de loopback.
- USB: adaptador USB para 3,5 mm e um adaptador de loopback ou uma interface de áudio USB e cabos de loopback.
FEATURE_AUDIO_LOW_LATENCY. O recurso android.hardware.audio.low_latency é declarado.
FEATURE_AUDIO_PRO. O recurso android.hardware.audio.pro é declarado.
MPC. Classe de performance de mídia.
Latência de rastreamento de cabeça. O tempo que leva do movimento da cabeça capturado pela unidade de medição inercial (IMU, na sigla em inglês) à detecção da mudança no som causada por esse movimento pelos transdutores dos fones de ouvido.

Fim dos novos requisitos

Se as implementações do dispositivo declararem android.hardware.audio.output, elas PRECISAM atender ou exceder os seguintes requisitos:

Início dos novos requisitos para o Android 15

~~[C-1-1] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp e AAudioStream_getTimestamp é preciso com precisão de +/- 2 ms.~~

Fim dos novos requisitos

[C-1-2] Latência de saída fria de 500 milissegundos ou menos.
[C-1-3] Abrir um stream de saída usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

Início dos novos requisitos para o Android 15

[C-1-4] As latências de ida e volta calculadas com base nos carimbos de data/hora de entrada e saída retornados por AAudioStream_getTimestamp PRECISAM estar dentro de 200 milissegundos da latência de ida e volta medida para AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY para alto-falantes, fones de ouvido com e sem fio.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

Se as implementações do dispositivo declararem android.hardware.audio.output, é ALTAMENTE RECOMENDÁVEL que elas atendam ou excedam os seguintes requisitos:

[C-SR-1] Latência de saída fria de 100 milissegundos ou menos no caminho de dados do alto-falante.

[C-SR-2] Latência de toque para tom de 80 milissegundos ou menos.

[C-SR-4] As latências de ida e volta calculadas com base nos carimbos de data/hora de entrada e saída retornados por AAudioStream_getTimestamp são ALTAMENTE RECOMENDADAS para ficar dentro de 30 milissegundos da latência de ida e volta medida para AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY para alto-falantes, fones de ouvido com e sem fio.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

Se as implementações do dispositivo atenderem aos requisitos acima, após a calibração inicial, ao usar a API de áudio nativa AAudio, para latência de saída contínua e latência de saída fria em pelo menos um dispositivo de saída de áudio com suporte, elas são:

[C-SR-5] É ALTAMENTE RECOMENDADO informar áudio de baixa latência declarando a flag de recurso android.hardware.audio.low_latency.

[C-SR-6] É FORTEMENTE RECOMENDADO atender aos requisitos de áudio de baixa latência usando a API AAudio.

[C-SR-7] É ALTAMENTE RECOMENDADO garantir que, para streams que retornam AAUDIO_PERFORMANCE_MODE_LOW_LATENCY de AAudioStream_getPerformanceMode(), o valor retornado por AAudioStream_getFramesPerBurst() seja menor ou igual ao valor retornado por android.media.AudioManager.getProperty(String) para a chave de propriedade AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

Se as implementações do dispositivo não atenderem aos requisitos de áudio de baixa latência pela API de áudio nativa AAudio, elas:

[C-2-1] NÃO é necessário informar suporte para áudio de baixa latência.

Fim dos novos requisitos

Se as implementações do dispositivo incluírem android.hardware.microphone, elas PRECISAM atender a estes requisitos de áudio de entrada:

Início dos novos requisitos para o Android 15

[C-3-1] Limitar o erro nas marcações de tempo de entrada, conforme retornado por AudioRecord.getTimestamp ou AAudioStream_getTimestamp, a +/- 2 ms. "Erro" significa aqui a variação em relação ao valor correto.

Fim dos novos requisitos

[C-3-2] Latência de entrada fria de 500 milissegundos ou menos.
[C-3-3] Abrir um stream de entrada usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

Início dos novos requisitos para o Android 15

Se as implementações do dispositivo incluírem android.hardware.microphone, é ALTAMENTE RECOMENDÁVEL que elas atendam a estes requisitos de áudio de entrada:

[C-SR-8] Latência de entrada fria de 100 milissegundos ou menos no caminho de dados do microfone.

[C-SR-11] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp ou AAudioStream_getTimestamp, para +/- 1 ms.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

Se as implementações do dispositivo declararem android.hardware.audio.output e android.hardware.microphone, elas:

[C-SR-12] É ALTAMENTE RECOMENDADO ter uma latência média contínua de ida e volta de 50 milissegundos ou menos em 5 medições, com uma média absoluta de desvio menor que 10 milissegundos em pelo menos um caminho com suporte.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

A tabela a seguir define os requisitos de RTL para implementações de dispositivos portáteis, conforme definido em 2.2.1, que declaram android.hardware.audio.output e android.hardware.microphone.

Dispositivos e declarações	RTL (ms)	MAD (ms)	Caminhos de loopback
Filmagem manual	250	30	alto-falante/microfone, analógico de 3,5 mm (se aceito), USB (se aceito)
>= MPC_T (14)	80	15	pelo menos um caminho
FEATURE_AUDIO_LOW_LATENCY	50	10	pelo menos um caminho
FEATURE_AUDIO_PRO	25	5	pelo menos um caminho
FEATURE_AUDIO_PRO	20	5	analógico (se houver suporte)
FEATURE_AUDIO_PRO	25	5	USB (se não for compatível com analógico)

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

A tabela a seguir define os requisitos de TTL para implementações de dispositivos portáteis, conforme definido em 2.2.1, que declaram android.hardware.audio.output e android.hardware.microphone.

Dispositivos e declarações	TTL (ms)
Filmagem manual	250
>= MPC_T (14)	80
MPC_S (13)	100
FEATURE_AUDIO_PRO	80

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

Se as implementações de dispositivos incluírem suporte a spatial audio com rastreamento de cabeça e declararem a flag PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, elas:

[C-4-1] É PRECISO apresentar um tempo de resposta máximo de rastreamento de cabeça para atualização de áudio de 300 ms.

Fim dos novos requisitos

5.7. Protocolos de rede

As implementações de dispositivos precisam oferecer suporte aos protocolos de rede de mídia para reprodução de áudio e vídeo, conforme especificado na documentação do SDK do Android.

Para cada codec e formato de contêiner que uma implementação de dispositivo precisa oferecer suporte, a implementação do dispositivo:

[C-1-1] É PRECISO ter suporte a esse codec ou contêiner por HTTP e HTTPS.
[C-1-2] É PRECISO oferecer suporte aos formatos de segmento de mídia correspondentes, conforme mostrado na tabela de formatos de segmento de mídia abaixo sobre o protocolo de rascunho de transmissão ao vivo em HTTP, versão 7.
[C-1-3] PRECISA oferecer suporte aos formatos de payload RTSP correspondentes, conforme mostrado na tabela RTSP abaixo. Para exceções, consulte as notas de rodapé da tabela na seção 5.1.

Formatos de segmento de mídia

Formatos de segmentos	Referência(s)	Suporte a codec obrigatório
Stream de transporte MPEG-2	ISO 13818	Codecs de vídeo: H264 AVC MPEG-4 SP MPEG-2 Consulte a seção 5.1.8 para saber mais sobre o H.264 AVC, o MPEG2-4 SP, e o MPEG-2. Codecs de áudio: AAC Consulte a seção 5.1.3 para saber mais sobre o AAC e as variantes.
AAC com enquadramento ADTS e tags ID3	ISO 13818-7	Consulte a seção 5.1.1 para detalhes sobre o AAC e as variantes dele.
WebVTT	WebVTT

Formatos de segmentos

Referência(s)

Suporte a codec obrigatório

Stream de transporte MPEG-2

ISO 13818

Codecs de vídeo:

H264 AVC
MPEG-4 SP
MPEG-2

Consulte a seção 5.1.8 para saber mais sobre o H.264 AVC, o MPEG2-4 SP,
e o MPEG-2.

Codecs de áudio:

Consulte a seção 5.1.3 para saber mais sobre o AAC e as variantes.

AAC com enquadramento ADTS e tags ID3

ISO 13818-7

Consulte a seção 5.1.1 para detalhes sobre o AAC e as variantes dele.

WebVTT

RTSP (RTP, SDP)

Nome do perfil	Referência(s)	Suporte a codec obrigatório
H264 AVC	RFC 6184	Consulte a seção 5.1.8 para saber mais sobre o AVC H264.
MP4A-LATM	RFC 6416 (em inglês)	Consulte a seção 5.1.3 para detalhes sobre AAC e suas variantes
H263-1998	RFC 3551 RFC 4629 RFC 2190	Consulte a seção 5.1.8 para saber mais sobre o H263.
H263-2000	RFC 4629	Consulte a seção 5.1.8 para saber mais sobre o H263.
AMR	RFC 4867	Consulte a seção 5.1.3 para detalhes sobre AMR-NB.
AMR-WB	RFC 4867	Consulte a seção 5.1.3 para saber mais sobre AMR-WB.
MP4V-ES	RFC 6416 (em inglês)	Consulte a seção 5.1.8 para detalhes sobre o MPEG-4 SP.
mpeg4-generic	RFC 3640 (em inglês)	Consulte a seção 5.1.3 para detalhes sobre AAC e suas variantes
MP2T	RFC 2250 (em inglês)	Consulte MPEG-2 Transport Stream em HTTP Live Streaming para mais detalhes.

5.8. Secure Media

Se as implementações do dispositivo oferecerem suporte à saída de vídeo segura e forem capazes de oferecer suporte a superfícies seguras, elas:

[C-1-1] É PRECISO declarar suporte para Display.FLAG_SECURE.

Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE e ao protocolo de exibição sem fio, elas:

[C-2-1] É OBRIGATÓRIO proteger a vinculação com um mecanismo criptograficamente seguro, como o HDCP 2.x ou mais recente, para as telas conectadas por protocolos sem fio, como o Miracast.

Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE e suportarem a tela externa com fio, elas:

[C-3-1] É NECESSÁRIO oferecer suporte ao HDCP 1.2 ou mais recente para todas as telas externas conectadas por uma porta com fio acessível ao usuário.

5.9. Interface digital para instrumentos musicais (MIDI)

Se as implementações de dispositivo informarem suporte ao recurso android.software.midi pela classe android.content.pm.PackageManager, elas:

[C-1-1] É PRECISO oferecer suporte a MIDI por todos os transportes de hardware compatíveis com MIDI para os quais eles oferecem conectividade genérica que não é MIDI, em que esses transportes são:
- Modo de host USB, seção 7.7
- MIDI por Bluetooth LE atuando no papel central, seção 7.4.3
[C-1-2] É PRECISO oferecer suporte ao transporte de software MIDI entre apps (dispositivos MIDI virtuais)
[C-1-3] É PRECISO incluir libamidi.so (suporte MIDI nativo).
DEVE ter suporte a MIDI no modo periférico USB, seção 7.7

5.10. Áudio profissional

Se as implementações de dispositivo informarem suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager, elas:

[C-1-1] É OBRIGATÓRIO informar o suporte ao recurso android.hardware.audio.low_latency.

Início dos novos requisitos para o Android 15

[C-1-2] ~~Ter a latência de áudio de ida e volta contínua~~, atender aos requisitos de latência para FEATURE_AUDIO_PRO conforme definido na seção 5.6 Latência de áudio ~~de 25 milissegundos ou menos em pelo menos um caminho compatível~~.

Fim dos novos requisitos

[C-1-3] É PRECISO incluir uma ou mais portas USB com suporte para o modo de host USB e o modo de periférico USB.
[C-1-4] É PRECISO informar o suporte ao recurso android.software.midi.

Início dos novos requisitos para o Android 15

[C-1-5] É PRECISO atender aos ~~latencies e~~ requisitos de latente de áudio USB usando a API AAudio nativa e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

Fim dos novos requisitos

[C-1-6] A latência de saída fria PRECISA ser de 200 milissegundos ou menos.
[C-1-7] A latência de entrada fria PRECISA ser de 200 milissegundos ou menos.

Início dos novos requisitos para o Android 15

[C-1-8] É OBRIGATÓRIO ter uma latência média de Tap-to-Tone de 80 milissegundos ou menos em pelo menos cinco medições no caminho de dados do alto-falante para o microfone.

[C-SR-1] É ALTAMENTE RECOMENDADO atender às latências conforme definido na seção 5.6 Latência de áudio, de 20 milissegundos ou menos, em mais de cinco medições com uma Desvio absoluto médio inferior a 5 milissegundos no caminho do alto-falante para o microfone.

[C-SR-2] É ALTAMENTE RECOMENDADO atender aos requisitos do Pro Audio para latívia contínua de ida e volta de áudio, latência de entrada fria e latência de saída fria e requisitos de áudio USB usando a API AAudio native audio no caminho MMAP.

[C-SR-3] É ALTAMENTE RECOMENDADO fornecer um nível consistente de desempenho da CPU enquanto o áudio está ativo e a carga da CPU está variando. Isso precisa ser testado usando o app Android SynthMark. O SynthMark usa um sintetizador de software executado em um framework de áudio simulado que mede o desempenho do sistema. Consulte a documentação do SynthMark para uma explicação dos comparativos. O app SynthMark precisa ser executado usando a opção "Teste automático" e alcançar os seguintes resultados:

voicemark.90 >= 32 vozes

latencymark.fixed.little <= 15 msec

latencymark.dynamic.little <= 50 msec

DEVE minimizar a imprecisão e a deriva do relógio de áudio em relação ao horário padrão.

DEVE minimizar a deriva do relógio de áudio em relação à CLOCK_MONOTONIC da CPU quando ambos estão ativos.

DEVE minimizar a latência de áudio em transdutores no dispositivo.

DEVE minimizar a latência de áudio por áudio digital USB.

DEVE documentar as medições de latência de áudio em todos os caminhos.

DEVE minimizar o jitter nos tempos de entrada de callback de conclusão do buffer de áudio, já que isso afeta a porcentagem utilizável da largura de banda total da CPU pelo callback.

DEVE não apresentar falhas de áudio no uso normal com a latência informada.

DEVE fornecer zero diferença de latência entre canais.

DEVE minimizar a latência média do MIDI em todos os transportes.

DEVE minimizar a variabilidade da latência MIDI sob carga (jitter) em todos os transportes.

DEVE fornecer carimbos de data/hora MIDI precisos em todos os transportes.

DEVE minimizar o ruído do sinal de áudio em transdutores no dispositivo, incluindo o período imediatamente após a inicialização a frio.

DEVEM fornecer zero diferença de relógio de áudio entre os lados de entrada e saída dos pontos finais correspondentes, quando ambos estiverem ativos. Exemplos de pontos finais correspondentes incluem o microfone e o alto-falante no dispositivo ou a entrada e a saída de áudio.

DEVE processar callbacks de conclusão de buffer de áudio para os lados de entrada e saída dos endpoints correspondentes na mesma linha de execução quando ambos estão ativos e entrar no callback de saída imediatamente após o retorno do callback de entrada. Ou, se não for viável processar os callbacks na mesma linha de execução, insira o callback de saída logo após inserir o callback de entrada para permitir que o aplicativo tenha um tempo consistente dos lados de entrada e saída.

DEVE minimizar a diferença de fase entre o buffer de áudio HAL para os lados de entrada e saída dos endpoints correspondentes.

DEVE minimizar a latência de toque.

DEVE minimizar a variabilidade da latência do toque sob carga (jitter).

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

Se as implementações do dispositivo atenderem a todos os requisitos acima, elas:

[C-SR-4] É ALTAMENTE RECOMENDADO informar o suporte para o recurso android.hardware.audio.pro usando a classe android.content.pm.PackageManager.

Fim dos novos requisitos

Se as implementações do dispositivo incluírem um conector de áudio de 3,5 mm com quatro condutores, elas:

Início dos novos requisitos para o Android 15

[C-2-1] É PRECISO ter uma latência de áudio de ida e volta contínua média, conforme definido na seção 5.6 Latência de áudio, de 20 milissegundos ou menos, em 5 medições com uma Média absoluta de desvio inferior a 5 milissegundos no caminho da entrada de áudio usando um dongle de retorno de áudio.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

[C-2-2] ~~[C-SR-5]~~ ~~É ALTAMENTE RECOMENDÁVEL~~ SERÃO OBRIGATORIAMENTE em conformidade com a seção Especificações de dispositivo móvel (jack) da Especificação de fone de ouvido com áudio com fio (v1.1).

Fim dos novos requisitos

Se as implementações do dispositivo omitirem uma entrada de áudio de 3,5 mm com quatro condutores e incluírem portas USB com suporte ao modo host USB, elas:

[C-3-1] É PRECISO implementar a classe de áudio USB.

Início dos novos requisitos para o Android 15

[C-3-2] É PRECISO ter uma latência de áudio de ida e volta contínua média de 25 milissegundos ou menos, em 5 medições com uma média absoluta de desvio menor que 5 milissegundos na porta do modo host USB usando a classe de áudio USB. Isso pode ser medido usando um adaptador USB-3, 5 mm e um dongle de áudio loopback ou usando uma interface de áudio USB com cabos de patch conectando as entradas às saídas.

[C-SR-6] É ALTAMENTE RECOMENDADO que ofereça suporte a E/S simultânea de até 8 canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usado com periféricos de áudio USB que também oferecem suporte a esses requisitos.

[C-SR-7] É ALTAMENTE RECOMENDADO atender a esse grupo de requisitos usando a API de áudio nativa AAudio no caminho MMAP.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

Se as implementações do dispositivo incluem uma porta HDMI, elas:

DEVE oferecer suporte à saída em estéreo e oito canais com profundidade de 20 ou 24 bits e 192 kHz sem perda de profundidade de bits ou reamostragem, em pelo menos uma configuração.

Fim dos novos requisitos

5.11. Captura para "Não processado"

O Android inclui suporte para gravação de áudio não processado pela fonte de áudio android.media.MediaRecorder.AudioSource.UNPROCESSED. No OpenSL ES, ele pode ser acessado com a predefinição de gravação SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Se as implementações de dispositivos tiverem a intenção de oferecer suporte à fonte de áudio não processada e disponibilizá-la para apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO informar o suporte usando a propriedade android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] É PRECISO mostrar características aproximadamente planas de amplitude em relação à frequência na faixa de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz para cada microfone usado para gravar a fonte de áudio não processada.
[C-1-3] É PRECISO mostrar níveis de amplitude no intervalo de baixa frequência: especificamente de ±20 dB de 5 z a 100 Hz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio não processada.
[C-1-4] É PRECISO mostrar níveis de amplitude no intervalo de alta frequência: especificamente de ±30 dB de 7000 Hz a 22 kHz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio não processada.
[C-1-5] É PRECISO definir a sensibilidade de entrada de áudio de modo que uma fonte de tom senoidal de 1000 Hz tocada a 94 dB de nível de pressão sonora (SPL, na sigla em inglês) gere uma resposta com RMS de 520 para amostras de 16 bits (ou -36 dB em escala completa para amostras de ponto flutuante/dupla precisão) para cada microfone usado para gravar a fonte de áudio não processada.
[C-1-6] É OBRIGATÓRIO ter uma proporção de sinal-ruído (SNR) de 60 dB ou mais para cada microfone usado para gravar a fonte de áudio não processada. O SNR é medido como a diferença entre 94 dB SPL e SPL equivalente do ruído próprio, ponderado em A.
[C-1-7] É PRECISO ter uma distorção harmônica total (THD) menor que 1% para 1 kHZ a 90 dB SPL de nível de entrada em cada microfone usado para gravar a fonte de áudio não processada.
[C-1-8] NÃO é permitido ter nenhum outro processamento de sinal (por exemplo, controle de ganho automático, filtro passa-alta ou cancelamento de eco) no caminho, exceto um multiplicador de nível para levar o nível ao intervalo desejado. Resumindo:
- [C-1-9] Se qualquer processamento de sinal estiver presente na arquitetura por qualquer motivo, ele PRECISA ser desativado e efetivamente introduzir zero atraso ou latência extra no caminho do sinal.
- [C-1-10] O multiplicador de nível, embora permitido no caminho, NÃO PODE introduzir atraso ou latência no caminho do sinal.

Todas as medições de SPL são feitas diretamente ao lado do microfone em teste. Para várias configurações de microfone, esses requisitos se aplicam a cada microfone.

Se as implementações do dispositivo declararem android.hardware.microphone, mas não oferecerem suporte à fonte de áudio não processada, elas:

[C-2-1] DEVE retornar null para o método da API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) para indicar corretamente a falta de suporte.
[C-SR-1] ainda é FORTEMENTE RECOMENDADO para atender a tantos requisitos quanto possível para o caminho do sinal da fonte de gravação não processada.

5.12. Vídeo HDR

O Android 13 oferece suporte às tecnologias HDR conforme descrito em um documento futuro.

Formato de pixel

Se um decodificador de vídeo anunciar suporte para COLOR_FormatYUVP010, então:

[C-1-1] DEVE oferecer suporte ao formato P010 para leitura de CPU (ImageReader, MediaImage, ByteBuffer). No Android 13, o P010 foi relaxado para permitir o passo arbitrário para os planos Y e UV.
[C-1-2] O buffer de saída P010 PRECISA ser amostrado pela GPU (quando alocado com o uso de GPU_SAMPLING). Isso permite a composição da GPU e o mapeamento de tons personalizados pelos apps.

Se um decodificador de vídeo anunciar suporte para COLOR_Format32bitABGR2101010, ele:

[C-2-1] É PRECISO oferecer suporte ao formato RGBA_1010102 para a superfície de saída e ser legível pela CPU (saída ByteBuffer).

Se um codificador de vídeo anunciar suporte para COLOR_FormatYUVP010, ele:

[C-3-1] PRECISA oferecer suporte ao formato P010 para entrada de superfície e entrada (ImageWriter, MediaImage, ByteBuffer) gravável pela CPU.

Se um codificador de vídeo anunciar suporte para COLOR_Format32bitABGR2101010, ele:

[C-4-1] PRECISA oferecer suporte ao formato RGBA_1010102 para a superfície de entrada e a entrada (ImageWriter, ByteBuffer) gravável pela CPU. Observação: a conversão entre várias curvas de transferência NÃO é necessária para codificadores.

Requisitos de captura HDR

Para todos os codificadores de vídeo compatíveis com perfis HDR, implementações de dispositivo:

[C-5-1] NÃO é permitido presumir que os metadados HDR sejam precisos. Por exemplo, o frame codificado pode ter pixels além do nível máximo de luminância ou o histograma pode não ser representativo do frame.
AGREGAR metadados dinâmicos HDR para gerar metadados estáticos HDR adequados para streams codificados e exibir esses metadados no final de cada sessão de codificação.

Se as implementações do dispositivo oferecerem suporte à captura HDR usando as APIs CamcorderProfile, elas:

[C-6-1] PRECISA oferecer suporte à captura HDR pelas APIs Camera2.
[C-6-2] É PRECISO oferecer suporte a pelo menos um codificador de vídeo com aceleração de hardware para cada tecnologia HDR com suporte.
[C-6-3] É OBRIGATÓRIO oferecer suporte (no mínimo) à captura HLG.
[C-6-4] É PRECISO oferecer suporte à gravação dos metadados HDR (se aplicável à tecnologia HDR) no arquivo de vídeo capturado. Para AV1, HEVC e DolbyVision, isso significa incluir os metadados no fluxo de bits codificado.
[C-6-5] PRECISA oferecer suporte a P010 e COLOR_FormatYUVP010.
[C-6-6] É PRECISO oferecer suporte ao mapeamento de tons HDR para SDR no decodificador padrão com aceleração de hardware para o perfil capturado. Em outras palavras, se um dispositivo pode capturar HDR10+ HEVC, o decodificador HEVC padrão PRECISA ser capaz de decodificar o stream capturado em SDR.

Requisitos de edição em HDR

Se as implementações de dispositivos incluírem codificadores de vídeo compatíveis com a edição HDR, elas:

DEVE usar a latência mínima para gerar os metadados HDR quando eles não estiverem presentes e DEVE lidar com situações em que os metadados estiverem presentes em alguns frames e não em outros. Esses metadados precisam ser precisos (por exemplo, representar a luminância máxima real e o histograma do frame).

Se a implementação do dispositivo incluir codecs compatíveis com FEATURE_HdrEditing, esses codecs:

[C-7-1] É PRECISO oferecer suporte a pelo menos um perfil HDR.
[C-7-2] É PRECISO oferecer suporte a FEATURE_HdrEditing para todos os perfis HDR anunciados por esse codec. Em outras palavras, eles PRECISAM oferecer suporte à geração de metadados HDR quando não estiverem presentes em todos os perfis HDR com suporte que usam metadados HDR.
[C-7-3] É PRECISO oferecer suporte aos seguintes formatos de entrada do codificador de vídeo que preservem totalmente o sinal descodificado HDR:
- RGBA_1010102 (já na curva de transferência de destino) para a superfície de entrada e ByteBuffer e PRECISA anunciar suporte para COLOR_Format32bitABGR2101010.

Se a implementação do dispositivo incluir codecs com suporte a FEATURE_HdrEditing, o dispositivo:

[C-7-4] É PRECISO anunciar suporte para a extensão OpenGL EXT_YUV_target.

6. Compatibilidade de ferramentas e opções para desenvolvedores

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

[C-0-1] É PRECISO oferecer suporte às Ferramentas para Desenvolvedores Android fornecidas no SDK do Android.
Android Debug Bridge (adb)

Início dos novos requisitos para o Android 15

[C-0-2] É PRECISO oferecer suporte ao adb conforme documentado no SDK do Android e aos comandos shell fornecidos no AOSP, que podem ser usados por desenvolvedores de apps, incluindo dumpsys, cmd stats e Simpleperf.

Fim dos novos requisitos

[C-0-11] É PRECISO ter suporte ao comando de shell cmd testharness. A atualização de implementações de dispositivos de uma versão anterior do Android sem um bloqueio de dados persistente PODE ser isenta da C-0-11.
[C-0-3] NÃO mude o formato ou o conteúdo dos eventos do sistema do dispositivo (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrados pelo comando dumpsys.

Início dos novos requisitos para o Android 15

[C-0-10] É OBRIGATÓRIO registrar, sem omissão, e tornar os eventos a seguir acessíveis e disponíveis para o comando de shell cmd stats e a classe da API System StatsManager.
- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged

Fim dos novos requisitos

[C-0-4] O demônio adb do dispositivo PRECISA estar inativo por padrão, e PRECISA haver um mecanismo acessível ao usuário para ativar a ponte de depuração do Android.
[C-0-5] É PRECISO oferecer suporte ao adb seguro. O Android inclui suporte para o adb seguro. O adb seguro ativa o adb em hosts autenticados conhecidos.
[C-0-6] É PRECISO fornecer um mecanismo que permita que o adb seja conectado de uma máquina host. Especificamente:

Se as implementações de dispositivos sem uma porta USB oferecerem suporte ao modo periférico, elas:

[C-3-1] É PRECISO implementar o adb por uma rede local (como Ethernet ou Wi-Fi).
[C-3-2] É PRECISO fornecer drivers para Windows 7, 8 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.

Se as implementações do dispositivo oferecerem suporte a conexões adb para uma máquina host via Wi-Fi ou Ethernet, elas:

[C-4-1] O método AdbManager#isAdbWifiSupported() PRECISA retornar true.

Se as implementações do dispositivo oferecerem suporte a conexões adb para uma máquina host via Wi-Fi ou Ethernet e incluírem pelo menos uma câmera, elas:

[C-5-1] O método AdbManager#isAdbWifiQrSupported() PRECISA retornar true.

Serviço de monitoramento de depuração do Dalvik (ddms)
- [C-0-7] É PRECISO oferecer suporte a todos os recursos do ddms, conforme documentado no SDK do Android. Como os ddms usam o adb, o suporte a eles DEVE estar inativo por padrão, mas PRECISA ser compatível sempre que o usuário tiver ativado a ponte de depuração do Android, como acima.
SysTrace
- [C-0-9] PRECISA oferecer suporte à ferramenta systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão, e é PRECISO ter um mecanismo acessível ao usuário para ativar o Systrace.
Perfetto
- [C-SR-1] É ALTAMENTE RECOMENDADO expor um binário /system/bin/perfetto ao usuário do shell, em que o cmdline obedece à documentação do perfetto.
- [C-SR-2] O binário do perfetto é ALTAMENTE RECOMENDADO para aceitar como entrada uma configuração protobuf que obedece ao esquema definido na documentação do perfetto.
- [C-SR-3] O binário do Perfetto é ALTAMENTE RECOMENDADO para gravar como saída um traço protobuf que obedece ao esquema definido na documentação do Perfetto.
- [C-SR-4] É ALTAMENTE RECOMENDADO fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto.
Low Memory Killer
- [C-0-12] É PRECISO gravar um átomo LMK_KILL_OCCURRED_FIELD_NUMBER no registro statsd quando um app é encerrado pelo Low Memory Killer.
Modo de teste do arcabouço Se as implementações do dispositivo oferecem suporte ao comando de shell cmd testharness e executam cmd testharness enable, elas:
- [C-2-1] PRECISA retornar true para ActivityManager.isRunningInUserTestHarness()
- [C-2-2] É OBRIGATÓRIO implementar o modo de arcabouço de testes conforme descrito na documentação do modo de arcabouço de testes.
Informações de trabalho da GPU

Implementações de dispositivos:
- [C-0-13] É PRECISO implementar o comando de shell dumpsys gpu --gpuwork para mostrar os dados de trabalho da GPU agregados retornados pelo ponto de rastreamento do kernel power/gpu_work_period ou não mostrar dados se o ponto de rastreamento não tiver suporte. A implementação do AOSP é frameworks/native/services/gpuservice/gpuwork/.

Se as implementações do dispositivo informarem o suporte ao Vulkan 1.0 ou mais recente usando as flags de recursos android.hardware.vulkan.version, elas:

[C-1-1] É PRECISO fornecer uma capacidade para que o desenvolvedor do app ative/desative as camadas de depuração de GPU.
[C-1-2] PRECISA, quando as camadas de depuração da GPU estão ativadas, enumerar camadas em bibliotecas fornecidas por ferramentas externas (ou seja, que não fazem parte da plataforma ou do pacote de aplicativos) encontradas no diretório base de aplicativos depuráveis para oferecer suporte a vkEnumerateInstanceLayerProperties() e métodos de API vkCreateInstance().

6.2. Opções do desenvolvedor

O Android inclui suporte para que os desenvolvedores configurem as configurações relacionadas ao desenvolvimento de apps.

As implementações de dispositivos precisam oferecer uma experiência consistente para as Opções do desenvolvedor. Elas:

[C-0-1] É PRECISO honrar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar as configurações relacionadas ao desenvolvimento do aplicativo. A implementação upstream do Android esconde o menu "Opções do desenvolvedor" por padrão e permite que os usuários acessem as opções do desenvolvedor depois de pressionar sete (7) vezes no item de menu Configurações > Sobre o dispositivo > Número da versão.
[C-0-2] É OBRIGATÓRIO ocultar as opções de desenvolvedor por padrão.
[C-0-3] É necessário fornecer um mecanismo claro que não dê tratamento preferencial a um app de terceiros em vez de outro para ativar as opções para desenvolvedores. É necessário fornecer um documento ou site visível publicamente que descreva como ativar as opções para desenvolvedores. Esse documento ou site PRECISA ser vinculado a documentos do SDK do Android.
DEVE ter uma notificação visual contínua para o usuário quando as opções de desenvolvedor estiverem ativadas e a segurança do usuário for uma preocupação.
PODE limitar temporariamente o acesso ao menu de opções para desenvolvedores, ocultando ou desativando o menu visualmente, para evitar distrações em cenários em que a segurança do usuário é uma preocupação.

7. Compatibilidade de hardware

Se um dispositivo incluir um componente de hardware específico que tenha uma API correspondente para desenvolvedores terceirizados:

[C-0-1] A implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android.

Se uma API no SDK interagir com um componente de hardware declarado como opcional e a implementação do dispositivo não tiver esse componente:

[C-0-2] As definições de classe completas (como documentado pelo SDK) para as APIs do componente AINDA PRECISAM ser apresentadas.
[C-0-3] Os comportamentos da API precisam ser implementados como no-ops de maneira razoável.
[C-0-4] Os métodos da API precisam retornar valores nulos quando permitido pela documentação do SDK.
[C-0-5] Os métodos da API precisam retornar implementações sem operação de classes em que valores nulos não são permitidos pela documentação do SDK.
[C-0-6] Os métodos da API NÃO PODEM gerar exceções não documentadas pela documentação do SDK.
[C-0-7] As implementações de dispositivos PRECISAM informar consistentemente informações precisas de configuração de hardware usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para o mesmo fingerprint de build.

Um exemplo típico de um cenário em que esses requisitos se aplicam é a API de telefonia: mesmo em dispositivos que não são smartphones, essas APIs precisam ser implementadas como no-ops razoáveis.

7.1. Tela e gráficos

O Android inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts de interface de maneira adequada para o dispositivo, garantindo que os aplicativos de terceiros funcionem bem em vários tipos de telas e configurações de hardware. Uma tela compatível com o Android é uma tela que implementa todos os comportamentos e APIs descritos em Desenvolvedores do Android: visão geral da compatibilidade da tela, nesta seção (7.1) e nas subseções dela, bem como qualquer outro comportamento específico do tipo de dispositivo documentado na seção 2 deste CDD.

Implementações de dispositivos:

[C-0-1] POR PADRÃO, RENDERIZE APENAS APLICATIVOS DE TERCEIROS EM DISPLAYS COMPATÍVEIS COM ANDROID.

As unidades referenciadas pelos requisitos nesta seção são definidas da seguinte maneira:

tamanho físico diagonal. A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
density. O número de pixels englobados por uma extensão linear horizontal ou vertical de 1", expressa em pixels por polegada (ppi ou dpi, na sigla em inglês). Quando os valores de ppi e dpi são listados, o dpi horizontal e vertical precisa estar dentro do intervalo listado.
proporção. A proporção dos pixels da dimensão maior em relação à dimensão menor da tela. Por exemplo, uma tela de 480 x 854 pixels seria 854/480 = 1,779, ou aproximadamente "16:9".
pixel independente de densidade (dp). Uma unidade de pixel virtual normalizada para uma densidade de tela de 160. Para uma densidade d e um número de pixels p, o número de pixels dp independentes de densidade é calculado como: dp = (160 / d) * p.

7.1.1. Configuração da tela

7.1.1.1. Tamanho e forma da tela

O framework de interface do Android oferece suporte a vários tamanhos de layout lógico de tela e permite que os aplicativos consultem o tamanho do layout da tela da configuração atual usando Configuration.screenLayout com SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO informar o tamanho correto do layout para o Configuration.screenLayout, conforme definido na documentação do SDK do Android. Especificamente, as implementações de dispositivo precisam informar as dimensões corretas de pixels (dp) independentes de densidade lógica, conforme abaixo:
- Dispositivos com o Configuration.uiMode definido como qualquer valor diferente de UI_MODE_TYPE_WATCH e que informem um tamanho small para o Configuration.screenLayout, PRECISAM ter pelo menos 426 dp x 320 dp.
- Os dispositivos que informam um tamanho normal para o Configuration.screenLayout PRECISAM ter pelo menos 480 dp x 320 dp.
- Os dispositivos que informam um tamanho large para o Configuration.screenLayout PRECISAM ter pelo menos 640 dp x 480 dp.
- Os dispositivos que informam um tamanho xlarge para o Configuration.screenLayout PRECISAM ter pelo menos 960 dp x 720 dp.
[C-0-2] É PRECISO respeitar corretamente o suporte declarado dos aplicativos para tamanhos de tela usando o atributo <supports-screens> no AndroidManifest.xml, conforme descrito na documentação do SDK do Android.
PODE ter telas compatíveis com Android com cantos arredondados.

Se as implementações de dispositivo oferecerem suporte a telas com a configuração de tamanho UI_MODE_TYPE_NORMAL e usarem telas físicas com cantos arredondados para renderizar essas telas, elas:

[C-1-1] É OBRIGATÓRIO garantir que pelo menos um dos seguintes requisitos seja atendido para cada tela:
- O raio dos cantos arredondados é menor ou igual a 38 dp.
- Quando uma caixa de 18 dp por 18 dp é ancorada em cada canto da tela lógica, pelo menos um pixel de cada caixa fica visível na tela.
DEVE incluir a capacidade do usuário de mudar para o modo de exibição com os cantos retangulares.

Se as implementações de dispositivos forem capazes apenas de configurar o teclado NO_KEYS e quiserem informar suporte para a configuração do modo de IU UI_MODE_TYPE_NORMAL, elas:

[C-4-1] É OBRIGATÓRIO ter um tamanho de layout, excluindo recortes de tela, de pelo menos 596 dp x 384 dp ou maior.

Para detalhes sobre como implementar corretamente as APIs sidecar ou de extensão, consulte a documentação pública do Jetpack Window Manager.

Início dos novos requisitos para o Android 15

Se as implementações do dispositivo incluírem uma ou mais áreas de exibição compatíveis com o Android que sejam dobráveis ou incluírem uma articulação dobrável entre várias áreas de painel de exibição compatíveis com o Android e disponibilizarem essas áreas de exibição para os aplicativos, elas:

[C-4-1] É PRECISO implementar a versão correta do nível da API WindowManagerExtensions, conforme descrito em WindowManagerExtensions.

Fim dos novos requisitos

7.1.1.2. Proporção da tela

Esta seção foi excluída no Android 14.

7.1.1.3. Densidade da tela

O framework de IU do Android define um conjunto de densidades lógicas padrão para ajudar os desenvolvedores de apps a segmentar os recursos do app.

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO informar uma das densidades do framework do Android listadas em DisplayMetrics pela API DENSITY_DEVICE_STABLE. Esse valor precisa ser estático para cada tela física. No entanto, o dispositivo PODE informar um DisplayMetrics.density diferente de acordo com as mudanças na configuração da tela feitas pelo usuário (por exemplo, tamanho da tela) definidas após a inicialização inicial.
DEVEM definir a densidade do framework padrão do Android que é numericamente mais próxima da densidade física da tela ou um valor que seria mapeado para as mesmas medidas angulares equivalentes de campo de visão de um dispositivo portátil.

Se as implementações do dispositivo oferecerem uma capacidade para mudar o tamanho de exibição do dispositivo, elas:

[C-1-1] PRECISA NÃO dimensionar a tela mais de 1,5 vezes DENSITY_DEVICE_STABLE ou produzir uma dimensão mínima de tela eficaz menor que 320 dp (equivalente ao qualificador de recurso sw320dp), o que ocorrer primeiro.
[C-1-2] NÃO É PERMITIDO dimensionar a tela menor que 0,85 vezes o DENSITY_DEVICE_STABLE.
Para garantir uma boa usabilidade e tamanhos de fonte consistentes, é RECOMENDÁVEL que a escalação a seguir das opções de exibição nativa seja fornecida (atendendo aos limites especificados acima)
- Pequeno: 0,85x
- Padrão: 1x (escala de tela nativa)
- Grande: 1,15x
- Maior: 1,3x
- Maior: 1,45x

7.1.2. Métricas de tela

Se as implementações de dispositivos incluírem telas ou saídas de vídeo compatíveis com o Android, elas:

[C-1-1] É PRECISO informar os valores corretos para todas as métricas de exibição compatíveis com o Android definidas na API android.util.DisplayMetrics.

Se as implementações de dispositivos não incluírem uma tela ou saída de vídeo incorporada, elas:

[C-2-1] É PRECISO informar os valores corretos da tela compatível com Android conforme definido na API android.util.DisplayMetrics para o view.Display padrão emulado.

7.1.3. Orientação da tela

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO informar quais orientações de tela são compatíveis (android.hardware.screen.portrait e/ou android.hardware.screen.landscape) e é OBRIGATÓRIO informar pelo menos uma orientação compatível. Por exemplo, um dispositivo com uma tela de orientação paisagem fixa, como uma televisão ou um laptop, DEVE informar apenas android.hardware.screen.landscape.
[C-0-2] É OBRIGATÓRIO informar o valor correto para a orientação atual do dispositivo, sempre que consultado pela android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.

Se as implementações do dispositivo oferecerem suporte a ambas as orientações da tela, elas:

[C-1-1] PRECISA oferecer suporte à orientação dinâmica por aplicativos para orientação de tela retrato ou paisagem. Ou seja, o dispositivo precisa respeitar a solicitação do aplicativo para uma orientação de tela específica.
[C-1-2] O tamanho ou a densidade da tela NÃO PODEM mudar quando a orientação é alterada.
PODE selecionar a orientação retrato ou paisagem como padrão.

7.1.4. Aceleração gráfica 2D e 3D

7.1.4.1. OpenGL ES

Implementações de dispositivos:

[C-0-1] É PRECISO identificar corretamente as versões OpenGL ES com suporte (1.1, 2.0, 3.0, 3.1, 3.2) pelas APIs gerenciadas (como pelo método GLES10.getString()) e pelas APIs nativas.
[C-0-2] É PRECISO incluir o suporte a todas as APIs gerenciadas e nativas correspondentes para todas as versões do OpenGL ES identificadas.

Se as implementações do dispositivo incluem uma saída de tela ou vídeo, elas:

Início dos novos requisitos para o Android 15

[C-1-1] É PRECISO oferecer suporte a ~~ambos~~ OpenGL ES 1.1, e 2.0, 3.0 e 3.1, conforme detalhado na documentação do SDK do Android.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

~~[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao OpenGL ES 3.1.~~

Fim dos novos requisitos

DEVE ter suporte ao OpenGL ES 3.2.

Os testes dEQP do OpenGL ES são divididos em várias listas de teste, cada uma com um número de data/versão associado. Eles estão na árvore de origem do Android em external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Um dispositivo que oferece suporte ao OpenGL ES em um nível informado por ele mesmo indica que pode passar nos testes dEQP em todas as listas de teste a partir desse nível.

Se as implementações do dispositivo forem compatíveis com qualquer uma das versões do OpenGL ES, elas:

[C-2-1] É OBRIGATÓRIO informar por meio das APIs gerenciadas e nativas do OpenGL ES outras extensões do OpenGL ES que foram implementadas e, inversamente, NÃO é permitido informar strings de extensão que não são compatíveis.
[C-2-2] PRECISA oferecer suporte às extensões EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
[C-2-3] É OBRIGATÓRIO informar a versão máxima dos testes dEQP do OpenGL ES com suporte à flag de recurso android.software.opengles.deqp.level.
[C-2-4] É PRECISO oferecer suporte à versão 132383489 (de 1º de março de 2020) como informado na flag de recurso android.software.opengles.deqp.level.
[C-2-5] É PRECISO passar em todos os testes dEQP do OpenGL ES nas listas de teste entre a versão 132383489 e a versão especificada na flag de recurso android.software.opengles.deqp.level, para cada versão do OpenGL ES com suporte.
[C-SR-2] É ALTAMENTE RECOMENDADO oferecer suporte às extensões EGL_KHR_partial_update e OES_EGL_image_external.
DEVE informar com precisão, pelo método getString(), qualquer formato de compactação de textura compatível, que geralmente é específico do fornecedor.
DEVEM oferecer suporte às extensões EGL_IMG_context_priority e EGL_EXT_protected_content.

Se as implementações do dispositivo declararem suporte ao OpenGL ES 3.0, 3.1 ou 3.2, elas:

[C-3-1] É OBRIGATÓRIO exportar os símbolos de função correspondentes para essas versões, além dos símbolos de função do OpenGL ES 2.0 na biblioteca libGLESv2.so.
[C-SR-3] É ALTAMENTE RECOMENDADO oferecer suporte à extensão OES_EGL_image_external_essl3.

Se as implementações do dispositivo forem compatíveis com o OpenGL ES 3.2, elas:

[C-4-1] PRECISA oferecer suporte ao pacote de extensão OpenGL ES para Android na íntegra.

Se as implementações do dispositivo oferecerem suporte ao pacote de extensões para Android do OpenGL ES na íntegra, elas:

[C-5-1] É OBRIGATÓRIO identificar o suporte usando a flag de recurso android.hardware.opengles.aep.

Se as implementações do dispositivo oferecerem suporte à extensão EGL_KHR_mutable_render_buffer, elas:

[C-6-1] É PRECISO ter suporte à extensão EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2. Vulkan

O Android inclui suporte ao Vulkan, uma API multiplataforma de baixa sobrecarga para gráficos 3D de alto desempenho.

Se as implementações do dispositivo forem compatíveis com o OpenGL ES 3.1, elas:

[C-SR-1] É ALTAMENTE RECOMENDADO incluir suporte ao Vulkan 1.3.
[C-4-1] NÃO pode oferecer suporte a uma versão da variante do Vulkan (ou seja, a parte variante da versão principal do Vulkan PRECISA ser zero).

Se as implementações do dispositivo incluem uma saída de tela ou vídeo, elas:

[C-SR-2] É ALTAMENTE RECOMENDADO incluir suporte ao Vulkan 1.3.

Os testes dEQP do Vulkan são divididos em várias listas de teste, cada uma com uma data/versão associada. Eles estão na árvore de origem do Android em external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Um dispositivo que oferece suporte ao Vulkan em um nível informado por ele mesmo indica que pode passar nos testes dEQP em todas as listas de teste a partir desse nível.

Se as implementações do dispositivo incluem suporte ao Vulkan, elas:

[C-1-1] É OBRIGATÓRIO informar o valor inteiro correto com os flags de recursos android.hardware.vulkan.level e android.hardware.vulkan.version.
[C-1-2] É PRECISO enumerar pelo menos um VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices().
[C-1-3] É PRECISO implementar totalmente as APIs Vulkan 1.1 para cada VkPhysicalDevice enumerado.
[C-1-4] É NECESSÁRIO enumerar camadas contidas em bibliotecas nativas nomeadas como libVkLayer*.so no diretório de bibliotecas nativas do pacote de aplicativos, por meio das APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties().
[C-1-5] NÃO ENUMERE camadas fornecidas por bibliotecas fora do pacote do aplicativo nem forneça outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o atributo android:debuggable definido como true ou os metadados com.android.graphics.injectLayers.enable definidos como true.
[C-1-6] É PRECISO informar todas as strings de extensão com suporte pelo APIs nativas do Vulkan e, inversamente, NÃO é PRECISO informar strings de extensão que não têm suporte.
[C-1-7] É PRECISO oferecer suporte às extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
[C-1-8] É PRECISO informar a versão máxima dos testes dEQP do Vulkan com suporte à flag de recurso android.software.vulkan.deqp.level.
[C-1-9] É PRECISO oferecer suporte à versão 132317953 (de 1º de março de 2019) conforme informado na flag de recurso android.software.vulkan.deqp.level.
[C-1-10] É PRECISO passar em todos os testes dEQP do Vulkan nas listas de teste entre a versão 132317953 e a versão especificada na flag de recurso android.software.vulkan.deqp.level.
[C-1-11] NÃO É PERMITIDO enumerar o suporte para as extensões VK_KHR_video_queue, VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.
[C-SR-3] É ALTAMENTE RECOMENDADO oferecer suporte às extensões VK_KHR_driver_properties e VK_GOOGLE_display_timing.
[C-1-12] NÃO É PERMITIDO enumerar o suporte à extensão VK_KHR_performance_query.
[C-SR-4] É FORTEMENTE RECOMENDADO atender aos requisitos especificados pelo perfil de referência do Android 2022.
[C-SR-5] É ALTAMENTE RECOMENDADO oferecer suporte a VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_EXT_global_priority.
[C-SR-6] É ALTAMENTE RECOMENDADO usar SkiaVk com HWUI.

Início dos novos requisitos para o Android 15

Se as implementações do dispositivo incluem suporte ao Vulkan, elas:

[C-SR-8] É ALTAMENTE RECOMENDADO não modificar o carregador do Vulkan.
[C-1-14] NÃO ENUMERE extensões de dispositivo Vulkan do tipo "KHR", "GOOGLE" ou "ANDROID", a menos que essas extensões sejam incluídas na flag de recurso android.software.vulkan.deqp.level.

Fim dos novos requisitos

Se as implementações do dispositivo não incluírem suporte ao Vulkan 1.0, elas:

[C-2-1] NÃO declarar nenhuma das flags de recursos do Vulkan (por exemplo, android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] NÃO É PERMITIDO enumerar nenhum VkPhysicalDevice para a API nativa vkEnumeratePhysicalDevices() do Vulkan.

Se as implementações do dispositivo incluírem suporte ao Vulkan 1.1 e declararem qualquer uma das flags de recursos do Vulkan descritas aqui, elas:

[C-3-1] PRECISA expor suporte para o semáforo externo SYNC_FD e processar tipos e a extensão VK_ANDROID_external_memory_android_hardware_buffer.
[C-SR-7] É ALTAMENTE RECOMENDADO disponibilizar a extensão VK_KHR_external_fence_fd para aplicativos de terceiros e permitir que o aplicativo exporte e importe payloads de cerca de descritores de arquivos POSIX, conforme descrito aqui.

7.1.4.3. RenderScript

Implementações de dispositivos:

[C-0-1] É PRECISO oferecer suporte ao Android RenderScript, conforme detalhado na documentação do SDK do Android.

7.1.4.4. Aceleração gráfica 2D

O Android inclui um mecanismo para que os aplicativos declarem que querem ativar a aceleração de hardware para gráficos 2D no nível do aplicativo, da atividade, da janela ou da visualização usando uma tag de manifesto android:hardwareAccelerated ou chamadas diretas de API.

Implementações de dispositivos:

[C-0-1] PRECISA ativar a aceleração de hardware por padrão e PRECISA desativar a aceleração de hardware se o desenvolvedor solicitar isso definindo android:hardwareAccelerated="false" ou desativando a aceleração de hardware diretamente pelas APIs Android View.
[C-0-2] PRECISA apresentar um comportamento consistente com a documentação do SDK do Android sobre aceleração de hardware.

O Android inclui um objeto TextureView que permite que os desenvolvedores integrem diretamente texturas OpenGL ES aceleradas por hardware como destinos de renderização em uma hierarquia de IU.

Implementações de dispositivos:

[C-0-3] PRECISA oferecer suporte à API TextureView e PRECISA apresentar comportamento consistente com a implementação upstream do Android.

7.1.4.5. Telas de ampla gama

Se as implementações de dispositivos declararem suporte a telas de ampla gama de cores usando Configuration.isScreenWideColorGamut(), elas:

[C-1-1] É PRECISO ter uma tela com cores calibradas.
[C-1-2] É OBRIGATÓRIO ter uma tela com uma gama que cubra toda a gama de cores sRGB no espaço CIE 1931 xyY.
[C-1-3] É PRECISO ter uma tela com uma gama de pelo menos 90% de DCI-P3 no espaço CIE 1931 xyY.
[C-1-4] PRECISA oferecer suporte a OpenGL ES 3.1 ou 3.2 e informar corretamente.
[C-1-5] É PRECISO anunciar suporte para as extensões EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear e EGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte a GL_EXT_sRGB.

Por outro lado, se as implementações de dispositivos não oferecerem suporte a telas de ampla gama de cores, elas:

[C-2-1] DEVE abranger 100% ou mais do sRGB no espaço CIE 1931 xyY, embora a gama de cores da tela seja indefinida.

7.1.5. Modo de compatibilidade de aplicativo legado

O Android especifica um "modo de compatibilidade" em que a estrutura opera em um modo de tamanho de tela "normal" equivalente (largura de 320 dp) para beneficiar aplicativos legados que não foram desenvolvidos para versões antigas do Android que antecedem a independência do tamanho da tela.

7.1.6. Tecnologia da tela

A plataforma Android inclui APIs que permitem que os aplicativos renderizem gráficos avançados em uma tela compatível com o Android. Os dispositivos precisam oferecer suporte a todas essas APIs, conforme definido pelo SDK do Android, a menos que seja permitido especificamente neste documento.

Todas as telas compatíveis com Android de uma implementação de dispositivo:

[C-0-1] PRECISA ser capaz de renderizar gráficos coloridos de 16 bits.
DEVE oferecer suporte a telas com gráficos coloridos de 24 bits.
[C-0-2] PRECISA ser capaz de renderizar animações.
[C-0-3] PRECISA ter uma proporção de pixels (PAR) entre 0,9 e 1,15. Ou seja, a proporção de pixels PRECISA estar próxima do quadrado (1,0) com uma tolerância de 10 a 15%.

7.1.7. Telas secundárias

O Android inclui suporte a telas secundárias compatíveis com o Android para ativar recursos de compartilhamento de mídia e APIs para desenvolvedores acessarem telas externas.

Se as implementações de dispositivos oferecerem suporte a uma tela externa por uma conexão de tela adicional embutida, com ou sem fio, elas:

[C-1-1] É OBRIGATÓRIO implementar o serviço do sistema e a API DisplayManager, conforme descrito na documentação do SDK do Android.

7.2. Dispositivos de entrada

Implementações de dispositivos:

[C-0-1] É PRECISO incluir um mecanismo de entrada, como uma tela tátil ou navegação sem toque, para navegar entre os elementos da interface.

7.2.1. Teclado

Se as implementações de dispositivos incluírem suporte a aplicativos de Editor de método de entrada (IME) de terceiros, elas:

[C-1-1] É PRECISO declarar a flag de recurso android.software.input_methods.
[C-1-2] É PRECISO implementar totalmente o Input Management Framework.
[C-1-3] É OBRIGATÓRIO ter um teclado de software pré-instalado.

Implementações de dispositivos:

[C-0-1] NÃO É PERMITIDO incluir um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.keyboard (QWERTY ou 12 teclas).
DEVE incluir outras implementações de teclado virtual.
PODE incluir um teclado de hardware.

7.2.2. Navegação sem toque

O Android inclui suporte para botão direcional, trackball e roda como mecanismos para navegação sem toque.

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO informar o valor correto para android.content.res.Configuration.navigation.

Se as implementações de dispositivos não tiverem navegações sem toque, elas:

[C-1-1] É OBRIGATÓRIO fornecer um mecanismo de interface do usuário alternativo razoável para a seleção e edição de texto, compatível com mecanismos de gerenciamento de entrada. A implementação de código aberto upstream do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação não táctil.

7.2.3. Teclas de navegação

As funções Home, Recentes e Voltar normalmente fornecidas por uma interação com um botão físico dedicado ou uma parte distinta da tela touchscreen são essenciais para o paradigma de navegação do Android e, portanto, para implementações de dispositivos:

[C-0-1] É necessário fornecer uma capacidade do usuário para iniciar aplicativos instalados que tenham uma atividade com o <intent-filter> definido com ACTION=MAIN e CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER para implementações de dispositivos de TV. A função "Início" DEVE ser o mecanismo para essa affordance do usuário.
DEVE fornecer botões para a função "Recentes" e "Voltar".

Se as funções "Início", "Recentes" ou "Voltar" forem fornecidas, elas:

[C-1-1] PRECISA ser acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando qualquer uma delas for acessível.
[C-1-2] É PRECISO indicar claramente qual ação única aciona cada função. Exemplos de indicações são ter um ícone visível impresso no botão, mostrar um ícone de software na parte da barra de navegação da tela ou guiar o usuário por um fluxo de demonstração guiado durante a experiência de configuração pronta para uso.

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO não fornecer o mecanismo de entrada para a função Menu, já que ela foi descontinuada em favor da barra de ações desde o Android 4.0.
[C-SR-2] É ALTAMENTE RECOMENDADO fornecer todas as funções de navegação como canceláveis. "Cancelável" é definido como a capacidade do usuário de impedir a execução da função de navegação (por exemplo, voltar à tela inicial, voltar, etc.) se o deslize não for liberado após um determinado limite.

Se as implementações do dispositivo oferecerem a função Menu, elas:

[C-2-1] É OBRIGATÓRIO mostrar o botão de menu flutuante de ação sempre que o pop-up do menu flutuante de ação não estiver vazio e a barra de ação estiver visível.
[C-2-2] NÃO MODIFIQUE a posição do pop-up de acúmulo de ações exibido ao selecionar o botão de acúmulo na barra de ações, mas PODE renderizar o pop-up de acúmulo de ações em uma posição modificada na tela quando ele é exibido ao selecionar a função de menu.

Se as implementações do dispositivo não fornecerem a função Menu, para compatibilidade com versões anteriores, elas:

[C-3-1] É PRECISO disponibilizar a função de menu para os aplicativos quando targetSdkVersion for menor que 10, seja por um botão físico, uma tecla de software ou gestos. Essa função de menu precisa ser acessível, a menos que esteja oculta com outras funções de navegação.

Se as implementações do dispositivo oferecerem a função de assistência, elas:

[C-4-1] A função Assist precisa ser acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando outras teclas de navegação estiverem acessíveis.
[C-SR-3] É ALTAMENTE RECOMENDADO usar o toque longo na função HOME como essa interação designada.

Se as implementações do dispositivo usarem uma parte distinta da tela para mostrar as teclas de navegação, elas:

[C-5-1] As teclas de navegação PRECISAM usar uma parte distinta da tela, que não esteja disponível para aplicativos, e NÃO PODEM obscurecer ou interferir de outra forma na parte da tela disponível para aplicativos.
[C-5-2] PRECISA disponibilizar uma parte da tela para aplicativos que atendem aos requisitos definidos na seção 7.1.1.
[C-5-3] É OBRIGATÓRIO honrar as flags definidas pelo app pelo método de API View.setSystemUiVisibility(), para que essa parte distinta da tela (também conhecida como barra de navegação) seja oculta corretamente, conforme documentado no SDK.

Se a função de navegação for fornecida como uma ação baseada em gestos na tela:

[C-6-1] O WindowInsets#getMandatorySystemGestureInsets() SÓ pode ser usado para informar a área de reconhecimento de gestos da tela inicial.
[C-6-2] Os gestos que começam em um retângulo de exclusão, conforme fornecido pelo aplicativo em primeiro plano por meio de View#setSystemGestureExclusionRects(), mas fora de WindowInsets#getMandatorySystemGestureInsets(), NÃO PODEM ser interceptados para a função de navegação, desde que o retângulo de exclusão seja permitido dentro do limite máximo de exclusão, conforme especificado na documentação de View#setSystemGestureExclusionRects().
[C-6-3] É OBRIGATÓRIO enviar ao app em primeiro plano um evento MotionEvent.ACTION_CANCEL quando os toques começarem a ser interceptados para um gesto do sistema, se o app em primeiro plano tiver recebido anteriormente um evento MotionEvent.ACTION_DOWN.
[C-6-4] É OBRIGATÓRIO fornecer uma affordance para o usuário mudar para uma navegação baseada em botões na tela (por exemplo, nas Configurações).
DEVE fornecer a função "Início" como um deslizar para cima da borda inferior da orientação atual da tela.
DEVE fornecer a função "Recentes" como um gesto de deslizar para cima e segurar antes da liberação, na mesma área do gesto de "Início".
Os gestos que começam dentro WindowInsets#getMandatorySystemGestureInsets() NÃO PODEM ser afetados por retângulos de exclusão fornecidos pelo aplicativo em primeiro plano usando View#setSystemGestureExclusionRects().

Se uma função de navegação for fornecida em qualquer lugar nas bordas esquerda e direita da orientação atual da tela:

[C-7-1] A função de navegação PRECISA ser "Voltar" e ser fornecida como um deslize das bordas esquerda e direita da orientação atual da tela.
[C-7-2] Se painéis do sistema deslizáveis personalizados forem fornecidos nas bordas esquerda ou direita, eles PRECISAM ser colocados na parte superior de um terço da tela com uma indicação visual clara e persistente de que arrastar para dentro invocaria os painéis mencionados e, portanto, não a opção "Voltar". Um painel do sistema PODE ser configurado por um usuário para que ele fique abaixo da 1/3 superior das bordas da tela, mas o painel do sistema NÃO PODE usar mais de 1/3 das bordas.
[C-7-3] Quando o app em primeiro plano tem as flags View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE definidas, o gesto de deslizar nas bordas PRECISA se comportar como implementado no AOSP, que é documentado no SDK.
[C-7-4] Quando o app em primeiro plano tem as flags View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE definidas, painéis de sistema deslizáveis personalizados precisam ser ocultados até que o usuário os traga ou desfoque as barras do sistema (também conhecidas como barra de navegação e de status) conforme implementado no AOSP.

Se a função de navegação de volta for fornecida e o usuário cancelar o gesto "Voltar", então:

[C-8-1] OnBackInvokedCallback.onBackCancelled() PRECISA ser chamado.
[C-8-2] OnBackInvokedCallback.onBackInvoked() NÃO PODE ser chamado.
[C-8-3] O evento KEYCODE_BACK NÃO deve ser enviado.

Se a função de navegação de retorno for fornecida, mas o aplicativo em primeiro plano NÃO tiver um OnBackInvokedCallback registrado, faça o seguinte:

O sistema DEVE fornecer uma animação para o aplicativo em primeiro plano que sugere que o usuário está voltando, conforme fornecido no AOSP.

Se as implementações do dispositivo oferecerem suporte à API setNavBarMode do sistema para permitir que qualquer app do sistema com permissão android.permission.STATUS_BAR defina o modo da barra de navegação, elas:

[C-9-1] É NECESSÁRIO oferecer suporte a ícones adequados para crianças ou navegação baseada em botões, conforme fornecido no código do AOSP.

7.2.4. Entrada por touchscreen

O Android oferece suporte a vários sistemas de entrada de ponteiro, como telas sensíveis ao toque, touchpads e dispositivos de entrada falsos. As implementações de dispositivos baseadas em tela touchscreen são associadas a uma tela de modo que o usuário tem a impressão de manipular itens diretamente na tela. Como o usuário toca diretamente na tela, o sistema não exige recursos adicionais para indicar os objetos que estão sendo manipulados.

Implementações de dispositivos:

DEVE ter um sistema de entrada de ponteiro de algum tipo (semelhante a um mouse ou por toque).
DEVE oferecer suporte a ponteiros rastreados de forma totalmente independente.

Se as implementações do dispositivo incluírem uma tela touchscreen (single-touch ou melhor) em uma tela principal compatível com o Android, elas:

[C-1-1] É OBRIGATÓRIO informar TOUCHSCREEN_FINGER para o campo da API Configuration.touchscreen.
[C-1-2] É OBRIGATÓRIO informar as flags de recursos android.hardware.touchscreen e android.hardware.faketouch.

Se as implementações do dispositivo incluírem uma tela touchscreen que pode rastrear mais de um toque em uma tela principal compatível com o Android, elas:

[C-2-1] É OBRIGATÓRIO informar os flags de recursos apropriados android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct e android.hardware.touchscreen.multitouch.jazzhand correspondentes ao tipo de tela tátil específica no dispositivo.

Se as implementações do dispositivo dependerem de um dispositivo de entrada externo, como mouse ou trackball (ou seja, não tocar diretamente na tela) para entrada em uma tela principal compatível com Android e atender aos requisitos de toque falso na seção 7.2.5, elas:

[C-3-1] NÃO DEVE informar nenhuma flag de recurso iniciada com android.hardware.touchscreen.
[C-3-2] É PRECISO informar apenas android.hardware.faketouch.
[C-3-3] É OBRIGATÓRIO informar TOUCHSCREEN_NOTOUCH para o campo Configuration.touchscreen da API.

7.2.5. Entrada por toque falsa

A interface de toque simulada fornece um sistema de entrada do usuário que aproxima um subconjunto de recursos de tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela se aproxima do toque, mas exige que o usuário primeiro aponte ou foco e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse aéreo baseado em giroscópio, ponteiro de giroscópio, joystick e trackpad multitoque, podem oferecer suporte a interações de toque falsas. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada não táctil (baseado em ponteiro) de alta fidelidade, como um mouse ou trackpad que pode emular adequadamente a entrada baseada em toque (incluindo suporte a gestos básicos) e indica que o dispositivo oferece suporte a um subconjunto emulado de recursos de tela touchscreen.

Se as implementações de dispositivos não incluírem uma tela touchscreen, mas incluírem outro sistema de entrada de ponteiro que elas queiram disponibilizar, elas:

DEVE declarar suporte à flag de recurso android.hardware.faketouch.

Se as implementações de dispositivos declararem suporte a android.hardware.faketouch, elas:

[C-1-1] É OBRIGATÓRIO informar as posições absolutas X e Y da tela do local do ponteiro e exibir um ponteiro visual na tela.
[C-1-2] É OBRIGATÓRIO informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre no ponteiro descendo ou subindo na tela.
[C-1-3] É NECESSÁRIO oferecer suporte ao ponteiro para baixo e para cima em um objeto na tela, o que permite que os usuários simulem o toque em um objeto na tela.
[C-1-4] É PRECISO oferecer suporte ao ponteiro para baixo, ponteiro para cima, ponteiro para baixo e ponteiro para cima no mesmo local em um objeto na tela dentro de um limite de tempo, o que permite que os usuários emulem o toque duplo em um objeto na tela.
[C-1-5] É PRECISO oferecer suporte ao ponteiro para baixo em um ponto arbitrário na tela, movimento do ponteiro para qualquer outro ponto arbitrário na tela, seguido por um ponteiro para cima, o que permite que os usuários emulem um arrasto por toque.
[C-1-6] PRECISA oferecer suporte ao ponteiro para baixo e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, o ponteiro para cima na tela, permitindo que os usuários joguem um objeto na tela.

Se as implementações de dispositivos declararem suporte para android.hardware.faketouch.multitouch.distinct, elas:

[C-2-1] É PRECISO declarar suporte para android.hardware.faketouch.
[C-2-2] É NECESSÁRIO oferecer suporte a um rastreamento distinto de duas ou mais entradas de ponteiro independentes.

Se as implementações de dispositivos declararem suporte para android.hardware.faketouch.multitouch.jazzhand, elas:

[C-3-1] É PRECISO declarar suporte para android.hardware.faketouch.
[C-3-2] É NECESSÁRIO oferecer suporte a rastreamento distinto de 5 (rastreamento de uma mão de dedos) ou mais entradas de ponteiro de forma totalmente independente.

7.2.6. Suporte a controles de jogos

7.2.6.1. Mapeamentos de botões

Implementações de dispositivos:

[C-1-1] É PRECISO que o sistema seja capaz de mapear eventos HID para as constantes InputEvent correspondentes, conforme listado nas tabelas abaixo. A implementação upstream do Android atende a esse requisito.

Se as implementações de dispositivos incorporarem um controlador ou forem enviadas com um controlador separado na caixa que ofereça meios para inserir todos os eventos listados nas tabelas abaixo, elas:

[C-2-1] É PRECISO declarar a flag de recurso android.hardware.gamepad

Botão	Uso de HID²	Botão do Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
S¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Botão direcional para cima¹ Botão direcional para baixo¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad para a esquerda1 D-pad para a direita¹	0x01 0x0039³	AXIS_HAT_X⁴
Botão de ombro esquerdo¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Botão de ombro direito¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clique no botão esquerdo¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clique no botão direito¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Voltar¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Os usos de HID acima precisam ser declarados em uma CA de gamepad (0x01 0x0005).

3 Esse uso precisa ter um mínimo lógico de 0, um máximo lógico de 7, um mínimo físico de 0, um máximo físico de 315, unidades em graus e um tamanho de relatório de 4. O valor lógico é definido como a rotação no sentido horário para longe do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e esquerda pressionadas.

4 MotionEvent

Controles analógicos¹	Uso de HID	Botão do Android
Gatilho esquerdo	0x02 0x00C5	AXIS_LTRIGGER
Gatilhos direito	0x02 0x00C4	AXIS_RTRIGGER
Joystick esquerdo	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick direito	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

Consulte a Seção 2.3.1 para ver os requisitos específicos do dispositivo.

7.3. Sensores

Se as implementações de dispositivo incluem um tipo de sensor específico que tem uma API correspondente para desenvolvedores de terceiros, a implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android e na documentação do Android Open Source sobre sensores.

Implementações de dispositivos:

[C-0-1] É PRECISO informar com precisão a presença ou ausência de sensores por classe android.content.pm.PackageManager.
[C-0-2] É PRECISO retornar uma lista precisa de sensores compatíveis usando SensorManager.getSensorList() e métodos semelhantes.
[C-0-3] PRECISA se comportar de maneira razoável para todas as outras APIs de sensor (por exemplo, retornando true ou false conforme apropriado quando os aplicativos tentam registrar listeners, não chamando listeners de sensor quando os sensores correspondentes não estão presentes etc.).

Se as implementações de dispositivos incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, eles:

[C-1-1] É OBRIGATÓRIO informar todas as medições do sensor usando os valores relevantes do Sistema Internacional de Unidades (métrico) para cada tipo de sensor, conforme definido na documentação do Android SDK.
[C-1-2] É OBRIGATÓRIO informar dados do sensor com uma latência máxima de 100 milissegundos + 2 * sample_time para o caso de um fluxo de sensor com uma latência máxima solicitada de 0 ms quando o processador do aplicativo está ativo. Esse atraso não inclui atrasos de filtragem.
[C-1-3] É OBRIGATÓRIO informar a primeira amostra do sensor em 400 milissegundos + 2 * sample_time do sensor sendo ativado. É aceitável que essa amostra tenha uma precisão de 0.
[C-1-4] Para que qualquer API indicada pela documentação do SDK do Android seja um sensor contínuo, as implementações do dispositivo PRECISAM fornecer continuamente amostras de dados periódicas que DEVEM ter um jitter abaixo de 3%, em que o jitter é definido como a variação padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.
[C-1-5] É NECESSÁRIO garantir que a transmissão de eventos do sensor NÃO impeça a CPU do dispositivo de entrar em um estado de suspensão ou de sair de um estado de suspensão.
[C-1-6] É OBRIGATÓRIO informar o horário do evento em nanossegundos, conforme definido na documentação do SDK do Android, representando o horário em que o evento ocorreu e sincronizado com o SystemClock.elapsedRealtimeNano().
[C-SR-1] É ALTAMENTE RECOMENDADO que o erro de sincronização de carimbo de data/hora seja inferior a 100 milissegundos e que o erro de sincronização de carimbo de data/hora seja inferior a 1 milissegundo.
Quando vários sensores são ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia informado pelo sensor individual.

A lista acima não é abrangente. O comportamento documentado do SDK do Android e da documentação de código aberto do Android sobre sensores é considerado autorizado.

Se as implementações de dispositivos incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, eles:

[C-1-6] É OBRIGATÓRIO definir uma resolução diferente de zero para todos os sensores e informar o valor pelo método da API Sensor.getResolution().

Alguns tipos de sensores são compostos, ou seja, podem ser derivados de dados fornecidos por um ou mais outros sensores. Por exemplo, o sensor de orientação e o sensor de aceleração linear.

Implementações de dispositivos:

IMPLEMENTAR esses tipos de sensores, quando eles incluem os sensores físicos necessários, conforme descrito em tipos de sensores.

Se as implementações do dispositivo incluírem um sensor composto, elas:

[C-2-1] É PRECISO implementar o sensor conforme descrito na documentação de código aberto do Android sobre sensores compostos.

Se as implementações de dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados e o sensor informar apenas um valor, as implementações de dispositivo:

[C-3-1] É OBRIGATÓRIO definir a resolução como 1 para o sensor e informar o valor pelo método de API Sensor.getResolution().

Se as implementações do dispositivo incluírem um tipo de sensor específico que ofereça suporte a SensorAdditionalInfo#TYPE_VEC3_CALIBRATION e o sensor for exposto a desenvolvedores terceirizados, eles:

[C-4-1] NÃO inclua parâmetros de calibração fixos e determinados pela fábrica nos dados fornecidos.

Se as implementações do dispositivo incluem uma combinação de acelerômetro de três eixos, um sensor de giroscópio de três eixos ou um sensor de magnetômetro, elas são:

[C-SR-2] É ALTAMENTE RECOMENDADO garantir que o acelerômetro, o giroscópio e o magnetômetro tenham uma posição relativa fixa, de modo que, se o dispositivo for transformável (por exemplo, dobrável), os eixos do sensor permaneçam alinhados e consistentes com o sistema de coordenadas do sensor em todos os estados de transformação possíveis do dispositivo.

7.3.1. Acelerômetro

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

Se as implementações do dispositivo incluírem um acelerômetro, elas:

[C-1-1] É PRECISO que o sistema consiga informar eventos com frequência de pelo menos 50 Hz.
[C-1-3] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor Android conforme detalhado nas APIs do Android.
[C-1-4] É PRECISO medir a partir de queda livre até quatro vezes o gravity(4g) ou mais em qualquer eixo.
[C-1-5] PRECISA ter uma resolução de pelo menos 12 bits.
[C-1-6] É OBRIGATÓRIO ter uma variação padrão não superior a 0,05 m/s^, em que a variação padrão precisa ser calculada por eixo em amostras coletadas durante um período de pelo menos 3 segundos na taxa de amostragem mais rápida.
DEVE informar eventos de até 200 Hz.
DEVE ter uma resolução de pelo menos 16 bits.
DEVEM ser calibrados durante o uso se as características mudarem ao longo do ciclo de vida e forem compensadas, e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
DEVE ser compensada pela temperatura.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos, elas:

[C-2-1] É PRECISO implementar e informar o sensor TYPE_ACCELEROMETER.
[C-SR-4] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
[C-SR-5] É ALTAMENTE RECOMENDADO implementar e informar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. É FORTEMENTE RECOMENDADO que os dispositivos Android atendam a esse requisito para que possam fazer upgrade para a versão futura da plataforma, quando isso se tornar OBRIGATÓRIO.
DEVE implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER conforme descrito no documento do SDK do Android.

Se as implementações do dispositivo incluírem um acelerômetro com menos de três eixos, elas:

[C-3-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
[C-SR-6] É STRONGLY_RECOMMENDED implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos e qualquer um dos sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER forem implementados:

[C-4-1] A soma do consumo de energia PRECISA ser sempre menor que 4 mW.
CADA UM DEVE ESTAR ABAIXO DE 2 mW E 0,5 mW QUANDO O DISPOSITIVO ESTIVER EM UMA CONDIÇÃO DINÂMICA OU ESTÁTICA.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, elas:

[C-5-1] É PRECISO implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
[C-SR-7] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos, um sensor de giroscópio de três eixos e um sensor de magnetômetro, elas:

[C-6-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

7.3.2. Magnetômetro

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO incluir um magnetômetro de 3 eixos (bússola).

Se as implementações do dispositivo incluírem um magnetômetro de três eixos, elas:

[C-1-1] É PRECISO implementar o sensor TYPE_MAGNETIC_FIELD.
[C-1-2] PRECISA ser capaz de informar eventos com frequência de pelo menos 10 Hz e DEVE informar eventos com frequência de pelo menos 50 Hz.
[C-1-3] É NECESSÁRIO obedecer ao sistema de coordenadas do sensor Android, conforme detalhado nas APIs do Android.
[C-1-4] É PRECISO medir entre -900 µT e +900 µT em cada eixo antes da saturação.
[C-1-5] É PRECISO ter um valor de deslocamento de ferro rígido menor que 700 µT e um valor abaixo de 200 µT, colocando o magnetômetro longe de campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímã).
[C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 µT.
[C-1-7] É PRECISO oferecer suporte à calibração on-line e compensação da polarização de ferro rígido e preservar os parâmetros de compensação entre reinicializações do dispositivo.
[C-1-8] A compensação de ferro macio PRECISA ser aplicada. A calibração pode ser feita durante o uso ou durante a produção do dispositivo.
[C-1-9] É PRECISO ter uma variação padrão, calculada por eixo em amostras coletadas por um período de pelo menos 3 segundos na taxa de amostragem mais rápida, não superior a 1,5 µT. É NECESSÁRIO ter uma variação padrão não superior a 0,5 µT.
[C-1-10] É PRECISO implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se as implementações do dispositivo incluem um magnetômetro de três eixos, um sensor de acelerômetro e um sensor de giroscópio de três eixos, elas:

[C-2-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

Se as implementações do dispositivo incluírem um magnetômetro de três eixos, um acelerômetro, elas:

PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se as implementações do dispositivo incluírem um magnetômetro de três eixos, um acelerômetro e um sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR, elas:

[C-3-1] PRECISA consumir menos de 10 mW.
CONSUMARÁ menos de 3 mW quando o sensor estiver registrado para o modo lote a 10 Hz.

7.3.3. GPS

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO incluir um receptor GPS/GNSS.

Se as implementações do dispositivo incluírem um receptor GPS/GNSS e informarem a capacidade para os aplicativos usando a flag de recurso android.hardware.location.gps, elas:

[C-1-1] É PRECISO oferecer suporte a saídas de localização com uma taxa de pelo menos 1 Hz quando solicitado por LocationManager#requestLocationUpdate.
[C-1-2] É PRECISO determinar o local em condições de céu aberto (sinais fortes, multicaminho desprezível, HDOP < 2) em até 10 segundos (tempo rápido até a primeira correção), quando conectado a uma conexão de Internet de dados de 0,5 Mbps ou mais rápida. Esse requisito geralmente é atendido pelo uso de alguma técnica de GPS/GNSS assistida ou prevista para minimizar o tempo de bloqueio do GPS/GNSS. Os dados de assistência incluem a hora de referência, a localização de referência e a efeméride/relógio do satélite.
- [C-1-6] Depois de fazer esse cálculo de localização, as implementações do dispositivo PRECISAM determinar a localização, em céu aberto, em até 5 segundos, quando as solicitações de localização forem reiniciadas, até uma hora após o cálculo inicial de localização, mesmo quando a solicitação subsequente for feita sem uma conexão de dados e/ou após um ciclo de energia.
Em condições de céu aberto, depois de determinar o local, enquanto estiver parado ou se movendo com menos de 1 metro por segundo ao quadrado de aceleração:
- [C-1-3] É PRECISO determinar a localização em até 20 metros e a velocidade em até 0, 5 metro por segundo, pelo menos 95% do tempo.
- [C-1-4] É necessário rastrear e informar simultaneamente via GnssStatus.Callback pelo menos 8 satélites de uma constelação.
- DEVE ser capaz de rastrear simultaneamente pelo menos 24 satélites de várias constelações (por exemplo, GPS + pelo menos um de Glonass, Beidou, Galileu).
[C-SR-2] É ALTAMENTE RECOMENDADO continuar a fornecer saídas de localização de GPS/GNSS normais usando APIs do provedor de localização GNSS durante uma chamada de emergência.
[C-SR-3] É ALTAMENTE RECOMENDADO informar as medições GNSS de todas as constelações rastreadas (conforme informado nas mensagens GnssStatus), com exceção do SBAS.
[C-SR-4] É ALTAMENTE RECOMENDADO informar o AGC e a frequência da medição do GNSS.
[C-SR-5] É ALTAMENTE RECOMENDADO informar todas as estimativas de precisão (incluindo a direção, a velocidade e a vertical) como parte de cada local de GPS/GNSS.
[C-SR-6] É ALTAMENTE RECOMENDADO informar as medições GNSS assim que elas forem encontradas, mesmo que um local calculado pelo GPS/GNSS ainda não tenha sido informado.
[C-SR-7] É ALTAMENTE RECOMENDADO informar pseudorastros e taxas de pseudorastro do GNSS que, em condições de céu aberto após a determinação do local, estacionados ou em movimento com menos de 0,2 metros por segundo ao quadrado de aceleração, são suficientes para calcular a posição em até 20 metros e a velocidade em até 0, 2 metros por segundo, pelo menos 95% do tempo.

7.3.4. Giroscópio

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO incluir um sensor de giroscópio.

Se as implementações do dispositivo incluírem um giroscópio, elas:

[C-1-1] É PRECISO que o sistema consiga informar eventos com frequência de pelo menos 50 Hz.
[C-1-4] PRECISA ter uma resolução de 12 bits ou mais.
[C-1-5] É PRECISO compensar a temperatura.
[C-1-6] DEVE ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
[C-1-7] PRECISA ter uma variação não maior que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar com a taxa de amostragem, mas PRECISA ser limitada por esse valor. Em outras palavras, se você medir a variação do giroscópio com uma taxa de amostragem de 1 Hz, ela NÃO PODE ser maior do que 1e-7 rad^2/s^2.
[C-SR-2] É ALTAMENTE RECOMENDÁVEL que o erro de calibração seja menor que 0,01 rad/s quando o dispositivo estiver parado à temperatura ambiente.
[C-SR-3] É ALTAMENTE RECOMENDADO ter uma resolução de 16 bits ou mais.
DEVE informar eventos de até 200 Hz.

Se as implementações do dispositivo incluírem um giroscópio de três eixos, elas:

[C-2-1] É PRECISO implementar o sensor TYPE_GYROSCOPE.
[C-SR-4] É altamente recomendável implementar o sensor TYPE_GYROSCOPE_UNCALIBRATED.

Se as implementações do dispositivo incluírem um giroscópio com menos de três eixos, elas:

[C-3-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES.
[C-SR-5] É STRONGLY_RECOMMENDED implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Se as implementações do dispositivo incluem um giroscópio de três eixos, um sensor de acelerômetro e um sensor de magnetômetro, elas:

[C-4-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, elas:

[C-5-1] É PRECISO implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
[C-SR-6] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO incluir um barômetro (sensor de pressão do ar ambiente).

Se as implementações do dispositivo incluírem um barômetro, elas:

[C-1-1] É PRECISO implementar e informar o sensor TYPE_PRESSURE.
[C-1-2] É PRECISO enviar eventos a 5 Hz ou mais.
[C-1-3] É PRECISO compensar a temperatura.
[C-SR-2] É ALTAMENTE RECOMENDADO que seja possível informar medições de pressão no intervalo de 300 a 1.100 hPa.
Deve ter uma precisão absoluta de 1hPa.
DEVE ter uma precisão relativa de 0,12hPa em um intervalo de 20hPa (equivalente a uma precisão de aproximadamente 1 m em uma mudança de aproximadamente 200 m no nível do mar).

7.3.6. Termômetro

Se as implementações do dispositivo incluírem um termômetro ambiente (sensor de temperatura), elas:

[C-1-1] É PRECISO definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura ambiente, e o sensor PRECISA medir a temperatura ambiente (cabine do veículo/sala) de onde o usuário está interagindo com o dispositivo em graus Celsius.

Se as implementações do dispositivo incluírem um sensor de termômetro que mede uma temperatura diferente da ambiente, como a da CPU, elas:

[C-2-1] DEFINIR SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura.

Se as implementações do dispositivo incluírem um sensor para monitorar a temperatura da pele, elas:

[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à API PowerManager.getThermalHeadroom.

7.3.7. Fotômetro

As implementações de dispositivos PODEM incluir um fotômetro (sensor de luz ambiente).

7.3.8. Sensor de proximidade

As implementações de dispositivos PODEM incluir um sensor de proximidade.

Se as implementações do dispositivo incluírem um sensor de proximidade e informarem apenas uma leitura binária "perto" ou "longe", elas:

[C-1-1] É NECESSÁRIO medir a proximidade de um objeto na mesma direção da tela. Ou seja, o sensor de proximidade PRECISA ser orientado para detectar objetos próximos à tela, já que a intenção principal desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se as implementações do dispositivo incluírem um sensor de proximidade com qualquer outra orientação, ele NÃO PODE ser acessível por essa API.
[C-1-2] PRECISA ter precisão de 1 bit ou mais.
[C-1-3] É OBRIGATÓRIO usar 0 centímetros como a leitura próxima e 5 centímetros como a leitura distante.
[C-1-4] É OBRIGATÓRIO informar um intervalo máximo e uma resolução de 5.

7.3.9. Sensores de alta fidelidade

Se as implementações de dispositivos incluírem um conjunto de sensores de maior qualidade, conforme definido nesta seção, e os disponibilizarem para apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO identificar o capability usando a flag de recurso android.hardware.sensor.hifi_sensors.

Se as implementações do dispositivo declararem android.hardware.sensor.hifi_sensors, elas:

[C-2-1] É PRECISO ter um sensor TYPE_ACCELEROMETER que:
- PRECISA ter um intervalo de medição entre pelo menos -8g e +8g, e é ALTAMENTE RECOMENDADO ter um intervalo de medição entre pelo menos -16g e +16g.
- PRECISA ter uma resolução de medição de pelo menos 2048 LSB/g.
- PRECISA ter uma frequência de medição mínima de 12,5 Hz ou inferior.
- PRECISA ter uma frequência de medição máxima de 400 Hz ou mais; DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
- O ruído de medição não pode exceder 400 μg/√Hz.
- É necessário implementar um formulário de não ativação desse sensor com uma capacidade de buffer de pelo menos 3.000 eventos do sensor.
- O consumo de energia em lote precisa ser de no máximo 3 mW.
- [C-SR-1] É ALTAMENTE RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
- DEVE ter uma caminhada aleatória de aceleração menor que 30 μg √Hz testada à temperatura ambiente.
- DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 1 mg/°C.
- DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,5% e uma mudança de sensibilidade em relação à temperatura de ≤ 0,03%/C°.
- DEVE ter uma sensibilidade no eixo transversal de < 2,5 % e uma variação de sensibilidade no eixo transversal de < 0,2% na faixa de temperatura de operação do dispositivo.
[C-2-2] É PRECISO ter um TYPE_ACCELEROMETER_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_ACCELEROMETER.
[C-2-3] É PRECISO ter um sensor TYPE_GYROSCOPE que:
- PRECISA ter um intervalo de medição entre pelo menos -1000 e +1000 dps.
- PRECISA ter uma resolução de medição de pelo menos 16 LSB/dps.
- PRECISA ter uma frequência de medição mínima de 12,5 Hz ou inferior.
- PRECISA ter uma frequência de medição máxima de 400 Hz ou mais; DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
- O ruído de medição não pode ser superior a 0,014°/s/√Hz.
- [C-SR-2] É ALTAMENTE RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
- DEVE ter uma taxa de caminhada aleatória menor que 0,001 °/s √Hz testada à temperatura ambiente.
- DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 0,05 °/ s / °C.
- DEVE ter uma mudança de sensibilidade em relação à temperatura de ≤ 0,02% / °C.
- DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,2%.
- DEVE ter uma densidade de ruído de ≤ 0,007 °/s/√Hz.
- DEVE ter um erro de calibração menor que 0,002 rad/s no intervalo de temperatura de 10 a 40 ℃ quando o dispositivo estiver parado.
- DEVE ter uma sensibilidade de gravidade menor que 0,1°/s/g.
- DEVE ter uma sensibilidade no eixo transversal de < 4,0 % e uma variação de sensibilidade no eixo transversal de < 0,3% no intervalo de temperatura de operação do dispositivo.
[C-2-4] É PRECISO ter um TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade que TYPE_GYROSCOPE.
[C-2-5] É PRECISO ter um sensor TYPE_GEOMAGNETIC_FIELD que:
- PRECISA ter um intervalo de medição entre pelo menos -900 e +900 μT.
- É PRECISO ter uma resolução de medição de pelo menos 5 LSB/uT.
- PRECISA ter uma frequência de medição mínima de 5 Hz ou menor.
- PRECISA ter uma frequência de medição máxima de 50 Hz ou mais.
- Deve ter um ruído de medição não superior a 0,5 uT.
[C-2-6] É PRECISO ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_GEOMAGNETIC_FIELD e, além disso:
- É necessário implementar um formulário de não ativação desse sensor com uma capacidade de buffer de pelo menos 600 eventos do sensor.
- [C-SR-3] É ALTAMENTE RECOMENDADO ter um espectro de ruído branco de 1 Hz a pelo menos 10 Hz quando a taxa de relatório for de 50 Hz ou mais.
[C-2-7] É OBRIGATÓRIO ter um sensor TYPE_PRESSURE que:
- PRECISA ter um intervalo de medição entre pelo menos 300 e 1.100 hPa.
- PRECISA ter uma resolução de medição de pelo menos 80 LSB/hPa.
- PRECISA ter uma frequência de medição mínima de 1 Hz ou inferior.
- PRECISA ter uma frequência máxima de medição de 10 Hz ou mais.
- O ruído de medição não pode exceder 2 Pa/√Hz.
- É PRECISO implementar um formulário de não ativação desse sensor com uma capacidade de buffer de pelo menos 300 eventos de sensor.
- O consumo de energia em lote precisa ser de no máximo 2 mW.
[C-2-8] É PRECISO ter um sensor TYPE_GAME_ROTATION_VECTOR.
[C-2-9] É OBRIGATÓRIO ter um sensor TYPE_SIGNIFICANT_MOTION que:
- O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo está estático e de 1,5 mW quando o dispositivo está em movimento.
[C-2-10] É PRECISO ter um sensor TYPE_STEP_DETECTOR que:
- É necessário implementar um formulário de não ativação desse sensor com uma capacidade de buffer de pelo menos 100 eventos do sensor.
- O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
- O consumo de energia em lote precisa ser de no máximo 4 mW.
[C-2-11] É PRECISO ter um sensor TYPE_STEP_COUNTER que:
- O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
[C-2-12] É PRECISO ter um sensor TILT_DETECTOR que:
- O consumo de energia precisa ser de no máximo 0,5 mW quando o dispositivo está estático e de 1,5 mW quando ele está em movimento.
[C-2-13] O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro, pelo giroscópio e pelo magnetômetro PRECISA estar a até 2, 5 milissegundos um do outro. O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro e pelo giroscópio DEVE estar dentro de 0,25 milissegundos um do outro.
[C-2-14] É OBRIGATÓRIO ter carimbos de data/hora de eventos do sensor de giroscópio na mesma base de tempo que o subsistema da câmera e com um erro de até 1 milissegundo.
[C-2-15] É NECESSÁRIO enviar amostras para os aplicativos em até 5 milissegundos a partir do momento em que os dados estão disponíveis em qualquer um dos sensores físicos acima para o aplicativo.
[C-2-16] NÃO PODE ter um consumo de energia maior que 0,5 mW quando o dispositivo está estático e 2,0 mW quando o dispositivo está em movimento quando qualquer combinação dos seguintes sensores está ativada:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] PODE ter um sensor TYPE_PROXIMITY, mas, se estiver presente, PRECISA ter uma capacidade de buffer mínima de 100 eventos do sensor.

Todos os requisitos de consumo de energia nesta seção não incluem o consumo de energia do processador de aplicativos. Ele inclui a energia gerada por toda a cadeia de sensores, o sensor, qualquer circuito de suporte, qualquer sistema de processamento de sensores dedicado etc.

Se as implementações de dispositivos incluem suporte a sensores diretos, elas:

[C-3-1] É OBRIGATÓRIO declarar corretamente o suporte a tipos de canal direto e ao nível de taxas de relatórios diretos usando a API isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
[C-3-2] É PRECISO oferecer suporte a pelo menos um dos dois tipos de canal direto do sensor para todos os sensores que declaram suporte ao canal direto do sensor.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
DEVE oferecer suporte à geração de relatórios de eventos pelo canal direto do sensor para o sensor principal (variante sem ativação) dos seguintes tipos:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensores biométricos

Para mais informações sobre como medir a segurança do desbloqueio biométrico, consulte Documentação sobre como medir a segurança biométrica.

Se as implementações do dispositivo incluem uma tela de bloqueio segura, elas:

DEVE incluir um sensor biométrico

Os sensores biométricos podem ser classificados como Classe 3 (antes Forte), Classe 2 (antes Fraco) ou Classe 1 (antes Conveniente) com base nas taxas de falsificação e aceitação de impostores e na segurança do pipeline biométrico. Essa classificação determina os recursos que o sensor biométrico tem para interagir com a plataforma e com aplicativos de terceiros. Os sensores precisam atender a outros requisitos, conforme detalhado abaixo, se quiserem ser classificados como Classe 1, Classe 2 ou Classe 3. A biometria de Classe 2 e Classe 3 recebe recursos adicionais, conforme detalhado abaixo.

Se as implementações do dispositivo disponibilizarem um sensor biométrico para apps de terceiros por meio de android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, eles:

[C-4-1] É OBRIGATÓRIO atender aos requisitos de biometria de Classe 3 ou Classe 2, conforme definido neste documento.
[C-4-2] DEVE reconhecer e honrar cada nome de parâmetro definido como uma constante na classe Authenticators e qualquer combinação dela. Por outro lado, NÃO É PERMITIDO reconhecer ou honrar constantes de número inteiro transmitidas para os métodos canAuthenticate(int) e setAllowedAuthenticators(int) diferentes daqueles documentados como constantes públicas em Authenticators e qualquer combinação deles.
[C-4-3] É PRECISO implementar a ação ACTION_BIOMETRIC_ENROLL em dispositivos que tenham biometria de Classe 3 ou Classe 2. Essa ação PRECISA apresentar apenas os pontos de entrada de inscrição para biometria de Classe 3 ou Classe 2.

Início dos novos requisitos para o Android 15

[C-4-4] É PRECISO permitir que os aplicativos adicionem conteúdo personalizado a BiometricPrompt usando os formatos de exibição de conteúdo PromptContentView. Os formatos de exibição de conteúdo NÃO PODEM ser estendidos para permitir imagens, links, conteúdo interativo ou outras formas de mídia que ainda não fazem parte da API BiometricPrompt. Ajustes estilísticos que não alterem, obscureçam ou truncem esse conteúdo podem ser feitos (como mudar a posição, o padding, as margens e a tipografia).

Fim dos novos requisitos

Se as implementações de dispositivos forem compatíveis com a biometria passiva, elas:

[C-5-1] POR PADRÃO, É NECESSÁRIO exigir uma etapa de confirmação extra (por exemplo, pressionar um botão).
[C-SR-1] É ALTAMENTE RECOMENDADO ter uma configuração que permita aos usuários substituir a preferência do aplicativo e sempre exigir uma etapa de confirmação.
[C-SR-2] É ALTAMENTE RECOMENDADO que a ação de confirmação seja protegida para que um comprometimento do sistema operacional ou do kernel não possa ser falsificado. Por exemplo, isso significa que a ação de confirmação baseada em um botão físico é roteada por um pino de entrada/saída (GPIO) de uso geral de um elemento seguro (SE) que não pode ser controlado por nenhum outro meio além de uma pressão de botão físico.
[C-5-2] É necessário implementar um fluxo de autenticação implícita (sem etapa de confirmação) correspondente a setConfirmationRequired(boolean), que os aplicativos podem definir para usar nos fluxos de login.

Se as implementações de dispositivos tiverem vários sensores biométricos, elas:

[C-7-1] É OBRIGATÓRIO que, quando uma biometria estiver bloqueada (ou seja, a biometria estiver desativada até que o usuário desbloqueie com a autenticação principal) ou com bloqueio temporário (ou seja, a biometria é desativada temporariamente até que o usuário aguarde um intervalo de tempo) devido a muitas tentativas com falha, também bloqueie todas as outras biometrias de uma classe biométrica inferior. No caso de bloqueio por tempo, o tempo de espera para a verificação biométrica PRECISA ser o tempo máximo de espera de todas as biometrias no bloqueio por tempo.
[C-SR-12] É ALTAMENTE RECOMENDADO, quando um recurso biométrico está bloqueado (ou seja, o recurso biométrico é desativado até que o usuário desbloqueie com a autenticação principal) ou bloqueado por tempo (ou seja, o recurso biométrico é desativado temporariamente até que o usuário aguarde um intervalo de tempo) devido a muitas tentativas com falha, também bloquear todos os outros recursos biométricos da mesma classe. No caso de bloqueio temporário, o tempo de espera para a verificação biométrica é ALTAMENTE RECOMENDADO como o tempo de espera máximo de todos os métodos biométricos em bloqueio temporário.
[C-7-2] É OBRIGATÓRIO que o usuário seja desafiado a fornecer a autenticação principal recomendada (por exemplo, PIN, padrão, senha) para redefinir o contador de bloqueio de uma biometria bloqueada. A biometria de classe 3 PODE ser usada para redefinir o contador de bloqueio de uma biometria bloqueada da mesma classe ou inferior. A biometria de classe 2 ou classe 1 NÃO PODE ser usada para concluir uma operação de redefinição de bloqueio para qualquer biometria.
[C-SR-3] É ALTAMENTE RECOMENDADO exigir que apenas uma biometria seja confirmada por autenticação. Por exemplo, se os sensores de impressão digital e facial estiverem disponíveis no dispositivo, onAuthenticationSucceeded será enviado depois que qualquer um deles for confirmado.

Para que as implementações de dispositivos permitam o acesso a chaves do keystore a aplicativos de terceiros, elas:

[C-6-1] PRECISA atender aos requisitos da Classe 3, conforme definido nesta seção abaixo.
[C-6-2] É PRECISO apresentar apenas biometria de Classe 3 quando a autenticação requer BIOMETRIC_STRONG ou a autenticação é invocada com um CryptoObject.

Se as implementações de dispositivo quiserem tratar um sensor biométrico como Classe 1 (anteriormente Convenience), elas:

[C-1-1] É PRECISO ter uma taxa de aceitação falsa menor que 0,002%.
[C-1-2] É OBRIGATÓRIO divulgar que esse modo pode ser menos seguro que um PIN, padrão ou senha fortes e listar claramente os riscos de ativá-lo, se as taxas de aceitação de falsificação e de impostor forem maiores que 7%, conforme medido pelos protocolos de teste de biometria do Android.
[C-1-9] É OBRIGATÓRIO que o usuário seja desafiado para a autenticação primária recomendada (por exemplo, PIN, padrão, senha) após no máximo 20 tentativas falsas e no mínimo 90 segundos de tempo de espera para a verificação biométrica, em que uma tentativa falsa é aquela com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
[C-SR-4] É ALTAMENTE RECOMENDADO reduzir o número total de tentativas falsas de verificação biométrica especificadas em [C-1-9] se as taxas de spoofing e de imitação forem maiores que 7%, conforme medido pelos protocolos de teste de biometria do Android.
[C-1-3] É OBRIGATÓRIO limitar a taxa de tentativas de verificação biométrica, em que uma tentativa falsa é aquela com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
[C-SR-5] É ALTAMENTE RECOMENDADO limitar a taxa de tentativas por pelo menos 30 segundos após cinco tentativas falsas de verificação biométrica para o número máximo de tentativas falsas por [C-1-9], em que uma tentativa falsa é uma com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
[C-SR-6] É ALTAMENTE RECOMENDADO ter toda a lógica de limitação de taxa no TEE.
[C-1-10] É PRECISO desativar a biometria quando o backoff da autenticação principal for acionado pela primeira vez, conforme descrito em [C-0-2] da seção 9.11.
[C-1-11] É PRECISO ter uma taxa de aceitação de falsificação e impostor não superior a 30%, com (1) uma taxa de aceitação de falsificação e impostor para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) de nível A não superior a 30% e (2) uma taxa de aceitação de falsificação e impostor de espécies de PAI de nível B não superior a 40%, conforme medido pelos protocolos de teste de biometria do Android.
[C-1-4] É PRECISO impedir a adição de novas biometrias sem primeiro estabelecer uma cadeia de confiança, fazendo com que o usuário confirme ou adicione uma nova credencial de dispositivo (PIN/padrão/senha) protegida pelo TEE. A implementação do Projeto de código aberto do Android fornece o mecanismo no framework para fazer isso.

Início dos novos requisitos para o Android 15

[C-1-5] É OBRIGATÓRIO remover completamente todos os dados biométricos identificáveis de um usuário quando a conta dele for removida (inclusive por redefinição para a configuração original) ou quando a autenticação principal recomendada (por exemplo, PIN, padrão, senha) for removida.

Fim dos novos requisitos

[C-1-6] É PRECISO honrar a flag individual para essa biometria (ou seja, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

Início dos novos requisitos para o Android 15

[C-1-7] É OBRIGATÓRIO solicitar ao usuário a autenticação primária recomendada (como PIN, padrão, senha) uma vez a cada 24 horas ou menos. Observação: a atualização de dispositivos lançados no Android versão 9 ou anterior PRECISA exigir a autenticação primária recomendada (como PIN, padrão ou senha) do usuário uma vez a cada 72 horas ou menos.

Fim dos novos requisitos

Início dos novos requisitos para o Android 15

[C-1-8] É OBRIGATÓRIO solicitar ao usuário a autenticação principal recomendada (como PIN, padrão, senha) ou a biometria de Classe 3 (FORTE) após uma das seguintes ações:
- um período de inatividade de 4 horas OU
- Três tentativas de autenticação biométrica com falha.
- O período de tempo limite de inatividade e a contagem de falhas de autenticação são redefinidos após qualquer confirmação bem-sucedida das credenciais do dispositivo. ~~Observação: o upgrade de dispositivos lançados no Android versão 9 ou anterior PODE ser isento da C-1-8.~~

Fim dos novos requisitos

[C-SR-7] É ALTAMENTE RECOMENDADO usar a lógica no framework fornecido pelo Projeto Android Open Source para aplicar restrições especificadas em [C-1-7] e [C-1-8] para novos dispositivos.
[C-SR-8] É ALTAMENTE RECOMENDADO ter uma taxa de rejeição falsa de menos de 10%, conforme medido no dispositivo.
[C-SR-9] É ALTAMENTE RECOMENDADO ter uma latência abaixo de 1 segundo, medida desde a detecção da biometria até o desbloqueio da tela, para cada biometria registrada.
[C-1-12] É PRECISO ter uma taxa de aceitação de falsificação e impostor não superior a 40% por instrumento de ataque de apresentação (PAI, na sigla em inglês), conforme medido pelos protocolos de teste de biometria do Android.
[C-SR-13] É ALTAMENTE RECOMENDADO ter uma taxa de spoofing e de aceitação de impostores não superior a 30% por espécie de instrumento de ataque de apresentação (PAI, na sigla em inglês), conforme medido pelos protocolos de teste de biometria do Android.
[C-SR-8] É ALTAMENTE RECOMENDADO ter uma taxa de rejeição falsa de menos de 10%, conforme medido no dispositivo.

Início dos novos requisitos para o Android 15

[C-1-15] É PRECISO permitir que os usuários removam uma ou várias inscrições de biometria.

Fim dos novos requisitos

[C-SR-14] É ALTAMENTE RECOMENDADO divulgar a classe biométrica do sensor biométrico e os riscos correspondentes de ativá-lo.
[C-SR-17] É ALTAMENTE RECOMENDÁVEL implementar as novas interfaces AIDL (como IFace.aidl e IFingerprint.aidl).

Se as implementações de dispositivo quiserem tratar um sensor biométrico como Classe 2 (anteriormente Fraco), elas:

[C-2-1] É PRECISO atender a todos os requisitos da Classe 1 acima.
[C-2-2] É OBRIGATÓRIO ter uma taxa de aceitação de falsificação e impostor não superior a 20%, com (1) uma taxa de aceitação de falsificação e impostor para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) de nível A não superior a 20%, e (2) uma taxa de aceitação de falsificação e impostor de espécies de PAI de nível B não superior a 30%, conforme medido pelos protocolos de teste de biometria do Android.
[C-SR-15] É ALTAMENTE RECOMENDADO ter uma taxa de aceitação de falsificação e de impostor não superior a 20% por tipo de instrumento de ataque de apresentação (PAI, na sigla em inglês), conforme medido pelos protocolos de teste de biometria do Android.
[C-2-3] É NECESSÁRIO realizar a correspondência biométrica em um ambiente de execução isolado fora do espaço do usuário ou do kernel do Android, como o ambiente de execução confiável (TEE), em um chip com um canal seguro para o ambiente de execução isolado ou em uma máquina virtual protegida que atenda aos requisitos da seção 9.17.
[C-2-4] É OBRIGATÓRIO que todos os dados identificáveis sejam criptografados e autenticados criptograficamente, de modo que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação no site do Projeto Android Open Source ou em uma máquina virtual protegida controlada por hipervisor que atenda aos requisitos da seção 9.17.
[C-2-5] Para biometria baseada em câmera, enquanto a autenticação ou o registro biométrico estiver acontecendo:
- PRECISA operar a câmera em um modo que impeça que os frames da câmera sejam lidos ou alterados fora do ambiente de execução isolado ou um chip com um canal seguro para o ambiente de execução isolado ou uma máquina virtual protegida controlada por hipervisor que atenda aos requisitos da seção 9.17.
- Para soluções de câmera RGB única, os frames da câmera PODEM ser legíveis fora do ambiente de execução isolado para oferecer suporte a operações como a visualização para registro, mas ELES NÃO PODEM ser alterados.
[C-2-6] NÃO é permitido permitir que aplicativos de terceiros distingam entre cada registro biométrico individual.
[C-2-7] NÃO É PERMITIDO permitir acesso não criptografado a dados biométricos identificáveis ou a qualquer dado derivado deles (como incorporações) ao processador de aplicativos fora do contexto do TEE ou da máquina virtual protegida controlada pelo hipervisor que atenda aos requisitos da seção 9.17. A atualização de dispositivos lançados na versão 9 ou anterior do Android não está isenta da C-2-7.
[C-2-8] É OBRIGATÓRIO ter um pipeline de processamento seguro para que um comprometimento do sistema operacional ou do kernel não permita que dados sejam injetados diretamente para autenticação falsa como o usuário. Observação: se as implementações do dispositivo já foram lançadas no Android versão 9 ou anterior e não puderem atender ao requisito C-2-8 com uma atualização do software do sistema, elas PODEM ser isentas do requisito.
[C-SR-10] É ALTAMENTE RECOMENDADO incluir a detecção de vida para todas as modalidades biométricas e a detecção de atenção para biometria facial.
[C-2-9] É OBRIGATÓRIO disponibilizar o sensor biométrico para apps de terceiros.

Se as implementações de dispositivo quiserem tratar um sensor biométrico como Classe 3 (antes Forte), elas:

[C-3-1] É OBRIGATÓRIO atender a todos os requisitos da classe 2 acima, exceto [C-1-7] e [C-1-8].
[C-3-2] É OBRIGATÓRIO ter uma implementação de keystore protegida por hardware.
[C-3-3] É PRECISO ter uma taxa de aceitação de falsificação e impostor não superior a 7%, com (1) uma taxa de aceitação de falsificação e impostor para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) de nível A não superior a 7% e (2) uma taxa de aceitação de falsificação e impostor de espécies de PAI de nível B não superior a 20%, conforme medido pelos protocolos de teste de biometria do Android.
[C-3-4] É OBRIGATÓRIO solicitar ao usuário a autenticação primária recomendada (como PIN, padrão, senha) a cada 72 horas ou menos.
[C-3-5] É PRECISO gerar novamente o ID do autenticador para todos os métodos biométricos de classe 3 compatíveis com o dispositivo se algum deles for reinserido.
[C-3-6] É necessário ativar chaves de keystore com suporte biométrico para aplicativos de terceiros.

[C-SR-16] É ALTAMENTE RECOMENDADO ter uma taxa de aceitação de falsificação e de impostor não superior a 7% por espécie de instrumento de ataque de apresentação (PAI, na sigla em inglês), conforme medido pelos protocolos de teste de biometria do Android.

Se as implementações do dispositivo contiverem um sensor de impressão digital sob a tela (UDFPS), elas:

[C-SR-11] É ALTAMENTE RECOMENDADO impedir que a área sensível ao toque do UDFPS interfira na navegação de três botões, que alguns usuários podem exigir para fins de acessibilidade.

7.3.11. Sensor de pose

Implementações de dispositivos:

PODE oferecer suporte ao sensor de pose com 6 graus de liberdade.

Se as implementações de dispositivos oferecerem suporte ao sensor de pose com seis graus de liberdade, elas:

[C-1-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_POSE_6DOF.
[C-1-2] PRECISA ser mais preciso do que o vetor de rotação sozinho.

7.3.12. Sensor de ângulo de dobradiça

Se as implementações de dispositivo oferecerem suporte a um sensor de ângulo de articulação, elas:

[C-1-1] É OBRIGATÓRIO implementar e informar TYPE_HINGLE_ANGLE.
[C-1-2] PRECISA oferecer suporte a pelo menos duas leituras entre 0 e 360 graus, ou seja, incluindo 0 e 360 graus.
[C-1-3] É PRECISO retornar um sensor de ativação para getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Se as implementações do dispositivo incluírem suporte ao 802.1.15.4 e exporem a funcionalidade a um aplicativo de terceiros, elas:

[C-1-2] É OBRIGATÓRIO informar a flag de recurso de hardware android.hardware.uwb.
[C-1-3] PRECISA oferecer suporte a todos os conjuntos de configuração a seguir (combinações predefinidas de parâmetros do FIRA UCI) definidos na implementação do AOSP.
- CONFIG_ID_1: STATIC STS DS-TWR de unicast definido por FiRa, modo adiado, intervalo de 240 ms.
- CONFIG_ID_2: STATIC STS DS-TWR de um para muitos definido por FiRa, modo adiado, intervalo de 200 ms. Caso de uso típico: o smartphone interaja com muitos dispositivos inteligentes.
- CONFIG_ID_3: igual a CONFIG_ID_1, exceto que os dados de ângulo de chegada (AoA) não são informados.
- CONFIG_ID_4: igual a CONFIG_ID_1, exceto que o modo de segurança P-STS está ativado.
- CONFIG_ID_5: igual a CONFIG_ID_2, exceto que o modo de segurança P-STS está ativado.
- CONFIG_ID_6: igual a CONFIG_ID_3, exceto que o modo de segurança P-STS está ativado.
- CONFIG_ID_7: igual a CONFIG_ID_2, exceto que o modo de chave de controle individual do P-STS está ativado.
[C-1-4] É PRECISO fornecer uma característica de uso para permitir que o usuário ative/desative o rádio UWB.
[C-1-5] É PRECISO que os apps que usam rádio UWB tenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICES).

A aprovação nos testes de conformidade e certificação relevantes definidos por organizações padronizadas, incluindo FIRA, CCC e CSA, ajuda a garantir que o 802.1.15.4 funcione corretamente.

7.4. Conectividade de dados

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android e neste documento, se refere especificamente a hardware relacionado a fazer chamadas de voz e enviar mensagens SMS ou estabelecer dados móveis por uma rede móvel (por exemplo, GSM, CDMA, LTE, NR)GSM ou CDMA. Um dispositivo compatível com "Telefonia" pode oferecer alguns ou todos os serviços de chamada, mensagens e dados de acordo com o produto.

O Android PODE ser usado em dispositivos que não incluem hardware de telefonia. Ou seja, o Android é compatível com dispositivos que não são smartphones.

Se as implementações de dispositivos incluírem telefonia GSM ou CDMA, elas:

[C-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.telephony e outras flags de subrecurso de acordo com a tecnologia.
[C-1-2] É PRECISO implementar suporte total à API para essa tecnologia.
DEVEM permitir todos os tipos de serviço celular disponíveis (2G, 3G, 4G, 5G etc.) durante chamadas de emergência (independentemente dos tipos de rede definidos por SetAllowedNetworkTypeBitmap()).

Se as implementações de dispositivos não incluírem hardware de telefonia, elas:

[C-2-1] É OBRIGATÓRIO implementar as APIs completas como no-ops.

Se as implementações de dispositivos oferecerem suporte a eUICCs ou eSIMs/chips integrados e incluírem um mecanismo reservado para disponibilizar a funcionalidade de eSIM para desenvolvedores de terceiros, eles:

[C-3-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.telephony.euicc.

Se as implementações do dispositivo não definirem a propriedade do sistema ro.telephony.iwlan\_operation\_mode como "legado", elas:

[C-4-1] NÃO DEVE informar 'NETWORK_TYPE_IWLAN' usando NetworkRegistrationInfo#getAccessNetworkTechnology() quando NetworkRegistrationInfo#getTransportType() for informado como 'TRANSPORT_TYPE_WWAN' para a mesma instância de NetworkRegistrationInfo.

Se as implementações de dispositivos oferecerem suporte a um único registro de subsistema multimídia IP (IMS, na sigla em inglês) para os recursos de serviço de telefonia multimídia (MMTEL) e serviço de comunicação avançado (RCS) e forem compatíveis com os requisitos da operadora de celular em relação ao uso de um único registro de IMS para todo o tráfego de sinalização de IMS, elas:

[C-5-1] É PRECISO declarar a flag de recurso android.hardware.telephony.ims e fornecer uma implementação completa da API ImsService para MMTEL e RCS API User Capability Exchange.
[C-5-2] É PRECISO declarar a flag de recurso android.hardware.telephony.ims.singlereg e fornecer uma implementação completa da API SipTransport, da API GbaService, indicações de portador dedicadas usando o HAL IRadio 1.6 e provisionamento por um servidor de configuração automática (ACS) ou outro mecanismo de provisionamento proprietário usando a API IMS Configuration.

Se as implementações de dispositivo informarem o recurso android.hardware.telephony, faça o seguinte:

[C-6-1] O SmsManager#sendTextMessage e o SmsManager#sendMultipartTextMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer a funcionalidade de mensagens de texto. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer a funcionalidade de mensagens multimídia.
[C-6-2] O aplicativo designado por android.provider.Telephony.Sms#getDefaultSmsPackage PRECISA usar as APIs SmsManager ao enviar e receber mensagens SMS e MMS. A implementação de referência do AOSP em packages/apps/Messaging atende a esse requisito.
[C-6-3] O aplicativo que responde a Intent#ACTION_DIAL PRECISA oferecer suporte à entrada de códigos de discagem arbitrários formatados como *#*#CODE#*#* e acionar uma transmissão TelephonyManager#ACTION_SECRET_CODE correspondente.
[C-6-4] O aplicativo que responde a Intent#ACTION_DIAL PRECISA usar VoicemailContract.Voicemails#TRANSCRIPTION para mostrar a transcrição visual do correio de voz aos usuários, se ele oferece suporte a transcrições visuais do correio de voz.
[C-6-5] PRECISA representar todos os SubscriptionInfo com UUIDs de grupo equivalentes como uma única assinatura em todos os affordances visíveis para o usuário que mostram e controlam as informações do chip SIM. Exemplos de affordances incluem interfaces de configurações que correspondem a Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
[C-6-6] NÃO PRECISA mostrar ou permitir o controle de nenhuma SubscriptionInfo com um UUID de grupo não nulo e um bit oportunista em nenhuma característica visível para o usuário que permite a configuração ou o controle das configurações do cartão SIM.

Se as implementações do dispositivo informarem o recurso android.hardware.telephony e fornecerem uma barra de status do sistema, faça o seguinte:

[C-7-1] É OBRIGATÓRIO selecionar uma assinatura ativa representativa para um determinado UUID de grupo para mostrar ao usuário em qualquer recurso que forneça informações de status do SIM. Exemplos de affordances incluem o ícone de sinal de celular da barra de status ou o bloco de Configurações rápidas.
[C-SR-1] É ALTAMENTE RECOMENDADO que a assinatura representativa seja escolhida para ser a assinatura de dados ativa, a menos que o dispositivo esteja em uma chamada de voz, durante a qual é ALTAMENTE RECOMENDADO que a assinatura representativa seja a assinatura de voz ativa.

Se as implementações de dispositivos informarem o recurso android.hardware.telephony, faça o seguinte:

[C-6-7] É PRECISO ser capaz de abrir e usar simultaneamente o número máximo de canais lógicos (20 no total) para cada UICC de acordo com o ETSI TS 102 221.
[C-6-8] NENHUM dos comportamentos a seguir pode ser aplicado a apps de operadora ativos (designados por TelephonyManager#getCarrierServicePackageName) automaticamente ou sem a confirmação explícita do usuário:
- Revogar ou limitar o acesso à rede
- Revogar permissões
- Restringir a execução de apps em segundo plano ou em primeiro plano além dos recursos de gerenciamento de energia incluídos no AOSP
- Desativar ou desinstalar o app

Se as implementações do dispositivo informarem o recurso android.hardware.telephony e todas as assinaturas não oportunísticas ativas que compartilham um UUID de grupo forem desativadas, removidas fisicamente do dispositivo ou marcadas como oportunísticas, o dispositivo:

[C-8-1] É OBRIGATÓRIO desativar automaticamente todas as assinaturas oportunistas ativas restantes no mesmo grupo.

Se as implementações de dispositivos incluem telefonia GSM, mas não telefonia CDMA, elas:

[C-9-1] NÃO DEVE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
[C-9-2] É PRECISO gerar uma IllegalArgumentException ao tentar definir qualquer tipo de rede 3GPP2 em máscaras de bits de tipo de rede preferido ou permitido.
[C-9-3] PRECISA retornar uma string vazia de TelephonyManager#getMeid.

Se as implementações do dispositivo oferecerem suporte a eUICCs com várias portas e perfis, elas:

[C-10-1] É PRECISO declarar a flag de recurso android.hardware.telephony.euicc.mep.

7.4.1.1. Compatibilidade com o bloqueio de números

Se as implementações de dispositivos informarem o recurso android.hardware.telephony.calling, elas:

[C-1-1] É PRECISO incluir suporte a bloqueio de números
[C-1-2] É PRECISO implementar totalmente BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.
[C-1-3] É PRECISO bloquear todas as ligações e mensagens de um número de telefone em 'BlockedNumberProvider' sem nenhuma interação com apps. A única exceção é quando o bloqueio de número é temporariamente suspenso, conforme descrito na documentação do SDK.
[C-1-4] É PRECISO gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada e FILTRAR chamadas com BLOCKED_TYPE da visualização de registro de chamadas padrão no app discador pré-instalado.
[C-1-5] NÃO É PERMITIDO gravar no provedor de telefonia para uma mensagem bloqueada.
[C-1-6] É PRECISO implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada pelo método TelecomManager.createManageBlockedNumbersIntent().
[C-1-7] NÃO É PERMITIDO que usuários secundários acessem ou editem os números bloqueados no dispositivo, porque a plataforma Android assume que o usuário principal tem controle total dos serviços de telefonia, uma única instância, no dispositivo. Toda a interface relacionada ao bloqueio PRECISA ser oculta para usuários secundários, e a lista de bloqueio PRECISA ser respeitada.
DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.
DEVE fornecer uma capacidade do usuário para mostrar chamadas bloqueadas no app de discagem pré-instalado.

7.4.1.2. API Telecom

Se as implementações de dispositivos informarem android.hardware.telephony.calling, elas:

[C-1-1] É PRECISO oferecer suporte às APIs ConnectionService descritas no SDK.
[C-1-2] É OBRIGATÓRIO mostrar uma nova chamada recebida e oferecer ao usuário a possibilidade de aceitar ou rejeitar a chamada recebida quando o usuário estiver em uma chamada feita por um app de terceiros que não oferece suporte ao recurso de retenção especificado por CAPABILITY_SUPPORT_HOLD.
[C-1-3] É PRECISO ter um aplicativo que implemente InCallService.
[C-SR-1] É ALTAMENTE RECOMENDADO notificar o usuário de que atender uma chamada recebida encerrará uma chamada em andamento.

A implementação do AOSP atende a esses requisitos com uma notificação de alerta que indica ao usuário que atender uma chamada recebida fará com que a outra chamada seja encerrada.
[C-SR-2] É ALTAMENTE RECOMENDADO pré-carregar o app de discagem padrão que mostra uma entrada de registro de chamadas e o nome de um app de terceiros no registro de chamadas quando o app de terceiros define a chave EXTRA_LOG_SELF_MANAGED_CALLS extras no PhoneAccount para true.
[C-SR-3] É ALTAMENTE RECOMENDADO processar os eventos KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK dos fones de ouvido de áudio para as APIs android.telecom conforme abaixo:
- Chame Connection.onDisconnect() quando um toque curto do evento de tecla for detectado durante uma chamada em andamento.
- Chame Connection.onAnswer() quando um toque curto do evento de tecla for detectado durante uma chamada recebida.
- Chame Connection.onReject() quando um pressionamento longo do evento de tecla for detectado durante uma chamada recebida.
- Alternar o status de silêncio do CallAudioState.

7.4.1.3. Descarregar o Keepalive NAT-T da rede celular

Implementações de dispositivos:

DEVE incluir suporte para o offload de keepalive de rede celular.

Se as implementações de dispositivos incluírem suporte ao offload de keepalive de rede celular e exibirem a funcionalidade para apps de terceiros, elas:

[C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
[C-1-2] É NECESSÁRIO oferecer suporte a pelo menos um slot de manutenção de conexão simultâneo por rede celular.
[C-1-3] É PRECISO oferecer suporte a tantos slots de keepalive celular simultâneos quantos forem compatíveis com o HAL do rádio celular.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte a pelo menos três slots de keepalive celular por instância de rádio.

Se as implementações de dispositivos não incluírem suporte ao offload de keepalive de rede celular, elas:

[C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementações de dispositivos:

DEVE incluir suporte a uma ou mais formas de 802.11.

Se as implementações de dispositivos incluírem suporte a 802.11 e exporem a funcionalidade a um aplicativo de terceiros, elas:

[C-1-1] É OBRIGATÓRIO implementar a API correspondente do Android.
[C-1-2] É OBRIGATÓRIO informar a flag de recurso de hardware android.hardware.wifi.
[C-1-3] É OBRIGATÓRIO implementar a API multicast conforme descrito na documentação do SDK.

Início dos novos requisitos para o Android 15

[C-1-4] É PRECISO oferecer suporte a DNS multicast (mDNS) e NÃO FILTRAR pacotes mDNS (224.0.0.251 ou ff02::fb) em qualquer momento da operação, inclusive quando a tela não está em um estado ativo, a menos que a exclusão ou filtragem desses pacotes seja necessária para permanecer dentro dos intervalos de consumo de energia exigidos por requisitos normativos aplicáveis ao mercado-alvo.

[C-1-4] DEVE oferecer suporte a mDNS e NÃO DEVE filtrar pacotes mDNS (224.0.0.251 ou ff02::fb) em qualquer momento da operação, inclusive quando a tela não está em um estado ativo, a menos que o bloqueio de multicast não seja mantido e os pacotes sejam filtrados pelo APF. Os pacotes não são necessários para atender a nenhuma operação mDNS atualmente solicitada por aplicativos usando as APIs NsdManager. No entanto, o dispositivo PODE filtrar pacotes mDNS se isso for necessário para permanecer dentro dos intervalos de consumo de energia exigidos pelas regulamentações aplicáveis ao mercado-alvo.

Fim dos novos requisitos

[C-1-5] NÃO DEVE tratar a chamada do método da API WifiManager.enableNetwork() como uma indicação suficiente para alternar o Network ativo atualmente, que é usado por padrão para o tráfego do aplicativo e é retornado por métodos da API ConnectivityManager como getActiveNetwork e registerDefaultNetworkCallback. Em outras palavras, eles só poderão desativar o acesso à Internet fornecido por qualquer outro provedor de rede (por exemplo, dados móveis) se validarem que a rede Wi-Fi está fornecendo acesso à Internet.
[C-1-6] É ALTAMENTE RECOMENDADO que, quando o método da API ConnectivityManager.reportNetworkConnectivity() for chamado, reavalie o acesso à Internet no Network e, assim que a avaliação determinar que o Network atual não fornece mais acesso à Internet, mude para qualquer outra rede disponível (por exemplo, dados móveis) que ofereça acesso à Internet.
[C-1-7] É PRECISO randomizar o endereço MAC de origem e o número de sequência dos frames de solicitação de sondagem, uma vez no início de cada verificação, enquanto a STA está desconectada.
[C-1-8] É PRECISO usar um endereço MAC consistente (NÃO É PERMITIDO randomizar o endereço MAC no meio de uma verificação).
[C-1-9] É PRECISO iterar o número de sequência da solicitação de sondagem normalmente (sequencialmente) entre as solicitações de sondagem em uma verificação.
[C-1-10] É PRECISO randomizar o número de sequência da solicitação de sondagem entre a última solicitação de sondagem de uma verificação e a primeira solicitação de sondagem da próxima verificação.
[C-SR-1] É ALTAMENTE RECOMENDADO randomizar o endereço MAC de origem usado para toda a comunicação STA com um ponto de acesso (AP) durante a associação e associação.
- O dispositivo PRECISA usar um endereço MAC aleatório diferente para cada SSID (FQDN para Passpoint) com que se comunica.
- O dispositivo PRECISA oferecer ao usuário uma opção para controlar a randomização por SSID (FQDN para Passpoint) com opções não aleatórias e aleatórias e PRECISA definir o modo padrão para que novas configurações do Wi-Fi sejam aleatórias.
[C-SR-2] É ALTAMENTE RECOMENDADO usar um BSSID aleatório para qualquer AP criado.
- O endereço MAC PRECISA ser randomizado e persistido por SSID usado pelo AP.
- O DISPOSITIVO PODE oferecer ao usuário uma opção para desativar esse recurso. Se essa opção for fornecida, a randomização PRECISA ser ativada por padrão.

Se as implementações de dispositivos incluírem suporte ao modo de economia de energia do Wi-Fi, conforme definido no padrão IEEE 802.11, elas:

PRECISA desativar o modo de economia de energia do Wi-Fi sempre que um app adquirir bloqueio WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY pelas APIs WifiManager.createWifiLock() e WifiManager.WifiLock.acquire() e o bloqueio estiver ativo.
[C-3-2] A latência média de ida e volta entre o dispositivo e um ponto de acesso enquanto o dispositivo está no modo de bloqueio de latência baixa do Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) PRECISA ser menor do que a latência durante um modo de bloqueio de alto desempenho do Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
[C-SR-3] É ALTAMENTE RECOMENDADO minimizar a latência de ida e volta do Wi-Fi sempre que uma trava de baixa latência (WIFI_MODE_FULL_LOW_LATENCY) é adquirida e entra em vigor.

Se as implementações do dispositivo oferecem suporte ao Wi-Fi e usam essa tecnologia para a verificação de local, elas:

[C-2-1] É OBRIGATÓRIO fornecer uma capacidade do usuário para ativar/desativar a leitura de valor pelo método da API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementações de dispositivos:

DEVE incluir suporte para Wi-Fi Direct (Wi-Fi ponto a ponto).

Se as implementações de dispositivos incluem suporte para Wi-Fi Direct, elas:

[C-1-1] É PRECISO implementar a API correspondente do Android conforme descrito na documentação do SDK.
[C-1-2] É OBRIGATÓRIO informar o recurso de hardware android.hardware.wifi.direct.
[C-1-3] PRECISA ter suporte à operação regular de Wi-Fi.
[C-1-4] É PRECISO oferecer suporte a operações Wi-Fi e Wi-Fi Direct simultaneamente.
[C-SR-1] É ALTAMENTE RECOMENDADO randomizar o endereço MAC de origem para todas as conexões Wi-Fi Direct recém-formadas.

7.4.2.2. Configuração de link direto com Wi-Fi em túnel

Implementações de dispositivos:

DEVE incluir suporte para Wi-Fi Tunneled Direct Link Setup (TDLS) conforme descrito na documentação do SDK do Android.

Se as implementações do dispositivo incluem suporte para TDLS e o TDLS é ativado pela API WiFiManager, elas:

[C-1-1] É PRECISO declarar suporte a TDLS por meio de WifiManager.isTdlsSupported.
Use TDLS apenas quando for possível E benéfico.
DEVE ter alguma heurística e NÃO usar TDLS quando o desempenho for pior do que passar pelo ponto de acesso Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementações de dispositivos:

DEVEM incluir suporte para Wi-Fi Aware.

Se as implementações do dispositivo incluírem suporte ao Wi-Fi Aware e exporem a funcionalidade a apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO implementar as APIs WifiAwareManager conforme descrito na documentação do SDK.
[C-1-2] É OBRIGATÓRIO declarar a flag de recurso android.hardware.wifi.aware.
[C-1-3] É PRECISO oferecer suporte a operações Wi-Fi e Wi-Fi Aware simultaneamente.
[C-1-4] É NECESSÁRIO randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de até 30 minutos e sempre que o Wi-Fi Aware estiver ativado, a menos que uma operação de varredura Aware esteja em andamento ou que um caminho de dados Aware esteja ativo. A randomização não é esperada enquanto o caminho de dados estiver ativo.

Se as implementações do dispositivo incluem suporte para Wi-Fi Aware e localização de Wi-Fi, conforme descrito na Seção 7.4.2.5, e expõem essas funcionalidades a apps de terceiros, então:

[C-2-1] É PRECISO implementar as APIs de descoberta com localização: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint do Wi-Fi

Se as implementações de dispositivos incluem suporte para 802.11 (Wi-Fi), elas:

[C-1-1] É PRECISO incluir suporte para Wi-Fi Passpoint.
[C-1-2] É PRECISO implementar as APIs WifiManager relacionadas à Passpoint conforme descrito na documentação do SDK.
[C-1-3] É necessário oferecer suporte ao padrão IEEE 802.11u, especificamente relacionado à descoberta e seleção de rede, como o serviço de publicidade genérica (GAS, na sigla em inglês) e o protocolo de consulta de rede de acesso (ANQP, na sigla em inglês).
[C-1-4] É PRECISO declarar a flag de recurso android.hardware.wifi.passpoint.
[C-1-5] É PRECISO seguir a implementação do AOSP para descobrir, corresponder e associar a redes do Passpoint.
[C-1-6] PRECISA oferecer suporte a pelo menos o seguinte subconjunto de protocolos de provisionamento de dispositivos, conforme definido na Wi-Fi Alliance Passpoint R2: autenticação EAP-TTLS e SOAP-XML.
[C-1-7] É OBRIGATÓRIO processar o certificado do servidor AAA, conforme descrito na especificação do Hotspot 2.0 R3.
[C-1-8] É PRECISO oferecer suporte ao controle de provisionamento do usuário pelo seletor de Wi-Fi.
[C-1-9] É PRECISO manter as configurações do Passpoint persistentes após reinicializações.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao recurso de aceitação de termos e condições.
[C-SR-2] É ALTAMENTE RECOMENDADO oferecer suporte ao recurso de informações do local.

Se um botão de desativação do controle do usuário global do Passpoint for fornecido, as implementações:

[C-3-1] É PRECISO ativar o Passpoint por padrão.

7.4.2.5. Local do Wi-Fi (tempo de retorno do Wi-Fi - RTT)

Implementações de dispositivos:

DEVE incluir suporte para Local do Wi-Fi.

Se as implementações de dispositivos incluírem suporte ao local do Wi-Fi e exporem a funcionalidade a apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO implementar as APIs WifiRttManager conforme descrito na documentação do SDK.
[C-1-2] É OBRIGATÓRIO declarar a flag de recurso android.hardware.wifi.rtt.
[C-1-3] É PRECISO randomizar o endereço MAC de origem de cada burst de RTT que é executado enquanto a interface Wi-Fi em que o RTT está sendo executado não está associada a um ponto de acesso.
[C-1-4] TEM QUE ser preciso com uma margem de 2 metros a 80 MHz de largura de banda no percentil 68 (calculado com a função de distribuição cumulativa).
[C-SR-1] É ALTAMENTE RECOMENDADO informar com precisão até 1,5 metro com largura de banda de 80 MHz no percentil 68 (calculado com a função de distribuição cumulativa).

7.4.2.6. Descarregar o keepalive do Wi-Fi

Implementações de dispositivos:

DEVE incluir suporte para transferência de dados de keepalive do Wi-Fi.

Se as implementações de dispositivos incluírem suporte ao offload de keepalive do Wi-Fi e exporem a funcionalidade a apps de terceiros, elas:

[C-1-1] É PRECISO oferecer suporte à API SocketKeepAlive.
[C-1-2] É PRECISO ter suporte a pelo menos três slots de keepalive simultâneos por Wi-Fi

Se as implementações de dispositivos não incluírem suporte ao offload de keepalive do Wi-Fi, elas:

[C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocolo de provisionamento de dispositivo)

Implementações de dispositivos:

DEVE incluir suporte para Wi-Fi Easy Connect (DPP).

Se as implementações de dispositivos incluírem suporte ao Wi-Fi Easy Connect e exporem a funcionalidade a apps de terceiros, elas:

[C-1-1] O método WifiManager#isEasyConnectSupported() PRECISA retornar true.

7.4.2.8. Validação do certificado do servidor de Wi-Fi empresarial

Se o certificado do servidor Wi-Fi não for validado ou se o nome de domínio do servidor Wi-Fi não estiver definido, as implementações do dispositivo:

[C-SR-1] É ALTAMENTE RECOMENDADO não oferecer ao usuário a opção de adicionar manualmente a rede Wi-Fi corporativa no app Configurações.

7.4.2.9. Trust on First Use (TOFU)

Se as implementações de dispositivos oferecerem suporte ao Trust on First Use (TOFU) e permitirem que o usuário defina configurações WPA/WPA2/WPA3-Enterprise, elas:

[C-4-1] É PRECISO fornecer ao usuário uma opção para selecionar o uso de TOFU.

7.4.3. Bluetooth

Se as implementações do dispositivo oferecem suporte ao perfil de áudio Bluetooth, elas:

DEVE oferecer suporte a codecs de áudio avançados e Bluetooth (por exemplo, LDAC)

Se as implementações do dispositivo oferecerem suporte a HFP, A2DP e AVRCP, elas:

DEVE oferecer suporte a pelo menos cinco dispositivos conectados.

Se as implementações do dispositivo declararem o recurso android.hardware.vr.high_performance, elas:

[C-1-1] É PRECISO ter suporte a Bluetooth 4.2 e à extensão de comprimento de dados do Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.

Se as implementações do dispositivo incluem suporte para Bluetooth e Bluetooth de baixa energia, elas:

[C-2-1] É OBRIGATÓRIO declarar os recursos relevantes da plataforma (android.hardware.bluetooth e android.hardware.bluetooth_le, respectivamente) e implementar as APIs da plataforma.
DEVE implementar perfis relevantes do Bluetooth, como A2DP, AVRCP, OBEX, HFP etc., conforme apropriado para o dispositivo.

Se as implementações de dispositivos incluem suporte para Bluetooth de baixa energia (BLE), elas:

[C-3-1] É OBRIGATÓRIO declarar o recurso de hardware android.hardware.bluetooth_le.
[C-3-2] É OBRIGATÓRIO ativar as APIs de Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e android.bluetooth.
[C-3-3] É PRECISO informar o valor correto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar se a lógica de filtragem das classes da API ScanFilter está implementada.
[C-3-4] É OBRIGATÓRIO informar o valor correto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar se a publicidade de baixa energia é compatível.
[C-3-5] É NECESSÁRIO implementar um tempo limite de endereço privado solucionável (RPA) de no máximo 15 minutos e rotacionar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo estiver usando BLE ativamente para digitalização ou publicidade. Para evitar ataques de tempo, os intervalos de tempo limite também precisam ser aleatórios entre 5 e 15 minutos.
DEVE oferecer suporte ao descarregamento da lógica de filtragem para o chipset Bluetooth ao implementar a API ScanFilter.
DEVE oferecer suporte ao descarregamento da verificação em lote para o chipset Bluetooth.
DEVE oferecer suporte a vários anúncios com pelo menos quatro slots.

Se as implementações do dispositivo oferecem suporte ao Bluetooth LE e usam esse tipo de Bluetooth para a verificação de local, elas:

[C-4-1] É OBRIGATÓRIO fornecer uma característica de uso do usuário para ativar/desativar a leitura de valor pela BluetoothAdapter.isBleScanAlwaysAvailable() da API do sistema.

Se as implementações do dispositivo incluírem suporte para o perfil de Bluetooth LE e de aparelhos auditivos, conforme descrito em Suporte a áudio de aparelho auditivo usando Bluetooth LE, elas:

[C-5-1] É PRECISO retornar true para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Se as implementações de dispositivos incluem suporte para Bluetooth ou Bluetooth Low Energy, elas:

[C-6-1] É PRECISO restringir o acesso a qualquer metadado do Bluetooth (como resultados de pesquisa) que possa ser usado para derivar a localização do dispositivo, a menos que o app solicitante transmita com sucesso uma verificação de permissão android.permission.ACCESS_FINE_LOCATION com base no estado atual em primeiro/segundo plano.

Se as implementações do dispositivo incluírem suporte a Bluetooth ou Bluetooth de baixa energia e o manifesto do app não incluir uma declaração do desenvolvedor informando que ele não está extraindo a localização do Bluetooth, ele:

[C-6-2] É OBRIGATÓRIO restringir o acesso ao Bluetooth atrás do android.permission.ACCESS_FINE_LOCATION.

Se as implementações do dispositivo retornarem true para a API BluetoothAdapter.isLeAudioSupported(), elas:

[C-7-1] É PRECISO oferecer suporte a clientes unicast.
[C-7-2] É PRECISO oferecer suporte a 2M PHY.
[C-7-3] É PRECISO oferecer suporte à publicidade estendida do LE.
[C-7-4] É PRECISO oferecer suporte a pelo menos duas conexões de CIS em um CIG.
[C-7-5] É PRECISO ativar o cliente unicast do BAP, o coordenador do conjunto CSIP, o servidor MCP, o controlador do VCP e o servidor CCP simultaneamente.
[C-SR-1] É ALTAMENTE RECOMENDADO ativar o cliente unicast HAP.

Se as implementações do dispositivo retornarem true para a API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), elas:

[C-8-1] É PRECISO ter suporte a pelo menos 2 links BIS em um BIG.
[C-8-2] É PRECISO ativar a fonte de transmissão do BAP e o assistente de transmissão do BAP simultaneamente.
[C-8-3] É PRECISO oferecer suporte à publicidade periódica de LE.

Se as implementações do dispositivo retornarem true para a API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), elas:

[C-9-1] É PRECISO oferecer suporte a PAST (transferência periódica de sincronização de publicidade).
[C-9-2] É PRECISO oferecer suporte à publicidade periódica de LE.

Se as implementações do dispositivo declararem FEATURE_BLUETOOTH_LE, elas:

[C-10-1] É OBRIGATÓRIO que as medições de RSSI estejam dentro de +/-9 dB para 95% das medições a 1 m de distância de um dispositivo de referência transmitindo em ADVERTISE_TX_POWER_HIGH em um ambiente de linha de visão.
[C-10-2] É PRECISO incluir correções de Rx/Tx para reduzir as variações por canal de modo que as medições em cada um dos três canais, em cada uma das antenas (se várias forem usadas), estejam dentro de +/-3 dB uma da outra para 95% das medições.
[C-SR-2] É ALTAMENTE RECOMENDADO medir e compensar o deslocamento de Rx para garantir que a RSSI média do BLE seja -60 dBm +/-10 dB a 1 m de distância de um dispositivo de referência que transmite em ADVERTISE_TX_POWER_HIGH, em que os dispositivos são orientados de modo que estejam em "planos paralelos" com telas voltadas para a mesma direção.
[C-SR-3] É ALTAMENTE RECOMENDADO medir e compensar o deslocamento de transmissão para garantir que a RSSI média do BLE seja -60 dBm +/-10 dB ao fazer a varredura de um dispositivo de referência posicionado a 1 m de distância e transmitindo em ADVERTISE_TX_POWER_HIGH, em que os dispositivos estão orientados de modo que estejam em "planos paralelos" com telas voltadas para a mesma direção.

É ALTAMENTE RECOMENDÁVEL seguir as etapas de configuração de medição especificadas em Requisitos de calibração de presença.

7.4.4. Comunicação a curta distância (NFC)

Implementações de dispositivos:

DEVE incluir um transceptor e hardware relacionado para comunicações a curta distância (NFC).
[C-0-1] É PRECISO implementar as APIs android.nfc.NdefMessage e android.nfc.NdefRecord, mesmo que elas não incluam suporte a NFC ou declarem o recurso android.hardware.nfc, porque as classes representam um formato de representação de dados independente de protocolo.

Se as implementações de dispositivos incluírem hardware NFC e planejam disponibilizá-lo para apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO informar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature().
PRECISA ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões NFC:
[C-1-2] PRECISA ser capaz de atuar como leitor/gravador do Fórum de NFC (conforme definido pela especificação técnica do Fórum de NFC NFCForum-TS-DigitalProtocol-1.0) pelos seguintes padrões de NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Tipos de tag do NFC Forum 1, 2, 3, 4 e 5 (definidos pelo NFC Forum)
[C-SR-1] ALTAMENTE RECOMENDADO para ser capaz de ler e gravar mensagens NDEF e dados brutos usando os seguintes padrões de NFC. Embora os padrões de NFC sejam indicados como ALTAMENTE RECOMENDADOS, a definição de compatibilidade para uma versão futura está planejada para mudar isso para OBRIGATÓRIO. Esses padrões são opcionais nesta versão, mas serão obrigatórios em versões futuras. Os dispositivos atuais e novos que executam essa versão do Android precisam atender a esses requisitos para fazer upgrade para as versões futuras da plataforma.
[C-1-13] É PRECISO pesquisar todas as tecnologias com suporte no modo de descoberta de NFC.
DEVE estar no modo de descoberta de NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.
DEVE ser capaz de ler o código de barras e o URL (se codificado) dos produtos de código de barras NFC Thinfilm.

Os links disponíveis publicamente não estão disponíveis para as especificações do JIS, ISO e NFC do fórum citadas acima.

O Android inclui suporte para o modo de emulação de cartão host (HCE) de NFC.

Se as implementações do dispositivo incluírem um chipset de controlador NFC compatível com HCE (para NfcA e/ou NfcB) e oferecerem suporte ao roteamento de ID do aplicativo (AID), elas:

[C-2-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.nfc.hce.
[C-2-2] É PRECISO oferecer suporte a APIs NFC HCE, conforme definido no SDK do Android.

Se as implementações do dispositivo incluírem um chipset de controlador NFC compatível com HCE para NfcF e implementarem o recurso para aplicativos de terceiros, elas:

[C-3-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.nfc.hcef.
[C-3-2] É OBRIGATÓRIO implementar as APIs de emulação de cartão NfcF conforme definido no SDK do Android.

Se as implementações do dispositivo incluírem suporte geral a NFC, conforme descrito nesta seção, e oferecerem suporte a tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) no papel de leitor/gravador, elas:

[C-4-1] É OBRIGATÓRIO implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
[C-4-2] É OBRIGATÓRIO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). Esse não é um recurso padrão do Android e, como tal, não aparece como uma constante na classe android.content.pm.PackageManager.

7.4.5. Protocolos de rede e APIs

7.4.5.1. Capacidade mínima de rede

Implementações de dispositivos:

[C-0-1] PRECISA incluir suporte a uma ou mais formas de rede de dados. Especificamente, as implementações de dispositivos precisam incluir suporte a pelo menos um padrão de dados com capacidade de 200 Kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
DEVE incluir suporte a pelo menos um padrão de dados sem fio comum, como 802.11 (Wi-Fi), quando um padrão de rede física (como Ethernet) é a conexão de dados principal.
PODE implementar mais de uma forma de conectividade de dados.

7.4.5.2. IPv6

Implementações de dispositivos:

[C-0-2] É PRECISO incluir uma pilha de rede IPv6 e oferecer suporte à comunicação IPv6 usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, bem como as APIs nativas, como os sockets AF_INET6.
[C-0-3] É OBRIGATÓRIO ativar o IPv6 por padrão.
- É PRECISO garantir que a comunicação IPv6 seja tão confiável quanto o IPv4, por exemplo:
  - [C-0-4] É NECESSÁRIO manter a conectividade IPv6 no modo de suspensão.
  - [C-0-5] A limitação de taxa NÃO PODE fazer com que o dispositivo perca a conectividade IPv6 em qualquer rede compatível com IPv6 que use tempos de vida de RA de pelo menos 180 segundos.
[C-0-6] É OBRIGATÓRIO fornecer a aplicativos de terceiros conectividade IPv6 direta à rede quando conectado a uma rede IPv6, sem qualquer forma de tradução de endereço ou de porta que ocorra localmente no dispositivo. As APIs gerenciadas, como Socket#getLocalAddress ou Socket#getLocalPort, e as APIs NDK, como getsockname() ou IPV6_PKTINFO, precisam retornar o endereço IP e a porta que são realmente usados para enviar e receber pacotes na rede e que são visíveis como o IP de origem e a porta para servidores da Internet (Web).

O nível necessário de suporte ao IPv6 depende do tipo de rede, conforme mostrado nos requisitos a seguir.

Se as implementações de dispositivos forem compatíveis com Wi-Fi, elas:

[C-1-1] É PRECISO oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.

Se as implementações de dispositivos oferecem suporte a Ethernet, elas:

[C-2-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 em Ethernet.

Se as implementações de dispositivos oferecerem suporte a dados móveis, elas:

[C-3-1] É PRECISO oferecer suporte à operação IPv6 (somente IPv6 e possivelmente pilha dupla) em redes celulares.

Se as implementações de dispositivos forem compatíveis com mais de um tipo de rede (por exemplo, Wi-Fi e dados móveis), eles:

[C-4-1] É necessário atender simultaneamente aos requisitos acima em cada rede quando o dispositivo estiver conectado simultaneamente a mais de um tipo de rede.

7.4.5.3. Portais passivos

Um portal cativo se refere a uma rede que exige login para ter acesso à Internet.

Se as implementações de dispositivo fornecerem uma implementação completa do android.webkit.Webview API, elas:

[C-1-1] É PRECISO fornecer um aplicativo de portal captive para processar a intent ACTION_CAPTIVE_PORTAL_SIGN_IN e mostrar a página de login do portal captive, enviando essa intent, em chamada para a API do sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] É OBRIGATÓRIO realizar a detecção de portais cativos e oferecer suporte ao login pelo aplicativo de portal cativo quando o dispositivo estiver conectado a qualquer tipo de rede, incluindo rede celular/móvel, Wi-Fi, Ethernet ou Bluetooth.
[C-1-3] É PRECISO oferecer suporte ao login em portais cativos usando DNS de texto sem criptografia quando o dispositivo estiver configurado para usar o modo estrito de DNS particular.
[C-1-4] É OBRIGATÓRIO usar o DNS criptografado de acordo com a documentação do SDK para android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive para todo o tráfego de rede que não se comunica explicitamente com o portal de acesso.
[C-1-5] É PRECISO garantir que, enquanto o usuário estiver fazendo login em um portal capturado, a rede padrão usada pelos aplicativos (retornada por ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback e usada por padrão pelas APIs de rede Java, como java.net.Socket e APIs nativas, como connect()) seja qualquer outra rede disponível que ofereça acesso à Internet, se disponível.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

[C-0-1] A configuração mestre de sincronização automática PRECISA estar ativada por padrão para que o método getMasterSyncAutomatically() retorne "true".

7.4.7. Economia de dados

Se as implementações de dispositivos incluírem uma conexão limitada, elas serão:

[C-SR-1] É ALTAMENTE RECOMENDADO fornecer o modo de economia de dados.

Se as implementações do dispositivo oferecerem o modo de Economia de dados, elas:

[C-1-1] É PRECISO oferecer suporte a todas as APIs na classe ConnectivityManager conforme descrito na documentação do SDK.

Se as implementações do dispositivo não oferecerem o modo de economia de dados, elas:

[C-2-1] PRECISA retornar o valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().
[C-2-2] NÃO DEVE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Elementos de segurança

Se as implementações de dispositivos oferecerem suporte a elementos seguros com suporte à API Open Mobile e os disponibilizarem para apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO enumerar os leitores de elementos seguros disponíveis usando a API android.se.omapi.SEService.getReaders().
[C-1-2] É NECESSÁRIO declarar os flags de recursos corretos usando android.hardware.se.omapi.uicc para o dispositivo com elementos seguros baseados em UICC, android.hardware.se.omapi.ese para o dispositivo com elementos seguros baseados em eSE e android.hardware.se.omapi.sd para o dispositivo com elementos seguros baseados em SD.

7.4.9. UWB

Se as implementações de dispositivos incluírem suporte ao 802.1.15.4 e exporem a funcionalidade a um aplicativo de terceiros, elas:

[C-1-1] É OBRIGATÓRIO implementar a API Android correspondente no android.uwb.
[C-1-2] É PRECISO informar a flag de recurso de hardware android.hardware.uwb.
[C-1-3] PRECISA oferecer suporte a todos os perfis UWB relevantes definidos na implementação do Android.
[C-1-4] É PRECISO fornecer uma característica de uso para permitir que o usuário ative/desative o rádio UWB.
[C-1-5] É PRECISO aplicar que os apps que usam rádio UWB tenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICES).
[C-SR-1] É ALTAMENTE RECOMENDADO passar nos testes de conformidade e certificação relevantes definidos por organizações de padrão, incluindo FIRA, CCC e CSA.
[C-1-6] É PRECISO garantir que as medições de distância estejam dentro de +/-15 cm para 95% das medições no ambiente de linha de visão a 1 m de distância em uma câmara não reflexiva.
[C-1-7] É OBRIGATÓRIO garantir que a mediana das medições de distância a 1 m do dispositivo de referência esteja entre [0,75 m, 1,25 m], em que a distância real é medida a partir da borda superior do DUT.
[C-SR-2] É ALTAMENTE RECOMENDADO seguir as etapas de configuração de medição especificadas em Requisitos de calibração de presença.

7,5. Cameras

Se as implementações do dispositivo incluírem pelo menos uma câmera, elas:

[C-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.camera.any.
[C-1-2] É PRECISO que um aplicativo possa alocar simultaneamente três bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo sensor de câmera de maior resolução no dispositivo, enquanto a câmera está aberta para a finalidade de visualização básica e captura de fotos.
[C-1-3] É necessário garantir que o app de câmera padrão pré-instalado que processa intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE seja responsável por remover a localização do usuário nos metadados da imagem antes de enviar para o app de recebimento quando ele não tiver ACCESS_FINE_LOCATION.

Se as implementações do dispositivo oferecem suporte ao recurso de saída HDR de 10 bits, elas:

[C-2-1] É PRECISO oferecer suporte a pelo menos o perfil HDR HLG para todos os dispositivos de câmera com saída de 10 bits.
[C-2-2] É NECESSÁRIO oferecer suporte à saída de 10 bits para a câmera traseira principal ou frontal principal.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à saída de 10 bits para as duas câmeras principais.
[C-2-3] PRECISA oferecer suporte aos mesmos perfis HDR para todas as subcâmeras físicas com compatibilidade com BACKWARD_COMPATIBLE de uma câmera lógica e a própria câmera lógica.

Para dispositivos de câmera lógica com suporte a HDR de 10 bits que implementam a API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, eles:

[C-3-1] PRECISA oferecer suporte à alternância entre todas as câmeras físicas com compatibilidade com versões anteriores pelo controle CONTROL_ZOOM_RATIO na câmera lógica.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera que captura imagens do mundo real no lado oposto do dispositivo, como uma câmera tradicional. Em dispositivos portáteis, é uma câmera localizada na lateral do dispositivo, oposta à tela.

Implementações de dispositivos:

DEVE incluir uma câmera traseira.

Se as implementações do dispositivo incluírem pelo menos uma câmera traseira, elas:

[C-1-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera e android.hardware.camera.any.
[C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
DEVE ter o autofoco de hardware ou de software implementado no driver da câmera (transparente para o software do aplicativo).
PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
PODE incluir um flash.

Se a câmera tiver um flash:

[C-2-1] A lâmpada do flash PRECISA DE ESTAR acesa enquanto uma instância de android.hardware.Camera.PreviewCallback foi registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha ativado explicitamente o flash ativando os atributos FLASH_MODE_AUTO ou FLASH_MODE_ON de um objeto Camera.Parameters. Essa restrição não se aplica ao aplicativo de câmera do sistema integrado do dispositivo, mas apenas a apps de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

Uma câmera frontal é uma câmera voltada para o usuário que normalmente é usada para capturar a imagem do usuário, como em videoconferências e aplicativos semelhantes. Em dispositivos portáteis, é uma câmera localizada no mesmo lado do dispositivo que a tela.

Implementações de dispositivos:

PODE incluir uma câmera frontal.

Se as implementações do dispositivo incluírem pelo menos uma câmera frontal, elas:

[C-1-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
[C-1-2] PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
[C-1-3] NÃO use uma câmera frontal como padrão para a API Camera e NÃO configure a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera do dispositivo.
[C-1-4] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo quando o aplicativo atual requer explicitamente que a tela da câmera seja girada por uma chamada ao método android.hardware.Camera.setDisplayOrientation(). Por outro lado, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo quando o aplicativo atual não solicita explicitamente que a tela da câmera seja girada por uma chamada para o método android.hardware.Camera.setDisplayOrientation().
[C-1-5] NÃO é permitido espelhar os streams de imagem estática ou vídeo capturados retornados aos callbacks do aplicativo ou comprometidos com o armazenamento de mídia.
[C-1-6] É PRECISO espelhar a imagem exibida pela visualização pós-reprodução da mesma forma que o fluxo de imagem de visualização da câmera.
PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

Se as implementações de dispositivo puderem ser giradas pelo usuário (por exemplo, automaticamente por um acelerômetro ou manualmente pela entrada do usuário):

[C-2-1] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação atual do dispositivo.

7.5.3. Câmera externa

Uma câmera externa é uma câmera que pode ser fisicamente conectada ou desconectada da implementação do dispositivo a qualquer momento e pode apontar para qualquer direção, como câmeras USB.

Implementações de dispositivos:

PODE incluir suporte para uma câmera externa que não está necessariamente sempre conectada.

Se as implementações do dispositivo incluem suporte para uma câmera externa, elas:

[C-1-1] É OBRIGATÓRIO declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
[C-1-2] É PRECISO oferecer suporte à classe de vídeo USB (UVC 1.0 ou mais recente) se a câmera externa se conectar pela porta host USB.
[C-1-3] É PRECISO passar nos testes do CTS da câmera com um dispositivo de câmera externa conectado. Os detalhes dos testes do CTS da câmera estão disponíveis em source.android.com.
DEVE oferecer suporte a compressões de vídeo, como MJPEG, para permitir a transferência de streams não codificados de alta qualidade (ou seja, streams de imagens brutos ou comprimidos de forma independente).
PODE oferecer suporte a várias câmeras.
PODE oferecer suporte à codificação de vídeo baseada na câmera.

Se a codificação de vídeo baseada na câmera for compatível:

[C-2-1] Um fluxo não codificado / MJPEG simultâneo (resolução QVGA ou maior) PRECISA estar acessível para a implementação do dispositivo.

7.5.4. Comportamento da API Camera

O Android inclui dois pacotes de API para acessar a câmera. A API android.hardware.camera2 mais recente expõe o controle de câmera de nível mais baixo para o app, incluindo fluxos de streaming/fotos em sequência eficientes sem cópia e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, redução de ruído, nitidez e muito mais.

O pacote de API mais antigo, android.hardware.Camera, está marcado como descontinuado no Android 5.0, mas ainda está disponível para uso em apps. As implementações de dispositivos Android precisam garantir o suporte contínuo da API, conforme descrito nesta seção e no SDK do Android.

Todos os recursos comuns entre a classe android.hardware.Camera descontinuada e o pacote mais recente android.hardware.camera2 PRECISAM ter desempenho e qualidade equivalentes nas duas APIs. Por exemplo, com configurações equivalentes, a velocidade e a precisão do autofoco precisam ser idênticas, e a qualidade das imagens capturadas precisa ser a mesma. Os recursos que dependem das diferentes semânticas das duas APIs não precisam ter velocidade ou qualidade correspondentes, mas precisam ser o mais próximos possível.

As implementações de dispositivos precisam implementar os seguintes comportamentos para as APIs relacionadas à câmera, para todas as câmeras disponíveis. Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO usar android.hardware.PixelFormat.YCbCr_420_SP para dados de pré-visualização fornecidos a callbacks de aplicativos quando um aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] PRECISA estar no formato de codificação NV21 quando um aplicativo registra uma instância android.hardware.Camera.PreviewCallback e o sistema chama o método onPreviewFrame() e o formato de visualização é YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame(). Ou seja, o NV21 PRECISA ser o padrão.
[C-0-3] PRECISA oferecer suporte ao formato YV12 (conforme indicado pela constante android.graphics.ImageFormat.YV12) para visualizações de câmera para câmeras frontais e traseiras para android.hardware.Camera. O codificador de vídeo e a câmera de hardware podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA oferecer suporte à conversão para YV12.
[C-0-4] É PRECISO oferecer suporte aos formatos android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG como saídas pela API android.media.ImageReader para dispositivos android.hardware.camera2 que anunciam o recurso REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE em android.request.availableCapabilities.
[C-0-5] A API Camera precisa ser implementada na documentação do SDK do Android, mesmo que o dispositivo tenha foco automático de hardware ou outros recursos. Por exemplo, câmeras que não têm foco automático ainda precisam chamar todas as instâncias android.hardware.Camera.AutoFocusCallback registradas, mesmo que isso não tenha relevância para uma câmera sem foco automático. Isso se aplica a câmeras frontais. Por exemplo, embora a maioria das câmeras frontais não ofereça suporte ao foco automático, os callbacks de API ainda precisam ser "falsos", conforme descrito.
[C-0-6] É PRECISO reconhecer e honrar cada nome de parâmetro definido como uma constante na classe android.hardware.Camera.Parameters e na classe android.hardware.camera2.CaptureRequest. Por outro lado, as implementações de dispositivos NÃO precisam reconhecer ou reconhecer constantes de string transmitidas ao método android.hardware.Camera.setParameters(), exceto aquelas documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos precisam oferecer suporte a todos os parâmetros padrão da câmera, se o hardware permitir, e NÃO podem oferecer suporte a tipos personalizados de parâmetros da câmera. Por exemplo, implementações de dispositivos que oferecem suporte à captura de imagens usando técnicas de High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera Camera.SCENE_MODE_HDR.
[C-0-7] É OBRIGATÓRIO informar o nível adequado de suporte com a propriedade android.info.supportedHardwareLevel conforme descrito no SDK do Android e informar as flags de recursos do framework adequadas.
[C-0-8] PRECISA declarar também os recursos de câmera individuais de android.hardware.camera2 usando a propriedade android.request.availableCapabilities e declarar as flags de recursos adequadas. PRECISA definir a flag de recurso se algum dos dispositivos de câmera conectados oferecer suporte ao recurso.
[C-0-9] É OBRIGATÓRIO transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada da imagem for adicionada à loja de mídia.
[C-0-10] É OBRIGATÓRIO transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da imagem for adicionada à loja de mídia.
[C-0-11] É OBRIGATÓRIO que todas as câmeras sejam acessíveis pela API android.hardware.Camera descontinuada, que também precisa ser acessível pela API android.hardware.camera2.
[C-0-12] É OBRIGATÓRIO garantir que a aparência facial NÃO seja alterada, incluindo, mas não se limitando a, alterar a geometria facial, o tom de pele facial ou o suavização da pele facial para qualquer API android.hardware.camera2 ou android.hardware.Camera.
[C-SR-1] Para dispositivos com várias câmeras RGB em proximidade e voltadas para a mesma direção, é ALTAMENTE RECOMENDADO oferecer suporte a um dispositivo de câmera lógica que liste o recurso CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composto por todas as câmeras RGB voltadas para essa direção como subdispositivos físicos.

Se as implementações do dispositivo fornecerem uma API de câmera reservada a apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO implementar essa API de câmera usando a API android.hardware.camera2.
PODE fornecer tags e/ou extensões do fornecedor à API android.hardware.camera2.

7.5.5. Orientação da câmera

Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, elas:

[C-1-1] PRECISA estar orientado de forma que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é segurado na orientação paisagem, as câmeras precisam capturar imagens nessa orientação. Isso se aplica independentemente da orientação natural do dispositivo, ou seja, se aplica a dispositivos com orientação principal de paisagem e retrato.

Os dispositivos que atendem a todos os critérios abaixo estão isentos do requisito acima:

O dispositivo implementa telas de geometria variável, como telas dobráveis ou articuladas.
Quando o estado de dobra ou articulação do dispositivo muda, ele alterna entre orientações retrato-principal e paisagem-principal (ou vice-versa).
Implementações de dispositivos que não podem ser giradas pelo usuário, como dispositivos automotivos.

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos

Implementações de dispositivos:

[C-0-1] PRECISA incluir um gerenciador de downloads que os aplicativos PODEM usar para fazer o download de arquivos de dados e PRECISA ser capaz de fazer o download de arquivos individuais de pelo menos 100 MB de tamanho para o local "cache" padrão.

7.6.2. Armazenamento compartilhado do aplicativo

Implementações de dispositivos:

[C-0-1] É PRECISO oferecer armazenamento para ser compartilhado por aplicativos, também conhecido como "armazenamento externo compartilhado", "armazenamento compartilhado do aplicativo" ou pelo caminho Linux "/sdcard" em que ele é montado.
[C-0-2] DEVE ser configurado com o armazenamento compartilhado montado por padrão, ou seja, "pronto para uso", independentemente de o armazenamento ser implementado em um componente de armazenamento interno ou em um meio de armazenamento removível (por exemplo, slot de cartão digital seguro).
[C-0-3] É PRECISO montar o armazenamento compartilhado do aplicativo diretamente no caminho sdcard do Linux ou incluir um link simbólico do Linux de sdcard para o ponto de montagem real.
[C-0-4] É OBRIGATÓRIO ativar o armazenamento de escopo por padrão para todos os apps com nível de API 29 ou mais recente, exceto na seguinte situação:
- Quando o app solicitou android:requestLegacyExternalStorage="true" no manifesto.
[C-0-5] É NECESSÁRIO editar os metadados de localização, como tags EXIF do GPS, armazenados em arquivos de mídia quando esses arquivos são acessados por MediaStore, exceto quando o app de chamada tem a permissão ACCESS_MEDIA_LOCATION.

As implementações de dispositivos PODEM atender aos requisitos acima usando uma das seguintes opções:

Armazenamento removível acessível ao usuário, como um slot para cartão Secure Digital (SD).
Parte do armazenamento interno (não removível) conforme implementado no Android Open Source Project (AOSP).

Se as implementações do dispositivo usarem armazenamento removível para atender aos requisitos acima, elas:

[C-1-1] É PRECISO implementar uma interface do usuário pop-up ou aviso ao usuário quando não há um meio de armazenamento inserido no slot.
[C-1-2] É PRECISO incluir um meio de armazenamento formatado em FAT (por exemplo, um cartão SD) ou mostrar na caixa e em outros materiais disponíveis no momento da compra que o meio de armazenamento precisa ser comprado separadamente.

Se as implementações do dispositivo usarem uma parte do armazenamento não removível para atender aos requisitos acima, elas:

DEVE usar a implementação do AOSP do armazenamento compartilhado do aplicativo interno.
PODE compartilhar o espaço de armazenamento com os dados privados do aplicativo.

Se as implementações de dispositivos tiverem uma porta USB com suporte ao modo periférico USB, elas:

[C-3-1] É PRECISO fornecer um mecanismo para acessar os dados no armazenamento compartilhado do aplicativo em um computador host.
EXPORÃO o conteúdo das duas rotas de armazenamento de forma transparente pelo serviço de verificação de mídia do Android e pelo android.provider.MediaStore.
PODE usar armazenamento em massa USB, mas DEVE usar o protocolo de transferência de mídia para atender a esse requisito.

Se as implementações do dispositivo tiverem uma porta USB com o modo periférico USB e oferecerem suporte ao protocolo de transferência de mídia, elas:

PRECISA ser compatível com o host de MTP do Android de referência, Transferência de arquivos do Android.
DEVE informar uma classe de dispositivo USB de 0x00.
DEVE informar um nome de interface USB de "MTP".

7.6.3. Armazenamento adotável

Se o dispositivo for móvel, ao contrário da televisão, as implementações do dispositivo serão:

[C-SR-1] É ALTAMENTE RECOMENDADO implementar o armazenamento adaptável em um local estável de longo prazo, já que a desconexão acidental pode causar perda/corrupção de dados.

Se a porta do dispositivo de armazenamento removível estiver em um local estável de longo prazo, como no compartimento da bateria ou em outra capa protetora, as implementações do dispositivo serão:

[C-SR-2] É ALTAMENTE RECOMENDADO implementar o armazenamento adotável.

7.7. USB

Se as implementações do dispositivo tiverem uma porta USB, elas:

DEVE oferecer suporte ao modo de periférico USB e ao modo de host USB.
DEVE oferecer suporte à desativação da sinalização de dados por USB.

7.7.1. Modo de periférico USB

Se as implementações de dispositivos incluírem uma porta USB com suporte ao modo periférico:

[C-1-1] A porta PRECISA ser conectável a um host USB com uma porta USB tipo A ou tipo C padrão.
[C-1-2] É OBRIGATÓRIO informar o valor correto de iSerialNumber no descritor de dispositivo padrão USB por android.os.Build.SERIAL.
[C-1-3] É PRECISO detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão de resistor do USB tipo C e PRECISA detectar mudanças na propaganda, se eles oferecem suporte ao USB tipo C.
[C-SR-1] A porta DEVE usar o formato USB micro-B, micro-AB ou tipo C. É ALTAMENTE RECOMENDADO que os dispositivos Android atuais e novos cumpram esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
[C-SR-2] A porta DEVE estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação de tela de software para todos os apps (incluindo a tela inicial), para que a tela seja renderizada corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É ALTAMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
[C-SR-3] DEVE implementar suporte para consumir 1,5 A de corrente durante o chirp de HS e o tráfego, conforme especificado na especificação de carregamento de bateria USB, revisão 1.2. É ALTAMENTE RECOMENDADO que os dispositivos Android atuais e novos cumpram esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
[C-SR-4] É ALTAMENTE RECOMENDADO não oferecer suporte a métodos de carregamento proprietários que modifiquem a tensão do Vbus além dos níveis padrão ou alterem os papéis de destino/fonte, já que isso pode resultar em problemas de interoperabilidade com os carregadores ou dispositivos que oferecem suporte aos métodos padrão de fornecimento de energia USB. Embora isso seja "FORTEMENTE RECOMENDADO", em versões futuras do Android, poderemos EXIGIR que todos os dispositivos tipo C ofereçam suporte à interoperabilidade completa com carregadores tipo C padrão.
[C-SR-5] É ALTAMENTE RECOMENDADO oferecer suporte à entrega de energia para dados e trocar de função de energia quando houver suporte para USB Type-C e modo de host USB.
DEVE oferecer suporte ao fornecimento de energia para carregamento de alta tensão e suporte a Modos alternativos, como saída de tela.
PRECISA implementar a API e a especificação do Android Open Accessory (AOA, na sigla em inglês) conforme documentado na documentação do SDK do Android.

Se as implementações do dispositivo incluem uma porta USB e implementam a especificação AOA, elas:

[C-2-1] É PRECISO declarar suporte ao recurso de hardware android.hardware.usb.accessory.
[C-2-2] A classe de armazenamento em massa USB PRECISA incluir a string "android" no final da string iInterface da descrição da interface do armazenamento em massa USB.

7.7.2. Modo de host USB

Se as implementações do dispositivo incluem uma porta USB com suporte ao modo host, elas:

[C-1-1] É OBRIGATÓRIO implementar a API host USB do Android conforme documentado no SDK do Android e DECLARAR suporte ao recurso de hardware android.hardware.usb.host.
[C-1-2] É PRECISO implementar suporte para conectar periféricos USB padrão. Em outras palavras, é PRECISO:
- Ter uma porta tipo C no dispositivo ou ser enviado com cabos que adaptam uma porta proprietary no dispositivo a uma porta USB-C padrão (dispositivo USB Type-C).
- Ter uma porta tipo A no dispositivo ou ser enviado com cabos que adaptam uma porta proprietary no dispositivo a uma porta USB tipo A padrão.
- Ter uma porta micro-AB no dispositivo, que DEVE ser enviada com um cabo que se adapta a uma porta tipo A padrão.
[C-1-3] NÃO PODE ser enviado com um adaptador que converte portas USB tipo A ou micro-AB em uma porta tipo C (soquete).
[C-SR-1] É ALTAMENTE RECOMENDÁVEL implementar a classe de áudio USB conforme documentado na documentação do SDK do Android.
DEVE oferecer suporte ao carregamento do dispositivo periférico USB conectado no modo host; anunciando uma corrente de origem de pelo menos 1,5 A, conforme especificado na seção "Termination Parameters" da especificação de cabo e conector USB Type-C, revisão 1.2 para conectores USB Type-C ou usando o intervalo de corrente de saída da porta de carregamento downstream (CDP, na sigla em inglês) conforme especificado nas especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
DEVEM implementar e oferecer suporte aos padrões USB Type-C.

Se as implementações do dispositivo incluem uma porta USB com suporte ao modo de host e à classe de áudio USB, elas:

[C-2-1] É PRECISO oferecer suporte à classe HID do USB.
[C-2-2] É PRECISO oferecer suporte à detecção e ao mapeamento dos seguintes campos de dados HID especificados nas tabelas de uso do USB HID e na solicitação de uso do comando de voz para as constantes KeyEvent conforme abaixo:
- Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
- Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
- Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Se as implementações do dispositivo incluírem uma porta USB com suporte ao modo host e ao Framework de acesso ao armazenamento (SAF, na sigla em inglês), elas:

[C-3-1] É OBRIGATÓRIO reconhecer todos os dispositivos MTP (protocolo de transferência de mídia) conectados remotamente e tornar o conteúdo deles acessível pelas intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se as implementações do dispositivo incluírem uma porta USB com suporte ao modo de host e ao USB Type-C, elas:

[C-4-1] É PRECISO implementar a funcionalidade de porta de função dupla, conforme definido pela especificação USB Type-C (seção 4.5.1.3.3). Para portas de função dupla, em dispositivos que incluem uma entrada de áudio de 3,5 mm, a detecção de sink USB (modo host) PODE estar desativada por padrão, mas PRECISA ser possível para o usuário ativá-la.
[C-SR-2] É ALTAMENTE RECOMENDADO que ofereça suporte a DisplayPort, DEVE oferecer suporte a taxas de dados USB SuperSpeed e ALTAMENTE RECOMENDADO que ofereça suporte ao fornecimento de energia para troca de dados e de funções.
[C-SR-3] É ALTAMENTE RECOMENDÁVEL que o modo de acessório do adaptador de áudio não seja compatível, conforme descrito no Apêndice A da Revisão 1.2 da especificação de cabo e conector USB Type-C.
PRECISA implementar o modelo Try.* mais adequado para o formato do dispositivo. Por exemplo, um dispositivo portátil DEVE implementar o modelo Try.SNK.

7.8. Áudio

7.8.1. Microfone

Se as implementações do dispositivo incluírem um microfone, elas:

[C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.microphone.
[C-1-2] É OBRIGATÓRIO atender aos requisitos de gravação de áudio na seção 5.4.
[C-1-3] É NECESSÁRIO atender aos requisitos de latência de áudio na seção 5.6.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à gravação de ultrassom, conforme descrito na seção 7.8.3.

Se as implementações do dispositivo omitirem um microfone, elas:

[C-2-1] NÃO DEVE informar a constante de recurso android.hardware.microphone.
[C-2-2] É PRECISO implementar a API de gravação de áudio pelo menos como no-ops, de acordo com a seção 7.

7.8.2. Saída de áudio

Se as implementações do dispositivo incluírem um alto-falante ou uma porta de saída de áudio/multimídia para um periférico de saída de áudio, como uma entrada de áudio de 3,5 mm com quatro condutores ou uma porta no modo host USB usando a classe de áudio USB, elas:

[C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.audio.output.
[C-1-2] É NECESSÁRIO atender aos requisitos de reprodução de áudio na seção 5.5.
[C-1-3] É NECESSÁRIO atender aos requisitos de latência de áudio na seção 5.6.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à reprodução próxima de ultrassom, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos não incluírem um alto-falante ou uma porta de saída de áudio, elas:

[C-2-1] NÃO DEVE informar o recurso android.hardware.audio.output.
[C-2-2] É PRECISO implementar as APIs relacionadas à saída de áudio como no-ops, no mínimo.

Para os fins desta seção, uma "porta de saída" é uma interface física, como uma entrada de áudio de 3,5 mm, HDMI ou porta de modo host USB com classe de áudio USB. O suporte à saída de áudio por protocolos baseados em rádio, como Bluetooth, Wi-Fi ou rede celular, não se qualifica como inclusão de uma "porta de saída".

7.8.2.1. Portas de áudio analógico

Para ser compatível com os fones de ouvido e outros acessórios de áudio que usam o plugue de áudio de 3,5 mm em todo o ecossistema do Android, se as implementações do dispositivo incluírem uma ou mais portas de áudio analógico, elas:

[C-SR-1] É ALTAMENTE RECOMENDADO incluir pelo menos uma das portas de áudio como um conector de áudio de 3,5 mm com 4 condutores.

Se as implementações do dispositivo tiverem um conector de áudio de 3,5 mm com quatro condutores, elas:

[C-1-1] É PRECISO oferecer suporte à reprodução de áudio em fones de ouvido estéreo e fones de ouvido estéreo com microfone.
[C-1-2] É PRECISO oferecer suporte a conectores de áudio TRRS com a ordem de pinagem CTIA.
[C-1-3] É PRECISO oferecer suporte à detecção e ao mapeamento para os códigos de tecla dos seguintes três intervalos de impedância equivalente entre o microfone e os condutores de terra no plugue de áudio:
- 70 ohms ou menos: KEYCODE_HEADSETHOOK
- 210-290 ohms: KEYCODE_VOLUME_UP
- 360-680 ohms: KEYCODE_VOLUME_DOWN
[C-1-4] PRECISA acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que todos os contatos no plugue estiverem tocando os segmentos relevantes na tomada.
[C-1-5] É PRECISO ser capaz de controlar pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohms.
[C-1-6] É PRECISO ter uma tensão de polarização do microfone entre 1,8 V e 2,9 V.
[C-1-7] É OBRIGATÓRIO detectar e mapear para o código de tecla o seguinte intervalo de impedância equivalente entre o microfone e os condutores de aterramento na tomada de áudio:
- 110-180 ohms:KEYCODE_VOICE_ASSIST
[C-SR-2] É ALTAMENTE RECOMENDADO oferecer suporte a plugues de áudio com a ordem de pinagem OMTP.
[C-SR-3] É ALTAMENTE RECOMENDADO oferecer suporte à gravação de áudio de fones de ouvido estéreo com microfone.

Se as implementações do dispositivo tiverem um conector de áudio de 3,5 mm com quatro condutores e oferecerem suporte a um microfone, e transmitirem o android.intent.action.HEADSET_PLUG com o microfone de valor extra definido como 1, elas:

[C-2-1] É PRECISO oferecer suporte à detecção de microfone no acessório de áudio conectado.

7.8.2.2. Portas de áudio digital

Consulte a seção 2.2.1 para ver os requisitos específicos do dispositivo.

7.8.3. Near-Ultrasound

O áudio próximo ao ultrassom é a faixa de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

É PRECISO informar corretamente o suporte ao recurso de áudio de quase ultrassom usando a API AudioManager.getProperty da seguinte maneira:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND for "true", os seguintes requisitos PRECISAM ser atendidos pelas fontes de áudio VOICE_RECOGNITION e UNPROCESSED:

[C-1-1] A resposta de potência média do microfone na faixa de 18,5 kHz a 20 kHz PRECISA ser de no máximo 15 dB abaixo da resposta em 2 kHz.
[C-1-2] A relação sinal-ruído não ponderada do microfone em 18,5 kHz a 20 kHz para um tom de 19 kHz em -26 dBFS PRECISA ser maior que 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND for "true":

[C-2-1] A resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser pelo menos 40 dB abaixo da resposta em 2 kHz.

7.8.4. Integridade do sinal

Implementações de dispositivos:

DEVEM fornecer um caminho de sinal de áudio sem falhas para fluxos de entrada e saída em dispositivos portáteis, conforme definido por zero falhas medidas durante um teste de um minuto por caminho. Teste usando o OboeTester "Teste de falhas automatizado".

O teste requer um dongle de loopback de áudio, usado diretamente em uma entrada de 3,5 mm e/ou em combinação com um adaptador USB-C para 3,5 mm. Todas as portas de saída de áudio precisam ser testadas.

No momento, o OboeTester oferece suporte a caminhos da AAudio. Portanto, as combinações a seguir DEVEM ser testadas para verificar falhas usando a AAudio:

Modo de desempenho	Compartilhamento	Taxa de amostragem	Em Chans	Out Chans
LOW_LATENCY	EXCLUSIVO	NÃO ESPECIFICADO	1	2
LOW_LATENCY	EXCLUSIVO	NÃO ESPECIFICADO	2	1
LOW_LATENCY	COMPARTILHADO	NÃO ESPECIFICADO	1	2
LOW_LATENCY	COMPARTILHADO	NÃO ESPECIFICADO	2	1
NENHUMA	COMPARTILHADO	48000	1	2
NENHUMA	COMPARTILHADO	48000	2	1
NENHUMA	COMPARTILHADO	44100	1	2
NENHUMA	COMPARTILHADO	44100	2	1
NENHUMA	COMPARTILHADO	16000	1	2
NENHUMA	COMPARTILHADO	16000	2	1

Um stream confiável DEVE atender aos seguintes critérios de razão sinal-ruído (SNR, na sigla em inglês) e distorção harmônica total (THD, na sigla em inglês) para seno de 2000 Hz.

Transdutor	THD	SNR
alto-falante principal integrado, medido usando um microfone de referência externo	< 3,0%	>= 50 dB
microfone principal integrado, medido usando um alto-falante de referência externo	< 3,0%	>= 50 dB
entradas analógicas integradas de 3,5 mm, testadas usando o adaptador de loopback	Menos de 1%	>= 60 dB
Adaptadores USB fornecidos com o smartphone, testados com adaptador de loopback	< 1,0%	>= 60 dB

7.9. Realidade virtual

O Android inclui APIs e recursos para criar apps de "realidade virtual" (RV), incluindo experiências de RV de alta qualidade em dispositivos móveis. As implementações de dispositivos precisam implementar essas APIs e comportamentos corretamente, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android inclui suporte ao modo de RV, um recurso que processa a renderização estereoscópica de notificações e desativa componentes da interface do sistema monocular enquanto um aplicativo de RV tem o foco do usuário.

7.9.2. Modo de realidade virtual: alto desempenho

Se as implementações do dispositivo oferecem suporte ao modo de RV, elas:

[C-1-1] É PRECISO ter pelo menos dois núcleos físicos.
[C-1-2] É PRECISO declarar o recurso android.hardware.vr.high_performance.
[C-1-3] É PRECISO oferecer suporte ao modo performance sustentada.
[C-1-4] É PRECISO oferecer suporte ao OpenGL ES 3.2.
[C-1-5] É PRECISO oferecer suporte a android.hardware.vulkan.level 0.
DEVE ter suporte a android.hardware.vulkan.level 1 ou mais recente.
[C-1-6] É NECESSÁRIO implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace e expor as extensões na lista de extensões EGL disponíveis.
[C-1-8] É PRECISO implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures e expor as extensões na lista de extensões GL disponíveis.
[C-SR-1] É ALTAMENTE RECOMENDADO implementar GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture e expor as extensões na lista de extensões GL disponíveis.
[C-SR-2] É ALTAMENTE RECOMENDADO oferecer suporte ao Vulkan 1.1.
[C-SR-3] É ALTAMENTE RECOMENDADO implementar VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image e expor na lista de extensões Vulkan disponíveis.
[C-SR-4] É ALTAMENTE RECOMENDADO expor pelo menos uma família de filas do Vulkan em que flags contenha VK_QUEUE_GRAPHICS_BIT e VK_QUEUE_COMPUTE_BIT, e queueCount seja pelo menos 2.
[C-1-7] A GPU e a tela precisam sincronizar o acesso ao front buffer compartilhado para que a renderização alternada de olho do conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de rasgo visíveis.
[C-1-9] É PRECISO implementar suporte para as flags AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT conforme descrito no NDK.
[C-1-10] É PRECISO implementar suporte para AHardwareBuffers com qualquer combinação dos flags de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para pelo menos os seguintes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] É ALTAMENTE RECOMENDADO oferecer suporte à alocação de AHardwareBuffers com mais de uma camada e sinalizações e formatos especificados em C-1-10.
[C-1-11] É PRECISO ter suporte à decodificação H.264 de pelo menos 3840 x 2160 a 30 fps, com compactação de uma média de 40 Mbps (equivalente a 4 instâncias de 1920 x 1080 a 30 fps-10 Mbps ou 2 instâncias de 1920 x 1080 a 60 fps-20 Mbps).
[C-1-12] É PRECISO ter suporte a HEVC e VP9, ser capaz de decodificar pelo menos 1920 x 1080 a 30 fps compactado para uma média de 10 Mbps e SER CAPAZ de decodificar 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 instâncias de 1920 x 1080 a 30 fps-5 Mbps).
[C-1-13] É NECESSÁRIO oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
[C-1-14] É PRECISO ter uma tela integrada, e a resolução PRECISA ser de pelo menos 1920 x 1080.
[C-SR-6] É ALTAMENTE RECOMENDADO ter uma resolução de tela de pelo menos 2.560 x 1.440.
[C-1-15] A tela PRECISA ser atualizada a pelo menos 60 Hz no modo de RV.