A partir de 2026, para alinhar com nosso modelo de desenvolvimento estável de tronco e garantir a estabilidade da plataforma para o ecossistema, vamos publicar o código-fonte no AOSP no segundo e quarto trimestres. Para criar e contribuir com o AOSP, recomendamos usar android-latest-release em vez de aosp-main. O branch de manifesto android-latest-release sempre vai fazer referência à versão mais recente enviada ao AOSP. Para mais informações, consulte Mudanças no AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Definição de compatibilidade do Android 17 [PRÉVIA]

1. Introdução

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

O uso de "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" está de acordo com o padrão IETF definido na RFC2119 (em inglês).

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

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

Quando esta definição ou os testes de software descritos na Seção 10 forem silenciosos, ambíguos ou incompletos, é responsabilidade do implementador do dispositivo garantir a compatibilidade com as implementações atuais.

Por isso, o Android Open Source Project é a implementação de referência e preferida do Android. É ALTAMENTE RECOMENDADO que os implementadores de dispositivos baseiem suas implementações, na maior medida possível, no código-fonte "upstream" disponível no Android Open Source Project. Embora alguns componentes possam ser substituídos por implementações alternativas, NÃO É RECOMENDADO seguir essa prática, já que a aprovação nos testes de software se torna muito mais difícil. É responsabilidade do implementador garantir a compatibilidade comportamental total com a 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 expressamente 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 desse SDK. Em qualquer caso em que esta definição de compatibilidade ou o conjunto de teste de compatibilidade discordar da documentação do SDK, a documentação do SDK será considerada oficial. Todos os detalhes técnicos fornecidos nos recursos vinculados ao longo deste 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 aplicáveis a um tipo de dispositivo específico. Cada subseção da Seção 2 é dedicada a um tipo específico de dispositivo.

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 mencionados como "Requisitos principais" neste documento.

1.1.2. ID do requisito

O ID do requisito é atribuído para requisitos MUST.

O ID é atribuído apenas para requisitos MUST.
Os requisitos FORTEMENTE RECOMENDADOS são marcados como [SR], mas não recebem ID.
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 (saiba mais em 2. Tipos de dispositivo)
- C: Núcleo (requisitos aplicados a todas as implementações de dispositivos Android)
- H: dispositivo portátil Android
- T: dispositivo Android TV
- R: Implementação do Android Automotive
- W: Android Watch implementation
- Guia: implementação em tablet Android
ID da condição
- Quando o requisito é incondicional, esse ID é definido como 0.
- Quando o requisito é condicional, 1 é atribuído à primeira condição, e o número aumenta em 1 na mesma seção e no mesmo tipo de dispositivo.
ID do requisito
- Ele começa em 1 e aumenta em 1 na mesma seção e 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 dele.

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 dispositivos

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

Esta seção descreve esses tipos de dispositivos, além de requisitos e recomendações adicionais aplicáveis a cada um deles.

Todas as implementações de dispositivos Android que não se enquadram em nenhum dos tipos de dispositivos descritos AINDA PRECISAM atender a todos os requisitos nas outras seções desta Definição de compatibilidade.

2.1 Configurações do dispositivo

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

2.2. Requisitos para dispositivos portáteis

Um dispositivo portátil Android 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 atendem a todos os critérios a seguir:

Ter uma fonte de energia que ofereça mobilidade, como uma bateria.
Ter um tamanho de tela diagonal física entre 4 e 8 polegadas.
Ter uma interface de entrada com tela sensível ao toque.

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

2.2.1. Hardware

Implementações de dispositivos portáteis:

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

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

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

Se as implementações de dispositivos portáteis declararem suporte a qualquer ABI de 64 bits (com ou sem ABI de 32 bits) e retornarem false para ActivityManager.isLowRamDevice(), elas:

[7.1.4.2/H-2-1] DEVE oferecer suporte ao Vulkan 1.1 ou versões mais recentes.

Se as implementações de dispositivos portáteis declararem suporte a telas de alto intervalo dinâmico usando Configuration.isScreenHdr(), elas:

[7.1.4.5/H-1-1] É OBRIGATÓRIO anunciar suporte às 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] É OBRIGATÓRIO informar se o dispositivo é compatível com o recurso de geração de perfil de GPU usando uma propriedade do sistema graphics.gpu.profiler.support.

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

[7.1.4.6/H-1-1] PRECISA informar como saída um rastreamento 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] PRECISA informar valores em conformidade para os contadores de GPU do dispositivo seguindo o proto de pacote gpu counter trace.
[7.1.4.6/H-1-3] Precisa informar valores compatíveis para os RenderStages da GPU do dispositivo seguindo o proto de pacote de rastreamento de estágio de renderização.
[7.1.4.6/H-1-4] PRECISA informar um ponto de rastreamento de frequência da GPU, conforme especificado pelo formato: power/gpu_frequency.

Implementações de dispositivos portáteis:

[7.1.5/H-0-1] DEVE incluir suporte para o modo de compatibilidade de aplicativos legados implementado pelo código-fonte aberto do Android upstream. Ou seja, as implementações de dispositivos NÃO PODEM alterar os gatilhos ou limiares 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] PRECISA incluir suporte a aplicativos de editor de método de entrada (IME) de terceiros.
[7.2.3/H-0-2] É OBRIGATÓRIO enviar o evento de toque 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 de hardware externo conectado ao dispositivo Android).
[7.2.3/H-0-3] É OBRIGATÓRIO fornecer a função "Início" em todas as telas compatíveis com Android que oferecem a tela inicial.
[7.2.3/H-0-4] É OBRIGATÓRIO fornecer a função "Voltar" em todas as telas compatíveis com Android e a função "Recentes" em pelo menos uma delas.
[7.2.4/H-0-1] DEVE oferecer suporte à entrada por tela sensível ao toque.
[7.2.4/H-SR-1] É FORTEMENTE RECOMENDADO iniciar o app assistente selecionado pelo usuário, ou seja, o app que implementa VoiceInteractionService ou uma atividade que processa o ACTION_ASSIST ao tocar e manter pressionado KEYCODE_MEDIA_PLAY_PAUSE ou KEYCODE_HEADSETHOOK se a atividade em primeiro plano não processar esses eventos de toque longo.
[7.3.1/H-SR-1] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

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

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

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

[7.3.3/H-2-1] É OBRIGATÓRIO informar as medições de GNSS assim que forem encontradas, mesmo que um local calculado com GPS/GNSS ainda não tenha sido informado.
[7.3.3/H-2-2] DEVE informar pseudodistâncias e taxas de pseudodistância do GNSS que, em condições de céu aberto após a determinação do local, enquanto parado ou se movendo 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 incluírem um giroscópio de três eixos, elas:

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

Implementações de dispositivos portáteis que podem fazer uma ligação 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 postura com 6 graus de liberdade.

Se as implementações de dispositivos portáteis forem compatíveis com conectividade de dados móveis, elas:

[7.4.1/H-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.telephony.data.

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

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

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

Se as implementações de dispositivos incluírem suporte para 802.11 (Wi-Fi), elas:

[7.4.2.4/H-1-1] DEVE incluir suporte para Wi-Fi Passpoint.

Se os dispositivos forem compatíveis com o protocolo Wi-Fi Neighbor Awareness Networking (NAN) ao declarar PackageManager.FEATURE_WIFI_AWARE e com a localização por Wi-Fi (tempo de retorno do Wi-Fi — RTT) ao declarar PackageManager.FEATURE_WIFI_RTT, eles:

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

É ALTAMENTE RECOMENDADO seguir as etapas de configuração de medição especificadas em Calibragem de presença.

Se os dispositivos portáteis forem compatíveis com o protocolo de detecção de proximidade (PD) do Wi-Fi declarando PackageManager.FEATURE_WIFI_PD e com a localização por Wi-Fi (tempo de retorno do Wi-Fi — RTT) declarando PackageManager.FEATURE_WIFI_RTT, eles:

[7.4.2.10/H-1-1] PRECISA usar pelo menos 160 MHz de largura de banda.
[7.4.2.10/H-1-2] É OBRIGATÓRIO informar o intervalo com precisão de +/-0,25 metros em uma largura de banda de 160 MHz no 68º percentil (calculado com a função de distribuição cumulativa), conforme observado pela API Android WifiRttManager#startRanging.

É ALTAMENTE RECOMENDADO seguir as etapas de configuração de medição especificadas em Calibragem de presença.

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

[7.4.3/H-1-3] É OBRIGATÓRIO medir e compensar o deslocamento de Rx para garantir que o RSSI BLE médio seja -50 dBm +/-15 dB a 1 m de distância de um dispositivo de referência transmitindo a ADVERTISE_TX_POWER_HIGH.
[7.4.3/H-1-4] É OBRIGATÓRIO medir e compensar o deslocamento de Tx para garantir que o RSSI BLE mediano seja -50 dBm +/-15 dB ao fazer a leitura de um dispositivo de referência posicionado a 1 m de distância e transmitindo a ADVERTISE_TX_POWER_HIGH.

Se as implementações de dispositivos portáteis incluírem pelo menos uma câmera traseira, elas:

[7.5.1/H-1-1] PRECISA ter uma resolução de pelo menos 2 megapixels.

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

[7.5.4/H-1-1] Precisa ter um campo de visão (FOV) normal por padrão e entre 50 e graus.

Implementações de dispositivos portáteis:

[7.6.1/H-0-1] Precisa ter pelo menos 4 GB de armazenamento não volátil disponível para dados particulares do aplicativo (também conhecida 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 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 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 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 1.344 MB se a tela padrão usar resoluções de framebuffer 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 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 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 até QHD (por exemplo, QWXGA).

Observe que 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 etc., que não estão sob o controle do kernel em implementações de dispositivos.

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

[7.6.1/H-9-1] MUST declare the feature flag android.hardware.ram.low.
[7.6.1/H-9-2] PRECISA ter pelo menos 1,1 GB de armazenamento não volátil para dados particulares do aplicativo (também conhecida 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] DEVE ter pelo menos 4 GB de armazenamento não volátil disponível para dados particulares do aplicativo (também conhecida como partição "/data").
PRECISA declarar a flag de recurso android.hardware.ram.normal.

Se as implementações de dispositivos portáteis incluírem 2 GB ou mais 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 incluírem 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] SÓ PODE oferecer suporte a uma única ABI (somente 64 bits ou somente 32 bits).

Implementações de dispositivos portáteis:

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

Se as implementações de dispositivos portáteis incluírem uma porta USB com um controlador operando no modo periférico, elas:

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

Se as implementações de dispositivos portáteis incluírem uma porta USB compatível com o 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] PRECISA incluir um microfone.
[7.8.2/H-0-1] PRECISA 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 oferecer suporte ao modo RV e incluírem suporte a ele, elas:

[7.9.1/H-1-1] MUST declare the android.hardware.vr.high_performance feature flag.
[7.9.1/H-1-2] PRECISA incluir um aplicativo que implemente android.service.vr.VrListenerService e possa ser ativado por aplicativos de RV via 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] PRECISA fornecer o seguinte mapeamento de software de códigos HID:

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

[7.8.2.2/H-1-2] DEVE acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que as interfaces e os endpoints de áudio USB forem 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] É OBRIGATÓRIO 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] É OBRIGATÓRIO 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] É OBRIGATÓRIO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSink() se o campo "Tipo de terminal de áudio USB" for 0x0302.
[7.8.2.2/H-4-2] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSink() se o campo de tipo de terminal de áudio USB for 0x0402.
[7.8.2.2/H-4-3] É OBRIGATÓRIO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSource() se o campo de tipo de terminal de áudio USB for 0x0402.
[7.8.2.2/H-4-4] É OBRIGATÓRIO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSink() se o campo de tipo de terminal de áudio USB for 0x603.
[7.8.2.2/H-4-5] É OBRIGATÓRIO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSource() se o campo de tipo de terminal de áudio USB for 0x604.
[7.8.2.2/H-4-6] É OBRIGATÓRIO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSink() se o campo de tipo de terminal de áudio USB for 0x400.
[7.8.2.2/H-4-7] DEVE listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e função isSource() se o campo de tipo de terminal de áudio USB for 0x400.
[7.8.2.2/H-SR-1] SÃO FORTEMENTE RECOMENDADOS ao conectar um periférico de áudio USB-C para realizar a enumeração de descritores USB, identificar tipos de terminais e transmitir a intent ACTION_HEADSET_PLUG em menos de 1.000 milissegundos.

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

Um atuador ressonante linear (LRA) é um sistema de mola de massa única que tem uma frequência ressonante dominante em que a massa se move na direção do movimento desejado.

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

[7.10/H] DEVE posicionar o atuador perto do local onde o dispositivo normalmente é segurado ou tocado com as mãos.
[7.10/H] DEVE mover o atuador háptico 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 ressonante 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 hápticas, elas:

[7.10/H]^* PRECISA verificar o status da implementação executando as APIs android.os.Vibrator.areAllEffectsSupported() e 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 de substituição para primitivos não compatíveis, 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 AAC MPEG-4 (AAC LC)
[5.1/H-0-4] Perfil HE AAC MPEG-4 (AAC+)
[5.1/H-0-5] AAC ELD (AAC aprimorado com atraso baixo)

[5.1/H-0-6] MPEG-D USAC com MPEG-D DRC (Extended High Efficiency AAC)

2.2.3. Software

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 ofereça ao usuário a capacidade de acessar os dados do provedor de documentos usando a API DocumentsProvider.

[3.2.3.1/H-0-2]^* PRECISA 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 de aplicativo listadas aqui. Observação: a página "Intents comuns do app" vai incluir a nova intent obrigatória "android.settings.VPN_APP_EXCLUSION_SETTINGS".

[3.2.3.1/H-SR-1] É FORTEMENTE RECOMENDADO pré-carregar um aplicativo de e-mail que possa processar intents ACTION_SENDTO, ACTION_SEND ou ACTION_SEND_MULTIPLE para enviar um e-mail.
[3.4.1/H-0-1] É OBRIGATÓRIO fornecer uma implementação completa da API android.webkit.Webview.
[3.4.2/H-0-1] PRECISA incluir um aplicativo de navegador independente para navegação na Web do usuário em geral.

[3.8.1/H-0-1] É OBRIGATÓRIO implementar uma tela de início padrão que permita a fixação de widgets no app.

[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 RECOMENDADO implementar um iniciador padrão que ofereça acesso rápido aos atalhos adicionais fornecidos por apps de terceiros usando a API ShortcutManager.
[3.8.1/H-SR-3] É FORTEMENTE RECOMENDADO incluir um app de tela de início padrão que mostre selos nos ícones dos apps.

[3.8.2/H-SR-1] É ALTAMENTE RECOMENDADO para oferecer suporte a widgets de apps de terceiros.

[3.8.2/H-0-1] PRECISA oferecer suporte a widgets de apps de terceiros.

[3.8.3/H-0-1] PRECISA 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] DEVE oferecer suporte a notificações avançadas.
[3.8.3/H-0-3] Precisa oferecer suporte a notificações heads-up.
[3.8.3/H-0-4] PRECISA incluir uma aba de notificações, permitindo que o usuário controle diretamente (por exemplo, responder, adiar, dispensar, bloquear) as notificações por meio de recursos do usuário, como botões de ação ou o painel de controle, conforme implementado no AOSP.
[3.8.3/H-0-5] MUST display the choices provided through RemoteInput.Builder setChoices() in the notification shade.
[3.8.3/H-SR-1] É ALTAMENTE RECOMENDADO mostrar a primeira opção fornecida por RemoteInput.Builder setChoices() na aba de notificações sem interação adicional do usuário.
[3.8.3/H-SR-2] É FORTEMENTE RECOMENDADO mostrar todas as opções fornecidas por RemoteInput.Builder setChoices() na aba de notificações quando o usuário expande todas as notificações na aba de notificações.
[3.8.3.1/H-SR-1] É ALTAMENTE RECOMENDADO mostrar ações em que Notification.Action.Builder.setContextual está definido como true em linha com as respostas mostradas pelo 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 forem compatíveis com notificações MediaStyle elas:

[3.8.3.1/H-SR-2] É ALTAMENTE RECOMENDADO fornecer uma opção de controle do usuário (por exemplo, um seletor de saída) acessada na interface do sistema que permite aos usuários alternar entre as rotas de mídia disponíveis adequadas (por exemplo, dispositivos Bluetooth e rotas fornecidas para MediaRouter2Manager) quando um app postar uma notificação MediaStyle com um token MediaSession.

Uma notificação de atualização dinâmica de um app pode ser promovida quando ele atende a todas as características da promoção. Essa notificação é descrita como "Notificação de atualização em tempo real promovida" neste documento. As implementações de dispositivos portáteis PRECISAM mostrar de forma destacada a Notificação de atualização dinâmica promovida de acordo com os seguintes requisitos.

Se as implementações de dispositivos portáteis declararem o nível da API 36.1 ou mais recente, elas:

[3.8.3.1/H-0-1] É OBRIGATÓRIO mostrar uma notificação de atualização dinâmica promovida em um lugar de destaque na tela de bloqueio.
[3.8.3.1/H-0-12] Precisa aparecer na parte de cima da pilha de notificações Notificação de alerta e acima das notificações coloridas (em que setColorized é true) quando a notificação de atualização em tempo real promovida é mostrada entre outras notificações.
- O MAY determina a ordem das notificações de atualização ao vivo promovidas exibidas na aba de notificações e na tela de bloqueio quando mais de um app se qualifica para receber notificações de atualização ao vivo promovidas.
[3.8.3.1/H-0-2] É OBRIGATÓRIO mostrar uma notificação de atualização em tempo real promovida no estado expandido.
[3.8.3.1/H-0-3] NÃO PODE fornecer um recurso para o usuário recolher a notificação expandida acima.
[3.8.3.1/H-0-4] É OBRIGATÓRIO mostrar os estilos básicos (negrito, itálico e sublinhado) do conteúdo de texto em uma notificação de atualização ao vivo promovida, conforme fornecido por StyleSpan ou UnderlineSpan.
[3.8.3.1/H-0-5] Só é permitido mostrar objetos de ação padrão (via Notification.Action), e é obrigatório ocultar objetos de ação não padrão, como caixas de entrada, botões de resposta e ações contextuais (via addRemoteInput() e setContextual()) em uma notificação de atualização dinâmica promovida, mesmo que ela os contenha.
[3.8.3.1/H-0-6] DEVE mostrar uma representação compacta, também chamada de Status Chip na documentação do SDK, para uma notificação de atualização dinâmica promovida que DEVE incluir Notification.getSmallIcon().
- [3.8.3.1/H-0-7] Outros campos são opcionais para a representação compacta, mas sempre que a representação compacta puder ser expandida, ela DEVERÁ mostrar Notification.getShortCriticalText() se estiver presente ou Notification.when se Notification.getShortCriticalText não estiver presente.
- [3.8.3.1/H-0-8] Quando houver mais de uma notificação de atualização ao vivo promovida, É OBRIGATÓRIO mostrar pelo menos uma delas na barra de status como uma Representação compacta.
- [3.8.3.1/H-0-9] DEVE mostrar a notificação associada (preferencial) ou abrir o app associado (via Notification.contentIntent), quando o usuário tocar na representação compacta.
- [3.8.3.1/H-0-13] Precisa mostrar todo o conteúdo na notificação associada, assim como o que está disponível na aba de notificações.
[3.8.3.1/H-0-10] É OBRIGATÓRIO oferecer ao usuário um recurso para desativar e ativar a exibição promovida das notificações de apps individuais.
[3.8.3.1/H-0-11] É OBRIGATÓRIO renderizar corretamente todas as notificações de atualização em tempo real, incluindo, mas não se limitando a, notificações de atualização em tempo real não promovidas que não atendem ou atendem apenas parcialmente às características da promoção. Essas notificações não promovidas PRECISAM ser mostradas em um estado não promovido.

Se as implementações de dispositivos, incluindo a tecla de navegação da função de apps recentes, conforme detalhado na seção 7.2.3, alterarem a interface, elas:

[3.8.3/H-1-1] É NECESSÁRIO implementar o comportamento de fixação de tela e oferecer ao usuário um menu de configurações para ativar/desativar o recurso.

Se as implementações de dispositivos portáteis forem compatíveis com a ação Assistente, 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 assistivo, conforme descrito na seção 7.2.3. PRECISA iniciar o app assistivo 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 forem compatíveis com conversation notifications e agruparem alertas e notificações silenciosas que não são de conversa em uma seção separada, elas:

[3.8.4/H-1-1]^* DEVE mostrar notificações de conversa 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 de importância:alta.

Se as implementações de dispositivos portáteis Android forem compatíveis com uma tela de bloqueio, elas:

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

Se as implementações de dispositivos portáteis oferecem 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 APIs ControlsProviderService e Control e permitirem que aplicativos de terceiros publiquem controles de dispositivos, eles:

[3.8.16/H-1-1] É OBRIGATÓRIO declarar a flag de recurso android.software.controls e defini-la como true.
[3.8.16/H-1-2] PRECISA oferecer uma conveniência ao usuário com a capacidade de adicionar, editar, selecionar e operar os controles de dispositivo favoritos do usuário nos controles registrados pelos aplicativos de terceiros pelas APIs ControlsProviderService e Control.
[3.8.16/H-1-3] PRECISA fornecer acesso a esse recurso do usuário em até três interações de uma tela de início padrão.
[3.8.16/H-1-4] DEVE renderizar com precisão nesta conveniência do usuário o nome e o ícone de cada app de terceiros que fornece controles pela API ControlsProviderService, bem como os campos especificados fornecidos pelas APIs Control.
[3.8.16/H-1-5] DEVE oferecer uma opção para o usuário desativar os controles triviais de autenticação do dispositivo designados pelo app nos controles registrados pelos aplicativos de terceiros usando a API ControlsProviderService e a Control Control.isAuthRequired.
[3.8.16/H-1-6] As implementações de dispositivos PRECISAM renderizar com precisão a ação do usuário da seguinte forma:
- 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 nessa ação do usuário.
- Se o app não declarar os metadados META_DATA_PANEL_ACTIVITY, ele PRECISA renderizar os campos especificados conforme fornecidos pela API ControlsProviderService e os campos especificados fornecidos pelas APIs Control.
[3.8.16/H-1-7] Se o app declarar os metadados META_DATA_PANEL_ACTIVITY, ele PRECISA transmitir a 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] É OBRIGATÓRIO informar null para as APIs ControlsProviderService e Control.
[3.8.16/H-2-2] É NECESSÁRIO declarar a flag de recurso android.software.controls e defini-la como false.

Se as implementações de dispositivos portáteis não estiverem sendo executadas no modo de bloqueio de atividade, quando o conteúdo é copiado para a área de transferência, ele:

[3.8.17/H-1-1] É OBRIGATÓRIO apresentar uma confirmação ao usuário 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] PRECISA oferecer suporte a serviços de acessibilidade de terceiros.
[3.10/H-SR-1] É FORTEMENTE RECOMENDADO pré-carregar serviços de acessibilidade no dispositivo comparáveis ou superiores à funcionalidade do acesso com interruptor e do 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.
[3.11/H-0-1] É obrigatório oferecer suporte à instalação de mecanismos de TTS de terceiros.
[3.11/H-SR-1] É ALTAMENTE RECOMENDADO incluir um mecanismo de TTS compatível com os idiomas disponíveis no dispositivo.
[3.13/H-SR-1] É ALTAMENTE RECOMENDADO incluir um componente de interface do usuário 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] Precisa ser compatível com o recurso de pareamento de dispositivos complementares.

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

Implementações de dispositivos portáteis:

[3.20.1/H-0-1] É necessário implementar todos os requisitos de fluxo de áudio do Google Assistente.

[7.2.3/H] A zona de reconhecimento de gestos para a função Home NÃO DEVE ter mais de 32 dp de altura da parte de baixo da tela.

Se as implementações de dispositivos portáteis oferecerem 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 gesto DEVE ter 24 dp de largura por padrão.

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

[3.9/H-1-2] É OBRIGATÓRIO 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 via android.hardware.camera.any, elas:

[7.5.4/H-1-1] É OBRIGATÓRIO respeitar a intenção 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] É OBRIGATÓRIO respeitar a intenção android.media.action.VIDEO_CAMERA de 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] PRECISA ter uma atividade que processe o intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY quando a funcionalidade de divisão está ativada. A atividade precisa ser protegida por android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK e 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, eles

[7.4.1.2/H-0-1] MUST declare the feature flag android.software.telecom.

[7.4.1.2/H-0-2] PRECISA implementar o framework de telecomunicações.

2.2.4. Desempenho e bateria

[8.1/H-0-1] Latência de frame consistente. Latência de frame inconsistente ou um atraso na renderização de frames NÃO PODE acontecer mais de cinco vezes por segundo e DEVE ser inferior a um 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 de baixa latência rolando uma lista de 10.000 entradas de lista,conforme definido pelo conjunto de teste de compatibilidade (CTS) do Android em menos de 36 segundos.
[8.1/H-0-3] Troca de tarefas. Quando vários aplicativos foram iniciados, a reinicialização de um aplicativo já em execução após o lançamento DEVE levar menos de um segundo.

Implementações de dispositivos portáteis:

[8.2/H-0-1] PRECISA garantir um desempenho de gravação sequencial de pelo menos 5 MB/s.
[8.2/H-0-2] DEVE garantir uma performance de gravação aleatória de pelo menos 0,5 MB/s.
[8.2/H-0-3] DEVE garantir uma performance de leitura sequencial de pelo menos 15 MB/s.
[8.2/H-0-4] DEVE garantir uma performance 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 estender os recursos incluídos no AOSP, elas:

[8.3/H-1-1] PRECISA oferecer ao usuário a opção de ativar e desativar o recurso de economia de bateria.
[8.3/H-1-2] PRECISA oferecer ao usuário a possibilidade de mostrar todos os apps isentos dos modos de economia de energia do App em espera e do "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 de cada componente de hardware e o consumo elevado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
[8.4/H-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliampères-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 com a 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 de apps.
[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] PRECISA respeitar a intenção android.intent.action.POWER_USAGE_SUMMARY e mostrar um menu de configurações que exibe esse uso de energia.

Implementações de dispositivos portáteis:

[8.5/H-0-1] PRECISA fornecer uma ação do usuário para ver todos os apps com serviços ativos em primeiro plano ou tarefas iniciadas pelo usuário, incluindo a duração de cada um desses serviços desde que foi iniciado, conforme descrito no documento do SDK.
[8.5/H-0-2]PRECISA fornecer uma opção para o usuário interromper um app que esteja 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] MUST declare the android.hardware.security.model.compatible feature.
[9.1/H-0-1] É OBRIGATÓRIO permitir que apps de terceiros acessem as estatísticas de uso pela permissão android.permission.PACKAGE_USAGE_STATS e fornecer 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.

Se as implementações de dispositivos portáteis incluírem um aplicativo padrão para oferecer suporte ao VoiceInteractionService, elas:

[9.1/H-0-2] NÃO DEVE conceder ACCESS_FINE_LOCATION como padrão para esse aplicativo.

As implementações de dispositivos PRECISAM declarar suporte para android.software.credentials e:

[9/H-0-2] É OBRIGATÓRIO respeitar a intenção 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 inseridas pelo Credential Manager.
[9/H-0-3] PRECISA oferecer suporte a pelo menos dois provedores de credenciais simultâneos e fornecer uma affordance para o usuário no app Configurações para ativar ou desativar provedores.
[9.5/H-1-1] Requisito removido no Android 16.

Implementações de dispositivos portáteis:

[9.11/H-0-2] É obrigatório fazer backup da implementação do keystore com um ambiente de execução isolado.
[9.11/H-0-3] DEVE ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções hash MD5, SHA-1 e SHA-2 para oferecer suporte adequado aos algoritmos compatíveis com o sistema Android Keystore em uma área isolada com segurança do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos possíveis pelos quais o kernel ou o código do espaço do usuário podem acessar o estado interno do ambiente isolado, incluindo DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada no 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] É OBRIGATÓRIO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e permitir o uso das chaves vinculadas à autenticação somente quando ela for bem-sucedida. As credenciais da tela de bloqueio precisam ser armazenadas de forma que apenas o ambiente de execução isolado possa realizar a autenticação da tela de bloqueio. O Android Open Source Project upstream fornece a camada de abstração de hardware (HAL) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
[9.11/H-0-5] DEVE oferecer suporte ao atestado de chave 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 NÃO PODEM ser usadas como identificadores permanentes de dispositivo.

Observação: para atender a esse requisito, é necessário compartilhar a mesma chave de atestado para uma determinada SKU,a menos que pelo menos 100.000 unidades dessa 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 chaves remotas pode ser usada para provisionar chaves de atestação de curta duração no dispositivo.

Observe que, se uma implementação de dispositivo já tiver sido lançada em uma versão anterior do Android, ela será isenta da exigência de ter um keystore com suporte de um ambiente de execução isolado e da confirmação de chaves, a menos que declare o recurso android.hardware.fingerprint, que exige um keystore com suporte de 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] PRECISA permitir que o usuário escolha o menor tempo limite de inatividade, ou seja, um tempo de transição do estado desbloqueado para bloqueado de 15 segundos ou menos.
[9.11/H-1-2] PRECISA oferecer ao usuário a possibilidade de ocultar notificações e desativar todas as formas de autenticação, exceto a autenticação 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 dispositivos tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que implementam a API TrustAgentService System, eles:

[9.11.1/H-1-1] PRECISA desafiar o usuário a usar um dos métodos de autenticação primária recomendados (como PIN, padrão ou senha) com mais frequência do que uma vez a cada 72 horas.

Se as implementações de dispositivos portáteis tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança que chamam a API do sistema TrustAgentService.grantTrust() com a flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, elas:

[9.11.1/H-1-1] PRECISA chamar TrustManagerService.revokeTrust() depois de:
- No máximo 24 horas após a concessão da confiança.
- Uma janela de inatividade de 8 horas.

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

[9.5/H-2-1] PRECISA 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 outros usuários trabalharem, com a capacidade de gerenciar restrições mais refinadas nos apps que estão 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 PODE oferecer suporte a perfis restritos, mas PRECISA estar alinhado à implementação do AOSP de controles para ativar /desativar o acesso de outros usuários a chamadas de voz e SMS.
[9.5/H-4-1] Requisito removido no Android 16.
[9.5/H-4-2] Requisito removido no Android 16.

Configurações restritas

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

Ser instalado depois de ser baixado por um aplicativo (por exemplo, um app de mensagens ou um navegador) que não seja uma "app store" identificada pelo PackageManager como PACKAGE_DOWNLOADED_FILE.
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 obrigatórias e os identificadores associados listados em [9.8/H-0-5] abaixo.

Esses aplicativos são rotulados 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 administrador do dispositivo (Manifest.permission.BIND_DEVICE_ADMIN)
  - Sobrepor a outros apps (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - Acesso ao uso (AppOpsManager.OPSTR_GET_USAGE_STATS)
- Funções (apps padrão)
  - Telefone (RoleManager.ROLE_DIALER)
  - SMS (RoleManager.ROLE_SMS)
- Permissões de tempo de execução
  - Duração do SMS (Manifest.permission_group.SMS)
[9.8/H-0-2] É OBRIGATÓRIO ativar as configurações restritas como padrão e É ALTAMENTE RECOMENDADO não ter nenhuma ação do usuário que permita 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] SÓ É PERMITIDO que a confirmação do usuário seja usada para ativar as configurações restritas obtidas na página AppInfo do aplicativo coberto, usando a API EnhancedConfirmationManager.
[9.8/H-0-5] É ALTAMENTE RECOMENDADO integrar e chamar 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
- Mudar 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
- Ouvinte de notificações: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Acesso ao uso: AppOpsManager.OPSTR_GET_USAGE_STATS
- Administrador do dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
- Não perturbe: Manifest.permission.MANAGE_NOTIFICATIONS

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

Se as implementações de dispositivos portáteis forem compatíveis com a API HotwordDetectionService do sistema ou outro mecanismo de detecção de palavra-chave sem indicação de acesso ao microfone, elas:

[9.8/H-1-1] É OBRIGATÓRIO garantir que o serviço de detecção de palavra-chave só possa transmitir dados para o sistema, ContentCaptureService, ou para 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 palavra-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 PODE fornecer áudio do microfone com mais de 30 segundos para uma solicitação individual acionada por hardware ao serviço de detecção de palavra-chave.
[9.8/H-1-4] NÃO PODE fornecer áudio do microfone armazenado em buffer com mais de 8 segundos para uma solicitação individual ao serviço de detecção de palavra-chave.
[9.8/H-1-5] NÃO PODE fornecer áudio do microfone armazenado em buffer com mais de 30 segundos para o serviço de interação por voz ou entidade semelhante.
[9.8/H-1-6] NÃO PODE permitir que mais de 100 bytes de dados (excluindo fluxos de áudio) sejam transmitidos do serviço de detecção de palavra-chave em cada resultado de palavra-chave bem-sucedido.
[9.8/H-1-7] NÃO PODE permitir que mais de 5 bits de dados sejam transmitidos para fora do serviço de detecção de palavra-chave em cada resultado negativo de palavra-chave.
[9.8/H-1-8] SÓ É PERMITIDO transmitir dados para fora do serviço de detecção de palavra-chave ativa em uma solicitação de validação de palavra-chave ativa do servidor do sistema.
[9.8/H-1-9] NÃO PODE permitir que um aplicativo instalável pelo usuário forneça o serviço de detecção de palavra-chave de ativação.
[9.8/H-1-10] NÃO PODE mostrar na interface dados quantitativos sobre o uso do microfone pelo serviço de detecção de palavra-chave de ativação.
[9.8/H-1-11] É OBRIGATÓRIO registrar o número de bytes incluídos em todas as transmissões do serviço de detecção de palavra-chave para permitir a capacidade de inspeção para pesquisadores de segurança.
[9.8/H-1-12] É OBRIGATÓRIO 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 palavra-chave para permitir a inspeção por pesquisadores de segurança.
[9.8/H-1-14] É OBRIGATÓRIO mostrar o indicador de microfone, conforme descrito na seção 9.8.2, quando um resultado de palavra-chave de ativação bem-sucedido é transmitido ao serviço de interação por voz ou entidade semelhante.
[9.8/H-1-15] DEVE garantir que os fluxos de áudio fornecidos em resultados de hotword bem-sucedidos sejam transmitidos de forma unidirecional 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 provedor do serviço de detecção de palavra-chave.
[9.8/H-SR-2] É ALTAMENTE RECOMENDADO proibir 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 palavra-chave de ativação pelo menos uma vez por hora ou a cada 30 eventos de ativação por hardware, o que vier primeiro.

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

[9.8/H-2-1] É OBRIGATÓRIO fornecer um aviso explícito ao usuário para cada frase de palavra-chave compatível.
[9.8/H-2-2] NÃO PODE preservar dados de áudio brutos ou derivados deles pelo serviço de detecção de palavra-chave.
[9.8/H-2-3] NÃO PODE transmitir do serviço de detecção de palavra-chave, dados de áudio, dados que podem ser usados para reconstruir (total ou parcialmente) o áudio ou conteúdo de áudio não relacionado à 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 de detecção de consultas sem indicação de acesso ao microfone e/ou à câmera, elas:

[9.8/H-3-1] É OBRIGATÓRIO garantir que o serviço de detecção de consultas só possa transmitir dados para o sistema, ContentCaptureService ou o serviço de reconhecimento de fala no dispositivo (criado por SpeechRecognizer#createOnDeviceSpeechRecognizer()).
[9.8/H-3-2] NÃO PODE permitir que informações de áudio ou vídeo sejam transmitidas para fora do VisualQueryDetectionService, exceto para ContentCaptureService ou serviço de reconhecimento de fala no dispositivo.
[9.8/H-3-3] É OBRIGATÓRIO mostrar um aviso ao usuário na interface do sistema quando o dispositivo detectar a intenção do usuário de interagir com o aplicativo de assistente digital (por exemplo, detectando a presença do usuário por uma câmera).
[9.8/H-3-4] DEVE 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 PODE permitir 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] É OBRIGATÓRIO mostrar o indicador de 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 têm as funções mencionadas na seção 9.1 com o identificador CDD [C-4-X].
[9.8.2/H-4-2] DEVE mostrar a lista de apps recentes e ativos que usam o microfone, conforme retornado de PermissionManager.getIndicatorAppOpUsageData(), além de todas as mensagens de atribuição associadas a eles.
[9.8.2/H-4-3] NÃO PODE ocultar o indicador de microfone para apps do sistema que têm interfaces de usuário visíveis ou interação direta com o usuário.
[9.8.2/H-4-4] DEVE mostrar a lista de apps recentes e ativos que usam 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 de câmera quando um app estiver acessando dados de 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 com o identificador CDD [C-4-X].
[9.8.2/H-5-2] PRECISA mostrar os apps recentes e ativos usando a câmera conforme retornado de PermissionManager.getIndicatorAppOpUsageData(), além de todas as mensagens de atribuição associadas a eles.
[9.8.2/H-5-3] NÃO pode ocultar o indicador de câmera para apps do sistema que têm interfaces de usuário visíveis ou interação direta com o usuário.

Quando um aplicativo em primeiro plano que não é do sistema acessa a localização exata de um dispositivo, ele:

[9.8.8/H-6-1] PRECISA mostrar um indicador visível para o usuário.

A Inicialização verificada é um recurso que garante a integridade do software do dispositivo. Se as implementações de dispositivos forem compatíveis com o 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.

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]* PRECISA oferecer suporte ao comando do shell cmd testharness.

Implementações de dispositivos portáteis:

Perfetto (link em inglês)
- [6.1/H-0-2] DEVE expor um binário /system/bin/perfetto ao usuário do shell, e a linha de comando precisa estar em conformidade com a 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 rastreamento do protobuf que obedece ao esquema definido na documentação do perfetto.
- [6.1/H-0-5] MUST fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto.
- [6.1/H-0-6] O daemon rastreado do perfetto PRECISA ser ativado por padrão (propriedade do sistema persist.traced.enable).

Fizemos mudanças significativas na estrutura de requisitos da classe de desempenho de mídia. A partir da API 37, adicionamos os novos níveis 1, 10, 20 e 37. Também reduzimos a complexidade dos requisitos ao fazer referência a uma página de medições da classe de desempenho de mídia, que detalha cada requisito medido por nível de MPC.

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

Consulte a seção 7.11 para conferir a definição de classe de desempenho de mídia e a Definição de classe de desempenho de mídia para todas as medidas.

2.2.7.1. Mídia

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

Precisa atender a todos os requisitos de mídia listados na seção 2.2.7.1 do CDD do Android 17 correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-1] É OBRIGATÓRIO 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 codecs usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints() correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-2] PRECISA oferecer suporte a sessões de decodificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recentes), instâncias simultâneas e quedas de frames correspondentes ao Nível da classe de desempenho de mídia declarado do dispositivo.
[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 codecs usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints() correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-4] PRECISA oferecer suporte a sessões de codificador de vídeo por hardware (AVC, HEVC, VP9, AV1 ou mais recentes), instâncias simultâneas e quedas de frames correspondentes ao Nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-5] É OBRIGATÓRIO anunciar o número máximo de sessões simultâneas de codificador e decodificador de vídeo de hardware em qualquer combinação de codecs usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints() correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-6] PRECISA oferecer suporte a sessões de decodificador e codificador de vídeo por hardware (AVC, HEVC, VP9, AV1 ou mais recentes), instâncias simultâneas e perdas de frames correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-7] DEVE ter uma latência de inicialização de codec para uma sessão de codificação de vídeo de 1080p ou menor para todos os codificadores de vídeo de hardware quando estiver sob carga correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-8] DEVE ter uma latência de inicialização de codec para uma sessão de codificação de áudio de taxa de bits de 128 kbps ou inferior para todos os codificadores de áudio quando sob carga correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-9] PRECISA oferecer suporte a duas instâncias de sessões de decodificador de vídeo de hardware seguro (AVC, HEVC, VP9, AV1 ou mais recentes) e quedas de frames correspondentes ao Nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-10] PRECISA oferecer suporte a três instâncias de sessões de decodificador de vídeo de hardware não seguro e uma instância de sessão de decodificador de vídeo de hardware seguro (quatro instâncias no total) (AVC, HEVC, VP9, AV1 ou mais recente), resoluções e quedas de frames correspondentes ao Nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-11] É OBRIGATÓRIO oferecer suporte a um decodificador seguro para cada decodificador de hardware AVC, HEVC, VP9 ou AV1 correspondente ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.1/H-1-12] É OBRIGATÓRIO ter uma latência de inicialização de codec para uma sessão de decodificação de vídeo de 1080p ou menor para todos os decodificadores de vídeo de hardware quando sob carga correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-13] DEVE ter uma latência de inicialização do codec para uma sessão de decodificação de áudio de 128 kbps ou taxa de bits menor para todos os decodificadores de áudio quando sob carga correspondente ao Nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-14] PRECISA oferecer suporte ao perfil, recurso e método de exibição do decodificador de hardware AV1 correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-15] PRECISA ter pelo menos um decodificador de vídeo de hardware compatível com 4K60 correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-16] PRECISA ter pelo menos um codificador de vídeo de hardware compatível com 4K60 correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-17] PRECISA ter pelo menos um decodificador de imagem de hardware compatível com o perfil de referência do AVIF correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-18] PRECISA oferecer suporte a um codificador AV1 que atenda aos requisitos de taxa de bits, frames por segundo e resolução correspondentes ao Nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-19] PRECISA oferecer 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 recentes), resolução e quedas de frames correspondentes ao Nível da classe de desempenho de mídia declarado do dispositivo.
[5.1/H-1-20] PRECISA oferecer suporte ao recurso Feature_HdrEditing para todos os codificadores de hardware AV1 e HEVC presentes no dispositivo correspondentes ao Nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.1/H-1-21] DEVE oferecer suporte a FEATURE_DynamicColorAspect para todos os decodificadores de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recentes) correspondentes ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.1/H-1-22] PRECISA oferecer suporte à codificação, decodificação, edição com GPU e exibição de conteúdo de vídeo na proporção retrato correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.2/H-2-1] Se a implementação do dispositivo for compatível com codificadores de hardware AVC ou HEVC, ela DEVERÁ atender à meta de qualidade mínima definida pelas curvas de taxa-distorção do codificador de vídeo para esses codecs, correspondentes ao Nível da classe de desempenho de mídia declarado do dispositivo.

[5.2/H-2-2] PRECISA oferecer suporte a MMAP no caminho do alto-falante correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.

[5.3/H-1-1] PRECISA atender aos requisitos de desempenho da sessão de vídeo e de perda de frames correspondentes ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.3/H-1-2] PRECISA atender aos requisitos de desempenho de mudança de resolução de vídeo correspondentes ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.6/H-1-1] PRECISA atender aos requisitos de latência de toque para tom correspondentes ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.6/H-1-2] PRECISA atender aos requisitos de latência de áudio de ida e volta correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.6/H-1-3] PRECISA atender aos requisitos de áudio de 24 bits correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.6/H-1-4] DEVE oferecer suporte a dispositivos de áudio USB com mais de quatro canais correspondentes ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar a flag de recurso MIDI correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.6/H-1-9] PRECISA oferecer suporte a pelo menos 12 mixagens de canais correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.

[5.6/H-3-1] DEVE ser capaz de alternar entre a reprodução de ondas senoidais sem subexecução de buffers de áudio correspondentes ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.6/H-3-2] PRECISA atender aos requisitos de canal de saída do dispositivo de áudio USB correspondentes ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.6/H-3-3] PRECISA atender aos requisitos de canal de entrada de dispositivo de áudio USB correspondentes ao nível da classe de desempenho de mídia declarado pelo dispositivo.

[5.6/H-SR-1] É ALTAMENTE RECOMENDADO que ofereçam suporte à mixagem de canais de áudio correspondente ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[5.7/H-1-2] PRECISA oferecer suporte a MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL com os recursos de descriptografia correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.12/H-1-2] PRECISA atender aos requisitos de formato de cor para codificadores de hardware AV1 e HEVC correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[5.12/H-1-3] É OBRIGATÓRIO anunciar o suporte à extensão EXT_YUV_target correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.1.4/H-1-1] PRECISA atender aos requisitos da unidade de processamento de tela (DPU) correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.

2.2.7.2. Câmera

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

PRECISA atender aos requisitos de câmera listados na seção 2.2.7.2 do CDD do Android 17 correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.

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

[7.5/H-1-1] PRECISA atender aos requisitos de resolução e captura de vídeo da câmera traseira principal correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-2] PRECISA atender aos requisitos principais de resolução da câmera frontal e captura de vídeo correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-3] PRECISA oferecer suporte aos requisitos de propriedade android.info.supportedHardwareLevel correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-4] PRECISA oferecer suporte a CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para as duas câmeras principais correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-5] PRECISA atender aos requisitos de latência de captura JPEG da camera2 correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-6] PRECISA atender aos requisitos de latência de inicialização da camera2 correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-8] PRECISA atender aos requisitos de captura de câmera RAW correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-9] PRECISA atender aos requisitos de captura de vídeo em alta velocidade da câmera principal traseira correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-10] PRECISA atender aos requisitos mínimos de proporção de zoom correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-11] PRECISA implementar o streaming simultâneo frontal e traseiro em câmeras principais correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-12] PRECISA oferecer suporte à estabilização de vídeo para a câmera traseira principal correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-13] PRECISA oferecer suporte ao recurso LOGICAL_MULTI_CAMERA para a câmera traseira principal correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-14] PRECISA oferecer suporte à capacidade STREAM_USE_CASE para a câmera frontal principal e a câmera traseira principal correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-15] É OBRIGATÓRIO oferecer suporte a extensões do modo noturno pelas extensões do CameraX e do Camera2 para câmeras principais correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-16] PRECISA oferecer suporte à capacidade DYNAMIC_RANGE_TEN_BIT para as câmeras principais correspondentes ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[7.5/H-1-17] PRECISA oferecer suporte a recursos de detecção de rosto para as câmeras principais correspondentes ao nível de classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-18] DEVE oferecer suporte a JPEG_R para as câmeras traseira e frontal principais correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.5/H-1-19] PRECISA oferecer suporte a CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para a câmera traseira principal correspondente ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[7.5/H-1-20] POR PADRÃO, DEVE gerar JPEG_R para as câmeras traseira e frontal principais no app de câmera nativo correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.

[7.5/H-1-21] PRECISA ter pelo menos uma câmera frontal ou traseira correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.

2.2.7.3. Hardware

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

Precisa atender aos requisitos de hardware listados na seção 2.2.7.3 do CDD do Android 17 correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.

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

[7.1.1.1/H-1-1] Este item foi ignorado intencionalmente.
[7.1.1.1/H-2-1] PRECISA ter uma resolução de tela correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.1.1.3/H-1-1] Este item foi ignorado intencionalmente.
[7.1.1.3/H-2-1] Precisa ter densidade de tela correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[7.1.1.3/H-3-1] PRECISA oferecer suporte aos requisitos de exibição HDR correspondentes ao Nível da classe de desempenho de mídia declarado do dispositivo.
[7.6.1/H-1-1] Este item foi ignorado propositalmente.
[7.6.1/H-2-1] PRECISA atender aos requisitos de memória correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.

2.2.7.4. Desempenho

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

Precisa atender aos requisitos de desempenho listados na seção 2.2.7.4 do CDD do Android 17 correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.

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

[8.2/H-1-1] É OBRIGATÓRIO garantir um desempenho de gravação sequencial correspondente ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[8.2/H-1-2] DEVE garantir um desempenho de gravação aleatória correspondente ao nível da classe de desempenho de mídia declarado do dispositivo.
[8.2/H-1-3] DEVE garantir um desempenho de leitura sequencial correspondente ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[8.2/H-1-4] DEVE garantir um desempenho de leitura aleatória correspondente ao nível da classe de desempenho de mídia declarado pelo dispositivo.
[8.2/H-1-5] DEVE garantir uma performance de leitura e gravação sequencial paralela correspondente ao nível da classe de desempenho de mídia declarado pelo dispositivo.

2.2.7.5. Gráficos

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

[7.1.4.1/H-1-2] PRECISA oferecer suporte às extensões EGL necessárias correspondentes ao Nível da classe de desempenho de mídia declarado do dispositivo.
[7.1.4.1/H-1-3] PRECISA oferecer suporte aos recursos Vulkan necessários correspondentes ao nível da classe de desempenho de mídia declarado do dispositivo.

2.3. Requisitos de televisão

Um dispositivo Android TV é 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 de 10 pés").

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

Fornecer um mecanismo para controlar remotamente a interface do usuário renderizada na tela, que pode estar a três metros de distância do usuário.
Ter uma tela integrada 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 Television.

2.3.1. Hardware

Implementações de dispositivos de televisão:

[7.2.2/T-0-1] Precisa oferecer suporte ao botão direcional.
[7.2.3/T-0-1] PRECISA oferecer as funções "Início" e "Voltar".
[7.2.3/T-0-2] PRECISA enviar o evento de toque normal e longo da função Voltar (KEYCODE_BACK) para o aplicativo em primeiro plano.
[7.2.6.1/T-0-1] Precisa incluir suporte para controles de jogos e declarar a flag de recurso android.hardware.gamepad.
[7.2.7/T] DEVE fornecer um controle remoto com o qual os usuários possam acessar a navegação sem toque e as entradas das teclas de navegação principais.

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

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

Implementações de dispositivos de televisão:

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

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

[7.5.3/T-1-1] PRECISA incluir suporte para uma câmera externa que se conecta por essa porta USB, mas não necessariamente está sempre conectada.

Se as implementações de dispositivos 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 alguma das seguintes densidades 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 de dispositivos 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 alguma das seguintes densidades for usada:
- 400 dpi ou mais em telas pequenas/normais
- xhdpi ou superior em telas grandes
- tvdpi ou superior em telas extragrandes

Observe que 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 de dispositivos.

Implementações de dispositivos de televisão:

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

2.3.2. Multimídia

As implementações de dispositivos de televisão 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 AAC MPEG-4 (AAC LC)
[5.1/T-0-2] Perfil HE AAC MPEG-4 (AAC+)
[5.1/T-0-3] AAC ELD (AAC aprimorado com atraso baixo)

[5.1/T-0-4] MPEG-D USAC com MPEG-D DRC (Extended High Efficiency AAC)

As implementações de dispositivos de televisão 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 televisão:

[5.2.2/T-SR-1] É ALTAMENTE RECOMENDADO que eles ofereçam 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 televisão 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 televisão PRECISAM ser compatíveis com a decodificação MPEG-2, conforme detalhado na seção 5.3.1, em frame rates e resoluções de vídeo padrão até:

[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 frames por segundo 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 televisão PRECISAM oferecer suporte à decodificação H.264, conforme detalhado na seção 5.3.4, com taxas de frame e resoluções de vídeo padrão até:

[5.3.4/T-1-1] HD 1080p a 60 quadros 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 High Profile Level 4.2

As implementações de dispositivos de televisão com decodificadores de hardware H.265 PRECISAM ser compatíveis com a decodificação H.265, conforme detalhado na seção 5.3.5, com taxas de frame de vídeo padrão e resoluções de até:

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

Se as implementações de dispositivos de televisão 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] PRECISA oferecer suporte ao perfil de decodificação UHD a 60 frames por segundo com o perfil Main10 Nível 5 Main Tier

As implementações de dispositivos de televisão PRECISAM oferecer suporte à decodificação VP8, conforme detalhado na seção 5.3.6, com frame rates e resoluções de vídeo padrão até:

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

As implementações de dispositivos de televisão com decodificadores de hardware VP9 PRECISAM ser compatíveis com a decodificação VP9, conforme detalhado na seção 5.3.7, com taxas de frame de vídeo padrão e resoluções de 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 televisão com decodificadores de hardware VP9 forem compatíveis com a decodificação VP9 e o perfil de decodificação UHD, elas:

[5.3.7/T-2-1] PRECISA 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 que ofereçam 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 televisão:

[5.5/T-0-1] DEVE incluir suporte ao volume principal do sistema e à atenuação do volume de saída de áudio digital em saídas compatíveis, exceto para saída de transmissão direta de áudio compactado (em que nenhuma decodificação de áudio é feita no dispositivo).

Se as implementações de dispositivos de televisão não tiverem uma tela integrada, mas forem compatíveis com uma tela externa conectada por HDMI, elas:

[5.8/T-0-1] É OBRIGATÓRIO definir o modo de saída HDMI para a resolução mais alta do formato de pixel escolhido que funciona com 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 de HDMI configurável pelo usuário.
[5.8] DEVE definir a taxa de atualização do modo de saída HDMI 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 televisão não tiverem uma tela integrada, mas forem compatíveis com uma tela externa conectada por HDMI, elas:

[5.8/T-1-1] DEVE oferecer suporte ao HDCP 2.2.

Se as implementações de dispositivos de televisão não forem compatíveis com a decodificação UHD, mas forem compatíveis com uma tela externa conectada por HDMI, elas:

[5.8/T-2-1] Precisa oferecer suporte ao HDCP 1.4

2.3.3. Software

Implementações de dispositivos de televisão:

[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 intent públicos definidos pelas intents de aplicativo a seguir, listadas aqui.
[3.4.1/T-0-1] É OBRIGATÓRIO fornecer uma implementação completa da API android.webkit.Webview.

Se as implementações de dispositivos Android Television forem compatíveis com uma tela de bloqueio, elas:

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

Implementações de dispositivos de televisão:

[3.8.14/T-SR-1] É ALTAMENTE RECOMENDADO para oferecer suporte ao modo picture-in-picture (PIP) em várias janelas.
[3.10/T-0-1] PRECISA oferecer suporte a serviços de acessibilidade de terceiros.
[3.10/T-SR-1] É FORTEMENTE RECOMENDADO que os serviços de acessibilidade sejam pré-carregados no dispositivo, comparáveis ou superiores à funcionalidade do Acesso com interruptor e do 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 televisão informarem o recurso android.hardware.audio.output, elas:

[3.11/T-SR-1] É ALTAMENTE RECOMENDADO incluir um mecanismo de TTS compatível com os idiomas disponíveis no dispositivo.
[3.11/T-1-1] É obrigatório oferecer suporte à instalação de mecanismos de TTS de terceiros.

O Android Television Input Framework (TIF) simplifica a entrega 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.

Implementações de dispositivos de televisão:

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

O Android Television Tuner Framework (TF) unifica o processamento de conteúdo ao vivo do Tuner com conteúdo de streaming de IP em dispositivos Android Television. 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 forem compatíveis com o Tuner, elas:

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

2.3.4. Desempenho e bateria

[8.1/T-0-1] Latência de frame consistente. A latência de frame inconsistente ou um atraso na renderização de frames NÃO PODE acontecer mais de cinco vezes por segundo e DEVE ser inferior a um frame por segundo.
[8.2/T-0-1] DEVE garantir uma performance de gravação sequencial de pelo menos 5 MB/s.
[8.2/T-0-2] DEVE garantir um desempenho de gravação aleatória de pelo menos 0,5 MB/s.
[8.2/T-0-3] DEVE garantir uma performance de leitura sequencial de pelo menos 15 MB/s.
[8.2/T-0-4] DEVE garantir um desempenho de leitura aleatória de pelo menos 3,5 MB/s.

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

[8.3/T-1-1] PRECISA oferecer ao usuário a opção de ativar e desativar o recurso de economia de bateria.

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

[8.3/T-1-2] É OBRIGATÓRIO 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] É OBRIGATÓRIO oferecer ao usuário a possibilidade de mostrar todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".

Implementações de dispositivos de televisão:

[8.4/T-0-1] PRECISA fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo elevado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
[8.4/T-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliampère-hora (mAh).
[8.4/T-0-3] DEVE informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a 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] PRECISA disponibilizar esse uso de energia ao desenvolvedor de apps usando o comando de shell adb shell dumpsys batterystats.

2.3.5. Modelo de segurança

Implementações de dispositivos de televisão:

[9/T-0-1] É OBRIGATÓRIO declarar o recurso android.hardware.security.model.compatible.

Se as implementações de dispositivos de televisão incluírem um aplicativo padrão para oferecer suporte ao VoiceInteractionService, elas:

[9.1/T-0-1] NÃO PODE conceder ACCESS_FINE_LOCATION como padrão para esse aplicativo.

Implementações de dispositivos de televisão:

[9.11/T-0-1] É OBRIGATÓRIO fazer backup da implementação do keystore com um ambiente de execução isolado.
[9.11/T-0-2] DEVE ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash MD5, SHA-1 e SHA-2 para oferecer suporte adequado aos algoritmos compatíveis com o sistema Android Keystore em uma área isolada com segurança do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos possíveis pelos quais o kernel ou o código do espaço do usuário podem acessar o estado interno do ambiente isolado, incluindo DMA. O Android Open Source Project (AOSP) upstream 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] DEVE realizar a autenticação da tela de bloqueio no ambiente de execução isolado e permitir o uso das chaves vinculadas à autenticação somente quando ela for bem-sucedida. As credenciais da tela de bloqueio precisam ser armazenadas de forma que apenas o ambiente de execução isolado possa fazer a autenticação da tela de bloqueio. O projeto de código aberto Android upstream fornece a camada de abstração de hardware (HAL) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
[9.11/T-0-4] PRECISA 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 NÃO PODEM ser usadas como identificadores permanentes de dispositivo.

Observação: para atender a esse requisito, é necessário compartilhar a mesma chave de atestado para uma determinada SKU,a menos que pelo menos 100.000 unidades dessa 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 chaves remotas pode ser usada para provisionar chaves de atestado de curta duração no dispositivo.

Se as implementações de dispositivos de televisão forem compatíveis com uma tela de bloqueio segura, elas:

[9.11/T-1-1] PRECISA permitir que o usuário escolha o tempo limite de espera 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 dispositivos de televisão incluírem vários usuários e não declararem a flag de recurso android.hardware.telephony, elas:

[9.5/T-2-1] Precisa 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 outros usuários trabalharem, com a capacidade de gerenciar restrições mais refinadas nos apps que estão disponíveis nesses ambientes.

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

[9.5/T-3-1] NÃO PODE oferecer suporte a perfis restritos, mas PRECISA estar alinhado à implementação do AOSP de controles para permitir /desativar o acesso de outros usuários a chamadas de voz e SMS.

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

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

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

[9.8.2/T-5-1] É OBRIGATÓRIO mostrar o indicador de câmera quando um app estiver acessando dados de 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 PODE ocultar o indicador de câmera para apps do sistema que têm interfaces de usuário visíveis ou interação direta com o usuário.

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

Implementações de dispositivos de televisão:

Perfetto (link em inglês)
- [6.1/T-0-1] PRECISA expor um binário /system/bin/perfetto ao usuário do shell, e a linha de comando precisa estar em conformidade com a documentação do perfetto.
- [6.1/T-0-2] 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/T-0-3] O binário do Perfetto PRECISA gravar como saída um rastreamento do protobuf que esteja em conformidade com o esquema definido na documentação do Perfetto.
- [6.1/T-0-4] PRECISA fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto.
- [6.1/T-0-5] O daemon rastreado do perfetto PRECISA ser ativado por padrão (propriedade do sistema persist.traced.enable).

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 critérios a seguir:

Ter uma tela com comprimento diagonal física entre 1,1 e 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

Assista às implementações de dispositivos:

[7.1.1.1/W-0-1] PRECISA ter uma tela com tamanho físico diagonal entre 1,1 e 2,5 polegadas.
[7.2.3/W-0-1] PRECISA ter a função "Início" disponível para o usuário e a função "Voltar", exceto quando estiver em UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] DEVE oferecer suporte à entrada por tela sensível ao toque.
[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 GPS/GNSS e informarem a capability para aplicativos pela flag de recurso android.hardware.location.gps, elas:

[7.3.3/W-1-1] É OBRIGATÓRIO informar as medições de GNSS assim que forem encontradas, mesmo que um local calculado com GPS/GNSS ainda não tenha sido informado.
[7.3.3/W-1-2] DEVE informar pseudodistâncias e taxas de pseudodistância do GNSS que, em condições de céu aberto após a determinação do local, enquanto parado ou se movendo 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 Watch incluírem um giroscópio de três eixos, elas:

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

Se as implementações de dispositivos Watch forem compatíveis com conectividade de dados móveis, elas:

[7.4.1/W-1-1] PRECISA declarar o recurso android.hardware.telephony.data.

Assista às implementações de dispositivos:

[7.4.3/W-0-1] Precisa ter suporte a Bluetooth.
[7.6.1/W-0-1] Precisa ter pelo menos 1 GB de armazenamento não volátil disponível para dados particulares do aplicativo (também conhecido como partição "/data").
[7.6.1/W-0-2] Precisa 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] PRECISA incluir um microfone.
[7.8.2/W] PODE ter saída de áudio.

2.4.2. Multimídia

Não há requisitos extras.

2.4.3. Software

Assista às implementações de dispositivos:

[3/W-0-1] MUST declare the feature android.hardware.type.watch.
[3/W-0-2] MUST support 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 intents de aplicativo listadas aqui.

Assista às implementações de dispositivos:

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

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

[3.10/W-1-1] DEVE oferecer suporte a serviços de acessibilidade de terceiros.
[3.10/W-SR-1] É FORTEMENTE RECOMENDADO fazer o pré-carregamento de serviços de acessibilidade no dispositivo comparáveis ou que excedam a funcionalidade do Acesso com interruptor e do 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 Watch informarem o recurso android.hardware.audio.output, elas:

[3.11/W-SR-1] É ALTAMENTE RECOMENDADO incluir um mecanismo de TTS compatível com os idiomas disponíveis no dispositivo.
[3.11/W-0-1] É obrigatório oferecer suporte à instalação de mecanismos 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 estender os recursos incluídos no AOSP, elas:

[8.3/W-SR-1] É ALTAMENTE RECOMENDADO oferecer ao usuário a opção de mostrar todos os apps dispensados dos modos de economia de energia do Soneca e de App em espera.
[8.3/W-SR-2] É ALTAMENTE RECOMENDADO fornecer capacidade de ativação e desativação do recurso de economia de bateria para o usuário.

Assista às implementações de dispositivos:

[8.4/W-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 elevado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
[8.4/W-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliampère-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 com a implementação do módulo do kernel uid_cputime.
[8.4/W-0-4] É OBRIGATÓRIO disponibilizar esse uso de energia pelo comando de shell adb shell dumpsys batterystats para o desenvolvedor de apps.
[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

Assista às implementações de dispositivos:

[9/W-0-1] MUST declare the android.hardware.security.model.compatible feature.

Se as implementações de dispositivos Watch incluírem um aplicativo padrão para oferecer suporte ao VoiceInteractionService, elas:

[9.1/W-0-1] NÃO PODE conceder ACCESS_FINE_LOCATION como padrão para esse aplicativo.

Se as implementações de dispositivos Watch 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 recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para outros usuários trabalharem, com a capacidade de gerenciar restrições mais refinadas nos apps que estão disponíveis nesses ambientes.

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

[9.5/W-2-1] NÃO PODE oferecer suporte a perfis restritos, mas PRECISA estar alinhado à implementação do AOSP de controles para ativar /desativar o acesso de outros usuários a chamadas de voz e SMS.

Se as implementações de dispositivos tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que implementam a TrustAgentService API System, elas:

[9.11.1/W-1-1] DEVE desafiar o usuário a usar um dos métodos de autenticação primária recomendados (como PIN, padrão ou senha) com mais frequência do que uma vez a cada 72 horas pelo menos a cada 336 horas (14 dias) .

Se as implementações de dispositivos tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que chamam a API do sistema TrustAgentService.grantTrust() com a flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, elas:

[9.11.1/W-2-1] PRECISA atender às seguintes condições para chamar grantTrust() com essa flag:
- O dispositivo está conectado a um dispositivo portátil principal físico próximo com uma tela de bloqueio própria, e
- O usuário autenticou a identidade em relação a essa tela de bloqueio ou biometria de Classe 3 nos últimos 30 segundos.
[9.11.1/W-2-2] É OBRIGATÓRIO definir o estado do dispositivo como TrustState.TRUSTABLE quando o dispositivo wearable for removido do pulso ou do corpo e o TrustAgent não tiver revogado a confiança.

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 toda a funcionalidade do sistema e/ou de infoentretenimento.

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

Estão incorporados como parte de um veículo automotivo ou podem ser conectados a ele.
Usar uma tela na fileira do banco do motorista como a 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] PRECISA ter uma tela de pelo menos 6 polegadas na diagonal física.
[7.1.1.1/A-0-2] Precisa ter um layout de tamanho de tela de pelo menos 750 dp x 480 dp.
[7.1.1.1/A-0-3] PRECISA oferecer suporte à composição de GPU de buffers gráficos pelo menos tão grandes quanto a resolução mais alta de qualquer tela integrada.

Se as implementações de dispositivos Automotive forem compatíveis com multiusuário simultâneo (em que vários usuários do Android podem interagir com o dispositivo simultaneamente, cada um usando a própria tela quando config_multiuserVisibleBackgroundUsers está ativado), elas:

[7.1.1.1/A-1-1] PRECISA ter uma tela separada de pelo menos 15 cm de tamanho físico na diagonal para cada zona de ocupante no display principal. Isso precisa ser marcado como CarOccupantZoneManager.DISPLAY_TYPE_MAIN para cada zona de ocupação.
[7.1.1.1/A-1-2] DEVE ter um layout de tamanho de tela de pelo menos 750 dp x 480 dp para cada tela principal.

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

[7.1.4.1/A-0-1] PRECISA declarar o OpenGL ES 3.1 ou uma versão mais recente.
[7.1.4.1/A-0-2] PRECISA oferecer suporte ao Vulkan 1.1.
[7.1.4.1/A-0-3] DEVE incluir o carregador do Vulkan e exportar todos os símbolos.

Se as implementações de dispositivos automotivos incluírem suporte ao Vulkan, elas:

[7.1.4.2/A-1-1] PRECISA atender aos requisitos especificados pelo perfil de referência do Android 2021.

Se as implementações de dispositivos automotivos declararem suporte a telas de alto alcance dinâmico usando Configuration.isScreenHdr(), elas:

[7.1.4.5/A-1-1] É OBRIGATÓRIO anunciar suporte às 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 automotivos:

[7.1.4.6/A-0-1] É OBRIGATÓRIO informar se o dispositivo é compatível com o recurso de geração de perfil de GPU usando uma propriedade do sistema graphics.gpu.profiler.support.

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

[7.1.4.6/A-1-1] PRECISA informar como saída um rastreamento de protobuf que esteja em conformidade com o esquema para contadores de GPU e GPU RenderStages definidos na documentação do Perfetto.
[7.1.4.6/A-1-2] PRECISA informar valores em conformidade para os contadores de GPU do dispositivo seguindo o proto de pacote gpu counter trace.
[7.1.4.6/A-1-3] PRECISA informar valores em conformidade para os RenderStages da GPU do dispositivo seguindo o render stage trace packet proto.
[7.1.4.6/A-1-4] PRECISA informar um ponto de rastreamento de frequência da GPU, conforme especificado pelo formato: power/gpu_frequency.

Implementações de dispositivos automotivos:

[7.1.5/A-0-1] DEVE incluir suporte para o modo de compatibilidade de apps legados implementado pelo código aberto do Android upstream. Ou seja, as implementações de dispositivos NÃO PODEM alterar os gatilhos ou limiares em que o modo de compatibilidade é ativado, e NÃO PODEM alterar o comportamento do próprio modo de compatibilidade.

Implementações de dispositivos automotivos:

[7.1.7/A-0-1] É OBRIGATÓRIO configurar displays secundários no campo de visão do motorista como FLAG_PRIVATE.
[7.2.3/A-0-1] PRECISA fornecer a função "Início" e PODE fornecer as funções "Voltar" e "Recentes".
[7.2.3/A-0-2] É OBRIGATÓRIO enviar o evento de toque normal e longo da função Voltar (KEYCODE_BACK) para o aplicativo em primeiro plano.
[7.3/A-0-1] PRECISA 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 subjacente PODE ser o mesmo que o fotômetro.
[7.3/A-0-3] É necessá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 posição Localização combinando GPS/GNSS com outros sensores. Se a Localização for estimada, é ALTAMENTE RECOMENDÁVEL implementar e informar os tipos de Sensor e/ou IDs de propriedade do veículo correspondentes usados.
[7.3/A-0-4] O local solicitado via LocationManager#requestLocationUpdates() NÃO PODE ser associado ao mapa.
[7.3.1/A-0-4] PRECISA obedecer ao sistema de coordenadas do sensor do carro do Android.
[7.3/A-SR-1] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos e um giroscópio de três eixos.
[7.3/A-SR-2] É ALTAMENTE RECOMENDADO implementar e informar o sensor TYPE_HEADING.

[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 dos bancos traseiros.

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 uma frequência de pelo menos 100 Hz.

Se as implementações de dispositivos 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] DEVE implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
[7.3.1/A-1-4] DEVE 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] PRECISA ser capaz de informar eventos com uma 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 +/-250 dps 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] DEVE 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 em rede celular, elas:

[7.3.3/A-3-1] DEVE determinar a localização na primeira vez que o receptor GPS/GNSS é ligado ou após 4 dias em 60 segundos.
[7.3.3/A-3-2] PRECISA atender aos critérios de tempo até o primeiro conserto, 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 quatro dias). O requisito 7.3.3/C-1-2 é atendido em veículos sem conectividade de dados baseada em rede celular usando previsões de órbita do GNSS calculadas no receptor ou o último local conhecido do veículo, além da capacidade de estimar por pelo menos 60 segundos com uma precisão de posição que satisfaç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] DEVE ser capaz de informar eventos com uma frequência de pelo menos 1 Hz.
[7.3.4/A-SR-3] É ALTAMENTE RECOMENDADO informar eventos com uma frequência de pelo menos 10 Hz.
PRECISA estar em referência ao norte verdadeiro.
DEVE estar disponível mesmo quando o veículo estiver parado.
PRECISA ter uma resolução de pelo menos 1 grau.

Implementações de dispositivos automotivos:

[7.4.3/A-0-1] DEVE oferecer suporte a Bluetooth e DEVERIA 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 (A2 DP).
- 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, na sigla em inglês).
[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.

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

Implementações de dispositivos automotivos:

[7.4.5/A] DEVE incluir suporte para conectividade de dados baseada em rede celular.
[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 de dispositivos incluírem suporte para rádio AM/FM e expuserem a funcionalidade a qualquer aplicativo, elas:

[7.4/A-1-1] É OBRIGATÓRIO declarar suporte para FEATURE_BROADCAST_RADIO.

Uma câmera traseira é uma câmera voltada para o mundo que pode ser localizada em qualquer lugar do veículo e está voltada para fora da cabine. Ou seja, ela captura imagens de cenas do outro lado 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 estar localizada em qualquer lugar do veículo e está voltada para dentro da cabine. Ela captura imagens do usuário, como para videoconferências e aplicativos semelhantes.

Implementações de dispositivos automotivos:

[7.5/A-SR-1] É FORTEMENTE RECOMENDADO incluir uma ou mais câmeras voltadas para o mundo.
PODE incluir uma ou mais câmeras voltadas para o 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 voltada para o mundo, ela vai:

[7.5/A-1-1] PRECISA estar orientado de forma que a dimensão longa da câmera se alinhe com o plano X-Y dos eixos do sensor automotivo do Android.
[7.5/A-SR-3] É ALTAMENTE RECOMENDÁVEL que tenham hardware de foco fixo ou EDOF (profundidade de campo estendida).
[7.5/A-1-2] PRECISA ter a câmera principal voltada para o ambiente como a câmera voltada para o ambiente com o menor ID.

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 voltada ao usuário PRECISA ser a câmera voltada ao usuário com o menor ID.
PODE estar orientado de forma que a dimensão longa da câmera se alinhe ao plano X-Y dos eixos do sensor automotivo do Android.

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

[7.5/A-3-1] PRECISA obedecer aos requisitos principais da câmera na seção 7.5.

Se as implementações de dispositivos automotivos incluírem uma câmera que não esteja acessível pelas APIs android.hardware.Camera ou android.hardware.camera2, elas:

[7.5/A-4-1] Precisa ser acessível pelo serviço do sistema Extended View System.

Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras acessíveis pelo Extended View System Service, para essa câmera, elas:

[7.5/A-5-1] NÃO ROTACIONAR nem ESPELHAR horizontalmente a visualização da câmera.
[7.5/A-SR-4] É ALTAMENTE RECOMENDADO que tenham uma resolução de pelo menos 1,3 megapixel.

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 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 proprietária, elas:

[7.5/A-7-1] É OBRIGATÓRIO implementar uma API de 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] É OBRIGATÓRIO ter pelo menos 4 GB de armazenamento não volátil disponível para dados particulares do aplicativo (partição /data).
[7.6.1/A] DEVE formatar a partição de dados para oferecer melhor desempenho e longevidade no armazenamento flash (por exemplo, usando o sistema de arquivos f2fs).

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

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

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

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

[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 alguma das seguintes densidades for usada:
- 280 dpi ou menos em telas pequenas/normais
- ldpi ou inferior em telas extragrandes
- mdpi ou inferior 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 alguma das seguintes densidades 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 1.280 MB por tela principal se alguma das seguintes densidades 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 1.824 MB por tela principal se alguma das seguintes densidades for usada:
- 560 dpi ou mais em telas pequenas/normais
- 400 dpi ou mais em telas grandes
- xhdpi ou superior em telas extragrandes

Implementações de dispositivos automotivos:

[7.7.1/A] DEVE incluir uma porta USB compatível com o modo periférico.

Se as implementações de dispositivos automotivos incluírem uma porta USB com um controlador operando no modo periférico, elas:

[7.7.1/A-1-1] É OBRIGATÓRIO implementar a API Android Open Accessory (AOA).

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

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

Implementações de dispositivos automotivos:

[7.8.1/A-0-1] PRECISA incluir um microfone.

Implementações de dispositivos automotivos:

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

[7.8.2/A-1-1] É OBRIGATÓRIO ter um dispositivo de saída de áudio para cada tela principal em sistemas de dispositivo compartilhado simultâneos.
[7.8.2/A-1-2] Precisa 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.

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

[7.8.2.2/A-1-1] É NECESSÁRIO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSink() se o campo "Tipo de terminal de áudio USB" for 0x0302.
[7.8.2.2/A-1-2] É NECESSÁRIO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSink() se o campo "Tipo de terminal de áudio USB" for 0x0402.
[7.8.2.2/A-1-3] É OBRIGATÓRIO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSink() se o campo "Tipo de terminal de áudio USB" for 0x0603.
[7.8.2.2/A-1-4] É NECESSÁRIO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e função isSink() se o campo "Tipo de terminal de áudio USB" for 0x0400.

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 AAC MPEG-4 (AAC LC)
[5.1/A-0-2] Perfil HE AAC MPEG-4 (AAC+)
[5.1/A-0-3] AAC ELD (AAC aprimorado com atraso baixo)

[5.1/A-0-4] MPEG-D USAC com MPEG-D DRC (AAC de alta eficiência estendida)

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 RECOMENDADO que as implementações de dispositivos automotivos ofereçam suporte à seguinte decodificação de vídeo:

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

[5.5.3/A-1-1] Precisa definir curvas de volume idênticas para todos os fluxos de saída de áudio mapeados para o mesmo grupo de volume, conforme definido no arquivo de configuração de áudio do carro.

2.5.3. Software

Implementações de dispositivos automotivos:

[3/A-0-1] PRECISA declarar o recurso android.hardware.type.automotive.
[3/A-0-2] Precisa oferecer suporte a uiMode = UI_MODE_TYPE_CAR.
[3/A-0-3] Precisa oferecer suporte a todas as APIs públicas no namespace android.car.*.

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

[3/A-1-1] NÃO PODE atribuir privilégios especiais ao uso dessas propriedades pelo aplicativo do sistema nem impedir que aplicativos de terceiros usem essas propriedades.
[3/A-1-2] NÃO PODE replicar uma propriedade do veículo que já existe no SDK.

Implementações de dispositivos automotivos:

[3.2.1/A-0-1] PRECISA oferecer suporte e aplicar todas as constantes de permissões 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úblicos definidos pelas intents de aplicativo a seguir, listadas aqui.
[3.2.3.1/A-0-2] É OBRIGATÓRIO ter um app 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 ofereça ao usuário a capacidade de acessar os dados do provedor de documentos usando a API DocumentsProvider.

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

[3.2.3.1/A-1-1] É obrigatório ter uma atividade que processe a intent 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.
[3.4.1/A-0-1] É OBRIGATÓRIO fornecer uma implementação completa da API android.webkit.Webview.

[3.8/A-1-1] É OBRIGATÓRIO implementar a seguinte lista predefinida de UserRestrictions para usuários secundários completos que não são o usuário em primeiro plano atual, mas têm acesso à interface do display atribuído 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 PODE permitir que usuários secundários completos que não sejam o usuário em primeiro plano atual, mas tenham acesso à interface à 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, modo noturno, escala de cinza do Bem-estar digital e reduzir cores brilhantes) para qualquer outro usuário nas configurações ou em uma API.

Implementações de dispositivos automotivos:

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

Se as implementações de dispositivos automotivos incluírem um botão de pressionar para falar, elas:

[3.8.4/A-1-1] É OBRIGATÓRIO usar um toque rápido no botão falar para ativar como a interação designada para iniciar o app assistivo selecionado pelo usuário, ou seja, o app que implementa VoiceInteractionService.

Implementações de dispositivos automotivos:

[3.8.3.1/A-0-1] PRECISA renderizar corretamente os recursos conforme descrito na documentação do SDK Notifications on Automotive OS.
[3.8.3.1/A-0-2] PRECISA 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çado, como controles por canal de notificação. PODE usar a capacidade de resposta da interface por aplicativo para reduzir os controles.

Se as implementações de dispositivos automotivos forem compatíveis com as propriedades da HAL do usuário, elas:

[3.9.3/A-1-1] PRECISA implementar todas as propriedades do ciclo de vida do usuário: INITIAL_USER_INFO, SWITCH_USER, CREATE_USER e 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] DEVE permitir que o usuário interaja com segurança com aplicativos de mídia enquanto dirige.
[3.14/A-0-3] DEVE oferecer suporte à ação da intent implícita CAR_INTENT_ACTION_MEDIA_TEMPLATE com o extra CAR_EXTRA_MEDIA_PACKAGE.
[3.14/A-0-4] PRECISA oferecer uma opção para navegar até a atividade de preferências de um aplicativo de mídia, mas SÓ pode ativar essa opção quando as restrições da UX do carro não estiverem em vigor.
[3.14/A-0-5] PRECISA mostrar mensagens de erro definidas pelos aplicativos de mídia e oferecer suporte aos extras opcionais ERROR_RESOLUTION_ACTION_LABEL e ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] PRECISA oferecer suporte a um recurso de pesquisa no app para apps que oferecem suporte a pesquisa.
[3.14/A-0-7] PRECISA respeitar as definições de CONTENT_STYLE_BROWSABLE_HINT e CONTENT_STYLE_PLAYABLE_HINT ao mostrar a hierarquia do MediaBrowser.

Implementações de dispositivos automotivos:

[3.14/A-0-8] É OBRIGATÓRIO declarar a flag de recurso android.software.car.templates_host.
[3.14/A-0-9] É OBRIGATÓRIO declarar a flag de recurso com.android.car.background_audio_while_driving.
[3.14/A-0-10] É OBRIGATÓRIO declarar a flag de recurso android.software.car.templates_host.media.

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

[3.14/A-1-1] PRECISA 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 de aplicativos para entrar no modo de tela cheia, conforme descrito em immersive documentation.
[3.8/A] A IA 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 de aplicativos para mudar as cores por trás dos elementos da interface do sistema, garantindo que esses elementos fiquem claramente visíveis o tempo todo.

Implementações de dispositivos automotivos:

[7.1.1/A-0-1] PRECISA declarar a flag de recurso android.software.car.display_compatibility.

Ao executar aplicativos em primeiro plano com o recurso android.software.car.display_compatibility ou sem o recurso android.hardware.type.automotive, os dispositivos automotivos:

[7.1.1/A-1-1] PRECISA fornecer a função "Voltar".

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

[7.4.1.2/A-1-1] PRECISA declarar a flag de recurso android.software.telecom.

[7.4.1.2/A-1-2] DEVE implementar a estrutura de telecomunicações.

2.5.4. Desempenho e bateria

[8.1/A-0-1] Latência de frame consistente. Latência de frame inconsistente ou um atraso na renderização de frames NÃO PODE acontecer mais de cinco vezes por segundo e DEVE ser inferior a um frame por segundo.
[8.1/A-0-2] Latência da interface do usuário. As implementações de dispositivos PRECISAM garantir uma experiência do usuário de baixa latência rolando uma lista de 10.000 entradas de lista, conforme definido pelo conjunto de teste de compatibilidade (CTS) do Android, em menos de 36 segundos.
[8.1/A-0-3] Troca de tarefas. Quando vários apps são iniciados, a reinicialização de um aplicativo já em execução após o lançamento PRECISA levar menos de um segundo.

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 estejam disponíveis para desenvolvedores pela API do sistema android.car.storagemonitoring.CarStorageMonitoringManager. O Android Open Source Project atende ao requisito com o módulo do kernel uid_sys_stats.
[8.2/A-0-2] DEVE garantir um desempenho de gravação sequencial de pelo menos 5 MB/s.
[8.2/A-0-3] DEVE garantir um desempenho de gravação aleatória de pelo menos 0,5 MB/s.
[8.2/A-0-4] É OBRIGATÓRIO garantir uma leitura sequencial de pelo menos 15 MB/s.
[8.2/A-0-5] DEVE garantir uma leitura aleatória com desempenho de pelo menos 3,5 MB/s.

Se as implementações de dispositivos automotivos retornarem android.os.Build.VERSION_CODES.U ou mais para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

[8.2/A-1-1] DEVE garantir um desempenho de gravação sequencial de pelo menos 150 MB/s.
[8.2/A-1-2] PRECISA garantir uma performance de gravação aleatória de pelo menos 10 MB/s.
[8.2/A-1-3] DEVE garantir uma performance de leitura sequencial de pelo menos 250 MB/s.
[8.2/A-1-4] PRECISA garantir uma performance de leitura aleatória de pelo menos 100 MB/s.
[8.2/A-1-5] DEVE garantir um desempenho paralelo de leitura e gravação sequencial com desempenho de leitura 2x e gravação 1x de pelo menos 50 MB/s.
[8.3/A-1-3] PRECISA oferecer suporte ao Modo garagem.
[8.3/A] PRECISA estar no modo garagem por pelo menos 15 minutos após cada viagem, a menos que:
- A bateria está descarregada.
- Nenhum job inativo é programado.
- O motorista sai do modo garagem.
[8.4/A-0-1] PRECISA fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo elevado aproximado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
[8.4/A-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliampère-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 com a 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 pelo comando de shell adb shell dumpsys batterystats para o desenvolvedor de apps.

2.5.5. Modelo de segurança

Se as implementações de dispositivos automotivos forem compatíveis com vários usuários, elas:

[9.5/A-1-1] NÃO PODE permitir que os usuários interajam com nem alternem para o usuário do sistema sem interface, exceto para o provisionamento de dispositivos.
[9.5/A-1-2] PRECISA mudar para um Usuário secundário antes de BOOT_COMPLETED.
[9.5/A-1-3] DEVE oferecer suporte à capacidade de criar um usuário visitante mesmo quando o número máximo de usuários em um dispositivo for atingido.

Se as implementações de dispositivos automotivos forem compatíveis com a API do sistema VisualQueryDetectionService ou outro mecanismo de detecção de consultas sem indicação de acesso ao microfone e/ou à câmera, elas:

[9.8/A-1-1] PRECISA garantir que o serviço de detecção de consultas só possa transmitir dados para o sistema, ContentCaptureService ou o serviço de reconhecimento de fala no dispositivo (criado por SpeechRecognizer#createOnDeviceSpeechRecognizer()).
[9.8/A-1-2] NÃO PODE permitir que informações de áudio ou vídeo sejam transmitidas para fora do VisualQueryDetectionService, exceto para ContentCaptureService ou o serviço de reconhecimento de fala no dispositivo.
[9.8/A-1-3] É OBRIGATÓRIO mostrar um aviso ao usuário na interface do sistema quando o dispositivo detectar a intenção do usuário de interagir com o aplicativo de assistente digital (por exemplo, detectando a presença do usuário por uma câmera).
[9.8/A-1-4] DEVE mostrar um indicador de microfone e exibir a consulta detectada do usuário na UI imediatamente após a detecção da consulta.
[9.8/A-1-5] NÃO PODE permitir 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 automotivos declararem android.hardware.microphone, elas:

[9.8.2/A-1-1] DEVE mostrar o indicador de 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 têm as funções mencionadas na seção 9.1 com o identificador CDD [C-4-X].
[9.8.2/A-1-2] NÃO PODE ocultar o indicador de microfone para apps do sistema que têm interfaces de usuário visíveis ou interação direta com o usuário.
[9.8.2/A-1-3] É OBRIGATÓRIO oferecer uma ação do usuário para ativar/desativar 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 de câmera quando um app estiver acessando dados de câmera ao vivo, mas não quando a câmera estiver sendo acessada apenas por apps que têm os papéis definidos na Seção 9.1 Permissões com o identificador CDD [C-4-X].
[9.8.2/A-2-2] NÃO PODE ocultar o indicador de câmera para apps do sistema que têm interfaces de usuário visíveis ou interação direta com o usuário.
[9.8.2/A-2-3] É OBRIGATÓRIO oferecer uma opção para ativar/desativar a câmera no app Configurações.
[9.8.2/A-2-4] PRECISA 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] PRECISA declarar o recurso android.hardware.security.model.compatible.
[9.11/A-0-1] É OBRIGATÓRIO fazer backup da implementação do keystore com um ambiente de execução isolado.
[9.11/A-0-2] PRECISA ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções hash MD5, SHA-1 e SHA-2 para oferecer suporte adequado aos algoritmos compatíveis com o sistema Android Keystore em uma área isolada com segurança do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos possíveis pelos quais o kernel ou o código do espaço do usuário podem acessar o estado interno do ambiente isolado, incluindo DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada no 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] É OBRIGATÓRIO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e permitir o uso das chaves vinculadas à autenticação somente quando a autenticação for bem-sucedida. As credenciais da tela de bloqueio precisam ser armazenadas de forma que apenas o ambiente de execução isolado possa realizar a autenticação da tela de bloqueio. O Android Open Source Project upstream fornece a camada de abstração de hardware (HAL) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
[9.11/A-0-4] DEVE 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 NÃO PODEM ser usadas como identificadores permanentes de dispositivo.

Observação: para atender a esse requisito, é necessário compartilhar a mesma chave de atestado para uma determinada SKU,a menos que pelo menos 100.000 unidades dessa 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 chaves remotas pode ser usada para provisionar chaves de atestação de curta duração no dispositivo.

Implementações de dispositivos automotivos:

[9.14/A-0-1] É OBRIGATÓRIO controlar o acesso a mensagens de subsistemas de veículos do framework Android (por exemplo, permitir tipos e fontes de mensagens na lista de permissões).
[9.14/A-0-2] É NECESSÁRIO usar um watchdog contra ataques de negação de serviço do framework 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 ao mau funcionamento dos subsistemas do veículo.

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

Implementações de dispositivos automotivos:

Perfetto (link em inglês)
- [6.1/A-0-1] MUST expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
- [6.1/A-0-2] 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/A-0-3] O binário do perfetto PRECISA gravar como saída um trace do protobuf que esteja em conformidade com o esquema definido na documentação do perfetto.
- [6.1/A-0-4] É OBRIGATÓRIO fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto.
- [6.1/A-0-5] O daemon rastreado do perfetto PRECISA ser ativado por padrão (propriedade do sistema persist.traced.enable).

2.6. Requisitos para tablets

Um tablet Android é um dispositivo Android que geralmente atende a todos os seguintes critérios:

Usado segurando com as duas mãos.
Não tem uma configuração clamshell ou conversível.
As implementações de teclado físico usadas com o dispositivo se conectam por meio de uma conexão padrão (por exemplo, USB, Bluetooth).
Tem uma fonte de energia que oferece mobilidade, como uma bateria.
Tem um tamanho de exibição maior que 7" e menor que 18", medido na diagonal.

As implementações de dispositivos tablet têm requisitos semelhantes às de dispositivos portáteis. As exceções são indicadas por um asterisco (*) nessa seção e observadas 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] DEVE ser capaz de medir 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 se aplicam a tablets.

Modo de realidade virtual (Seção 7.9.1)

Realidade virtual de alta performance (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 tablet incluírem vários usuários e não declararem a flag de recurso android.hardware.telephony, elas:

[9.5/T-1-1] PRECISA 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 outros usuários trabalharem, com a capacidade de gerenciar restrições mais refinadas nos apps que estão 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 PODE oferecer suporte a perfis restritos, mas PRECISA estar alinhado à implementação do AOSP de controles para ativar /desativar o acesso de outros usuários a chamadas de voz e SMS.

2.6.2. Software

[3.2.3.1/Tab-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úblicos definidos pelas seguintes intents de aplicativos listadas aqui.

3. Software

3.1. Compatibilidade gerenciada de API

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

Implementações de dispositivos:

[C-0-1] PRECISA 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 upstream do Android.
[C-0-2] PRECISA oferecer suporte/preservar todas as classes, métodos e elementos associados marcados pela anotação TestApi (@TestApi).
[C-0-3] NÃO PODE omitir nenhuma API gerenciada, alterar interfaces ou assinaturas de API, desviar do comportamento documentado ou incluir ambientes autônomos, exceto quando especificamente permitido por esta Definição de compatibilidade.
[C-0-4] AINDA DEVE manter as APIs 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 requisitos específicos desse cenário.
[C-0-5] NÃO PODE permitir que apps de terceiros usem interfaces não SDK, que são definidas como métodos e campos nos pacotes da linguagem Java que estão no classpath 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 um @SystemAPI, conforme descrito nos documentos do SDK e membros de classe privados e privados de pacote.
[C-0-6] DEVE ser enviado com todas as interfaces não SDK nas mesmas listas restritas fornecidas pelas flags provisórias e de lista de bloqueio no caminho prebuilts/runtime/appcompat/hiddenapi-flags.csv para a ramificação do nível da API apropriado no AOSP.
[C-0-7] PRECISA oferecer suporte ao mecanismo de atualização dinâmica da 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 atuais presentes no AOSP.

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

[C-0-8] NÃO PODE oferecer suporte à instalação de aplicativos destinados a um nível da API inferior a 24 26.

3.1.1. Extensões Android

O Android permite estender a superfície de API gerenciada de um nível de API específico atualizando a versão da extensão para esse nível de API. 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 da API.

Implementações de dispositivos Android:

[C-0-1] PRECISA pré-carregar a implementação do AOSP da biblioteca compartilhada ExtShared e dos serviços ExtServices com versões maiores ou iguais às mínimas permitidas por nível da API. Por exemplo, as implementações de dispositivos Android 7.0 que executam o nível 24 da API precisam incluir pelo menos a versão 1.
[C-0-2] SÓ PODE retornar um número de versão de extensão válido que tenha sido definido pelo AOSP.
[C-0-3] PRECISA oferecer suporte a todas as APIs definidas pelas versões de extensão retornadas por android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) da mesma forma que outras APIs gerenciadas, seguindo os requisitos na seção 3.1.

3.1.2. Biblioteca do Android

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

[C-0-1] NÃO PODE colocar a biblioteca org.apache.http.legacy no bootclasspath.
[C-0-2] É OBRIGATÓRIO adicionar a biblioteca org.apache.http.legacy ao classpath do aplicativo somente quando o app atender a uma das seguintes condições:
- Direcionado ao nível 28 da API ou a 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 flexível de API

Além das APIs gerenciadas da seção 3.1, o Android também inclui uma API "soft" significativa somente de tempo de execução, na forma de intents, permissões e aspectos semelhantes de aplicativos Android que não podem ser aplicados no tempo de 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. Observe que a seção 9 lista outros requisitos relacionados ao modelo de segurança do Android.

3.2.2. Parâmetros de 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, que as implementações de dispositivos PRECISAM seguir.

Parâmetro	Detalhes
VERSION.RELEASE	A versão do sistema Android em execução no momento, em formato legível. Esse campo PRECISA ter um dos valores de string definidos em Strings de versão permitidas para Android 17.
VERSION.SDK	A versão do sistema Android em execução no momento, em um formato acessível ao código do aplicativo de terceiros. Para o Android 17, esse campo PRECISA ter o valor inteiro 17_INT.
VERSION.SDK&lowbar;INT	A versão do sistema Android em execução no momento, em um formato acessível ao código do aplicativo de terceiros. Para o Android 17, esse campo PRECISA ter o valor inteiro 17&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 formato legível para humanos. Esse valor NÃO DEVE ser reutilizado em builds diferentes disponibilizados aos usuários finais. Um uso típico desse campo é indicar qual número da versão ou identificador de mudança de controle de origem foi usado para gerar o build. O valor deste campo PRECISA ser codificável como ASCII de 7 bits imprimível e corresponder à expressão regular `^[^ :\/~]+$`.
TABULEIRO	Um valor escolhido pelo implementador do dispositivo que identifica o hardware interno específico usado pelo dispositivo, em formato legível para 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 associada ao dispositivo, conforme conhecido pelos usuários finais. PRECISA estar em um formato legível para humanos e DEVE representar o fabricante do dispositivo ou a marca da empresa em que ele é comercializado. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9_-]+$`.
SUPPORTED&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.
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.
SUPPORTED&lowbar;64&lowbar;BIT&lowbar;ABIS	O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) de código nativo. Consulte a seção 3.3. Compatibilidade de API nativa.
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.
CPU&lowbar;ABI2	O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) de código nativo. Consulte a seção 3.3. Compatibilidade de API nativa.
DISPOSITIVO	Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o codinome que identifica a configuração dos recursos de hardware e o 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_-]+$`. Esse nome NÃO PODE mudar durante a vida útil do produto.
FINGERPRINT	Uma string que identifica exclusivamente esta build. Ele PRECISA ser razoavelmente legível. Ele PRECISA seguir este modelo: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Exemplo: acme/myproduct/ mydevice:17/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 (na linha de comando do kernel ou em /proc). Ele PRECISA ser razoavelmente legível. O valor desse campo PRECISA ser codificável 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. 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 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 deste 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 sobre 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 o ciclo de vida 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 ]+)`, NÃO PODE começar ou terminar com espaços em branco e NÃO PODE 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 em um chip (SoC) principal 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ços em branco e NÃO PODE ser igual a "unknown". Esse campo NÃO PODE mudar durante a vida útil do produto.
MODELO	Um valor escolhido pelo implementador do dispositivo que contém o nome do dispositivo conhecido pelo usuário final. Esse nome PRECISA ser o mesmo usado para comercializar e vender o dispositivo aos usuários finais. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia (""). É ALTAMENTE RECOMENDADO que esse campo NÃO seja alterado durante o ciclo de vida do produto.
PRODUTO	Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o codinome do produto específico (SKU) que PRECISA ser exclusivo na mesma marca. Precisa ser legível por humanos, mas não necessariamente destinado à 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_-]+$`. O nome do produto NÃO PODE mudar durante a vida útil dele.
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 separada por vírgulas de tags escolhidas pelo implementador do dispositivo que distinguem ainda mais o build. As tags PRECISAM ser codificáveis como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9._-]+` e PRECISAM ter um dos valores correspondentes às três configurações típicas de assinatura da plataforma Android: release-keys, dev-keys e test-keys.
TIME	Um valor que representa o carimbo de data/hora de quando o build ocorreu.
TIPO	Um valor escolhido pelo implementador do dispositivo que especifica a configuração de tempo de execução do build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas de tempo 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 está vulnerável a nenhum dos problemas descritos até o Boletim público de segurança do Android designado. Ele precisa estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no Boletim público de segurança 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 este build, exceto pelos patches fornecidos no Boletim público de segurança do Android. Ele PRECISA informar o valor correto e, se tal build não existir, informar uma string vazia ("").
BOOTLOADER	Um valor escolhido pelo implementador do dispositivo que identifica a versão específica do carregador de inicialização interno usada no dispositivo, em formato legível para 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 usado no dispositivo, em formato legível. Se um dispositivo não tiver nenhum rádio/modem interno, ele precisará retornar NULL. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `^[a-zA-Z0-9._-,]+$`.
getSerial()	PRECISA ser ou retornar um número de série de hardware, que PRECISA 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]+$`.
STRONGBOX&lowbar;MANUFACTURER	O nome comercial do fabricante do chip StrongBox usado no produto. O fornecedor do StrongBox fornece a constante correta. Dispositivos com o mesmo fornecedor do StrongBox precisam usar o mesmo valor constante. O valor desse campo PRECISA corresponder à expressão regular `^([0-9A-Za-z ]+)` e NÃO PODE ser igual a "unsupported". Esse campo NÃO PODE mudar durante a vida útil do produto.
STRONGBOX&lowbar;MODEL	O nome do modelo do chip StrongBox usado no produto. O fornecedor do StrongBox fornece a constante correta. Dispositivos com o mesmo fornecedor do StrongBox DEVEM usar o mesmo valor constante. O valor desse campo precisa corresponder à expressão regular `^([0-9A-Za-z ._/+-]+)$` e não pode ser igual a "unsupported". Esse campo NÃO PODE mudar durante a vida útil do produto.

3.2.3. Compatibilidade de intents

3.2.3.1. Intents comuns de aplicativos

As intents do Android permitem que componentes de aplicativos solicitem funcionalidades 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 intent públicos definidos pelas intents de aplicativos listadas aqui e fornecer atendimento, ou seja, atender à expectativa do desenvolvedor para essas intents de aplicativos comuns, conforme descrito no SDK.

Consulte a Seção 2 para conferir intents obrigatórios de aplicativos 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 as configurações, seja substituído por aplicativos de terceiros. A implementação de código aberto do Android upstream permite isso por padrão.
[C-0-2] Os implementadores de dispositivos NÃO DEVEM anexar privilégios especiais ao uso desses padrões de intent por aplicativos do sistema nem impedir que aplicativos de terceiros se vinculem e assumam o controle desses padrões. Essa proibição inclui, entre outras opções, 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 dispositivos 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 de URI específicos (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 do 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 autoritativo para determinados tipos de intents de URI da Web. Quando essas declarações autorizadas são definidas nos padrões de filtro de intent de um app, as implementações de dispositivo:

[C-0-4] PRECISA tentar validar todos os filtros de intent seguindo as etapas de validação definidas na especificação do Digital Asset Links, conforme implementado pelo gerenciador de pacotes no Android Open Source Project upstream.
[C-0-5] DEVE tentar validar os filtros de intent durante a instalação do aplicativo e definir todos os filtros de intent de URI validados com sucesso como processadores de apps padrão para os URIs.
PODE definir filtros de intent de URI específicos como gerenciadores 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 DEVERÁ fornecer ao usuário substituições adequadas de padrão por URI no menu de configurações.
É OBRIGATÓRIO fornecer ao usuário controles de links do app por aplicativo em "Configurações" da seguinte forma:
- [C-0-6] O usuário PRECISA conseguir substituir de forma holística o comportamento padrão dos links de app para que um app seja: sempre aberto, sempre perguntado ou nunca aberto, o que deve se aplicar a todos os filtros de intent de URI candidatos igualmente.
- [C-0-7] O usuário PRECISA conseguir ver uma lista dos filtros de intent de URI candidato.
- A implementação do dispositivo PODE oferecer ao usuário a capacidade de substituir filtros de intent de URI candidatos específicos que foram verificados com êxito, com base em cada 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 candidato específicos se a implementação do dispositivo permitir que alguns filtros de intent de URI candidato passem na verificação enquanto outros podem falhar.

3.2.3.3. Namespaces de intents

[C-0-1] As implementações de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou 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 respeitem novos padrões de intent ou intent de transmissão usando uma ACTION, CATEGORY ou outra string de chave 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 de 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 sobre mudanças no ambiente de hardware ou software.

Implementações de dispositivos:

[C-0-1] DEVE transmitir as intents de transmissão pública listadas aqui em resposta a eventos apropriados do sistema, conforme descrito na documentação do SDK. Esse requisito não entra em conflito com a seção 3.5, já que 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 de hardware. Se o dispositivo for compatível com o hardware necessário, ele PRECISA transmitir as intents e fornecer o comportamento de acordo com a documentação do SDK.

3.2.3.5. Intents de aplicativos 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 fizer sentido, as implementações de dispositivos PRECISAM fornecer um menu de configurações semelhante e ser compatíveis 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] PRECISA respeitar a intent android.settings.HOME_SETTINGS para mostrar um menu padrão de configurações de apps na tela inicial.

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

[C-2-1] PRECISA fornecer um menu de configurações que chame a intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar uma caixa de diálogo e mudar o app de SMS padrão.
[C-2-2] PRECISA obedecer à intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar uma caixa de diálogo que permita ao usuário mudar o aplicativo Telefone padrão.
- PRECISA usar a interface do app Telefone padrão selecionado pelo usuário para chamadas recebidas e feitas, exceto para chamadas de emergência, que usam o app Telefone pré-instalado.
[C-2-3] PRECISA respeitar a intent android.telecom.action.CHANGE_PHONE_ACCOUNTS para oferecer 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 vai usar para fazer ligações. A implementação do AOSP atende a esse requisito ao incluir um menu "Opção de contas de chamada" no menu de configurações "Chamadas".
[C-2-4] PRECISA permitir android.telecom.CallRedirectionService para um app que tenha o papel android.app.role.CALL_REDIRECTION.
[C-2-5] PRECISA oferecer ao usuário a capacidade de escolher um app que tenha a função android.app.role.CALL_REDIRECTION.
[C-2-6] PRECISA obedecer às intents android.intent.action.SENDTO e android.intent.action.VIEW e fornecer uma atividade para enviar/mostrar mensagens SMS.
[C-SR-1] É ALTAMENTE RECOMENDADO honrar intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW e android.intent.action.DIAL com um aplicativo discador pré-carregado que pode processar esses intents e fornecer atendimento conforme descrito no SDK.

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

[C-3-1] DEVE obedecer à intent android.settings.NFC_PAYMENT_SETTINGS para mostrar um menu de configurações de app padrão para pagamento por aproximação.
[C-3-2] PRECISA obedecer à intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT para mostrar uma atividade que abre uma caixa de diálogo e pede ao usuário para mudar o serviço de emulação de cartão padrão para uma determinada categoria, conforme descrito no SDK.

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

[C-4-1] PRECISA obedecer a estas intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED e 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] PRECISA obedecer à 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] PRECISA obedecer à intent 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' e mostrar uma atividade do sistema que solicita o modo detectável.

Se as implementações de dispositivos forem compatíveis com o recurso Não perturbe, elas:

[C-6-1] É OBRIGATÓRIO 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 não perturbe.

Se as implementações de dispositivos 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 forem compatíveis com serviços de acessibilidade de terceiros, elas:

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

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

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

Se as implementações de dispositivos oferecem 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 e permita que os usuários adicionem ou removam aplicativos da lista de permissões.

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

[C-11-1] PRECISA ter uma atividade que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mas PODE implementá-la como uma operação nula.

Se as implementações de dispositivos declararem suporte à câmera via 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] DEVE respeitar a intenção android.app.action.ADD_DEVICE_ADMIN de invocar uma interface para orientar o usuário a adicionar o administrador do dispositivo ao sistema (ou permitir que ele rejeite).
[C-13-2] PRECISA obedecer às 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 atender a essas intents, conforme descrito aqui no SDK.

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

[C-14-1] É OBRIGATÓRIO 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 que permite ativar e desativar o preenchimento automático e mudar o serviço padrão para o usuário.

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

[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 qualquer app, incluindo os pré-instalados, acesse as estatísticas de uso, elas:

[C-15-1] AINDA PRECISA ter uma atividade que processe o padrão de intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mas PRECISA implementá-lo como uma operação nula, ou seja, ter um comportamento equivalente a quando o acesso do usuário é negado.

Se as implementações de dispositivos mostrarem links para as atividades especificadas por AutofillService_passwordsActivity em "Configurações" ou links para senhas de usuários 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 de dispositivos forem compatíveis com o VoiceInteractionService e tiverem mais de um aplicativo usando essa API instalado por vez, elas:

[C-18-1] PRECISA respeitar a intent android.settings.ACTION_VOICE_INPUT_SETTINGS para mostrar um menu de configurações padrão do app para entrada de texto por voz e assistência.

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

[C-SR-3] É ALTAMENTE RECOMENDADO que os intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA e android.speech.tts.engine.GET_SAMPLE_TEXT tenham uma atividade para fornecer atendimento a esses intents, conforme descrito aqui no SDK.

O Android inclui suporte para protetores de tela interativos, antes chamados de Dreams. Com os protetores de tela, os usuários podem interagir com aplicativos quando um dispositivo conectado a uma fonte de energia está inativo ou encaixado em uma base de mesa. Implementações de dispositivos:

DEVE incluir suporte para 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 de dispositivos informarem android.hardware.nfc.uicc ou android.hardware.nfc.ese, elas:

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

3.2.4. Atividades em telas secundárias/múltiplas

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

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

Se as implementações de dispositivos permitirem iniciar atividades do Android normais 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 a tela. Todos podem iniciar uma tela com a flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilidade da API nativa

A compatibilidade com código nativo é um desafio. Por isso, os implementadores de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO usar as implementações das bibliotecas listadas abaixo do Android Open Source Project upstream.

3.3.1. Interfaces binárias de aplicativos

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 depende muito da tecnologia do processador subjacente, o Android define várias interfaces binárias de aplicativo (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] PRECISA incluir suporte para código em execução 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, com o cabeçalho) e com o binário (para a ABI) de cada biblioteca obrigatória na lista abaixo.
[C-0-5] PRECISA informar com precisão a interface binária do aplicativo (ABI) nativa compatível com o 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írgula e ordenadas da mais para a menos preferida.
[C-0-6] É OBRIGATÓRIO informar, usando os parâmetros acima, um subconjunto da seguinte lista de ABIs e NÃO É PERMITIDO informar nenhuma ABI que não esteja na lista.
- armeabi (não é mais compatível como destino pelo NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64
[C-0-7] É OBRIGATÓRIO disponibilizar todas as seguintes bibliotecas, que fornecem APIs nativas, para apps que incluem código nativo:
- libaaudio.so (compatibilidade nativa de áudio AAudio)
- libamidi.so (suporte nativo a MIDI, 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 nativo)
- 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 para APIs nativas de mídia)
- libm (biblioteca de matemática)
- libneuralnetworks.so (API Neural Networks)
- libOpenMAXAL.so (suporte ao OpenMAX AL 1.0.1)
- libOpenSLES.so (suporte de áudio OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (compatibilidade mínima com 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] PRECISA listar outras bibliotecas não AOSP expostas diretamente a apps de terceiros em /vendor/etc/public.libraries.txt.
[C-0-10] NÃO PODE expor outras bibliotecas nativas, implementadas e fornecidas no AOSP como bibliotecas do sistema, a apps de terceiros direcionados ao nível 24 da API ou mais recente, já que elas sã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 (link em inglês), conforme definido no NDK, pela biblioteca libGLESv3.so. Embora todos os símbolos sejam obrigatórios, a seção 7.1.4.1 descreve em mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
[C-0-12] MUST export function symbols for the core Vulkan 1.1 function symbols, as well as the VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, and VK_KHR_get_physical_device_properties2 extensions through the libvulkan.so library. 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.
DEVE ser criado usando o código-fonte e os arquivos de cabeçalho disponíveis no Android Open Source Project upstream.

Observe que as versões futuras do Android podem introduzir suporte para ABIs adicionais.

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

Se as implementações de dispositivos informarem o suporte à ABI armeabi, elas:

[C-3-1] Também é necessário oferecer suporte a armeabi-v7a e informar esse suporte, já que armeabi é apenas para compatibilidade com versões anteriores de apps.

Se as implementações de dispositivos informarem a compatibilidade com a ABI armeabi-v7a, os apps que usam essa ABI:

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

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com WebView

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

[C-1-1] PRECISA informar android.software.webview.
[C-1-2] É OBRIGATÓRIO usar o build do projeto Chromium do Android Open Source Project upstream na ramificação Android 17 para a implementação da API android.webkit.WebView.
[C-1-3] A string do user agent informada pela WebView para apps destinados ao nível 35 do SDK e versões anteriores PRECISA estar no seguinte formato:

Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like 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 Android Open Source Project upstream.
- As implementações de dispositivos PODEM omitir "Mobile" na string do user agent.
O componente WebView DEVE incluir suporte para o maior número possível de recursos do HTML5 e, se for compatível com o recurso, DEVE estar em conformidade com a especificação do HTML5.
[C-1-4] PRECISA renderizar o conteúdo fornecido ou o conteúdo do URL remoto em um processo que seja diferente do aplicativo que cria a instância do WebView. Especificamente, o processo de renderização separado PRECISA ter privilégio menor, 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 mínimos necessários pelo Binder. A implementação do WebView no AOSP atende a esse requisito.

[C-1-5] A string do user agent padrão do sistema informada pela WebView para apps segmentados para o nível 36 do SDK e mais recentes PRECISA estar no seguinte formato:
```
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
```
- $(VERSION) PRECISA ser o valor estático 10.
- $(MODEL) PRECISA ser a letra estática K.
- $(CHROMIUM_MAJOR_VER) PRECISA ser a versão principal do Chromium no Android Open Source Project upstream.
- As implementações de dispositivos PODEM omitir "Mobile" na string do user agent.

Observe que, se as implementações de dispositivo forem de 32 bits ou declararem a flag de recurso android.hardware.ram.low, elas serão isentas de 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] PRECISA oferecer suporte a cada uma destas APIs associadas ao HTML5:
[C-1-2] PRECISA oferecer suporte à API webstorage HTML5/W3C e DEVE oferecer suporte à API IndexedDB HTML5/W3C. Observe que, como os órgãos de padrões de desenvolvimento da Web estão fazendo a transição para favorecer o IndexedDB em vez do webstorage, espera-se que o IndexedDB se torne um componente obrigatório em uma versão futura do Android.
PODE enviar uma string de user agent personalizada no aplicativo navegador independente.
DEVE implementar o suporte para o máximo possível de HTML5 no aplicativo navegador independente (seja com base no aplicativo 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] AINDA PRECISA oferecer suporte aos padrões de intents públicos, conforme descrito na seção 3.2.3.1.

3.5. Compatibilidade comportamental da API

Implementações de dispositivos:

[C-0-9] PRECISA 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 PODE implementar a abordagem de lista de permissões que garante a compatibilidade comportamental da API apenas para apps selecionados pelos implementadores de dispositivos.

Os comportamentos de cada um dos tipos de API (gerenciada, flexível, nativa e da Web) precisam ser consistentes com a implementação preferida do Android Open Source Project. 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 Service, Activity, 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 impostas aos aplicativos em segundo plano. Mais especificamente, para apps em segundo plano:
- [C-0-4] eles PRECISAM interromper a execução de callbacks registrados pelo app para receber saídas do GnssMeasurement e do GnssNavigationMessage.
- [C-0-5] eles PRECISAM limitar a taxa de frequência das atualizações fornecidas ao app pela classe da API LocationManager ou pelo método WifiManager.startScan().
- [C-0-6] Se o app for destinado à API de nível 25 ou mais recente, NÃO será permitido registrar 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, assim como se 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 lidar com uma tarefa visível ao 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 sete primeiros valores de matriz do método Security.getProviders(), na ordem e com os nomes fornecidos (conforme retornado por Provider.getName()) e classes, a menos que o app tenha modificado a lista usando insertProviderAt() ou removeProvider(). Os dispositivos PODEM retornar outros provedores depois da lista especificada 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 isso, 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 dispositivos implementarem um mecanismo reservado para restringir apps (por exemplo, mudando ou restringindo comportamentos de API descritos no SDK) e esse mecanismo for mais restritivo do que o intervalo de espera do app restrito, ele:

[C-1-1] PRECISA permitir que o usuário veja a lista de apps restritos.
[C-1-2] PRECISA oferecer ao usuário a possibilidade de ativar / desativar todas essas restrições de propriedade em cada app.
[C-1-3] NÃO pode aplicar automaticamente essas restrições proprietárias sem evidências de comportamento inadequado da integridade do sistema, mas PODE aplicar as restrições em apps ao detectar comportamento inadequado da integridade do sistema, como bloqueios de ativação presos, serviços de longa duração e outros critérios. Os critérios PODEM ser determinados pelos implementadores de dispositivos, mas PRECISAM estar relacionados ao impacto do app na integridade do sistema. Outros critérios que não estão puramente relacionados à 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 PODE aplicar automaticamente essas restrições reservadas para apps quando um usuário desativa as restrições de apps manualmente e PODE sugerir que o usuário aplique essas restrições reservadas.
[C-1-5] É OBRIGATÓRIO informar aos usuários se essas restrições de propriedade forem aplicadas a um app automaticamente. Essas informações precisam ser fornecidas no período de 24 horas antes da aplicação dessas restrições de propriedade.
[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 PODE restringir o aplicativo em primeiro plano principal 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 usar explicitamente o app, tornando-o o aplicativo em primeiro plano.
[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 ter um link nos documentos do SDK do Android e incluir:
- Condições de ativação 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 pedir uma isenção às restrições de propriedade, se ele oferecer suporte a essa isenção para apps que o usuário pode instalar.

Se um app for pré-instalado no dispositivo e nunca tiver sido usado explicitamente por um usuário por mais de 30 dias, as restrições [C-1-3] e [C-1-5] não serão aplicadas.

Se as implementações de dispositivos ampliarem as restrições de apps implementadas no AOSP, elas:

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

3.5.2. Hibernação de aplicativos

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

[C-1-1] PRECISA 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 para um usuário SÓ PODE ser aplicada quando houver evidências de que ele não usou o app por algum período. Recomendamos que essa duração seja de um mês ou mais. O uso PRECISA ser definido por interação do usuário explícita via API UsageStats#getLastTimeVisible() ou qualquer coisa que faça um app sair 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] SÓ pode aplicar restrições que afetam todos os usuários do dispositivo quando houver evidências de que o pacote não foi usado por NENHUM usuário por algum período. É 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 provedor 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 (veja abaixo) nestes namespaces de pacotes:

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

Ou seja, eles:

[C-0-1] NÃO PODE modificar as APIs expostas publicamente na plataforma Android mudando assinaturas de métodos ou classes ou removendo classes ou campos de classes.
[C-0-2] NÃO PODE adicionar elementos expostos publicamente (como classes ou interfaces, ou campos ou métodos a classes ou interfaces atuais) nem 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", conforme usado no código-fonte upstream do Android.

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

[C-0-3] NÃO PODE afetar o comportamento declarado e a assinatura da linguagem Java de qualquer API exposta publicamente.
[C-0-4] NÃO PODE ser anunciado nem exposto a desenvolvedores de outra forma.

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 de outra organização ou que se refira a ela. Por exemplo, os implementadores de dispositivos NÃO PODEM adicionar APIs ao com.google.* ou namespace 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 no uso da memória dessas APIs.

Os implementadores de dispositivos PODEM adicionar APIs personalizadas em linguagens nativas, 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 propuser melhorar um dos namespaces de pacote acima (por exemplo, adicionando uma nova funcionalidade útil a uma API existente ou uma nova API), ele DEVE 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.

Observe que as restrições acima correspondem às convenções padrão para nomear APIs na linguagem de programação Java. Esta seção apenas reforça essas convenções e as torna vinculativas ao incluí-las nesta Definição de compatibilidade.

3.7. Compatibilidade com o ambiente de execução

Implementações de dispositivos:

[C-0-1] PRECISA oferecer suporte ao formato completo Dalvik Executable (DEX) e à especificação e semântica de bytecode Dalvik.
[C-0-2] É OBRIGATÓRIO configurar os ambientes de execução do Dalvik para alocar memória de acordo com a plataforma Android upstream e conforme especificado na tabela a seguir. Consulte a seção 7.1.1 para ver as definições de tamanho e densidade da tela.
É RECOMENDADO 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.
É RECOMENDADO executar testes de fuzzing em vários modos de execução e arquiteturas de destino para garantir a estabilidade do tempo de execução. Consulte JFuzz e DexFuzz no site do Android Open Source Project.

Observe que 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)	32 MB
	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)	32 MB
	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)	128 MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256 MB
grande	120 dpi (ldpi)	32 MB
	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)	128 MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256 MB
	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. Tela de início (Launcher)

O Android inclui um aplicativo de acesso rápido (tela inicial) e suporte para aplicativos de terceiros que substituem 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, eles:

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

Se as implementações de dispositivos 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] PRECISA ter uma ação do usuário pedindo confirmação antes de adicionar um atalho solicitado por apps usando o método ShortcutManager.requestPinShortcut() da API.
[C-2-3] PRECISA oferecer suporte a atalhos fixados e atalhos dinâmicos e estáticos, conforme documentado na página Atalhos de apps.

Por outro lado, se as implementações de dispositivos não forem compatíveis com a fixação de atalhos no app, elas:

[C-3-1] MUST report false for 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 API.

Se as implementações de dispositivos incluírem um app de tela de início padrão que mostre selos para os ícones de apps, eles:

[C-5-1] PRECISA respeitar o método da API NotificationChannel.setShowBadge(). Em outras palavras, mostre uma sugestão visual associada ao ícone do app se o valor for definido como true e não mostre nenhum esquema de ícones de notificação do app quando todos os canais de notificação do app tiverem definido o valor como false.
PODE substituir os selos de ícones do app pelo esquema de selos proprietário quando aplicativos de terceiros indicam suporte ao esquema de selos proprietário usando APIs proprietárias, mas DEVE 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 de dispositivos forem compatíveis com ícones monocromáticos, eles:

[C-6-1] SÓ pode ser usado quando um usuário o ativa explicitamente (por exemplo, nas Configurações ou no menu de seleção de plano de fundo).

3.8.2. Widgets

O Android oferece suporte a widgets de apps de terceiros definindo um tipo de componente e uma API e um ciclo de vida correspondentes que permitem que os aplicativos exponham um "AppWidget" para o usuário final.

Se as implementações de dispositivos forem compatíveis com widgets de apps de terceiros, elas:

[C-1-1] PRECISA declarar suporte ao recurso da plataforma android.software.app_widgets.
[C-1-2] PRECISA incluir suporte integrado para AppWidgets e expor recursos de interface do usuário para adicionar, configurar, visualizar, remover, ver e redimensionar AppWidgets a menos que a segurança do usuário (como distração do motorista) seja uma preocupação.

~~[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 mais detalhes.~~

[C-1-4] PRECISA oferecer suporte a prévias de widgets geradas dinamicamente.
[C-1-5] DEVE ter capacidade de interação do usuário com a prévia, pedindo permissão antes de adicionar um widget solicitado por apps via AppWidgetManager.requestPinAppWidget().
[C-1-6] PRECISA oferecer suporte à fixação de widgets no app.
[C-1-7] MUST report true for AppWidgetManager.html.isRequestPinAppWidgetSupported().

PODE oferecer suporte a widgets de aplicativos na tela de bloqueio.

Se as implementações de dispositivos forem compatíveis com 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] PRECISA ter uma opção para o usuário confirmar antes de adicionar um atalho solicitado por apps usando o método da API AppWidgetManager.requestPinAppWidget().

3.8.3. Notificações

O Android inclui 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, aba de notificações, barra de sistema) do dispositivo.

3.8.3.1. Apresentação de notificações

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

[C-1-1] DEVE 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 DEVE implementar corretamente as APIs de vibração. Se uma implementação de dispositivo não tiver hardware, as APIs correspondentes precisarão ser implementadas como ambiente autônomo. Esse comportamento é detalhado na seção 7.
[C-1-2] DEVE 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 POSSA 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] PRECISA respeitar e implementar corretamente os comportamentos descritos para as APIs para atualizar, remover e agrupar notificações.
[C-1-4] PRECISA fornecer o comportamento completo da API NotificationChannel documentada no SDK.
[C-1-5] DEVE oferecer ao usuário uma opção para bloquear e modificar a notificação de um determinado app de terceiros em cada canal e nível de pacote do app.
[C-1-6] Também é necessário oferecer uma opção para o usuário mostrar os canais de notificação excluídos.
[C-1-7] DEVE renderizar corretamente todos os recursos (imagens, adesivos, ícones etc.) fornecidos por Notification.MessagingStyle junto com o texto da notificação sem interação adicional do usuário. Por exemplo, DEVE mostrar todos os recursos, incluindo ícones fornecidos por android.app.Person em uma conversa em grupo definida por setGroupConversation.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer ao usuário uma maneira de controlar as notificações expostas a apps que receberam a permissão de listener de notificação. A granularidade precisa ser tal que o usuário possa controlar para cada listener de notificação quais tipos de notificação são vinculados a ele. Os tipos precisam incluir notificações de "conversas", "alertas", "silenciosas" e "importantes em andamento".
[C-SR-2] É ALTAMENTE RECOMENDADO oferecer aos usuários uma opção para especificar apps que não devem notificar nenhum listener de notificação específico.
[C-SR-3] É ALTAMENTE RECOMENDADO mostrar automaticamente uma opção para o usuário bloquear a notificação de um determinado app de terceiros em cada canal e pacote de app depois que o usuário dispensa essa notificação várias vezes.
DEVE oferecer suporte a notificações avançadas.
DEVE apresentar algumas notificações de maior prioridade como notificações de alerta.
DEVE ter uma ação do usuário para adiar notificações.
O MAY gerencia apenas a visibilidade e o tempo em que 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 de Pessoas publicado.

Implementações de dispositivos:

[C-SR-4] É ALTAMENTE RECOMENDADO agrupar e mostrar conversation notifications antes das notificações que não são de conversa, exceto notificações de serviço em primeiro plano em andamento e notificações de importance:high.

Se as implementações de dispositivos forem compatíveis com conversation notifications e o app fornecer os dados necessários para bubbles, eles:

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

Se as implementações de dispositivos forem compatíveis com notificações avançadas, elas:

[C-2-1] É OBRIGATÓRIO usar os recursos exatos fornecidos pela classe da API Notification.Style e as subclasses dela para os elementos de recursos apresentados.
DEVE apresentar todos os elementos de recursos (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, independente da plataforma em que ele está. Se as implementações de dispositivos forem compatíveis com 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 da API Notification.Builder quando as notificações de alerta são apresentadas.
[C-3-2] PRECISA mostrar as ações fornecidas por Notification.Builder.addAction() junto 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 (depois de serem ativados explicitamente pelo usuário) recebam uma cópia de todas as notificações à medida que são postadas ou atualizadas.

Implementações de dispositivos:

[C-0-1] PRECISA atualizar corretamente e imediatamente as notificações por completo para todos os serviços de listener instalados e ativados pelo usuário, incluindo todos os metadados anexados ao objeto de notificação.
[C-0-2] PRECISA respeitar a chamada de API snoozeNotification() e dispensar a notificação, fazendo um callback após o período de adiamento definido na chamada de API.

Se as implementações de dispositivos tiverem uma opção para adiar notificações, elas:

[C-1-1] PRECISA refletir corretamente o status da notificação adiada usando as APIs padrão, como NotificationListenerService.getSnoozedNotifications().
[C-1-2] PRECISA disponibilizar essa ação 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. NP (Não perturbe) / Modo de prioridade

Se as implementações de dispositivos forem compatíveis com o recurso Não perturbe (também chamado de modo prioritário), elas:

[C-1-1] DEVE, quando a implementação do dispositivo fornecer um meio para o usuário conceder ou negar o acesso de apps de terceiros à configuração da política de não perturbe, mostrar Regras automáticas de não perturbe criadas por aplicativos junto com as regras criadas e predefinidas pelo usuário.
[C-1-3] PRECISA respeitar os valores de suppressedVisualEffects transmitidos com o NotificationManager.Policy e, se um app tiver definido alguma das flags SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, ele DEVE indicar ao usuário que os efeitos visuais estão desativados no menu de configurações do Não perturbe.

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

As informações sensíveis de notificação incluem conteúdo como senhas únicas, códigos de confirmação únicos e códigos semelhantes de autenticação ou redefinição 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] É OBRIGATÓRIO ocultar informações sensíveis de notificações antes de serem transmitidas para listeners de notificação, a menos que o serviço de listener seja um dos seguintes:
- Apps assinados pelo sistema com um uid < 10000
- IU do sistema
- Shell
- App complementar de dispositivo designado (definido por CompanionDeviceManager)
- Papel SYSTEM_AUTOMOTIVE_PROJECTION
- Papel SYSTEM_NOTIFICATION_INTELLIGENCE
- Função HOME

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

3.8.4. APIs de assistência

O Android inclui as APIs Assist para permitir que os aplicativos escolham quanta informação do contexto atual será compartilhada com o Google Assistente no dispositivo.

Se as implementações de dispositivos forem compatíveis com a ação Assistente, elas:

[C-2-1] PRECISA indicar claramente ao usuário final quando o contexto é compartilhado, de uma das seguintes formas:
- Cada vez que o app assistivo acessa o contexto, uma luz branca aparece nas bordas da tela que atendem ou excedem a duração e o brilho da implementação do Android Open Source Project.
- Para o app assistivo pré-instalado, ofereça uma affordance ao usuário a menos de duas navegações de distância do menu de configurações padrão do app de entrada de texto por voz e do app assistivo e compartilhe o contexto apenas quando o app assistivo for invocado explicitamente pelo usuário com uma hotword ou uma tecla de navegação de assistência.

[C-2-1] É OBRIGATÓRIO compartilhar o contexto com o app assistivo somente quando o app é invocado explicitamente pelo usuário usando a tecla de navegação de assistência, uma hotword ou outro ponto de entrada designado.

[C-2-2] A interação designada para iniciar o app assistivo, conforme descrito na seção 7.2.3, PRECISA iniciar o app assistivo 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 notificações temporárias

Os aplicativos podem usar a API Toast para mostrar strings curtas não modais ao usuário final que desaparecem após um breve 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 de dispositivos incluírem uma tela ou saída de vídeo, elas:

[C-1-1] DEVE fornecer uma ação do usuário para impedir que um app mostre janelas de alerta que usam o TYPE_APPLICATION_OVERLAY. A implementação do AOSP atende a esse requisito com controles na aba de notificações.
[C-1-2] PRECISA obedecer à API Toast e mostrar avisos de aplicativos aos usuários finais de maneira bem visível.

3.8.6. Temas

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

O Android inclui uma família de temas "Holo" e "Material" como um conjunto de estilos definidos para desenvolvedores de aplicativos usarem se quiserem corresponder à aparência do tema Holo conforme definido pelo SDK do Android.

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

[C-1-1] NÃO PODE alterar nenhum dos atributos do tema Holo expostos aos aplicativos.
[C-1-2] PRECISA oferecer suporte à família de temas "Material" e NÃO PODE alterar nenhum dos atributos do tema Material 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 compatíveis com Roboto ou oferecer uma opção para o usuário mudar a fonte usada na família "sans-serif" para Roboto versão 2.x para os idiomas compatíveis com Roboto.
[C-1-4] DEVE gerar paletas tonais 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] É OBRIGATÓRIO gerar paletas tonais 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 enviadas com android.theme.customization.system_palette (conforme documentado em Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).
[C-1-6] PRECISA ter um valor de croma CAM16 de 5 ou maior.
- DEVE ser derivado do plano de fundo via com.android.systemui.monet.ColorScheme#getSeedColors, que fornece várias cores de origem válidas para escolher uma.
- É RECOMENDADO 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 desenvolvedores de aplicativos usarem se quiserem corresponder à aparência do tema do dispositivo, conforme definido pelo implementador do dispositivo.

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

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

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

[C-2-1] É OBRIGATÓRIO usar branco 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 uma API e um ciclo de vida correspondentes que permitem que aplicativos exponham um ou mais papéis de parede animados para o usuário final. Os planos de fundo interativos são animações, padrões ou imagens semelhantes com recursos de entrada limitados que aparecem como plano de fundo, atrás de outros aplicativos.

O hardware é considerado capaz de executar planos de fundo interativos de maneira confiável se puder executar todos os planos de fundo interativos, sem limitações de funcionalidade, a uma taxa de frames razoável e sem efeitos adversos em outros aplicativos. Se as limitações no hardware fizerem com que os planos de fundo e/ou aplicativos falhem, apresentem mau funcionamento, consumam CPU ou bateria em excesso ou sejam executados com taxas de frame rate inaceitavelmente baixas, o hardware será considerado incapaz de executar o plano de fundo interativo. Por exemplo, alguns papéis de parede dinâmicos podem usar um contexto OpenGL 2.0 ou 3.x para renderizar o conteúdo. Os planos de fundo interativos não funcionam de maneira confiável em hardware que não é compatível com vários contextos do OpenGL porque o uso de um contexto do OpenGL por um plano de fundo interativo pode entrar em conflito com outros aplicativos que também usam um contexto do OpenGL.

As implementações de dispositivos capazes de executar planos de fundo interativos de forma 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] MUST report the platform feature flag android.software.live_wallpaper.

3.8.8. Troca de atividade

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 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 da função de itens recentes, conforme detalhado na seção 7.2.3, PODEM alterar a interface.

Se as implementações de dispositivos, incluindo a tecla de navegação da função de apps recentes, conforme detalhado na seção 7.2.3, alterarem a interface, elas:

[C-1-1] PRECISA oferecer suporte a até 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 uma ação de fechamento ("x"), mas PODE atrasar isso até que o usuário interaja com as telas.
DEVE implementar um atalho para mudar facilmente para a atividade anterior.
DEVE acionar a ação de troca rápida entre os dois apps usados mais recentemente quando a tecla de função de apps recentes for pressionada duas vezes.
DEVE acionar o modo de várias janelas em tela dividida, se compatível, quando a tecla de funções de apps recentes for pressionada e mantida pressionada.
PODE mostrar itens recentes afiliados como um grupo que se move junto.
[C-SR-1] É ALTAMENTE RECOMENDADO usar a interface do usuário Android upstream (ou uma interface semelhante baseada em miniaturas) para a tela de visão geral.

3.8.9. Gerenciamento de entradas

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

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

[C-1-1] PRECISA declarar o recurso da plataforma android.software.input_methods e oferecer suporte às APIs IME, conforme definido na documentação do SDK do Android.

3.8.10. Controle de mídia na tela de bloqueio

A API Remote Control Client foi descontinuada no Android 5.0 em favor do modelo de notificação de mídia que permite que aplicativos de mídia se integrem aos controles de reprodução mostrados na tela de bloqueio.

3.8.11. Protetores de tela (antes chamados de "Sonhos")

Consulte a seção 3.2.3.5 para ver as configurações de intenção de configurar protetores de tela.

3.8.12. Local

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

[C-1-2] PRECISA mostrar o status atual da localização no menu "Localização" das Configurações.
[C-1-3] NÃO PODE mostrar modos de localização no menu "Localização" 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 de dispositivos incluírem uma tela ou saída de vídeo, elas:

[C-1-1] PRECISA ser capaz de renderizar esses caracteres de emoji em glifo colorido.
[C-1-2] PRECISA incluir suporte para:
- Fonte Roboto 2 com diferentes pesos: 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 de latim, grego e cirílico, incluindo os intervalos A, B, C e D do latim estendido e todos os glifos no bloco de símbolos de moeda do Unicode 7.0.
[C-1-3] NÃO PODE remover nem modificar NotoColorEmoji.tff na imagem do sistema. (É aceitável adicionar uma nova fonte de emoji para substituir os emojis em NotoColorEmoji.tff)
PRECISA oferecer suporte ao tom de pele e aos emojis de família diversificada, conforme especificado no Relatório técnico do Unicode nº 51.

Se as implementações de dispositivos incluírem um IME, elas:

DEVE fornecer um método de entrada para o usuário desses caracteres de emoji.

O Android inclui suporte para renderizar fontes do Myanmar. Mianmar tem várias fontes não compatíveis com Unicode, conhecidas como "Zawgyi", para renderizar idiomas do país.

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

[C-2-1] DEVE renderizar texto com uma fonte compatível com Unicode por padrão. Uma fonte não compatível com Unicode NÃO DEVE ser definida como padrão, a menos que o usuário a escolha no seletor de idioma.
[C-2-2] PRECISA oferecer suporte a uma fonte Unicode e a uma fonte não compatível com Unicode se o dispositivo for compatível com uma fonte não compatível com Unicode. Uma fonte não compatível com Unicode NÃO PODE remover ou substituir a fonte Unicode.
[C-2-3] PRECISA renderizar texto com uma fonte não 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 ISO de idioma ou região (atribuído, não atribuído ou reservado) pode ser usado para se referir a uma fonte não compatível com Unicode para Myanmar. Os desenvolvedores de apps e autores de páginas da Web podem especificar my-Qaag como o código de idioma designado, assim como fariam com qualquer outro idioma.

3.8.14. Várias janelas

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

[C-1-1] PRECISA implementar esses modos de várias janelas de acordo com os comportamentos e APIs de aplicativos descritos na documentação de suporte ao modo de várias janelas do SDK do Android e atender aos seguintes requisitos:
[C-1-2] Requisito removido no Android 16.
[C-1-3] NÃO PODE oferecer tela dividida ou modo livre se a altura da tela for menor que 440 dp e a largura 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 que não sejam picture-in-picture.

[C-1-5] DEVE mostrar tarefas com a propriedade selfMovable em opacidade total, com uma decoração persistente distinguível (por exemplo, barra de legenda) e um método para fechar essas tarefas fora das decorações persistentes.

Implementações de dispositivos com tamanho de tela xlarge DEVEM oferecer suporte ao modo livre.

Se as implementações de dispositivos oferecerem suporte aos modos de várias janelas e de tela dividida, elas:

[C-2-2] PRECISA cortar a atividade ancorada de uma tela dividida com várias janelas, mas DEVE mostrar algum conteúdo dela se o app de tela inicial for a janela em foco.
[C-2-3] PRECISA respeitar os valores declarados de AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight do aplicativo de tela de início de terceiros e não substituir esses valores ao mostrar algum conteúdo da atividade ancorada.

Se as implementações de dispositivos oferecerem suporte aos modos de várias janelas e picture-in-picture de várias janelas, elas:

[C-3-1] DEVE iniciar atividades no modo picture-in-picture de várias janelas quando o app estiver:
- Segmentar o nível 26 da API ou mais recente e declarar android:supportsPictureInPicture
- Direcionado ao nível 25 da API ou versões anteriores e declara android:resizeableActivity e android:supportsPictureInPicture.
[C-3-2] PRECISA expor as ações na SystemUI conforme especificado pela atividade PIP atual usando a API setActions().
[C-3-3] PRECISA 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 na 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 DEVE estar disponível para a atividade em primeiro plano.
[C-3-5] PRECISA oferecer um affordance para o usuário bloquear a exibição de um app no modo PIP. A implementação do AOSP atende a esse requisito com controles na bandeja de notificações.
[C-3-6] É OBRIGATÓRIO alocar a seguinte largura e altura mínimas para a janela PIP quando um aplicativo não declara nenhum valor para AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight:
- Dispositivos com o Configuration.uiMode definido como algo 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.

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] PRECISA oferecer suporte ao modo de várias janelas.

Se as implementações de dispositivos forem compatíveis com o modo de várias janelas, elas:

[C-5-1] É OBRIGATÓRIO implementar a versão correta do nível da API Window Manager Extensions, conforme descrito em Extensões WindowManager.

3.8.15. Corte da tela

O Android é compatível com um corte da 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 tela curva nas bordas.

Se as implementações de dispositivos incluírem cortes da tela, elas:

[C-1-5] NÃO PODE ter cortes 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] PRECISA obedecer às flags de corte da tela definidas pelo app usando a API WindowManager.LayoutParams conforme descrito no SDK.
[C-1-4] PRECISA informar os valores corretos para todas as métricas de corte definidas na API DisplayCutout.

3.8.16. Controles do dispositivo

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

Consulte a seção 2_2_3 para ver 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 nenhuma conexão de rede sem uma ação explícita do usuário (por exemplo, pressionar um botão na sobreposição) ou 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 de dispositivos gerarem uma prévia visível para o usuário quando o conteúdo for copiado para a área de transferência de qualquer item ClipData em que ClipData.getDescription().getExtras() contenha android.content.extra.IS_SENSITIVE, elas:

[C-1-1] É OBRIGATÓRIO encobrir a prévia visível ao usuário

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

3.8.18. Botão de localização

O botão de localização é um elemento da interface do Android que os desenvolvedores de apps podem incorporar nos apps para receber uma concessão de permissão de localização precisa para a sessão desse app.

Implementações de dispositivos:

[C-0-1] NÃO é permitido adicionar, modificar nem remover opções de personalização fornecidas aos desenvolvedores de apps para o botão de localização.

3.9. Administração do dispositivo

O Android inclui recursos que permitem que os aplicativos controladores de política de dispositivo realizem funções de administração de dispositivos no nível do sistema, como aplicar políticas de senha ou fazer apagamento remoto, usando as APIs Device Policy Manager.

3.9.1. Provisionamento de dispositivos

3.9.1.1. Provisionamento do proprietário do dispositivo

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

[C-1-1] PRECISA oferecer suporte ao registro de um controlador de política de dispositivo (DPC) como um app proprietário do dispositivo conforme descrito abaixo:
- Quando a implementação do dispositivo não tem usuários nem dados do usuário configurados, ela:
  - [C-1-5] É OBRIGATÓRIO registrar o aplicativo DPC como o app proprietário do dispositivo ou permitir que o app DPC escolha se quer se tornar proprietário do dispositivo ou do perfil, se o dispositivo declarar suporte a comunicação a curta distância (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] PRECISA 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 ao app Proprietário do dispositivo se um proprietário for estabelecido durante o provisionamento, independente do método usado. O usuário não pode continuar no assistente de configuração até que o app 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 pode registrar mais nenhum aplicativo DPC como app proprietário do dispositivo.
[C-1-2] Requisito removido no Android 15.
[C-2-1] Requisito removido no Android 15.
[C-2-2] Requisito removido no Android 15.
[C-2-3] Requisito removido no Android 15.

3.9.1.2. Provisionamento de perfil gerenciado

Se as implementações de dispositivos declararem android.software.managed_users, elas:

[C-1-1] É OBRIGATÓRIO declarar android.software.device_admin e implementar as APIs permitindo que um aplicativo controlador de políticas de dispositivo (DPC) se torne o proprietário de um novo perfil gerenciado.
[C-1-2] Requisito removido no Android 16.
[C-1-3] DEVE fornecer as seguintes affordances do 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 ação do usuário (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 breve mensagem de explicação, conforme fornecida pelo administrador do dispositivo via setShortSupportMessage.
- O ícone do aplicativo DPC.
[C-1-4] PRECISA iniciar o manipulador da intent ACTION_PROVISIONING_SUCCESSFUL no perfil de trabalho se um proprietário do perfil for estabelecido quando o provisionamento for iniciado pela intent android.app.action.PROVISION_MANAGED_PROFILE e o DPC tiver implementado o manipulador.
[C-1-5] É OBRIGATÓRIO enviar a transmissão ACTION_PROFILE_PROVISIONING_COMPLETE para o DPC do perfil de trabalho quando o provisionamento é iniciado pelo intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] É OBRIGATÓRIO enviar o intent ACTION_GET_PROVISIONING_MODE depois que o provisionamento do proprietário do perfil for acionado para que o app DPC possa escolher se vai se tornar proprietário do dispositivo ou do perfil, exceto quando o provisionamento for acionado pelo intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] É OBRIGATÓRIO enviar a intent ACTION_ADMIN_POLICY_COMPLIANCE para o perfil de trabalho quando um proprietário do perfil é estabelecido durante o provisionamento, independente do método 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 Profile Owner seja concluído.
[C-1-8] É OBRIGATÓRIO enviar a transmissão ACTION_MANAGED_PROFILE_PROVISIONED para o DPC do perfil pessoal quando um proprietário do perfil é estabelecido, independente do método de provisionamento usado.

3.9.2. Suporte para perfil gerenciado

Se as implementações de dispositivos declararem android.software.managed_users, elas:

[C-1-1] PRECISA oferecer suporte a perfis gerenciados pelas APIs android.app.admin.DevicePolicyManager.
[C-1-2] PRECISA permitir a criação de apenas um perfil gerenciado.
[C-1-3] PRECISA usar um ícone de badge (semelhante ao crachá de trabalho upstream do AOSP) para representar os aplicativos e widgets gerenciados e outros elementos da interface com badge como "Recentes e notificações".
[C-1-4] DEVE 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] DEVE mostrar um aviso indicando que o usuário está no perfil gerenciado quando o dispositivo é ativado (ACTION_USER_PRESENT) e o aplicativo em primeiro plano está no perfil gerenciado.
[C-1-6] Quando um perfil gerenciado existir, É OBRIGATÓRIO mostrar uma sugestão visual no "Chooser" 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 Controlador de políticas do dispositivo.
[C-1-7] Quando um perfil gerenciado existir, É NECESSÁRIO expor as seguintes possibilidades de interação para o usuário principal e o perfil gerenciado:
- Contabilização separada para bateria, local, dados móveis e uso do armazenamento para o usuário principal e o perfil gerenciado.
- Gerenciamento independente de aplicativos de VPN instalados no usuário principal ou no perfil gerenciado.
- Gerenciamento independente de aplicativos instalados no usuário principal ou no perfil gerenciado.
- Gerenciamento independente de contas no usuário principal ou no perfil gerenciado.
[C-1-8] DEVE garantir que os aplicativos de discador, contatos e mensagens pré-instalados possam pesquisar e consultar informações de autor da chamada do perfil gerenciado (se houver um) junto com as do perfil principal, se o controlador de política de dispositivo permitir.
[C-1-9] PRECISA 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 usuário principal.
[C-1-10] É OBRIGATÓRIO garantir que os dados de captura de tela sejam salvos no armazenamento do perfil de trabalho quando uma captura de tela é feita com uma janela topActivity que tem foco (aquela com 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 PODE capturar nenhum outro conteúdo da tela (barra de sistema, notificações ou conteúdo de 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 de dispositivos declararem android.software.managed_users e android.software.secure_lock_screen, elas:

[C-2-1] DEVE oferecer suporte à capacidade de especificar uma tela de bloqueio separada que atenda aos seguintes requisitos para conceder acesso apenas a apps em execução em um perfil gerenciado.
- As implementações de dispositivos PRECISAM respeitar 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 de credenciais e gerenciamento do perfil principal, conforme documentado no site do Android Open Source Project.
- 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 interface do usuário durante a chamada, nas notificações de chamadas em andamento e perdidas, nos apps de contatos e mensagens, eles DEVEM ser identificados com o mesmo selo usado para indicar aplicativos do perfil gerenciado.

3.9.3. Suporte para usuários gerenciados

Se as implementações de dispositivos declararem android.software.managed_users, elas:

[C-1-1] DEVE fornecer um affordance para o usuário fazer logout do usuário atual e voltar ao usuário principal em uma sessão multiusuário quando isLogoutEnabled retornar true. O recurso do usuário PRECISA estar acessível na tela de bloqueio sem desbloquear o dispositivo.

Se as implementações de dispositivos declararem android.software.device_admin e oferecerem uma conveniência para o usuário no dispositivo para adicionar mais usuários secundários, elas:

[C-SR-1] É ALTAMENTE RECOMENDADO mostrar as mesmas declaraçõ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 de função para gerenciamento de políticas de dispositivos

Se as implementações de dispositivos declararem android.software.device_admin, 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 a função de gerenciamento de políticas do dispositivo PODE ser definido ao definir config_devicePolicyManagement como o nome do pacote. O nome do pacote PRECISA ser seguido por dois pontos (:) 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 dispositivos PRECISAM oferecer suporte ao provisionamento sem um aplicativo de detentor de função de gerenciamento de políticas de dispositivos (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 detentor da função de gerenciamento de políticas do dispositivo 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 de dispositivos declararem android.software.device_admin, elas:

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

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 fornece APIs de plataforma que permitem que implementações de serviços de acessibilidade recebam callbacks para eventos de usuário e do sistema e gerem mecanismos de feedback alternativos, como conversão de texto em voz, retorno tátil e navegação com trackball/botão direcional.

Se as implementações de dispositivos forem compatíveis com serviços de acessibilidade de terceiros, elas:

[C-1-1] PRECISA fornecer uma implementação da estrutura de acessibilidade do Android, conforme descrito na documentação do SDK das APIs de acessibilidade.
[C-1-2] PRECISA gerar eventos de acessibilidade e entregar o AccessibilityEvent adequado a todas as implementações AccessibilityService registradas, conforme documentado no SDK.
[C-1-4] PRECISA oferecer uma opção para o usuário controlar serviços de acessibilidade que declaram a flag AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Em implementações de dispositivos com uma barra de navegação do sistema, é RECOMENDÁVEL 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 de dispositivos incluírem serviços de acessibilidade pré-instalados, eles:

[C-2-1] É OBRIGATÓRIO implementar esses serviços de acessibilidade pré-instalados como apps compatíveis com inicialização direta quando o armazenamento de dados é criptografado com criptografia baseada em arquivos (FBE, na sigla em inglês).
DEVE fornecer um mecanismo no fluxo de configuração inicial para que os usuários ativem serviços de acessibilidade relevantes, além de opções para ajustar o tamanho da fonte, tamanho de exibição e gestos de ampliação.

3.11. Text-to-Speech

O Android inclui APIs que permitem que os aplicativos usem serviços de conversão de texto em voz (TTS, na sigla em inglês) e que os provedores de serviços ofereçam implementações de serviços de TTS.

Se as implementações de dispositivos que informam o recurso android.hardware.audio.output:

[C-1-1] PRECISA oferecer suporte às APIs do framework de TTS do Android.

Se as implementações de dispositivos forem compatíveis com a instalação de mecanismos de TTS de terceiros, elas:

[C-2-1] DEVE oferecer ao usuário a possibilidade de selecionar um mecanismo de TTS para uso no nível do sistema.

3.12. N/A

3.13. Configurações rápidas

O Android oferece um componente de interface do usuário 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 de dispositivos incluírem um componente de interface do usuário das Configurações rápidas e forem compatíveis com Configurações rápidas de terceiros, elas:

[C-1-1] DEVE permitir que o usuário adicione ou remova os blocos fornecidos pelas APIs quicksettings de um app de terceiros.
[C-1-2] NÃO PODE adicionar automaticamente um bloco de um app de terceiros diretamente às Configurações rápidas.
[C-1-3] PRECISA mostrar todos os blocos adicionados pelo usuário de apps de terceiros ao lado dos blocos de configurações rápidas fornecidos pelo sistema.

3.14. Interface de mídia

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

[C-1-2] PRECISA mostrar claramente ícones obtidos via getIconBitmap() ou getIconUri() e títulos obtidos via getTitle(), conforme descrito em MediaDescription. Podemos encurtar os títulos para obedecer às 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 exibir conteúdo fornecido por esse aplicativo.
[C-1-4] DEVE permitir que o usuário interaja com toda a hierarquia de MediaBrowser. PODE restringir o acesso a parte da hierarquia para obedecer a regulamentações 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] PRECISA considerar o toque duplo em KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent.

3.15. Instant Apps

Se as implementações de dispositivos forem compatíveis com apps instantâneos, elas PRECISAM atender aos seguintes requisitos:

[C-1-1] Os apps instantâneos SÓ PODEM receber permissões que tenham o android:protectionLevel definido como "instant".
[C-1-2] Os apps instantâneos NÃO PODEM interagir com apps instalados usando intentos implícitos 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 via 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 oferecer as seguintes opções de interação do usuário com apps instantâneos. O AOSP atende aos requisitos com a interface do sistema, as configurações e o launcher padrão. Implementações de dispositivos:
- [C-1-5] DEVE oferecer uma opção para o usuário ver e excluir os apps instantâneos armazenados em cache localmente para cada pacote do app individual.
- [C-1-6] PRECISA fornecer uma notificação persistente ao usuário que pode ser recolhida 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 um intent com a ação definida como Intent.ACTION_VIEW e com um esquema "http" ou "https", uma conveniência adicional para o usuário DEVE permitir que ele não inicie o app instantâneo e inicie o link associado com o navegador da Web configurado, se um navegador estiver disponível no dispositivo.
- [C-1-7] É OBRIGATÓRIO permitir que os apps instantâneos em execução sejam acessados na 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 processador de intents para as intents listadas no SDK aqui e tornar as intents visíveis para os apps instantâneos.

3.16. Pareamento de dispositivo complementar

O Android inclui suporte para pareamento de dispositivos complementares para gerenciar de forma mais eficaz a associação com dispositivos complementares e fornece a API CompanionDeviceManager para que os apps acessem esse recurso.

Se as implementações de dispositivos forem compatíveis com o recurso de pareamento de dispositivos complementares, elas:

[C-1-1] PRECISA declarar a flag de recurso FEATURE_COMPANION_DEVICE_SETUP.
[C-1-2] É OBRIGATÓRIO garantir que as APIs no pacote android.companion estejam totalmente implementadas.
[C-1-3] PRECISA oferecer recursos para que o usuário selecione/confirme a presença e o funcionamento de um dispositivo complementar, que PRECISA usar a mesma mensagem implementada no AOSP sem adição ou modificação.

3.17. Apps pesados

Se as implementações de dispositivos declararem o recurso FEATURE_CANT_SAVE_STATE, elas:

[C-1-1] SÓ PODE ter um app instalado que especifique cantSaveState em execução no sistema por vez. Se o usuário sair de um app sem sair explicitamente dele (por exemplo, pressionando "Home" ao sair de uma atividade ativa no sistema, em vez de pressionar "Voltar" sem atividades ativas restantes no sistema), as implementações de dispositivos PRECISAM priorizar esse app na RAM, assim como fazem com outras coisas que devem permanecer em execução, como serviços em primeiro plano. Enquanto um app desse tipo está em segundo plano, o sistema ainda pode aplicar recursos de gerenciamento de energia, como limitar o acesso à CPU e à rede.
[C-1-2] PRECISA fornecer uma ação na interface para escolher o app que não vai participar do mecanismo normal de salvar/restaurar estado quando o usuário iniciar um segundo app declarado com o atributo cantSaveState.
[C-1-3] NÃO PODE aplicar outras mudanças na política a apps que especificam cantSaveState, como mudar o desempenho da CPU ou a priorização do agendamento.

Se as implementações de dispositivos não declararem o recurso FEATURE_CANT_SAVE_STATE, elas:

[C-1-1] DEVE ignorar o atributo cantSaveState definido pelos apps e NÃO DEVE 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 também podem ficar armazenados apenas localmente no dispositivo. Os contatos armazenados apenas no dispositivo são chamados de contatos locais.

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

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

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

Implementações de dispositivos:

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

Se as implementações de dispositivos 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] Os contatos brutos inseridos por aplicativos de terceiros sem especificar uma conta precisam ser inseridos na conta de contato padrão do dispositivo. Se a conta de contato padrão for DEFAULT_ACCOUNT_STATE_LOCAL ou DEFAULT_ACCOUNT_STATE_NOT_SET, esses contatos brutos precisarão ser armazenados 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 remoção imediata dos contatos brutos (como se o parâmetro CALLER_IS_SYNCADAPTER estivesse definido como "true"), mesmo que o parâmetro CALLER_IS_SYNCADAPTER estivesse definido como "false" ou não especificado.

Contas de SIM: contas de contatos brutos espelhadas de um ou mais chips físicos inseridos no dispositivo e que não estão associadas a uma conta no AccountManager.

Implementações de dispositivos:

Se as implementações de dispositivos usarem contas de chip:

[C-1-6] As contas de chip PRECISAM ser retornadas por ContactsContract.SimContacts.getSimAccounts.

3.18.2. Seletor de contatos do sistema

O Android inclui suporte para um seletor de contatos do sistema que permite que os apps acessem informações de contato limitadas sem exigir permissões de acesso amplo.

Se as implementações de dispositivos forem compatíveis com os contatos do Android, elas:

[C-1-1] PRECISA implementar o seletor de contatos do sistema (com.android.contactspicker) para apps destinados ao nível 37 da API ou mais recente.
[C-1-2] PRECISA implementar a intent Intent.ACTION_PICK_CONTACTS.

3.19. Configurações de idioma

Implementações de dispositivos:

[C-0-1] NÃO PODE oferecer ao usuário a opção de selecionar tratamento de linguagem específico para gênero em idiomas que não oferecem suporte a traduções específicas para gênero. Consulte recursos gramaticais para mais informações.

3.20. Experiências baseadas no Google Assistente

O framework de desenvolvimento do Google Assistente para Android permite o controle por voz de apps Android. Com o Google Assistente, os usuários podem usar a voz para iniciar apps, realizar tarefas, acessar conteúdo e muito mais.

Para esta seção, consulte as seguintes classificações de implementações de dispositivos especializados:

Volume fixo:um dispositivo de volume fixo tem controles de volume, mas impede que os apps mudem o nível do stream de áudio usando métodos AudioManager padrão (por exemplo, carros com Android Automotive OS).
Volume máximo:um dispositivo de volume máximo é aquele cujo volume está bloqueado em um nível máximo e sem atenuação, e em que o controle de software é impedido (por exemplo, uma TV com alto-falantes externos).
Volume único:um dispositivo de volume único é aquele que mapeia todos os fluxos de áudio para um fluxo de volume único, resultando em ajustes de volume que afetam todos os fluxos de áudio de maneira uniforme (por exemplo, uma TV).

3.20.1. Requisitos do stream de áudio do Google Assistente

Um aplicativo com a permissão MANAGE_ASSISTANT_AUDIO:

[C-0-1] PRECISA ter permissão para mudar o volume do STREAM_ASSISTANT de maneira programática.

Se as implementações de dispositivos não declararem android.hardware.type.watch e não forem de volume fixo, único ou total, elas:

[C-1-1] PRECISA implementar STREAM_ASSISTANT como um stream de áudio desacoplado e NÃO PODE ter alias para outro stream.
[C-1-2] PRECISA garantir que a reprodução de áudio usando AudioAttributes com USAGE_ASSISTANT tenha o volume controlado por STREAM_ASSISTANT.
[C-1-3] DEVE garantir que, para um determinado fone de ouvido Bluetooth, o índice de volume STREAM_ASSISTANT permaneça o mesmo quando o fone de ouvido alternar entre os perfis de áudio A2DP e HFP.
[C-1-4] É OBRIGATÓRIO impedir que qualquer stream diferente de STREAM_ASSISTANT mude o volume de STREAM_ASSISTANT ou a atenuação aplicada à reprodução de USAGE_ASSISTANT enquanto o MODE_ASSISTANT_CONVERSATION estiver ativo.
[C-1-5] PRECISA mudar o volume do fluxo STREAM_ASSISTANT e nenhum outro volume de fluxo quando o volume é ajustado pelas teclas de volume do dispositivo ou periférico (como um fone de ouvido Bluetooth) e quando:
- MODE_ASSISTANT_CONVERSATION está ativo e
- Não há personalização específica do app nem reprodução remota ativa.
[C-1-6] PRECISA refletir qualquer mudança no volume do Google Assistente na interface do usuário.

3.21. Suporte a recursos de sincronização de dispositivos complementares

O Android inclui suporte para recursos de sincronização de dados em dispositivos complementares.

Se as implementações de dispositivos forem compatíveis com o recurso de sincronização do Não perturbe, elas:

[C-1-1] É OBRIGATÓRIO implementar a API ContextualModeManager#isModeSyncSupported.
[C-1-2] PRECISA sincronizar a configuração que indica que o modo Não perturbe está ativado pelo canal seguro CompanionDeviceManager usando um formato de dados compatível com a implementação padrão CompanionDeviceManagerService.
[C-1-3] É OBRIGATÓRIO ativar essa sincronização se ContextualModeManager#isModeSyncEnabled retornar true.

Se as implementações de dispositivos forem compatíveis com o recurso de sincronização do modo avião, elas:

[C-1-4] DEVE sincronizar a configuração que indica que o modo avião está ativado pelo canal seguro CompanionDeviceManager usando um formato de dados compatível com a implementação padrão CompanionDeviceManagerService.
[C-1-5] PRECISA ativar essa sincronização se Settings.Global.AIRPLANE_MODE_SYNC estiver ativado.

3.22. API ComputerControls

A API ComputerControls permite que agentes compatíveis realizem ações autônomas e não programadas em nome do usuário para concluir tarefas em um dispositivo Android.

[C-1-1] Se as implementações de dispositivos pré-carregarem a biblioteca de extensões com.android.extensions.computercontrol para oferecer suporte ao ComputerControl, elas:

É NECESSÁRIO ativar o android.software.activities_on_secondary_display.
PRECISA mostrar o recurso do sistema com.android.extensions.computercontrol como disponível.
É NECESSÁRIO ativar o VirtualDeviceManager.
PRECISA incluir com.android.extensions.computercontrol na lista retornada por PackageManager#getSharedLibraries().
É NECESSÁRIO pré-carregar o aplicativo da plataforma com.android.virtualdevicemanager (destino de build VirtualDeviceManager).

4. Compatibilidade de empacotamento de aplicativos

Implementações de dispositivos:

[C-0-1] PRECISA ser capaz de instalar e executar arquivos ".apk" do Android gerados pela ferramenta "aapt" incluída no SDK do Android oficial.
- Como o requisito acima pode ser difícil de atender, é 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] PRECISA oferecer suporte à verificação de arquivos ".apk" usando Esquema de assinatura de APK v3.2, 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 PODE estender os formatos .apk, manifesto do Android, bytecode Dalvik ou bytecode 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 PODE permitir que apps que não sejam o "instalador registrado" 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 fontes desconhecidas, a menos que o app que solicita a instalação atenda a todos os requisitos a seguir:
- Ele PRECISA declarar a permissão REQUEST_INSTALL_PACKAGES ou ter o android:targetSdkVersion definido como 24 ou menos.
- Ele PRECISA ter recebido permissão do usuário para instalar apps de fontes desconhecidas.
DEVE fornecer ao usuário uma opção para conceder/revogar a permissão de instalar apps de Fontes desconhecidas por aplicativo, mas PODE 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 não há essa opção.
[C-0-7] DEVE mostrar uma caixa de diálogo de aviso com a string de aviso fornecida pela API do sistema PackageManager.setHarmfulAppWarning 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 opção para o usuário escolher desinstalar ou iniciar um aplicativo na caixa de diálogo de aviso.
[C-0-8] É OBRIGATÓRIO implementar o suporte ao sistema de arquivos incremental, 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 multimídia

Implementações de dispositivos:

[C-0-1] PRECISA 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] PRECISA declarar e informar o suporte dos codificadores e decodificadores disponíveis para aplicativos de terceiros via 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 fluxos de bits gerados pelos codificadores e os perfis informados no CamcorderProfile.

Implementações de dispositivos:

DEVE buscar 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 uma vez processados.
- NÃO DEVE manter buffers decodificados por mais tempo do que o especificado pelo padrão (por exemplo, SPS).
- NÃO DEVE manter buffers codificados por mais tempo do que o exigido pela estrutura do GOP.

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

O Google e a Open Handset Alliance não garantem que esses codecs não violem patentes de terceiros. As pessoas que pretendem usar esse código-fonte em produtos de hardware ou software precisam saber que as implementações desse código, inclusive em software de código aberto ou shareware, podem exigir licenças de patente dos titulares 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 de dispositivos 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

[C-1-4] USAC MPEG-D com DRC MPEG-D (AAC de alta eficiência estendida)

Todos os codificadores de áudio precisam ser compatíveis com:

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

Ao codificar MPEG-D USAC com áudio MPEG-D DRC (AAC de alta eficiência estendida):

[C-3-2] Todos os fluxos de bits precisam conter os conjuntos de metadados em conformidade com o perfil de controle de intensidade sonora MPEG-D ou com o perfil de controle de faixa dinâmica MPEG-D, nível 1 ou superior, de acordo com a ISO/IEC 23003-4.

5.1.2. Decodificação de áudio

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

Se as implementações de dispositivos declararem suporte ao recurso android.hardware.audio.output, elas precisarão ser compatíveis com a decodificação dos seguintes formatos de áudio:

[C-1-1] Perfil AAC MPEG-4 (AAC LC)
[C-1-2] Perfil HE AAC MPEG-4 (AAC+)
[C-1-3] Perfil MPEG-4 HE AACv2 (AAC+ aprimorado)
[C-1-4] AAC ELD (AAC aprimorado com atraso baixo)
[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. Observação: esse requisito é apenas para decodificação, e um dispositivo pode reduzir a taxa de amostragem e fazer downmix durante a fase de reprodução.
[C-1-10] Opus
[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 faixa dinâmica ISO/IEC 23003-4)

Se as implementações de dispositivos forem compatíveis com a decodificação de buffers de entrada AAC de fluxos multicanal (ou seja, mais de dois canais) para PCM usando o decodificador de áudio AAC padrão na API android.media.MediaCodec, o seguinte DEVE ser compatível:

[C-2-1] A decodificação NÃO PODE ser feita 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 de faixa dinâmica precisam ser definidos em "Controle de faixa dinâmica (DRC)" na ISO/IEC 14496-3, e as chaves de android.media.MediaFormat DRC para configurar os comportamentos relacionados à faixa dinâmica 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 atendidos por todos os decodificadores de áudio AAC.

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

[C-3-1] Os metadados de intensidade sonora e DRC precisam ser interpretados e aplicados de acordo com o perfil de controle de faixa dinâmica do DRC MPEG-D nível 1.
[C-3-2] O decodificador PRECISA se comportar de acordo com a configuração definida 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 intensidade e intervalo dinâmico usando o perfil de controle de intervalo dinâmico ISO/IEC 23003-4.

Se a ISO/IEC 23003-4 for compatível 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 têm precedência.

Todos os decodificadores de áudio PRECISAM oferecer suporte à saída de:

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

Se as implementações de dispositivos forem compatíveis com a decodificação de buffers de entrada AAC de fluxos multicanal (ou seja, mais de dois canais) para PCM pelo decodificador de áudio AAC padrão na API android.media.MediaCodec, o seguinte DEVE ser compatível:

[C-7-1] PRECISA ser configurado pelo aplicativo usando a decodificação com a chave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar se o conteúdo é mixado para estéreo (ao usar um valor de 2) ou é gerado 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 quando alimentado com 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).

Todos os dispositivos portáteis ou tablets com efeito de espacialização e todos os dispositivos automotivos e de televisão:

[C-8-1] DEVE oferecer suporte à decodificação de IAMF v1.0 com fluxos de áudio codificados em AAC, FLAC, Opus ou PCM e DEVE apresentar um decodificador IAMF pela API android.media.MediaCodec.
[C-8-2] É OBRIGATÓRIO garantir que o decodificador IAMF respeite a máscara de canal usada para configurá-lo pela chave KEY_CHANNEL_MASK , usando constantes android.media.AudioFormat, como CHANNEL_OUT_5POINT1.
[C-8-3] É OBRIGATÓRIO garantir que o decodificador IAMF anuncie a máscara de canal ativa no formato de saída usando a chave KEY_CHANNEL_MASK e constantes android.media.AudioFormat, como CHANNEL_OUT_5POINT1.

Se as implementações de dispositivos forem compatíveis com decodificadores de áudio diferentes do AAC padrão e puderem gerar áudio multicanal (ou seja, mais de dois canais) quando recebem conteúdo multicanal compactado, 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 é mixado para estéreo (ao usar um valor de 2) ou é gerado 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 quando alimentado com 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 compatíveis
Lei μ e lei A do G.711	Compatibilidade com conteúdo mono/estéreo/5.1 com amostragem de 8 kHz	WAVE (.wav)
Perfil AAC MPEG-4 (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, somente 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)	Compatível com conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC MPEG-D USAC com MPEG-D DRC (AAC de alta eficiência estendida)	Decodificação:compatibilidade com conteúdo mono/estéreo com taxas de amostragem padrão de 7,35 a 48 kHz. Codificação: compatibilidade com conteúdo mono/estéreo com taxas de amostragem de 44,1 e 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, codec de banda larga multitaxa adaptável	3GPP (.3gp)
FLAC	Para codificador e decodificador: pelo menos os modos mono e estéreo precisam ser compatíveis. Taxas de amostragem de até 192 kHz PRECISAM ser compatíveis, e resoluções de 16 bits e 24 bits PRECISAM ser compatíveis. O processamento de dados de áudio de 24 bits 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. Compatibilidade com os 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 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)
PCM/WAVE	O codec PCM PRECISA oferecer suporte a PCM linear de 16 bits e ponto flutuante de 16 bits. O extrator WAVE precisa ser compatível com PCM linear de 16, 24 e 32 bits e ponto flutuante de 32 bits (taxas até o limite de hardware). As taxas de amostragem precisam ser compatíveis 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 de imagem a seguir:

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP
[C-0-4] AVIF
- Os dispositivos precisam ser compatíveis com BITRATE_MODE_CQ e o perfil de referência.

Se as implementações de dispositivos forem compatíveis com a codificação HEIC via android.media.MediaCodec para o tipo de mídia MIMETYPE_IMAGE_ANDROID_HEIC, elas:

[C-1-1] PRECISA fornecer um codec codificador HEVC acelerado por hardware que ofereça suporte ao modo de controle de taxa de bits BITRATE_MODE_CQ, perfil HEVCProfileMainStill e tamanho de frame de 512 x 512 pixels.

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 ser compatíveis com a 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 de dispositivos forem compatíveis com a decodificação de vídeo HEVC, elas:

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

Decodificadores de imagem que oferecem suporte a um formato de alta profundidade de bits (mais de 9 bits 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)	Perfil de referência de imagem, coleção de imagens e sequência de imagens	Contêiner HEIF (.avif)

Codificadores e decodificadores de imagens expostos pela API MediaCodec.

[C-1-1] PRECISA oferecer suporte ao formato de cor flexível YUV420 8:8:8 (COLOR_FormatYUV420Flexible) por CodecCapabilities.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao formato de cor RGB888 para o modo de entrada Surface.
[C-1-3] PRECISA ser compatível com pelo menos um formato de cor YUV420 8:8:8 planar ou semiplanar: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). É ALTAMENTE RECOMENDADO que ambos sejam compatíveis.

5.1.7. Codecs de vídeo

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

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

[C-1-1] Os codecs de vídeo precisam ser compatíveis com tamanhos de bytebuffer de saída e entrada que acomodem o maior frame compactado e não compactado possível, conforme determinado pelo padrão e pela configuração, mas sem alocação excessiva.
[C-1-2] Os codificadores e decodificadores de vídeo PRECISAM oferecer suporte a formatos de cores flexíveis YUV420 8:8:8 (COLOR_FormatYUV420Flexible) por meio de CodecCapabilities.
[C-1-3] Os codificadores e decodificadores de vídeo PRECISAM ser compatíveis com pelo menos um formato de cor YUV420 8:8:8 planar ou semiplanar: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). É ALTAMENTE RECOMENDADO que eles sejam compatíveis com os dois.
[C-SR-1] É ALTAMENTE RECOMENDADO que codificadores e decodificadores de vídeo sejam compatíveis com pelo menos um formato de cor YUV420 8:8:8 planar ou semiplanar otimizado para hardware (YV12, NV12, NV21 ou formato equivalente otimizado para fornecedor).
[C-1-5] Os decodificadores de vídeo que oferecem suporte a um formato de alta profundidade de bits (mais de 9 bits por canal) PRECISAM oferecer suporte à saída de um formato equivalente de 8 bits se solicitado pelo aplicativo. Isso PRECISA ser refletido com a compatibilidade de um formato de cor YUV420 8:8:8 via android.media.MediaCodecInfo.

Se as implementações de dispositivos anunciarem a compatibilidade com o perfil HDR usando Display.HdrCapabilities, elas:

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

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

[C-3-1] PRECISA oferecer suporte aos períodos de atualização no intervalo de 10 a 60 frames e operar com precisão dentro de 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] PRECISA usar por padrão o formato de cor otimizado para exibição de hardware se configurado usando a saída de superfície.
[C-4-2] PRECISA usar por padrão um formato de cor YUV420 8:8:8 otimizado para leitura da CPU se estiver configurado para não usar saída de superfície.

Para implementações de dispositivos que incluem um decodificador ou codificador de vídeo:

[C-5-1] Os decodificadores de vídeo que usam uma tecnologia de codificação de 2003 ou posterior (como AV1, AVC, HEVC, VP8, VP9 ou VVC) DEVEM:
- Ter um tamanho mínimo de 144 x 144 pixels e
- Anuncie esse suporte usando a API VideoCapabilities, como os métodos getSupportedWidths() e getSupportedHeightsFor().
[C-5-2] Os codificadores de vídeo que usam uma tecnologia de codificação de 2003 ou posterior (como AV1, AVC, HEVC, VP8, VP9 ou VVC) PRECISAM:
- Ofereça suporte à entrada do Surface no seguinte tamanho mínimo para cada codificador:
  - AVC: 160 x 160 px
  - VP8, HEVC, VP9 (se o codificador for fornecido): 160 x 160 pixels
  - AV1 (se o codificador for fornecido): 256 x 256 px
- PODEM produzir um fluxo de bits com um tamanho de frame maior que o mínimo, desde que codifiquem o tamanho adequado usando informações do retângulo de corte.

5.1.8. Lista de codecs de vídeo

Formato/Codec	Detalhes	Tipos de arquivo/formatos de contêiner compatíveis
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 detalhes na seção 5.3.	MPEG-4 (.mp4) Matroska (.mkv, somente decodificação)
MPEG-2	Perfil principal	MPEG2-TS (.ts, não pesquisável) MPEG-4 (.mp4, somente 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 detalhes na seção 5.3.	WebM (.webm) Matroska (.mkv)
AV1	Consulte a seção 5.2 e a seção 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 para OMX, uma API de aceleração multimídia multiplataforma, além do Codec 2.0, uma API de aceleração multimídia de baixa sobrecarga.

Se as implementações de dispositivos forem compatíveis com multimídia, elas:

[C-1-1] PRECISA oferecer suporte a codecs de mídia usando as APIs OMX ou Codec 2.0 (ou ambas) como no Android Open Source Project, sem desativar ou burlar as proteções de segurança. Isso não significa que todo codec PRECISA usar a API OMX ou Codec 2.0, apenas que o suporte para pelo menos uma dessas APIs PRECISA estar disponível, e o suporte para as APIs disponíveis PRECISA incluir as proteções de segurança presentes.
[C-SR-1] É ALTAMENTE RECOMENDADO incluir suporte para a API Codec 2.0.

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

[C-2-1] É NECESSÁRIO incluir o codec de software OMX correspondente do Android Open Source Project (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) compatível com o dispositivo.
[C-2-2] Codecs com nomes que começam com "OMX.google." precisa ser baseada no código-fonte do Android Open Source Project.
[C-SR-2] É FORTEMENTE RECOMENDADO que os codecs de software OMX sejam executados em um processo de codec que não tenha acesso a drivers de hardware além de mapeadores de memória.

Se as implementações de dispositivos forem compatíveis com a API Codec 2.0, elas:

[C-3-1] É NECESSÁRIO incluir o codec de software Codec 2.0 correspondente do Android Open Source Project (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) compatível com o dispositivo.
[C-3-2] DEVE hospedar os codecs de software Codec 2.0 no processo de codec de software, conforme fornecido no Android Open Source Project, para permitir a concessão de acesso mais restrita a codecs de software.
[C-3-3] Codecs com nomes que começam com "c2.android." precisa ser baseada no código-fonte do Android Open Source Project.

5.1.10. Caracterização de codec de mídia

Se as implementações de dispositivos forem compatíveis com codecs de mídia, elas:

[C-1-1] PRECISA retornar os 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." PRECISA usar as APIs OMX e ter nomes que estejam de acordo com as diretrizes de nomenclatura da IL do OMX.
[C-1-3] Codecs com nomes que começam com "c2." É OBRIGATÓRIO usar a API Codec 2.0 e ter nomes que estejam de acordo 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 acelerado por hardware.
[C-1-5] Codecs executados em um processo de codec (fornecedor ou sistema) que têm acesso a drivers de hardware diferentes de alocadores e mapeadores de memória NÃO DEVEM ser caracterizados como somente software.
[C-1-6] Os codecs que não estão presentes no Android Open Source Project ou que não são baseados no código-fonte desse projeto DEVEM ser caracterizados como fornecedores.
[C-1-7] Os codecs que usam aceleração de hardware PRECISAM ser caracterizados como acelerados por hardware.
[C-1-8] Os nomes de codecs NÃO PODEM ser enganosos. Por exemplo, codecs chamados "decoders" precisam oferecer suporte à decodificação, e aqueles chamados "encoders" precisam oferecer suporte à codificação. Os codecs com nomes que contêm formatos de mídia precisam ser compatíveis com esses formatos.

Se as implementações de dispositivos forem compatíveis com codecs de vídeo:

[C-2-1] Todos os codecs de vídeo PRECISAM publicar dados de taxa de frames alcançável para os seguintes tamanhos, se compatíveis com o codec:

	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 (outros)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (codificador MPEG4) 720 x 480 px (outros, AV1)	1408 x 1152 px (H263) 1280 x 720 px (outros, 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 sobre pontos de desempenho. Cada uma delas PRECISA listar todos os pontos de desempenho padrão compatíveis (listados na API PerformancePoint), a menos que sejam cobertos por outro ponto de desempenho padrão compatível.
Além disso, eles DEVEM publicar pontos de desempenho estendido se oferecerem suporte a desempenho de vídeo sustentado diferente de um dos padrões listados.

5.2. Codificação de vídeo

Se as implementações de dispositivos forem compatíveis com qualquer codificador de vídeo e o disponibilizarem para apps de terceiros, e definirem o
MediaFormat.KEY_BITRATE_MODE como BITRATE_MODE_VBR para que o codificador opere no modo de taxa de bits variável, então, desde que não afete o nível mínimo de qualidade, a taxa de bits codificada :

NÃO PODE ser, em uma janela deslizante, mais de 15% acima da taxa de bits entre intervalos intraquadro (I-frame).
NÃO PODE ser mais de 100% acima da taxa de bits em uma janela deslizante de 1 segundo.

Se as implementações de dispositivos forem compatíveis com qualquer codificador de vídeo e o disponibilizarem para apps de terceiros e definirem 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] é FORTEMENTE RECOMENDADO para não exceder em mais de 15% a taxa de bits desejada em uma janela deslizante de 1 segundo.

Se as implementações de dispositivos incluírem uma tela integrada com comprimento diagonal de pelo menos 2,5 polegadas ou incluírem uma porta de saída de vídeo ou declararem o suporte de uma câmera usando a flag de recurso android.hardware.camera.any, elas:

[C-1-1] PRECISA 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 forem compatíveis com qualquer um dos codificadores de vídeo H.264, VP8, VP9 ou HEVC e disponibilizarem esses recursos para aplicativos de terceiros, elas:

[C-2-1] DEVE 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 forem compatíveis com o codificador de vídeo MPEG-4 SP e o disponibilizarem para apps de terceiros, elas:

PRECISA oferecer suporte a taxas de bits configuráveis dinamicamente para o codificador compatível.

Se as implementações de dispositivos fornecerem codificadores de vídeo ou imagem acelerados por hardware e forem compatíveis com uma ou mais câmeras de hardware conectadas ou plugáveis expostas pelas APIs android.camera:

[C-4-1] todos os codificadores de vídeo e imagem acelerados por 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 de dispositivos oferecem codificação HDR, elas:

[C-SR-1] é FORTEMENTE RECOMENDADO para fornecer um plug-in para a API de transcodificação sem problemas para converter do formato HDR para SDR.

5.2.1. H.263

Se as implementações de dispositivos forem compatíveis com 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 perfil de referência nível 45. A resolução SQCIF é opcional.

5.2.2. H.264

Se as implementações de dispositivos forem compatíveis com o codec H.264, elas:

[C-1-1] PRECISA oferecer suporte ao nível 3 do perfil de referência. No entanto, o suporte para ASO (ordenação arbitrária de segmentos), FMO (ordenação flexível de macroblocos) e RS (segmentos redundantes) é OPCIONAL. Além disso, para manter a compatibilidade com outros dispositivos Android, é RECOMENDADO que ASO, FMO e RS não sejam usados para o perfil de referência por codificadores.
[C-1-2] MUST support the SD (Standard Definition) video encoding profiles in the following table.
PRECISA oferecer suporte ao nível 4 do perfil principal.
PRECISA 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 com resolução de 720p ou 1080p pelas APIs de mídia, elas:

[C-2-1] PRECISA 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 ser compatível com os perfis de codificação de vídeo SD.
PRECISA ser compatível com os seguintes perfis de codificação de vídeo em HD (alta definição).
[C-1-2] MUST support writing Matroska WebM files.
É RECOMENDADO fornecer um codec VP8 de hardware que atenda aos requisitos de codificação de hardware RTC do projeto WebM (em inglês) para garantir uma 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] PRECISA 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] PRECISA oferecer suporte ao perfil 0 nível 3.
[C-1-1] É obrigatório oferecer suporte à gravação de arquivos Matroska WebM.
[C-1-3] MUST generate CodecPrivate data.
DEVE oferecer suporte aos perfis de decodificação HD, conforme indicado na tabela a seguir.
[C-SR-1] são FORTEMENTE RECOMENDADOS para oferecer suporte aos perfis de decodificação 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	3.840 x 2.160 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 de dispositivos afirmarem oferecer suporte ao perfil 2 ou 3 pelas APIs de mídia:

O suporte para o formato de 12 bits é OPCIONAL.

5.2.5. H.265

Se as implementações de dispositivos forem compatíveis com o codec H.265, elas:

[C-1-1] PRECISA oferecer suporte ao nível 3 do perfil principal com resolução de até 512 x 512.
[C-SR-1] são FORTEMENTE RECOMENDADOS para oferecer suporte ao perfil SD de 720 x 480 e aos perfis de codificação 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	3.840 x 2.160 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 de dispositivos forem compatíveis com o codec AV1, elas:

[C-1-1] PRECISA oferecer suporte ao perfil principal, incluindo conteúdo de 8 e 10 bits.
[C-1-2] DEVE publicar dados de desempenho, ou seja, gerar relatórios de dados de desempenho usando as APIs getSupportedFrameRatesFor() ou getSupportedPerformancePoints() para resoluções compatíveis na tabela abaixo.
[C-1-3] PRECISA aceitar metadados HDR e gerar o bitstream

Se o codificador AV1 tiver aceleração de hardware, ele:

[C-2-1] PRECISA oferecer suporte a até e incluindo o perfil de codificação HD1080p 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	3.840 x 2.160 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 forem compatíveis com codecs VP8, VP9, H.264, H.265 ou AV1, elas:

[C-1-1] PRECISA ser compatível com a resolução dinâmica de vídeo e a alternância de frame rate por meio das APIs padrão do Android no mesmo fluxo para todos os codecs VP8, VP9, H.264, H.265 e AV1 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 forem compatíveis com decodificadores MPEG-2, elas:

[C-1-1] PRECISA ser compatível com o perfil principal de alto nível.

5.3.2. H.263

Se as implementações de dispositivos forem compatíveis com decodificadores H.263, elas:

[C-1-1] PRECISA oferecer suporte ao perfil de referência nível 30 (resoluções CIF, QCIF e SQCIF a 30 fps 384 kbps) e nível 45 (resoluções QCIF e SQCIF a 30 fps 128 kbps).

5.3.3. MPEG-4

Se as implementações de dispositivos tiverem decodificadores MPEG-4, elas:

[C-1-1] PRECISA oferecer suporte ao Simple Profile Level 3.

5.3.4. H.264

Se as implementações de dispositivos forem compatíveis com decodificadores H.264, elas:

[C-1-1] PRECISA oferecer suporte ao nível 3.1 do perfil principal e ao perfil de referência. O suporte para ASO (ordenação arbitrária de segmentos), FMO (ordenação flexível de macroblocos) e RS (segmentos 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 nível 3.1 (incluindo 720p30).
PRECISA ser capaz de decodificar vídeos com os perfis HD (alta definição), 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] PRECISA oferecer suporte aos perfis de decodificação de vídeo HD 720p na tabela a seguir.
[C-2-2] PRECISA 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 fps (60 fps^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 forem compatíveis com o codec H.265, elas:

[C-1-1] PRECISA oferecer suporte ao nível 3 do perfil principal e aos perfis de decodificação de vídeo SD, conforme indicado na tabela a seguir.
DEVE oferecer suporte aos perfis de decodificação HD, conforme indicado na tabela a seguir.
[C-1-2] PRECISA oferecer suporte aos perfis de decodificação HD, conforme indicado na tabela a seguir, 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 de perfis 720, 1080 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	3.840 x 2.160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30/60 QPS (60 QPS^{TV com decodificação 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 de dispositivos afirmarem oferecer suporte a um perfil HDR pelas APIs Media:

[C-3-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR obrigatórios do aplicativo, além de oferecer suporte à extração e saída dos metadados HDR obrigatórios do fluxo de bits e/ou contêiner.
[C-3-2] As implementações de dispositivos PRECISAM exibir corretamente o conteúdo HDR 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] PRECISA oferecer suporte aos perfis de decodificação SD na tabela a seguir.
Use um codec VP8 de hardware que atenda aos requisitos.
PRECISA oferecer suporte aos perfis de decodificação 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 ser compatíveis com 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 fps (60 fps^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 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] PRECISA oferecer suporte aos perfis de decodificação 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 uma das decodificações VP9 ou H.265 dos perfis 720, 1080 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	3.840 x 2.160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps (60 fps^{Televisão 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 de dispositivos afirmarem oferecer suporte a VP9Profile2 ou VP9Profile3 pelas APIs de mídia 'CodecProfileLevel':

O suporte para o formato de 12 bits é OPCIONAL.

Se as implementações de dispositivos afirmarem oferecer 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 obrigató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 exibir corretamente o conteúdo HDR 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] PRECISA fornecer um extrator com tecnologia Dolby Vision.
[C-1-2] DEVE exibir corretamente o conteúdo do Dolby Vision na tela do dispositivo ou em uma tela externa conectada por uma porta de saída de vídeo padrão (como HDMI).
[C-1-3] PRECISA 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 forem compatíveis com o codec AV1 e o disponibilizarem para aplicativos de terceiros, elas:

[C-1-1] PRECISA oferecer suporte ao perfil principal, incluindo conteúdo de 8 e 10 bits.

Se as implementações de dispositivos oferecerem suporte ao codec AV1 com um decodificador acelerado por hardware, elas:

[C-2-1] DEVE ser capaz de decodificar pelo menos perfis de decodificação de vídeo HD 720p da tabela abaixo quando a altura informada pelo método Display.getSupportedModes() for igual ou maior que 720p.
[C-2-2] DEVE ser capaz de 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	3.840 x 2.160 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 de dispositivos forem compatíveis com o perfil HDR pelas APIs de mídia, elas:

[C-3-1] DEVE oferecer suporte à extração e saída de metadados HDR do bitstream e/ou contêiner.
[C-3-2] PRECISA exibir corretamente o conteúdo HDR 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 estejam listados como SHOULD desde o Android 4.3, a Definição de compatibilidade para versões futuras planeja mudar isso para MUST. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos listados como "SHOULD". Caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

5.4.1. Captura de áudio bruto e informações do microfone

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

[C-1-1] DEVE permitir a captura de conteúdo de áudio bruto para qualquer fluxo de entrada AudioRecord ou AAudio 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: tantos canais quanto o número de microfones no dispositivo
[C-1-2] PRECISA capturar nas taxas de amostragem acima sem upsampling.
[C-1-3] É OBRIGATÓRIO incluir um filtro anti-aliasing adequado quando as taxas de amostragem acima forem capturadas com subamostragem.
DEVE permitir a captura de rádio AM e conteúdo de áudio bruto com qualidade de DVD, o que significa as seguintes características:
- Formato: PCM linear, 16 bits
- Taxas de amostragem: 22050, 48000 Hz
- Canais: estéreo
[C-1-4] PRECISA respeitar 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 rádio AM e captura de conteúdo de áudio bruto com qualidade de DVD, elas:
[C-2-1] É OBRIGATÓRIO capturar sem upsampling em qualquer proporção maior que 16000:22050 ou 44100:48000.
[C-2-2] PRECISA incluir um filtro anti-aliasing adequado para qualquer upsampling ou downsampling.

5.4.2. Captura para reconhecimento de voz

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

[C-1-1] PRECISA capturar a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION em uma das taxas de amostragem, 44.100 e 48.000.
[C-1-2] POR PADRÃO, é necessário desativar qualquer processamento de áudio com redução de ruído ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
[C-1-3] Por padrão, é necessário desativar qualquer controle automático de ganho ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
DEVE apresentar características de amplitude versus frequência aproximadamente estáveis na faixa de frequência média: especificamente ±3 dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
[C-SR-1] é FORTEMENTE RECOMENDADO para exibir níveis de amplitude na faixa de baixa frequência, especificamente de ±20 dB de 30 Hz a 100 Hz em comparação com a faixa de frequência média para todos os microfones usados para gravar a fonte de áudio de reconhecimento de voz.
[C-SR-2] é FORTEMENTE RECOMENDADO para exibir níveis de amplitude na faixa de alta frequência: especificamente de ±30 dB de 4.000 Hz a 22 KHz em comparação com a faixa de frequência média para todos os microfones usados para gravar a fonte de áudio de reconhecimento de voz.
É RECOMENDADO definir a sensibilidade de entrada de áudio para que uma fonte de tom senoidal de 1.000 Hz reproduzida a 90 dB de nível de pressão sonora (SPL, na sigla em inglês), medida ao lado do microfone, produza uma resposta ideal de RMS 2.500 em um intervalo de 1.770 e 3.530 para amostras de 16 bits (ou -22,35 dB ±3 dB em escala completa para amostras de ponto flutuante/precisão dupla) para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
DEVE gravar o stream de áudio de reconhecimento de voz para que os níveis de amplitude de PCM acompanhem linearmente as mudanças de SPL de entrada em pelo menos um intervalo de 30 dB, de -18 dB a +12 dB re 90 dB SPL no microfone.
DEVE gravar o fluxo de áudio de reconhecimento de voz com distorção harmônica total (THD) menor que 1% para 1 kHz em um nível de entrada de 90 dB SPL no microfone.

Se as implementações de dispositivos declararem android.hardware.microphone e tecnologias de supressão (redução) de ruído ajustadas para reconhecimento de fala, elas:

[C-2-1] PRECISA permitir que esse efeito de áudio seja controlado com a API android.media.audiofx.NoiseSuppressor.
[C-2-2] PRECISA identificar exclusivamente cada implementação de tecnologia de supressão de ruído usando o 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 de dispositivos declararem android.hardware.audio.output e android.hardware.microphone, elas:

[C-1-1] É OBRIGATÓRIO implementar corretamente a fonte de áudio REMOTE_SUBMIX para que, quando um aplicativo usar a API android.media.AudioRecord para gravar dessa fonte de áudio, ele capture uma combinação de todos os fluxos de áudio, exceto os seguintes:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. Cancelador de eco acústico

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

DEVE implementar uma tecnologia de cancelamento de eco acústico (AEC, na sigla em inglês) ajustada para comunicação de voz e aplicada ao caminho de captura ao capturar usando AudioSource.VOICE_COMMUNICATION.

Se as implementações de dispositivos fornecerem um cancelador de eco acústico inserido no caminho de áudio de captura quando AudioSource.VOICE_COMMUNICATION for selecionado, elas:

[C-SR-1] [C-1-1] são FORTEMENTE RECOMENDADOS DEVEM declarar isso usando o método da API AcousticEchoCanceler AcousticEchoCanceler.isAvailable() retornando true.

[C-1-2] PRECISA refletir a ativação do AEC no caminho de áudio pelo método da API AcousticEchoCanceler AcousticEchoCanceler.getEnabled(), que precisa retornar true quando ativo e false quando inativo.

[C-SR-2] [C-SR-1] são FORTEMENTE RECOMENDADOS para permitir que esse efeito de áudio seja controlado com a API AcousticEchoCanceler.
[C-SR-3] [C-SR-2] são FORTEMENTE RECOMENDADOS para identificar de forma exclusiva cada implementação da tecnologia AEC usando o campo AudioEffect.Descriptor.uuid.

5.4.5. Captura simultânea

Se as implementações de dispositivos declararem android.hardware.microphone, elas DEVERÃO implementar a captura simultânea conforme descrito neste documento. Especificamente:

[C-1-1] PRECISA permitir o acesso simultâneo ao microfone por um serviço de acessibilidade que captura com AudioSource.VOICE_RECOGNITION e pelo menos um aplicativo que captura com qualquer AudioSource.
[C-1-2] DEVE permitir o acesso simultâneo ao microfone por um aplicativo pré-instalado que tenha uma função do Google Assistente e pelo menos um aplicativo capturando com qualquer AudioSource, exceto AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
[C-1-3] PRECISA silenciar a captura de áudio de qualquer outro aplicativo, exceto um serviço de acessibilidade, enquanto um aplicativo estiver 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 for um app privilegiado (pré-instalado) com permissão CAPTURE_AUDIO_OUTPUT.
[C-1-4] Se dois ou mais aplicativos estiverem capturando simultaneamente e nenhum deles tiver uma interface na parte de cima, o que iniciou 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 de dispositivos declararem android.hardware.audio.output, elas:

[C-1-1] DEVE 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 multicanal válidas com até 8 canais
- Taxas de amostragem (em Hz):
  - 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 nas configurações de canal listadas acima
  - 96.000 em mono e estéreo

5.5.2. Efeitos de áudio

O Android oferece uma API para efeitos de áudio para implementações de dispositivos.

Se as implementações de dispositivos 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 AudioEffect Equalizer e LoudnessEnhancer.
[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 EFFECT_TYPE_DYNAMICS_PROCESSING controlável pela subclasse AudioEffect DynamicsProcessing.
[C-1-4] DEVE oferecer suporte a efeitos de áudio com entrada e saída de ponto flutuante quando os resultados do efeito são retornados ao pipeline de áudio do framework. Isso se refere a efeitos típicos de inserção ou 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 pós-processamento ou efeitos descarregados.
[C-1-5] PRECISA garantir que os efeitos de áudio sejam compatíveis com 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 da estrutura. Isso se refere a efeitos típicos de inserção ou auxiliares, mas exclui efeitos especiais, como downmix, upmix ou espacialização, que mudam a contagem de canais. O comportamento equivalente é recomendado quando os efeitos não são visíveis pelo canal de áudio do framework, como pós-processamento ou efeitos descarregados.
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] SÃO FORTEMENTE RECOMENDADOS para oferecer suporte a efeitos em usar pontos flutuantes e multicanal.

5.5.3. Volume da saída de áudio

Implementações de dispositivos automotivos:

DEVE permitir o ajuste do volume do áudio separadamente para cada stream de áudio usando o tipo de conteúdo ou o uso conforme definido por AudioAttributes e o uso de áudio do carro conforme definido publicamente em android.car.CarAudioManager.

5.5.4. Descarregamento de áudio

Se as implementações de dispositivos forem compatíveis com reprodução de descarga de áudio, elas:

[C-SR-1] É ALTAMENTE RECOMENDADO cortar o conteúdo de áudio sem intervalos reproduzido entre dois clipes com o mesmo formato quando especificado pela API sem intervalos do AudioTrack e pelo contêiner de mídia do MediaPlayer.
[C-SR-2] É ALTAMENTE RECOMENDADO implementar a reprodução de descarga para formatos AAC, MP3, OPUS e PCM.

Se as implementações de dispositivos declararem suporte para o descarregamento de MMAP PCM (declarado por uma porta de mixagem com flags que contêm AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD e AUDIO_OUTPUT_FLAG_MMAP_NOIRQ), elas:

[C-1-1] PRECISA oferecer suporte a pelo menos AUDIO_FORMAT_PCM_16_BIT, a 44,1 kHz e 48 kHz para estéreo e mono.
[C-1-2] PRECISA ter um tamanho de buffer capaz de armazenar um mínimo de 5 segundos de áudio em PCM estéreo de 48 kHz e 16 bits por amostra.

5.5.5. Parâmetros de reprodução

Se as implementações de dispositivos forem compatíveis com a API PlaybackParams, os parâmetros de reprodução:

[C-1-1] PRECISA oferecer suporte a velocidades entre 0,5 e 2,0 com uma taxa de 1,0.

5.6. Latência de áudio

A latência de áudio é o atraso de tempo quando um sinal de áudio passa por um sistema. Muitas classes de aplicativos dependem de latências curtas para alcançar 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 fluxo 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 ficou 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 começa a tocar á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 um sinal entra no dispositivo por uma porta e o momento em que um aplicativo lê o frame correspondente de dados codificados em PCM.
entrada perdida. A parte inicial de um indicador de entrada que não pode ser usada ou está indisponível.
latência de entrada fria. O tempo entre o início da transmissão e o recebimento do primeiro frame válido, quando o sistema de entrada de áudio ficou inativo e desligado antes da solicitação.
latência de entrada contínua. A latência de entrada para frames subsequentes enquanto o dispositivo captura á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 que o app processe o sinal e mitigue a diferença de fase entre os fluxos de entrada e saída.
API de fila do buffer PCM do OpenSL ES. O conjunto de APIs OpenSL ES relacionadas a PCM no Android NDK.
API de áudio nativa AAudio. O conjunto de APIs AAudio no Android NDK.
Timestamp. Um par que consiste em uma posição de frame relativa em um fluxo 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 um valor de amostra incorreto no sinal de áudio, geralmente causado por um buffer underrun para saída, estouro de buffer 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 para um conjunto de valores.
A latência de toque para tom (TTL), medida pelo CTS Verifier, é o tempo entre o toque na tela e a audição de um tom gerado como resultado desse toque no alto-falante. Essa média é calculada com base em cinco medições usando a API de áudio nativa AAudio para saída.
Latência de ida e volta (RTL), medida pelo CTS Verifier, é a latência média contínua em cinco medições, medida em um caminho de loopback que envia a saída de volta para a entrada, usando a API nativa de áudio 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 loopback ou uma interface de áudio USB e cabos 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 desempenho de mídia.
Latência de rastreamento da cabeça. O tempo que leva desde o movimento da cabeça capturado pela unidade de medição inercial (IMU) até a detecção pelos transdutores dos fones de ouvido da mudança no som causada por esse movimento.

Implementações de dispositivos:

[C-0-1] DEVE garantir que, quando um aplicativo chamar android.media.AudioManager.setCommunicationDevice() com um device compatível (como fones de ouvido com fio, alto-falantes integrados ou fones de ouvido, ou fones de ouvido USB), o callback android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() será invocado com esse dispositivo de áudio em até 1.500 ms da chamada setCommunicationDevice() retornando true.

Se as implementações de dispositivos declararem android.hardware.audio.output, elas PRECISAM atender ou exceder os seguintes requisitos:

[C-1-1] Requisito removido no Android 15.
[C-1-2] Latência de saída a frio de 500 milissegundos ou menos.
[C-1-3] Abrir um fluxo de saída usando AAudioStreamBuilder_openStream() DEVE levar menos de 1.000 milissegundos.
[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 ms da latência de ida e volta medida para AAUDIO_PERFORMANCE_MODE_NONE e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY em alto-falantes, fones de ouvido com fio e sem fio.
[C-SR-1] Requisito removido no Android 15.
[C-SR-2] Requisito removido no Android 15.
[C-SR-4] Requisito removido no Android 15.
[C-SR-5] Requisito removido no Android 15.
[C-SR-6] Requisito removido no Android 15.
[C-SR-7] Requisito removido no Android 15.
[C-2-1] Requisito removido no Android 15.

Se as implementações de dispositivos incluírem android.hardware.microphone, elas PRECISAM atender a estes requisitos de áudio de entrada:

[C-3-1] Requisito removido no Android 15.
[C-3-2] Latência de entrada a frio de 500 milissegundos ou menos.
[C-3-3] A abertura de um fluxo de entrada usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.
[C-SR-8] Requisito removido no Android 15.
[C-SR-11] Requisito removido no Android 15.
[C-SR-12] Requisito removido no 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.

Dispositivo e declarações	RTL (ms)	MAD (ms)	Caminhos de loopback
Filmagem manual	200	25	alto-falante/microfone, analógico de 3,5 mm (se compatível), USB (se compatível)
MPC_C (17) e versões mais recentes	65	10	todos os caminhos de dados compatíveis
>= MPC_T (13) até MPC_B (16)	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 compatível)
FEATURE_AUDIO_PRO	25	5	USB (se o analógico não for compatível)

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.

Dispositivo e declarações	TTL (ms)
Filmagem manual	250
MPC_C (17) e versões mais recentes	65
>= MPC_T (13) até MPC_B (16)	80
MPC_S (12)	100
FEATURE_AUDIO_PRO	80

Se as implementações de dispositivos incluírem suporte para spatial audio com rastreamento da cabeça e declararem a flag PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, elas:

[C-4-1] DEVE apresentar uma latência máxima de rastreamento da cabeça para atualização de áudio de 300 ms.

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 suportar, a implementação do dispositivo:

[C-1-1] Precisa oferecer suporte a esse codec ou contêiner por HTTP e HTTPS.
[C-1-2] PRECISA oferecer suporte aos formatos de segmento de mídia correspondentes, conforme mostrado na tabela abaixo, usando o protocolo de rascunho HTTP Live Streaming, 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 segmento	Referência(s)	Suporte obrigatório a codecs
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 detalhes sobre H264 AVC, MPEG2-4 SP, e MPEG-2. Codecs de áudio: AAC Consulte a seção 5.1.3 para mais detalhes sobre o AAC e suas variantes.
AAC com enquadramento ADTS e tags ID3	ISO 13818-7	Consulte a seção 5.1.1 para mais detalhes sobre o AAC e suas variantes.
WebVTT	WebVTT

Formatos de segmento

Referência(s)

Suporte obrigatório a codecs

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 detalhes sobre H264 AVC, MPEG2-4 SP,
e MPEG-2.

Codecs de áudio:

Consulte a seção 5.1.3 para mais detalhes sobre o AAC e suas variantes.

AAC com enquadramento ADTS e tags ID3

ISO 13818-7

Consulte a seção 5.1.1 para mais detalhes sobre o AAC e suas variantes.

WebVTT

RTSP (RTP, SDP)

Nome do perfil	Referência(s)	Suporte obrigatório a codecs
H264 AVC	RFC 6184	Consulte a seção 5.1.8 para saber mais detalhes sobre o H264 AVC.
MP4A-LATM	RFC 6416	Consulte a seção 5.1.3 para detalhes sobre o AAC e suas variantes.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Consulte detalhes sobre o H263 na seção 5.1.8.
H263-2000	RFC 4629	Consulte detalhes sobre o H263 na seção 5.1.8.
AMR	RFC 4867	Consulte a seção 5.1.3 para detalhes sobre o AMR-NB.
AMR-WB	RFC 4867	Consulte a seção 5.1.3 para detalhes sobre o AMR-WB.
MP4V-ES	RFC 6416	Consulte a seção 5.1.8 para mais detalhes sobre o MPEG-4 SP.
mpeg4-generic	RFC 3640	Consulte a seção 5.1.3 para detalhes sobre o AAC e suas variantes.
MP2T	RFC 2250	Consulte MPEG-2 Transport Stream em HTTP Live Streaming para mais detalhes.

5.8. Secure Media

Se as implementações de dispositivos forem compatíveis com saída de vídeo segura e puderem oferecer suporte a superfícies seguras, elas:

[C-1-1] É OBRIGATÓRIO declarar suporte para Display.FLAG_SECURE.

Se as implementações de dispositivos declararem compatibilidade com Display.FLAG_SECURE e com o protocolo de display sem fio, elas:

[C-2-1] É OBRIGATÓRIO proteger o link com um mecanismo criptograficamente forte, como 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 para Display.FLAG_SECURE e suportarem telas externas com fio, elas:

[C-3-1] DEVE oferecer suporte ao HDCP 1.2 ou versões mais recentes 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 dispositivos informarem suporte ao recurso android.software.midi pela classe android.content.pm.PackageManager, elas:

[C-1-1] DEVE oferecer suporte a MIDI em todos os transportes de hardware compatíveis com MIDI para os quais fornecem conectividade genérica não MIDI, em que esses transportes são:
- Modo de host USB, seção 7.7
- MIDI por Bluetooth LE atuando como central, seção 7.4.3
[C-1-2] PRECISA oferecer suporte ao transporte de software MIDI entre apps (dispositivos MIDI virtuais)
[C-1-3] PRECISA incluir libamidi.so (suporte nativo a MIDI)
DEVE oferecer suporte ao modo periférico MIDI por USB, seção 7.7

5.10. Áudio profissional

Se as implementações de dispositivos informarem suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager, elas:

[C-1-1] MUST report support for feature android.hardware.audio.low_latency.
[C-1-2] PRECISA atender aos requisitos de latência para FEATURE_AUDIO_PRO, conforme definido na seção 5.6 Latência de áudio .
[C-1-3] DEVE incluir uma ou mais portas USB compatíveis com o modo host USB e o modo periférico USB.
[C-1-4] MUST report support for feature android.software.midi.
[C-1-5] PRECISA atender aos requisitos de latência de áudio USB usando a API AAudio native audio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
[C-1-6] PRECISA ter uma latência de saída a frio de 200 milissegundos ou menos.
[C-1-7] PRECISA ter uma latência de entrada fria de 200 milissegundos ou menos.

Se as implementações de dispositivos incluírem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

[C-2-2] PRECISA obedecer à seção Especificações de dispositivos móveis (entrada para fone de ouvido) da Especificação de fones de ouvido com fio (v1.1).

Se as implementações de dispositivos omitirem uma entrada para fone de ouvido de 3,5 mm com quatro condutores e incluírem uma ou mais portas USB compatíveis com o modo host USB, elas:

[C-3-1] PRECISA implementar a classe de áudio USB.

5.11. Captura para "Não processado"

O Android inclui suporte para gravação de áudio não processado usando a 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 pretendem oferecer suporte a fontes de áudio não processadas e disponibilizá-las para apps de terceiros, elas:

[C-1-1] MUST report the support through the android.media.AudioManager property PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] PRECISA apresentar características de amplitude versus frequência aproximadamente planas 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] PRECISA apresentar níveis de amplitude na faixa de baixa frequência: especificamente de ±20 dB de 5 Hz a 100 Hz em comparação com a faixa de média frequência para todos os microfones usados para gravar a fonte de áudio não processada.
[C-1-4] PRECISA apresentar níveis de amplitude na faixa de alta frequência: especificamente de ±30 dB de 7.000 Hz a 22 KHz em comparação com a faixa de frequência média para cada microfone usado para gravar a fonte de áudio não processada.
[C-1-5] É OBRIGATÓRIO definir a sensibilidade da entrada de áudio para que uma fonte de tom senoidal de 1.000 Hz reproduzida a 94 dB de nível de pressão sonora (SPL) produza uma resposta com RMS de 520 para amostras de 16 bits (ou -36 dB de escala completa para amostras de ponto flutuante/precisão dupla) para cada microfone usado para gravar a fonte de áudio não processada.
[C-1-6] PRECISA ter uma proporção sinal-ruído (SNR) de 60 dB ou mais para todos os microfones usados para gravar a fonte de áudio não processada. Enquanto a SNR é medida como a diferença entre 94 dB SPL e o SPL equivalente do ruído próprio, ponderado com A.
[C-1-7] PRECISA ter uma distorção harmônica total (THD) menor que 1% para 1 kHz a um nível de entrada de 90 dB SPL em todos os microfones usados para gravar a fonte de áudio não processada.
[C-1-8] NÃO PODE ter nenhum outro processamento de sinal (por exemplo, controle automático de ganho, filtro passa-alta ou cancelamento de eco) no caminho, exceto um multiplicador de nível para trazer o nível ao intervalo desejado. Resumindo:
- [C-1-9] Se houver processamento de sinal na arquitetura por qualquer motivo, ele DEVE ser desativado e introduzir efetivamente zero atraso ou latência extra no caminho do sinal.
- [C-1-10] O multiplicador de nível, embora possa estar 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 de dispositivos declararem android.hardware.microphone, mas não forem compatíveis com a fonte de áudio não processado, elas:

[C-2-1] PRECISA 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 são FORTEMENTE RECOMENDADOS para atender ao máximo de requisitos do caminho de sinal para a fonte de gravação não processada.

5.12. Vídeo HDR

O Android 13 é compatível com as tecnologias HDR descritas em um documento futuro.

Formato de pixel

Se um decodificador de vídeo anunciar suporte para COLOR_FormatYUVP010, então:

[C-1-1] PRECISA oferecer suporte ao formato P010 para leitura de CPU (ImageReader, MediaImage, ByteBuffer). No Android 13, o P010 é flexibilizado para permitir um incremento arbitrário para os planos Y e UV.
[C-1-2] O buffer de saída P010 PRECISA poder ser amostrado pela GPU (quando alocado com uso de GPU_SAMPLING). Isso permite a composição da GPU e o mapeamento de tons personalizado pelos apps.

Se um decodificador de vídeo anunciar suporte para COLOR_Format32bitABGR2101010, ele:

[C-2-1] PRECISA oferecer suporte ao formato RGBA_1010102 para superfície de saída e saída legível por CPU (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 gravável por CPU (ImageWriter, MediaImage, ByteBuffer).

Se um codificador de vídeo anunciar suporte para COLOR_Format32bitABGR2101010, ele:

[C-4-1] PRECISA oferecer suporte ao formato RGBA_1010102 para entrada de superfície e entrada gravável por CPU (ImageWriter, ByteBuffer). Observação: não é necessário converter entre várias curvas de transferência para codificadores.

Requisitos de captura de HDR

Para todos os codificadores de vídeo compatíveis com perfis HDR, implementações de dispositivos:

[C-5-1] NÃO DEVE presumir que os metadados HDR são precisos. Por exemplo, o frame codificado pode ter pixels além do nível de luminância máxima, ou o histograma pode não ser representativo do frame.
DEVE agregar metadados dinâmicos de HDR para gerar metadados estáticos de HDR adequados para streams codificados e gerar esses dados no final de cada sessão de codificação.

Se as implementações de dispositivos forem compatíveis com a captura HDR usando as APIs CamcorderProfile, elas:

[C-6-1] PRECISA oferecer suporte à captura em HDR também pelas APIs Camera2.
[C-6-2] PRECISA oferecer suporte a pelo menos um codificador de vídeo acelerado por hardware para cada tecnologia HDR compatível.
[C-6-3] PRECISA oferecer suporte (no mínimo) à captura HLG.
[C-6-4] PRECISA 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 ser compatível com P010 e COLOR_FormatYUVP010.
[C-6-6] PRECISA 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 puder capturar HEVC HDR10+, o decodificador HEVC padrão PRECISA ser capaz de decodificar o stream capturado em SDR.

Requisitos de edição de HDR

Se as implementações de dispositivos incluírem codificadores de vídeo compatíveis com a edição em HDR, eles:

DEVE usar latência mínima para gerar os metadados HDR quando eles não estiverem presentes e DEVE processar normalmente situações em que os metadados estão presentes em alguns frames e não em outros. Esses metadados PRECISAM ser precisos (por exemplo, representar o histograma e a luminância de pico real do frame).

Se a implementação do dispositivo incluir codecs compatíveis com FEATURE_HdrEditing, esses codecs:

[C-7-1] PRECISA oferecer suporte a pelo menos um perfil HDR.
[C-7-2] PRECISA oferecer suporte a FEATURE_HdrEditing para todos os perfis HDR anunciados pelo codec. Em outras palavras, PRECISA oferecer suporte à geração de metadados HDR quando eles não estiverem presentes para todos os perfis HDR compatíveis que usam metadados HDR.
[C-7-3] PRECISA oferecer suporte aos seguintes formatos de entrada de codificador de vídeo que preservam totalmente o sinal decodificado em HDR:
- RGBA_1010102 (já na curva de transferência desejada) para a superfície de entrada e o ByteBuffer e PRECISA anunciar o suporte para COLOR_Format32bitABGR2101010.

Se a implementação do dispositivo incluir codecs compatíveis com FEATURE_HdrEditing, o dispositivo:

[C-7-4] PRECISA anunciar a compatibilidade com a extensão EXT_YUV_target do OpenGL.

Requisitos de exibição HDR

Se as implementações de dispositivos receberem conteúdo de buffer codificado com ADATASPACE_TRANSFER_HLG, e esse conteúdo for enviado à tela por SurfaceControl.Transaction#setBuffer, elas:

[C-8-1] PRECISA seguir a recomendação de branco gráfico em BT. 2408-7 e mostrar apenas conteúdo que seja, no máximo, 4,926 vezes maior que o conteúdo SDR.

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

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

[C-0-1] PRECISA oferecer suporte às ferramentas para desenvolvedores Android fornecidas no SDK do Android.
Android Debug Bridge (adb)
[C-0-2] DEVE oferecer suporte ao adb conforme documentado no SDK do Android e nos comandos do shell fornecidos no AOSP, que podem ser usados por desenvolvedores de apps, incluindo dumpsys, cmd stats e Simpleperf.
[C-0-11] PRECISA ser compatível com o comando shell cmd testharness. O upgrade de implementações de dispositivos de uma versão anterior do Android sem um bloco de dados persistente PODE ser isento de C-0-11.
[C-0-3] NÃO PODE alterar o formato ou o conteúdo dos eventos do sistema do dispositivo (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrados com o comando dumpsys.
[C-0-10] PRECISA registrar, sem omissão, e disponibilizar os seguintes eventos 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
- PressureStallInformation
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
[C-0-4] O daemon adb do lado do dispositivo PRECISA estar inativo por padrão, e PRECISA haver um mecanismo acessível ao usuário para ativar a Android Debug Bridge.
[C-0-5] É obrigatório oferecer suporte ao adb seguro. O Android inclui suporte para adb seguro. O adb seguro permite o adb em hosts autenticados conhecidos.
[C-0-6] PRECISA fornecer um mecanismo que permita a conexão do adb de uma máquina host. Especificamente:

Se as implementações de dispositivos sem uma porta USB forem compatíveis com o modo periférico, elas:

[C-3-1] É OBRIGATÓRIO implementar o adb por uma rede local (como Ethernet ou Wi-Fi).
[C-3-2] PRECISA fornecer drivers para Windows 7, 8 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.

Se as implementações de dispositivos forem compatíveis com conexões adb a uma máquina host por Wi-Fi ou Ethernet, elas:

[C-4-1] PRECISA ter o método AdbManager#isAdbWifiSupported() retornando true.

Se as implementações de dispositivos forem compatíveis com conexões adb a uma máquina host por Wi-Fi ou Ethernet e incluírem pelo menos uma câmera, elas:

[C-5-1] PRECISA fazer com que o método AdbManager#isAdbWifiQrSupported() retorne true.
Serviço de monitoramento de depuração do Dalvik (ddms)
- [C-0-7] Precisa oferecer suporte a todos os recursos do ddms, conforme documentado no SDK do Android. Como o ddms usa o adb, o suporte a ele DEVE estar inativo por padrão, mas PRECISA ser compatível sempre que o usuário ativar o Android Debug Bridge, conforme 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 deve haver um mecanismo acessível ao usuário para ativá-lo.
Perfetto (link em inglês)
- [C-SR-1] É FORTEMENTE RECOMENDADO expor um binário /system/bin/perfetto ao usuário do shell que a linha de comando esteja em conformidade com a documentação do perfetto.
- [C-SR-2] É ALTAMENTE RECOMENDADO que o binário do perfetto aceite como entrada uma configuração do protobuf que esteja em conformidade com o esquema definido na documentação do perfetto.
- [C-SR-3] É ALTAMENTE RECOMENDADO que o binário do perfetto grave como saída um rastreamento do protobuf que esteja em conformidade com o 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 (em inglês)
- [C-0-12] É OBRIGATÓRIO gravar um átomo LMK_KILL_OCCURRED_FIELD_NUMBER no registro do statsd quando um app é encerrado pelo Low Memory Killer.
Modo de arcabouço de testes

Se as implementações de dispositivos forem compatíveis com o comando de shell cmd testharness e executarem cmd testharness enable, elas:
- [C-2-1] MUST return true for 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] É obrigatório implementar o comando do shell dumpsys gpu --gpuwork para mostrar os dados agregados de trabalho da GPU retornados pelo ponto de rastreamento do kernel power/gpu_work_period ou não mostrar dados se o ponto de rastreamento não for compatível. A implementação do AOSP é frameworks/native/services/gpuservice/gpuwork/.

Se as implementações de dispositivos informarem o suporte ao Vulkan 1.0 ou mais recente usando as flags de recurso android.hardware.vulkan.version, elas:

[C-1-1] PRECISA oferecer uma affordance para que o desenvolvedor de apps ative/desative camadas de depuração de GPU.
[C-1-2] DEVE, quando as camadas de depuração da GPU estão ativadas, enumerar camadas em bibliotecas fornecidas por ferramentas externas (ou seja, não fazem parte da plataforma ou pacote de aplicativos) encontradas no diretório base de aplicativos depuráveis para compatibilidade com os métodos de API vkEnumerateInstanceLayerProperties() e vkCreateInstance().

Se as implementações de dispositivos definirem as propriedades do sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_frequency como true, elas:

[C-6-1] DEVE informar um ponto de rastreamento de frequência da GPU conforme especificado pelo formato power/gpu_frequency, conforme definido em power.proto.

Se as implementações de dispositivos definirem as propriedades do sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters como true, elas:

[C-7-1] MUST provide a Perfetto data producer for a data source named gpu.counters, queryable using: perfetto --query.
[C-7-2] É OBRIGATÓRIO informar as descrições dos contadores de GPU em conformidade com o proto do pacote de rastreamento do contador de GPU.
[C-7-3] PRECISA informar valores em conformidade para os contadores de GPU do dispositivo seguindo o proto de pacote de rastreamento de contador de GPU.
[C-7-4] É OBRIGATÓRIO gravar as descrições de texto de todos os contadores de GPU ativados sem carimbo de data/hora no rastreamento do Perfetto.
[C-7-6] É OBRIGATÓRIO fornecer um conjunto padrão não vazio de contadores de desempenho da GPU para criação de perfis, conforme especificado em GpuCounterSpec#select_by_default.
- É necessário ativar todos esses contadores padrão ao mesmo tempo.
- Todos ELES PRECISAM emitir valores para o Perfetto quando ativados.
[C-7-7] PRECISA refletir a utilização da GPU para pelo menos um contador selecionado por padrão, usando GpuCounterSpec#select_by_default.

Se as implementações de dispositivos definirem as propriedades do sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters.period como true, elas:

[C-8-1] PRECISA respeitar counter_period_ns para a taxa de amostragem dos contadores de GPU. A taxa de amostragem compatível PRECISA ser de 1 ms ou mais rápida.
[C-SR-1] É ALTAMENTE RECOMENDADO para oferecer suporte a uma taxa de amostragem de 0,2 ms ou mais rápida.

Se as implementações de dispositivos definirem as propriedades do sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters.groups como true, elas:

[C-9-1] PRECISA ter pelo menos um contador em cada um dos seguintes grupos de contadores de GPU, conforme especificado por GpuCounterSpec: COMPUTE, FRAGMENTS, MEMORY, PRIMITIVES e VERTICES.

Se as implementações de dispositivos definirem as propriedades do sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters.groups como true e o dispositivo for compatível com o ray tracing, ele:

[C-10-1] PRECISA ter um contador no grupo RAY_TRACING.

Se as implementações de dispositivos definirem as propriedades do sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.gpu_counters.zeroes_optimization como true, elas:
[C-11-1] Na mesma sessão de rastreamento do Perfetto, os contadores da GPU SÓ podem informar valores zero se o valor informado anterior ou seguinte for diferente de zero.

Se as implementações de dispositivos definirem as propriedades do sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.render_stages como true, elas:

[C-12-1] MUST provide a Perfetto data producer for a data source named gpu.renderstages, queryable using perfetto --query.
[C-12-2] MUST report conformant values for GPU render stages following the GPU render stage event proto.

Se as implementações de dispositivos definirem as propriedades do sistema graphics.gpu.profiler.support e graphics.gpu.profiler.support.render_stages.queue_submit como true, elas:

[C-13-1] Para cada chamada de envio de fila do Vulkan, o driver do Vulkan PRECISA emitir um evento de rastreamento do Perfetto de acordo com a especificação de mensagem de evento da API Vulkan.
- Esse evento PRECISA conter um submission_id exclusivo e monotonicamente crescente que corresponda ao submission_id no evento de estágio de renderização da GPU correspondente.

6.2. Opções do desenvolvedor

O Android inclui suporte para que os desenvolvedores configurem as configurações relacionadas ao desenvolvimento de aplicativos.

As implementações de dispositivos precisam oferecer uma experiência consistente para as opções do desenvolvedor. Elas:

[C-0-1] PRECISA obedecer à intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar configurações relacionadas ao desenvolvimento de aplicativos. A implementação upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários iniciem as "Opções do desenvolvedor" depois de pressionar sete vezes o item de menu Configurações > Sobre o dispositivo > Número da versão.
[C-0-2] As Opções do desenvolvedor precisam ficar ocultas por padrão.
[C-0-3] PRECISA fornecer um mecanismo claro que não dê tratamento preferencial a um app de terceiros em vez de outro para ativar as opções do desenvolvedor. É NECESSÁRIO fornecer um documento ou site visível publicamente que descreva como ativar as opções do desenvolvedor. Este documento ou site PRECISA ter um link nos documentos do SDK do Android.
PRECISA ter uma notificação visual contínua para o usuário quando as opções de desenvolvedor estão ativadas e a segurança do usuário é uma preocupação.
PODE limitar temporariamente o acesso ao menu "Opções do desenvolvedor", ocultando ou desativando visualmente o menu, para evitar distrações em situações 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 (conforme documentado pelo SDK) para as APIs de componentes AINDA precisam ser apresentadas.
[C-0-3] Os comportamentos da API precisam ser implementados como ambiente autônomo de alguma forma 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 de 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 de forma consistente informações precisas de configuração de hardware usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para a mesma impressão digital de build.

Um exemplo típico de 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 ambiente autônomo razoável.

7.1. Tela e gráficos

O Android inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts de IU de acordo com o dispositivo para garantir que os aplicativos de terceiros funcionem bem em uma variedade 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 Android Developers - Visão geral da compatibilidade de tela, nesta seção (7.1) e nas subseções dela, bem como outros comportamentos específicos do tipo de dispositivo documentados na seção 2 deste CDD.

Implementações de dispositivos:

[C-0-1] POR PADRÃO, renderizar aplicativos de terceiros apenas em telas compatíveis com o Android.

As unidades referenciadas pelos requisitos nesta seção são definidas da seguinte maneira:

tamanho físico da diagonal. A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
density. O número de pixels abrangidos por um intervalo linear horizontal ou vertical de 1", expresso como pixels por polegada (ppi ou dpi). Quando os valores de ppi e dpi são listados, os dpi horizontal e vertical precisam estar dentro do intervalo listado.
proporção. A proporção entre os pixels da dimensão mais longa e a dimensão mais curta 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 determinada densidade d e um número de pixels p, o número de pixels independentes de densidade dp é 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 de tela lógicos diferentes e permite que os aplicativos consultem o tamanho do layout de tela da configuração atual usando Configuration.screenLayout com SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

Implementações de dispositivos:

[C-0-1] PRECISA informar o tamanho correto do layout para o Configuration.screenLayout, conforme definido na documentação do SDK do Android. Especificamente, as implementações de dispositivos PRECISAM informar as dimensões corretas da tela em pixel independente de densidade (dp), conforme abaixo:
- Dispositivos com o Configuration.uiMode definido como qualquer valor diferente de UI_MODE_TYPE_WATCH e que informam um tamanho small para o Configuration.screenLayout PRECISAM ter pelo menos 426 dp x 320 dp.
- Os dispositivos que informam um tamanho de 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] PRECISA respeitar corretamente o suporte declarado pelos 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 dispositivos forem compatíveis com telas capazes da configuração de tamanho UI_MODE_TYPE_NORMAL e usarem telas físicas com cantos arredondados para renderizar essas telas, elas:

[C-1-1] PRECISA garantir que pelo menos um dos seguintes requisitos seja atendido para cada exibição:
- 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 da configuração de teclado NO_KEYS e pretendem informar suporte para a configuração do modo de interface UI_MODE_TYPE_NORMAL, elas:

[C-4-1] PRECISA ter um tamanho de layout, excluindo cortes de tela, de pelo menos 596 dp x 384 dp ou maior.

Para detalhes sobre a implementação correta das APIs sidecar ou de extensão, consulte a documentação pública do Window Manager Jetpack.

[C-4-1] Requisito removido no Android 15.

7.1.1.2. Proporção da tela

Essa seção foi removida no Android 14.

7.1.1.3. Densidade da tela

O framework de interface do Android define um conjunto de densidades lógicas padrão para ajudar os desenvolvedores de aplicativos a segmentar recursos de aplicativos.

Implementações de dispositivos:

[C-0-1] PRECISA informar uma das densidades do framework Android listadas em DisplayMetrics pela API DENSITY_DEVICE_STABLE e 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 de exibição) definidas após a inicialização.
DEVE definir a densidade padrão do framework Android que seja numericamente mais próxima da densidade física da tela ou um valor que mapeie para as mesmas medições equivalentes de campo de visão angular de um dispositivo portátil.

Se as implementações de dispositivos oferecerem uma opção para mudar o tamanho de exibição do dispositivo, elas:

[C-1-1] NÃO PODE dimensionar a tela para mais de 1,5 vezes DENSITY_DEVICE_STABLE ou produzir uma dimensão mínima efetiva da tela menor que 320 dp (equivalente ao qualificador de recurso sw320dp), o que ocorrer primeiro.
[C-1-2] NÃO PODE dimensionar a tela para menos de 0,85 vezes o DENSITY_DEVICE_STABLE.
Para garantir boa usabilidade e tamanhos de fonte consistentes, é RECOMENDADO que o seguinte escalonamento de opções de display nativo seja fornecido (em conformidade com os limites especificados acima):
- Pequena: 0,85x
- Padrão: 1x (escala de exibição nativa)
- Grande: 1,15x
- Maior: 1,3x
- Maior 1,45x

7.1.2. Métricas de display

Se as implementações de dispositivos incluírem telas compatíveis com o Android ou saída de vídeo para telas compatíveis com o Android, elas:

[C-1-1] PRECISA informar valores corretos para todas as métricas de exibição compatíveis com 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] PRECISA informar os valores corretos da tela compatível com o 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] PRECISA informar quais orientações de tela são compatíveis (android.hardware.screen.portrait e/ou android.hardware.screen.landscape) e PRECISA informar pelo menos uma orientação compatível. Por exemplo, um dispositivo com uma tela paisagem de orientação fixa, como uma televisão ou um laptop, SÓ DEVE informar android.hardware.screen.landscape.
[C-0-2] É OBRIGATÓRIO informar o valor correto da orientação atual do dispositivo sempre que for consultado pelas APIs ß android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras.

Se as implementações de dispositivos forem compatíveis com as duas orientações de tela, elas:

[C-1-1] Requisito removido no Android 16.
[C-1-2] NÃO PODE mudar o tamanho ou a densidade da tela informados ao mudar a orientação.
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] DEVE identificar corretamente as versões compatíveis do OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) usando as APIs gerenciadas (como o método GLES10.getString()) e as APIs nativas.
[C-0-2] PRECISA incluir o suporte para todas as APIs gerenciadas e nativas correspondentes para todas as versões do OpenGL ES que foram identificadas como compatíveis.

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

[C-1-1] PRECISA oferecer suporte ao OpenGL ES 1.1, 2.0, 3.0 e 3.1, conforme incorporado e detalhado na documentação do SDK do Android.
[C-SR-1] Requisito removido no Android 15.
DEVE ser compatível com o OpenGL ES 3.2.

Os testes dEQP do OpenGL ES são divididos em várias listas de testes, cada uma com uma data/número de 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 auto-relatado indica que ele pode passar nos testes dEQP em todas as listas de testes desse nível e anteriores.

Se as implementações de dispositivos forem compatíveis com alguma das versões do OpenGL ES, elas:

[C-2-1] PRECISA informar pelas APIs gerenciadas e nativas do OpenGL ES qualquer outra extensão do OpenGL ES implementada e, inversamente, NÃO PODE 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] PRECISA informar a versão máxima dos testes dEQP do OpenGL ES compatíveis com a flag de recurso android.software.opengles.deqp.level.
[C-2-4] PRECISA oferecer suporte pelo menos à versão 132383489 (de 1º de março de 2020), conforme informado na flag de recurso android.software.opengles.deqp.level.
[C-2-5] PRECISA passar em todos os testes dEQP do OpenGL ES nas listas de testes 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 compatível.
[C-SR-2] É ALTAMENTE RECOMENDÁVEL que ofereçam suporte às extensões EGL_KHR_partial_update e OES_EGL_image_external.
DEVE informar com precisão, usando o método getString(), qualquer formato de compactação de textura compatível, que geralmente é específico do fornecedor.
PRECISA ser compatível com as extensões EGL_IMG_context_priority e EGL_EXT_protected_content.

Se as implementações de dispositivos declararem compatibilidade com o OpenGL ES 3.0, 3.1 ou 3.2, elas:

[C-3-1] PRECISA 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] SÃO FORTEMENTE RECOMENDADOS para oferecer suporte à extensão OES_EGL_image_external_essl3.

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

[C-4-1] PRECISA oferecer suporte ao pacote de extensões para Android do OpenGL ES por completo.

Se as implementações de dispositivos forem compatíveis com o pacote de extensões para Android do OpenGL ES por completo, elas:

[C-5-1] MUST identify the support through the android.hardware.opengles.aep feature flag.

Se as implementações de dispositivos expuserem suporte à extensão EGL_KHR_mutable_render_buffer, elas:

[C-6-1] Também é necessário oferecer suporte à extensão EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2. Vulkan

O Android inclui suporte para Vulkan, uma API multiplataforma de baixa sobrecarga para gráficos 3D de alto desempenho.

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

[C-SR-1] É ALTAMENTE RECOMENDADO incluir suporte para Vulkan 1.3.
[C-4-1] NÃO PODE oferecer suporte a uma versão variante do Vulkan (ou seja, a parte variante da versão principal do Vulkan PRECISA ser zero).

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

[C-SR-2] É FORTEMENTE RECOMENDADO incluir suporte para Vulkan 1.3.

Os testes dEQP do Vulkan são divididos em várias listas de testes, 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 autodeclarado indica que ele pode passar nos testes dEQP em todas as listas de testes desse nível e anteriores.

Se as implementações de dispositivos incluírem suporte ao Vulkan, elas:

[C-1-1] PRECISA informar o valor inteiro correto com as flags de recurso android.hardware.vulkan.level e android.hardware.vulkan.version.
[C-1-2] PRECISA enumerar pelo menos um VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices().
[C-1-3] PRECISA implementar totalmente as APIs do Vulkan 1.1 para cada VkPhysicalDevice enumerado.
[C-1-4] É OBRIGATÓRIO enumerar as camadas contidas em bibliotecas nativas chamadas como libVkLayer*.so no diretório de bibliotecas nativas do pacote do aplicativo, usando as APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties().

[C-1-5] NÃO PODE enumerar camadas fornecidas por bibliotecas fora do pacote de aplicativos nem oferecer 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 , exceto para camadas de OEM e plataforma, de acordo com a documentação Implementar o Vulkan.

[C-1-6] É OBRIGATÓRIO informar todas as strings de extensão compatíveis pelas APIs nativas do Vulkan e, inversamente, NÃO É PERMITIDO informar strings de extensão que não são compatíveis corretamente.

[C-1-7] PRECISA oferecer suporte às seguintes extensões:
- VK_EXT_present_mode_fifo_latest_ready
- VK_KHR_present_wait2
- VK_KHR_android_surface
- VK_KHR_incremental_present
- VK_KHR_present_id
- VK_KHR_present_id2
- VK_KHR_surface
- VK_KHR_swapchain

[C-1-8] DEVE informar a versão máxima dos testes dEQP do Vulkan compatíveis com a flag de recurso android.software.vulkan.deqp.level.
[C-1-9] PRECISA oferecer suporte a pelo menos a versão 132317953 (de 1º de março de 2019) conforme informado na flag de recurso android.software.vulkan.deqp.level.
[C-1-10] PRECISA 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 PODE 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 que ofereçam suporte às seguintes extensões:
- VK_EXT_present_timing
- VK_GOOGLE_display_timing
- VK_KHR_driver_properties

[C-1-12] NÃO PODE enumerar o suporte à extensão VK_KHR_performance_query.
[C-SR-4] São FORTEMENTE RECOMENDADOS para atender aos requisitos especificados pelo perfil de referência do Android 2022.
[C-SR-5] É ALTAMENTE RECOMENDADO que eles sejam compatíveis com VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory e VK_EXT_global_priority.
[C-SR-6] É FORTEMENTE RECOMENDADO usar SkiaVk com HWUI.

Se as implementações de dispositivos incluírem suporte ao Vulkan, elas:

[C-SR-8] É FORTEMENTE RECOMENDADO não modificar o carregador do Vulkan.
[C-1-14] NÃO PODE enumerar extensões de dispositivo Vulkan do tipo "KHR", "GOOGLE" ou "ANDROID", a menos que essas extensões estejam incluídas na flag de recurso android.software.vulkan.deqp.level.

Se as implementações de dispositivos não incluírem suporte para o Vulkan 1.0, elas:

[C-2-1] NÃO PODE declarar nenhuma das flags de recursos do Vulkan (por exemplo, android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] NÃO PODE enumerar nenhum VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices().

Se as implementações de dispositivos incluírem suporte para Vulkan 1.1 e declararem qualquer uma das flags de recursos do Vulkan descritas aqui ou mais recente, elas:

[C-3-1] MUST expose support for the SYNC_FD external semaphore and handle types and the VK_ANDROID_external_memory_android_hardware_buffer extension.
[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 restrição de local para e de descritores de arquivo POSIX conforme descrito aqui.

7.1.4.3. RenderScript

Implementações de dispositivos:

[C-0-1] Precisa oferecer suporte ao Android RenderScript, conforme detalhado na documentação do SDK 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 DESATIVAR se o desenvolvedor solicitar definindo android:hardwareAccelerated="false" ou desativando a aceleração de hardware diretamente pelas APIs do 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 aos desenvolvedores integrar diretamente texturas OpenGL ES aceleradas por hardware como destinos de renderização em uma hierarquia de UI.

Implementações de dispositivos:

[C-0-3] Precisa oferecer suporte à API TextureView e 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] PRECISA ter uma tela calibrada por cores.
[C-1-2] PRECISA ter uma tela cuja gama cubra totalmente a gama de cores sRGB no espaço CIE 1931 xyY.
[C-1-3] PRECISA ter uma tela cujo gamut tenha uma área de pelo menos 90% de DCI-P3 no espaço CIE 1931 xyY.
[C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.1 ou 3.2 e informar isso corretamente.
[C-1-5] PRECISA anunciar suporte às 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 para oferecer suporte a GL_EXT_sRGB.

Por outro lado, se as implementações de dispositivos não forem compatíveis com telas de ampla gama, elas:

[C-2-1] DEVE cobrir 100% ou mais do sRGB no espaço CIE 1931 xyY, embora a gama de cores da tela não esteja definida.

7.1.5. Modo de compatibilidade de aplicativos legados

O Android especifica um "modo de compatibilidade" em que o framework opera em um modo de tamanho de tela "normal" equivalente (320 dp de largura) para beneficiar aplicativos legados não desenvolvidos para versões antigas do Android que antecedem a independência de tamanho da tela.

7.1.6. Tecnologia da tela

A plataforma Android inclui APIs que permitem aos aplicativos renderizar gráficos avançados em uma tela compatível com Android. Os dispositivos PRECISAM oferecer suporte a todas essas APIs, conforme definido pelo SDK do Android, a menos que seja especificamente permitido 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 capazes de 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 ser quase quadrada (1,0) com uma tolerância de 10 a 15%.

7.1.7. Telas secundárias

O Android inclui suporte para telas secundárias compatíveis com o Android para ativar recursos de compartilhamento de mídia e APIs de desenvolvedor para acessar telas externas.

Se as implementações de dispositivos forem compatíveis com uma tela externa por uma conexão com fio, sem fio ou uma conexão de tela adicional incorporada, elas:

[C-1-1] É OBRIGATÓRIO implementar o serviço e a API do sistema DisplayManager conforme descrito na documentação do SDK do Android.

7.2. Dispositivos de entrada

Implementações de dispositivos:

[C-0-1] PRECISA incluir um mecanismo de entrada, como uma tela sensível ao toque 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 para aplicativos de Editor de método de entrada (IME) de terceiros, elas:

[C-1-1] PRECISA declarar a flag de recurso android.software.input_methods.
[C-1-2] PRECISA implementar totalmente Input Management Framework
[C-1-3] PRECISA ter um teclado de software pré-instalado.

Implementações de dispositivos:

[C-0-1] NÃO PODE incluir um teclado físico 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 de software.
PODE incluir um teclado físico.

7.2.2. Navegação sem toque

O Android inclui suporte para botão direcional, trackball e roda como mecanismos de navegação sem toque.

Implementações de dispositivos:

[C-0-1] MUST report the correct value for android.content.res.Configuration.navigation.

Se as implementações de dispositivos não tiverem navegações sem toque, elas:

[C-1-1] PRECISA fornecer um mecanismo alternativo razoável de interface do usuário para a seleção e edição de texto, compatível com mecanismos de gerenciamento de entrada. A implementação upstream de código aberto do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação sem toque.

7.2.3. Teclas de navegação

As funções Início, Recentes e Voltar, normalmente fornecidas por uma interação com um botão físico dedicado ou uma parte distinta da tela sensível ao toque, são essenciais para o paradigma de navegação do Android e, portanto, para as implementações de dispositivos:

[C-0-1] DEVE fornecer um recurso ao 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 televisão. A função "Home" DEVE ser o mecanismo para essa conveniência do usuário.
DEVE fornecer botões para as funções "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 estiver acessível.
[C-1-2] PRECISA indicar claramente qual ação única acionaria cada funçã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 uma demonstração guiada de fluxo de etapas durante a experiência de configuração inicial são exemplos dessa indicação.

Implementações de dispositivos:

[C-SR-1] é FORTEMENTE RECOMENDADO a não fornecer o mecanismo de entrada para a função de menu porque 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, ir para a tela inicial, voltar etc.) se o deslizar não for liberado após um determinado limite.

Se as implementações de dispositivos oferecem a função "Menu", elas:

[C-2-1] DEVE mostrar o botão flutuante sempre que o pop-up do menu flutuante não estiver vazio e a barra de ações estiver visível.
[C-2-2] NÃO PODE modificar a posição do pop-up de estouro de ação mostrado ao selecionar o botão flutuante na barra de ações, mas PODE renderizar o pop-up de estouro de ação em uma posição modificada na tela quando ele é mostrado ao selecionar a função "Menu".

Se as implementações de dispositivos não fornecerem a função "Menu", para compatibilidade com versões anteriores, elas:

[C-3-1] É OBRIGATÓRIO disponibilizar a função "Menu" para 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 estar acessível, a menos que esteja oculta com outras funções de navegação.

Se as implementações de dispositivos oferecem a função Assist, elas:

[C-4-1] DEVE tornar a função Assistente 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 de dispositivos 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, não disponível para aplicativos, e não podem obscurecer nem interferir de outra forma na parte da tela disponível para aplicativos.
[C-5-2] DEVE disponibilizar uma parte da tela para aplicativos que atendam aos requisitos definidos na seção 7.1.1.
[C-5-3] PRECISA obedecer às flags definidas pelo app usando o método da API View.setSystemUiVisibility() para que essa parte distinta da tela (também conhecida como barra de navegação) seja ocultada corretamente, conforme documentado no SDK.

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

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() SÓ pode ser usado para informar a área de reconhecimento do gesto de início.
[C-6-2] Gestos que começam dentro de um retângulo de exclusão fornecido pelo aplicativo em primeiro plano via View#setSystemGestureExclusionRects(), mas fora de WindowInsets#getMandatorySystemGestureInsets(), NÃO DEVEM 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] DEVE enviar ao app em primeiro plano um evento MotionEvent.ACTION_CANCEL assim que os toques começarem a ser interceptados para um gesto do sistema, se o app em primeiro plano tiver recebido um evento MotionEvent.ACTION_DOWN antes.
[C-6-4] DEVE oferecer uma opção para o usuário mudar para uma navegação na tela baseada em botões (por exemplo, em "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 deslizar para cima e manter pressionado antes de soltar, na mesma área do gesto de tela inicial.
Gestos que começam em WindowInsets#getMandatorySystemGestureInsets() NÃO DEVEM ser afetados por retângulos de exclusão fornecidos pelo aplicativo em primeiro plano via 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 personalizados com capacidade de deslizar forem fornecidos nas bordas esquerda ou direita, eles PRECISAM ser colocados no terço superior da tela com uma indicação visual clara e persistente de que arrastar para dentro invocaria os painéis mencionados e, portanto, não o botão "Voltar". Um painel do sistema PODE ser configurado por um usuário para que fique abaixo do 1/3 superior das bordas da tela, mas NÃO PODE usar mais de 1/3 das bordas.
[C-7-3] Quando o aplicativo 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 das bordas precisa se comportar como implementado no AOSP, que é documentado no SDK.
[C-7-4] Quando o aplicativo 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, os painéis de sistema personalizados que podem ser deslizados precisam ser ocultados até que o usuário traga ou remova o escurecimento das barras de sistema (ou seja, barra de navegação e de status), conforme implementado no AOSP.

Se a função de navegação de retorno for fornecida e o usuário cancelar o gesto de voltar, acontecerá o seguinte:

[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 PRECISA fornecer uma animação para o aplicativo em primeiro plano que sugira que o usuário está voltando, conforme fornecido no AOSP.

Se as implementações de dispositivos oferecerem suporte à API do sistema setNavBarMode 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] PRECISA oferecer suporte a ícones adequados para crianças ou navegação baseada em botões, conforme fornecido no código AOSP.

7.2.4. Entrada por toque

O Android inclui suporte para vários sistemas de entrada de ponteiro, como touchscreens, touchpads e dispositivos de entrada de toque simulado. Implementações de dispositivos com tela sensível ao toque são associadas a uma tela para que o usuário tenha a impressão de manipular diretamente itens na tela. Como o usuário está tocando diretamente na tela, o sistema não exige mais affordances para indicar os objetos que estão sendo manipulados.

Implementações de dispositivos:

PRECISA ter um sistema de entrada de ponteiro de algum tipo (semelhante a mouse ou toque).
DEVE oferecer suporte a ponteiros rastreados de forma totalmente independente.

Se as implementações de dispositivos incluírem uma tela sensível ao toque (toque único 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] PRECISA informar as flags de recursos android.hardware.touchscreen e android.hardware.faketouch.

Se as implementações de dispositivos incluírem uma tela touchscreen que possa rastrear mais de um único toque em uma tela principal compatível com Android, elas:

[C-2-1] PRECISA informar as flags de recursos adequadas android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand correspondentes ao tipo de touchscreen específico no dispositivo.

Se as implementações de dispositivos dependerem de um dispositivo de entrada externo, como mouse ou trackball (ou seja, sem tocar diretamente na tela), para entrada em uma tela principal compatível com Android e atenderem aos requisitos de toque falso na seção 7.2.5, elas:

[C-3-1] NÃO PODE informar nenhuma flag de recurso que comece com android.hardware.touchscreen.
[C-3-2] SÓ PODE informar android.hardware.faketouch.
[C-3-3] MUST report TOUCHSCREEN_NOTOUCH for the Configuration.touchscreen API field.

7.2.5. Entrada por toque simulada

A interface de toque simulada oferece um sistema de entrada do usuário que se aproxima de um subconjunto de recursos da 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 foque e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse aéreo baseado em giroscópio, giroponto, joystick e trackpad multitoque, podem oferecer suporte a interações de toque simulado. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada de alta fidelidade sem toque (baseado em ponteiro), 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 funcionalidades de tela touchscreen.

Se as implementações de dispositivos não incluírem uma tela sensível ao toque, mas incluírem outro sistema de entrada de ponteiro que queiram disponibilizar, elas:

PRECISA declarar suporte à flag de recurso android.hardware.faketouch.

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

[C-1-1] PRECISA informar as posições absolutas X e Y da tela do local do ponteiro e mostrar 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 ao descer ou subir na tela.
[C-1-3] PRECISA oferecer suporte a pressionar e soltar um objeto na tela, o que permite que os usuários emulem um toque em um objeto na tela.
[C-1-4] DEVE oferecer suporte a pressionar e soltar o ponteiro, pressionar e soltar o ponteiro no mesmo lugar em um objeto na tela dentro de um limite de tempo, o que permite que os usuários emulem um toque duplo em um objeto na tela.
[C-1-5] PRECISA oferecer suporte a pressionar um ponto arbitrário na tela, mover o ponteiro para qualquer outro ponto arbitrário na tela e soltar o ponteiro, o que permite que os usuários emulem um arrastar por toque.
[C-1-6] PRECISA oferecer suporte ao toque para baixo e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, toquem para cima na tela, o que permite que os usuários deslizem rapidamente um objeto na tela.

Se as implementações de dispositivos declararem suporte para android.hardware.faketouch.multitouch.distinct, elas:

[C-2-1] É OBRIGATÓRIO declarar suporte para android.hardware.faketouch.
[C-2-2] PRECISA oferecer suporte ao 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] É OBRIGATÓRIO declarar suporte para android.hardware.faketouch.
[C-3-2] PRECISA oferecer suporte ao 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] PRECISA ser capaz de mapear eventos de 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 forneça meios para inserir todos os eventos listados nas tabelas abaixo, elas:

[C-2-1] MUST declare the feature flag 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)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Botão direcional para cima¹ Botão direcional para baixo¹	0x01 0x0039³	AXIS_HAT_Y⁴
Botão direcional para a esquerda1 Botão direcional para a direita¹	0x01 0x0039³	AXIS_HAT_X⁴
Botão esquerdo do ombro¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Botão direito do ombro¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clique no botão analógico esquerdo¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clique no botão analógico 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 afastada 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 para a esquerda pressionadas.

4 MotionEvent

Controles analógicos¹	Uso de HID	Botão do Android
Gatilho esquerdo	0x02 0x00C5	AXIS_LTRIGGER
Gatilho 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 requisitos específicos do dispositivo.

7.3. Sensores

Se as implementações de dispositivos incluírem um tipo específico de sensor que tenha uma API correspondente para desenvolvedores terceirizados, 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] MUST accurately report the presence or absence of sensors per the android.content.pm.PackageManager class.
[C-0-2] PRECISA retornar uma lista precisa de sensores compatíveis usando os métodos SensorManager.getSensorList() e semelhantes.
[C-0-3] DEVE 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 específico de sensor que tenha uma API correspondente para desenvolvedores terceirizados, elas:

[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 SDK do Android.
[C-1-2] DEVE 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 de aplicativos está ativo. Esse atraso não inclui atrasos de filtragem.
[C-1-3] DEVE informar a primeira amostra do sensor em até 400 milissegundos + 2 * sample_time da ativação do sensor. É aceitável que essa amostra tenha uma acurácia de 0.
[C-1-4] Para qualquer API indicada na documentação do SDK do Android como um sensor contínuo, as implementações de dispositivos precisam fornecer continuamente amostras de dados periódicas que devem ter um jitter abaixo de 3%, em que o jitter é definido como o desvio padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.
[C-1-5] MUST ensure that the sensor event stream MUST NOT prevent the device CPU from entering a suspend state or waking up from a suspend state.
[C-1-6] DEVE 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 relógio SystemClock.elapsedRealtimeNano().
[C-SR-1] É ALTAMENTE RECOMENDADO que o erro de sincronização de carimbo de data/hora seja inferior a 100 milissegundos e DEVE ser 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 de cada sensor.

A lista acima não é abrangente. O comportamento documentado do SDK do Android e as documentações de código aberto do Android sobre sensores devem ser considerados autorizados.

Se as implementações de dispositivos incluírem um tipo específico de sensor que tenha uma API correspondente para desenvolvedores terceirizados, elas:

[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 sensores. Por exemplo, o sensor de orientação e o sensor de aceleração linear.

Implementações de dispositivos:

DEVE implementar esses tipos de sensores quando eles incluírem os sensores físicos necessários, conforme descrito em tipos de sensores.

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

[C-2-1] É OBRIGATÓRIO implementar o sensor conforme descrito na documentação do Android Open Source sobre sensores compostos.

Se as implementações de dispositivos incluírem um tipo específico de sensor que tenha uma API correspondente para desenvolvedores terceirizados e o sensor informar apenas um valor, as implementações de dispositivos:

[C-3-1] É OBRIGATÓRIO definir a resolução como 1 para o sensor e informar o valor usando o método da API Sensor.getResolution().

Se as implementações de dispositivos 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 PODE incluir parâmetros de calibragem fixos e determinados na fábrica nos dados fornecidos.

Se as implementações de dispositivos incluírem 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 serão:

[C-SR-2] É ALTAMENTE RECOMENDADO garantir que o acelerômetro, o giroscópio e o magnetômetro tenham uma posição relativa fixa. Assim, se o dispositivo for transformável (por exemplo, dobrável), os eixos do sensor vão permanecer 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] É FORTEMENTE RECOMENDADO incluir um acelerômetro de três eixos.

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

[C-1-1] PRECISA ser capaz de informar eventos com uma frequência de pelo menos 50 Hz.
[C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor Android conforme detalhado nas APIs Android.
[C-1-4] DEVE ser capaz de medir desde 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] PRECISA ter um desvio padrão não maior que 0,05 m/s², em que o desvio padrão precisa ser calculado 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é pelo menos 200 Hz.
PRECISA ter uma resolução de pelo menos 16 bits.
PRECISA ser calibrado durante o uso se as características mudarem ao longo do ciclo de vida e forem compensadas, além de preservar os parâmetros de compensação entre reinicializações do dispositivo.
PRECISA ter compensação de temperatura.

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

[C-2-1] É OBRIGATÓRIO 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, em que isso pode 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 de dispositivos 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] É ALTAMENTE RECOMENDADO implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Se as implementações de dispositivos incluírem um acelerômetro de três eixos e qualquer um dos sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER:

[C-4-1] A soma do consumo de energia DEVE sempre ser inferior a 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 de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, elas:

[C-5-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
[C-SR-7] É ALTAMENTE RECOMENDÁVEL implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

Se as implementações de dispositivos 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] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

7.3.2. Magnetômetro

Implementações de dispositivos:

[C-SR-1] É FORTEMENTE RECOMENDADO incluir um magnetômetro de três eixos (bússola).

Se as implementações de dispositivos incluírem um magnetômetro de três eixos, eles:

[C-1-1] PRECISA implementar o sensor TYPE_MAGNETIC_FIELD.
[C-1-2] DEVE ser capaz de informar eventos com uma frequência de pelo menos 10 Hz e DEVE informar eventos com uma frequência de pelo menos 50 Hz.
[C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor Android conforme detalhado nas APIs Android.
[C-1-4] PRECISA ser capaz de medir entre -900 µT e +900 µT em cada eixo antes da saturação.
[C-1-5] PRECISA ter um valor de compensação de ferro duro menor que 700 µT e DEVE ter 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] PRECISA oferecer suporte à calibragem e compensação on-line do viés de ferro duro e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
[C-1-8] PRECISA ter a compensação de ferro macio aplicada. A calibragem pode ser feita durante o uso ou durante a produção do dispositivo.
[C-1-9] PRECISA ter um desvio padrão, calculado por eixo em amostras coletadas durante um período de pelo menos 3 segundos na taxa de amostragem mais rápida, não maior que 1,5 µT; DEVE ter um desvio padrão não maior que 0,5 µT.
[C-1-10] É obrigatório implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se as implementações de dispositivos incluírem 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] É OBRIGATÓRIO implementar um sensor composto TYPE_ROTATION_VECTOR.

Se as implementações de dispositivos incluírem um magnetômetro de três eixos e um acelerômetro, eles:

PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se as implementações de dispositivos incluírem um magnetômetro de três eixos, um acelerômetro e um sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR, eles:

[C-3-1] PRECISA consumir menos de 10 mW.
DEVE consumir menos de 3 mW quando o sensor estiver registrado para o modo em 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 de dispositivos incluírem um receptor de GPS/GNSS e informarem a capacidade aos aplicativos pela flag de recurso android.hardware.location.gps, elas:

[C-1-1] PRECISA oferecer suporte a saídas de localização a uma taxa de pelo menos 1 Hz quando solicitadas via LocationManager#requestLocationUpdate.
[C-1-2] PRECISA ser capaz de determinar a localização em condições de céu aberto (sinais fortes, multipath insignificante, HDOP < 2) em até 10 segundos (tempo rápido para o primeiro fixo), quando conectado a uma conexão de Internet com velocidade de dados de 0,5 Mbps ou mais rápida. Normalmente, esse requisito é atendido com o uso de alguma forma de técnica de GPS/GNSS assistido ou previsto para minimizar o tempo de fixação do GPS/GNSS. Os dados de assistência incluem horário de referência, local de referência e efemérides/relógio de satélite.
- [C-1-6] Depois de fazer esse cálculo de localização, as implementações de dispositivo PRECISAM determinar a localização, em céu aberto, em até 5 segundos, quando as solicitações de localização são reiniciadas, até uma hora após o cálculo inicial, mesmo quando a solicitação subsequente é 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, parado ou em movimento com menos de 1 metro por segundo ao quadrado de aceleração:
- [C-1-3] DEVE ser capaz de 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] PRECISA rastrear e gerar relatórios simultaneamente via GnssStatus.Callback pelo menos oito 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 e pelo menos uma das seguintes: Glonass, Beidou, Galileo).
[C-SR-2] É ALTAMENTE RECOMENDADO continuar fornecendo saídas de localização GPS/GNSS normais pelas APIs do provedor de localização GNSS durante uma ligação de emergência.
[C-SR-3] É ALTAMENTE RECOMENDADO informar medições de GNSS de todas as constelações rastreadas (conforme informado nas mensagens GnssStatus), exceto SBAS.
[C-SR-4] É FORTEMENTE RECOMENDADO informar AGC e frequência de medição do GNSS.
[C-SR-5] É ALTAMENTE RECOMENDADO informar todas as estimativas de acurácia (incluindo direção, velocidade e vertical) como parte de cada localização por GPS/GNSS.
[C-SR-6] É ALTAMENTE RECOMENDADO informar as medições de GNSS assim que forem encontradas, mesmo que um local calculado com GPS/GNSS ainda não tenha sido informado.
[C-SR-7] É ALTAMENTE RECOMENDADO informar pseudodistâncias e taxas de pseudodistância do GNSS que, em condições de céu aberto após a determinação do local, enquanto parado ou se movendo 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% das vezes.

7.3.4. Giroscópio

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO incluir um sensor de giroscópio.

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

[C-1-1] PRECISA ser capaz de informar eventos com uma frequência de pelo menos 50 Hz.
[C-1-4] PRECISA ter uma resolução de 12 bits ou mais.
[C-1-5] PRECISA ter compensação de temperatura.
[C-1-6] PRECISA ser calibrado e compensado durante o uso, além de preservar os parâmetros de compensação entre reinicializações do dispositivo.
[C-1-7] PRECISA ter uma variância não maior que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variância pode variar com a taxa de amostragem, mas precisa ser limitada por esse valor. Em outras palavras, se você medir a variância do giroscópio a uma taxa de amostragem de 1 Hz, ela NÃO DEVE ser maior que 1e-7 rad^2/s^2.
[C-SR-2] É ALTAMENTE RECOMENDADO que o erro de calibragem seja menor que 0,01 rad/s quando o dispositivo estiver parado à temperatura ambiente.
[C-SR-3] É ALTAMENTE RECOMENDADO que tenham uma resolução de 16 bits ou mais.
DEVE informar eventos de até pelo menos 200 Hz.

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

[C-2-1] É obrigatório implementar o sensor TYPE_GYROSCOPE.
[C-SR-4] É altamente recomendável implementar o sensor TYPE_GYROSCOPE_UNCALIBRATED.

Se as implementações de dispositivos 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] É ALTAMENTE RECOMENDADO implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Se as implementações de dispositivos incluírem um giroscópio de três eixos, um sensor de acelerômetro e um sensor de magnetômetro, eles:

[C-4-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

Se as implementações de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, elas:

[C-5-1] PRECISA 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 atmosférica).

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

[C-1-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_PRESSURE.
[C-1-2] PRECISA ser capaz de gerar eventos a 5 Hz ou mais.
[C-1-3] PRECISA ter compensação de temperatura.
[C-SR-2] É ALTAMENTE RECOMENDADO para poder informar medições de pressão no intervalo de 300 hPa a 1.100 hPa.
PRECISA ter uma acurácia absoluta de 1 hPa.
DEVE ter uma acurácia relativa de 0,12 hPa em uma faixa de 20 hPa (equivalente a uma acurácia de ~1 m em uma mudança de ~200 m ao nível do mar).

Implementações de dispositivos que declaram a propriedade do sistema sensor.barometer.high_quality.implemented:

[C-2-1] PRECISA informar medições de pressão no intervalo de 300 hPa a 1.100 hPa, com uma precisão absoluta de +/- 1 hPa.
[C-2-2] PRECISA ter uma acurácia relativa de 0,15 hPa em um intervalo de 100 hPa, equivalente a uma acurácia de ~1 m em uma mudança de ~1.000 m ao nível do mar.
[C-2-3] PRECISA ser estável em +/- 0, 5 hPa quando o usuário toca, pressiona ou aperta o dispositivo.
[C-2-4] PRECISA ser estável em +/- 0,15 hPa quando o usuário caminha com o dispositivo na mão ou no bolso.
[C-2-5] NÃO PODE ser suavizado com uma constante de tempo maior que 300 ms para ativações acima de 5 Hz, e a suavização NÃO PODE vazar entre as ativações do sensor.
[C-2-6] Precisa ser estável em +/- 0,15 hPa quando exposto à iluminação e às radiofrequências do dia a dia introduzidas por fontes comuns, como Bluetooth, conexão celular ou Wi-Fi.

7.3.6. Termômetro

Se as implementações de dispositivos incluírem um termômetro ambiente (sensor de temperatura), elas:

[C-1-1] PRECISA definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura ambiente, e o sensor PRECISA medir a temperatura ambiente (ambiente/cabine do veículo) de onde o usuário está interagindo com o dispositivo em graus Celsius.

Se as implementações de dispositivos incluírem um sensor de termômetro que mede uma temperatura diferente da ambiente, como a da CPU, elas:

[C-2-1] NÃO PODE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura.

Se as implementações de dispositivos 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 de dispositivos incluírem um sensor de proximidade e relatarem apenas uma leitura binária "perto" ou "longe", elas:

[C-1-1] PRECISA medir a proximidade de um objeto na mesma direção da tela. Ou seja, o sensor de proximidade PRECISA estar orientado para detectar objetos próximos à tela, já que a principal finalidade desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se as implementações de dispositivos incluírem um sensor de proximidade com qualquer outra orientação, ele NÃO DEVE estar acessível por essa API.
[C-1-2] PRECISA ter 1 bit de precisão ou mais.
[C-1-3] É OBRIGATÓRIO usar 0 centímetro como leitura próxima e 5 centímetros como leitura distante.
[C-1-4] MUST report a maximum range and resolution of 5.

7.3.9. Sensores de alta fidelidade

Se as implementações de dispositivos incluírem um conjunto de sensores de qualidade superior, conforme definido nesta seção, e os disponibilizarem para apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO identificar a capability usando a flag de recurso android.hardware.sensor.hifi_sensors.

Se as implementações de dispositivos declararem android.hardware.sensor.hifi_sensors, elas:

[C-2-1] PRECISA 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 menos.
- Precisa ter uma frequência máxima de medição de 400 Hz ou mais. Deve ser compatível com o SensorDirectChannel RATE_VERY_FAST.
- PRECISA ter um ruído de medição não superior a 400 μg/√Hz.
- PRECISA implementar uma forma não ativada desse sensor com capacidade de buffer de pelo menos 3.000 eventos de sensor.
- PRECISA ter um consumo de energia em lote não pior que 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.
- PRECISA ter uma caminhada aleatória de aceleração menor que 30 μg √Hz testada em temperatura ambiente.
- DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 1 mg/°C.
- PRECISA ter uma não linearidade da linha de ajuste ideal de ≤ 0,5% e uma mudança de sensibilidade em relação à temperatura de ≤ 0,03%/°C.
- DEVE ter sensibilidade entre eixos < 2,5 % e variação de sensibilidade entre eixos < 0,2% na faixa de temperatura de operação do dispositivo.
[C-2-2] PRECISA ter um TYPE_ACCELEROMETER_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_ACCELEROMETER.
[C-2-3] PRECISA 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 menos.
- Precisa ter uma frequência máxima de medição de 400 Hz ou mais. Deve ser compatível com o SensorDirectChannel RATE_VERY_FAST.
- PRECISA ter um ruído de medição não 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 caminhada aleatória de taxa menor que 0,001°/s √Hz testada em 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.
- PRECISA ter uma não linearidade de linha de regressão ajustada de ≤ 0,2%.
- DEVE ter uma densidade de ruído de ≤ 0,007°/s/√Hz.
- DEVE ter um erro de calibragem menor que 0,002 rad/s na faixa de temperatura de 10 a 40 ℃ quando o dispositivo estiver parado.
- DEVE ter sensibilidade a g menor que 0,1&°/s/g.
- DEVE ter sensibilidade entre eixos < 4,0 % e variação de sensibilidade entre eixos < 0,3% no intervalo de temperatura de operação do dispositivo.
[C-2-4] PRECISA ter um TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_GYROSCOPE.
[C-2-5] PRECISA ter um sensor TYPE_GEOMAGNETIC_FIELD que:
- PRECISA ter um intervalo de medição entre pelo menos -900 e +900 μT.
- PRECISA ter uma resolução de medição de pelo menos 5 LSB/uT.
- Precisa ter uma frequência mínima de medição de 5 Hz ou menos.
- PRECISA ter uma frequência máxima de medição de 50 Hz ou mais.
- PRECISA ter um ruído de medição não superior a 0,5 uT.
[C-2-6] PRECISA ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_GEOMAGNETIC_FIELD e, além disso:
- PRECISA implementar uma forma não ativadora desse sensor com capacidade de buffer de pelo menos 600 eventos de 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 atualização é de 50 Hz ou mais.
[C-2-7] PRECISA 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 mínima de medição de 1 Hz ou menos.
- Precisa ter uma frequência máxima de medição de 10 Hz ou mais.
- Precisa ter um ruído de medição não superior a 2 Pa/√Hz.
- PRECISA implementar uma forma não wake-up desse sensor com uma capacidade de buffer de pelo menos 300 eventos de sensor.
- Precisa ter um consumo de energia em lote não pior que 2 mW.
[C-2-8] PRECISA ter um sensor TYPE_GAME_ROTATION_VECTOR.
[C-2-9] PRECISA ter um sensor TYPE_SIGNIFICANT_MOTION que:
- Precisa ter um consumo de energia não superior a 0,5 mW quando o dispositivo está estático e 1,5 mW quando ele está em movimento.
[C-2-10] PRECISA ter um sensor TYPE_STEP_DETECTOR que:
- PRECISA implementar uma forma não ativada por despertar desse sensor com capacidade de buffer de pelo menos 100 eventos de sensor.
- Precisa ter um consumo de energia não superior a 0,5 mW quando o dispositivo está estático e 1,5 mW quando ele está em movimento.
- PRECISA ter um consumo de energia em lote não pior que 4 mW.
[C-2-11] PRECISA ter um sensor TYPE_STEP_COUNTER que:
- Precisa ter um consumo de energia não superior a 0,5 mW quando o dispositivo está estático e 1,5 mW quando ele está em movimento.
[C-2-12] PRECISA ter um sensor TILT_DETECTOR que:
- Precisa ter um consumo de energia não superior a 0,5 mW quando o dispositivo está estático e 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, giroscópio e magnetômetro PRECISA estar dentro de 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] PRECISA ter carimbos de data/hora de eventos do sensor de giroscópio na mesma base de tempo que o subsistema de câmera e com um erro de até 1 milissegundo.
[C-2-15] É OBRIGATÓRIO entregar amostras aos aplicativos em até 5 milissegundos a partir do momento em que os dados ficam disponíveis em qualquer um dos sensores físicos acima.
[C-2-16] NÃO PODE ter um consumo de energia maior que 0,5 mW quando o dispositivo está parado 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 presente, DEVE ter uma capacidade mínima de buffer de 100 eventos de sensor.

Observe que todos os requisitos de consumo de energia nesta seção não incluem o consumo de energia do processador de aplicativos. Isso inclui a energia consumida por toda a cadeia de sensores: o sensor, qualquer circuito de suporte, qualquer sistema dedicado de processamento de sensores etc.

Se as implementações de dispositivos incluírem suporte direto a sensores, elas:

[C-3-1] PRECISA declarar corretamente o suporte a tipos de canais diretos e níveis de taxas de relatórios diretos usando as APIs isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
[C-3-2] PRECISA oferecer suporte a pelo menos um dos dois tipos de canal direto do sensor para todos os sensores que declaram suporte a esse tipo de canal.
- 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 não wake-up) 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 a documentação sobre como medir a segurança biométrica.

Se as implementações de dispositivos incluírem uma tela de bloqueio segura, elas:

DEVE incluir um sensor biométrico

Os sensores biométricos podem ser classificados como Classe 3 (antiga Forte),

Classe 2 (antes Fraca) ou Classe 1 (antes Conveniência) com base nas taxas de aceitação de spoofing e 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. As biometrias de Classe 2 e Classe 3 recebem recursos adicionais, conforme detalhado abaixo.

Se as implementações de dispositivos disponibilizarem um sensor biométrico para aplicativos de terceiros usando android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, elas:

[C-4-1] PRECISA atender aos requisitos de biometria de Classe 3 ou Classe 2, conforme definido neste documento.
[C-4-2] PRECISA reconhecer e respeitar cada nome de parâmetro definido como uma constante na classe Authenticators e qualquer combinação deles. Por outro lado, NÃO DEVE honrar ou reconhecer constantes inteiras transmitidas para os métodos canAuthenticate(int) e setAllowedAuthenticators(int) que não sejam aqueles documentados como constantes públicas em Authenticators e qualquer combinação deles.
[C-4-3] É OBRIGATÓRIO implementar a ação ACTION_BIOMETRIC_ENROLL em dispositivos com biometria de classe 3 ou classe 2. Essa ação SÓ PODE apresentar os pontos de entrada de inscrição para biometria de Classe 3 ou Classe 2.
[C-4-4] É OBRIGATÓRIO 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, ocultem ou truncam esse conteúdo podem ser feitos (como mudar a posição, o padding, as margens e a tipografia).

Se as implementações de dispositivos forem compatíveis com biometria passiva, elas:

[C-5-1] Por padrão, DEVE exigir uma etapa de confirmação adicional (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 uma violação do sistema operacional ou do kernel não possa falsificá-la. Por exemplo, isso significa que a ação de confirmação baseada em um botão físico é encaminhada por um pino de entrada/saída (GPIO) de uso geral somente de entrada de um elemento de segurança (SE) que não pode ser acionado por nenhum outro meio além de um botão físico.
[C-5-2] Também é 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 em fluxos de login.

Se as implementações de dispositivos tiverem vários sensores biométricos, eles:

[C-7-1] DEVE, quando uma biometria estiver em bloqueio (ou seja, a biometria está desativada até que o usuário desbloqueie com a autenticação principal) ou bloqueio por tempo (ou seja, a biometria está temporariamente desativada até que o usuário aguarde um intervalo de tempo) devido a muitas tentativas com falha, também bloquear todas as outras biometrias de uma classe biométrica inferior. No caso de bloqueio por tempo limitado, o tempo de espera para verificação biométrica PRECISA ser o tempo máximo de espera de todas as biometrias no bloqueio por tempo limitado.
[C-SR-12] É ALTAMENTE RECOMENDADO que, quando uma biometria estiver bloqueada (ou seja, a biometria será desativada até que o usuário desbloqueie com a autenticação principal) ou bloqueada por tempo (ou seja, a biometria será desativada temporariamente até que o usuário aguarde um intervalo de tempo) devido a muitas tentativas com falha, todas as outras biometrias da mesma classe biométrica também sejam bloqueadas. No caso de bloqueio por tempo limitado, é FORTEMENTE RECOMENDADO que o tempo de espera para verificação biométrica seja o tempo máximo de espera de todas as biometrias no bloqueio por tempo limitado.
[C-7-2] PRECISA desafiar o usuário a usar a autenticação principal recomendada (como PIN, padrão ou senha) para redefinir o contador de bloqueio de uma biometria bloqueada. A biometria de classe 3 PODE ser permitida para redefinir o contador de bloqueio de uma biometria bloqueada da mesma classe ou de uma classe inferior. As biometrias de classe 2 ou classe 1 NÃO PODEM concluir uma operação de bloqueio de redefinição para nenhuma biometria.
[C-SR-3] É ALTAMENTE RECOMENDADO que apenas uma biometria seja confirmada por autenticação. Por exemplo, se os sensores de impressão digital e de rosto estiverem disponíveis no dispositivo, onAuthenticationSucceeded deverá ser enviado depois que um deles for confirmado.

Para que as implementações de dispositivos permitam o acesso a chaves do keystore por aplicativos de terceiros, elas precisam:

[C-6-1] PRECISA atender aos requisitos da Classe 3, conforme definido na seção abaixo.
[C-6-2] SÓ PODE apresentar biometria de classe 3 quando a autenticação exige BIOMETRIC_STRONG ou é invocada com um CryptoObject.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 1 (antiga Conveniência), elas precisam:

[C-1-1] PRECISA ter uma taxa de aceitação falsa menor que 0,002%.
[C-1-2] É OBRIGATÓRIO divulgar que esse modo pode ser menos seguro do que um PIN, um padrão ou uma senha fortes e enumerar claramente os riscos de ativá-lo se as taxas de aceitação de falsificação e impostor forem superiores a 7%, conforme medido pelos Protocolos de teste de biometria do Android.
[C-1-9] DEVE desafiar o usuário para a autenticação primária recomendada (por exemplo, PIN, padrão, senha) após não mais de 20 tentativas incorretas e não menos de 90 segundos de espera para verificação biométrica. Uma tentativa incorreta é 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 para a verificação biométrica especificada em [C-1-9] se as taxas de aceitação de falsificação e impostor 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. Um teste falso é aquele 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]. Uma tentativa falsa é aquela 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] É OBRIGATÓRIO desativar a biometria assim que o backoff de autenticação principal for acionado pela primeira vez, conforme descrito em [C-0-2] da seção 9.11.
[C-1-11] PRECISA ter uma taxa de aceitação de spoofing e impostores não superior a 30%, com (1) uma taxa de aceitação de spoofing e impostores para espécies de instrumento de ataque de apresentação (PAI) de nível A não superior a 30% e (2) uma taxa de aceitação de spoofing e impostores 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] DEVE impedir a adição de novas biometrias sem primeiro estabelecer uma cadeia de confiança. Para isso, o usuário precisa confirmar as credenciais de dispositivo (PIN/padrão/senha) atuais ou adicionar novas, que são protegidas pelo TEE. A implementação do Android Open Source Project fornece o mecanismo no framework para fazer isso.
[C-1-5] DEVE remover completamente todos os dados biométricos identificáveis de um usuário quando a conta dele for removida (inclusive por uma redefinição de fábrica) ou quando a autenticação principal recomendada (como PIN, padrão, senha) for removida.
[C-1-6] PRECISA respeitar a flag individual para essa biometria (ou seja, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE, ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] DEVE desafiar o usuário para a autenticação primária recomendada (como PIN, padrão, senha) uma vez a cada 24 horas ou menos.
[C-1-8] DEVE desafiar o usuário para a autenticação primária recomendada (como PIN, padrão, senha) ou biométrica de Classe 3 (FORTE) após qualquer uma das seguintes situações:
- Um período de tempo limite de inatividade de quatro horas.
- Três tentativas de autenticação biométrica falharam.
- O período de tempo limite de inatividade e a contagem de autenticações com falha são redefinidos após qualquer confirmação bem-sucedida das credenciais do dispositivo.
[C-SR-7] É ALTAMENTE RECOMENDADO usar a lógica no framework fornecido pelo Android Open Source Project para aplicar as restrições especificadas em [C-1-7] e [C-1-8] para novos dispositivos.
[C-SR-8] É ALTAMENTE RECOMENDADO que tenham uma taxa de rejeição falsa de menos de 10%, medida no dispositivo.
[C-SR-9] É ALTAMENTE RECOMENDADO que tenham 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] PRECISA ter uma taxa de aceitação de spoofing e impostor não superior a 40% por espécie de instrumento de ataque de apresentação (PAI), conforme medido pelos Protocolos de teste de biometria do Android.
[C-SR-13] É ALTAMENTE RECOMENDÁVEL ter uma taxa de aceitação de falsificação e impostor não superior a 30% por espécie de instrumento de ataque de apresentação (PAI), conforme medido pelos protocolos de teste de biometria do Android.
[C-SR-8] É ALTAMENTE RECOMENDADO que tenham uma taxa de rejeição falsa de menos de 10%, medida no dispositivo.
[C-1-15] DEVE permitir que os usuários removam um ou vários registros biométricos.
[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 dispositivos quiserem tratar um sensor biométrico como Classe 2 (antiga Fraca), elas precisam:

[C-2-1] PRECISA atender a todos os requisitos da Classe 1 acima.
[C-2-2] DEVE 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) 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 impostor não superior a 20% por espécie de instrumento de ataque de apresentação (PAI), conforme medido pelos Protocolos de teste de biometria do Android.
[C-2-3] PRECISA 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] PRECISA ter todos os dados identificáveis criptografados e autenticados criptograficamente para 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 Android Open Source Project 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 está em andamento:
- É NECESSÁRIO operar a câmera em um modo que impeça a leitura ou alteração de frames fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado ou uma máquina virtual protegida controlada por um hipervisor que atenda aos requisitos da Seção 9.17.
- Para soluções RGB de câmera única, os frames da câmera PODEM ser legíveis fora do ambiente de execução isolado para oferecer suporte a operações como visualização para inscrição, mas NÃO PODEM ser alterados.
[C-2-6] NÃO PODE permitir que aplicativos de terceiros façam distinção entre registros biométricos individuais.
[C-2-7] NÃO PODE permitir acesso não criptografado a dados biométricos identificáveis ou a dados derivados deles (como incorporações) ao processador de aplicativos fora do contexto do TEE ou da máquina virtual protegida controlada pelo hipervisor que atende aos requisitos da Seção 9.17. Os dispositivos lançados com a versão 9 ou anterior do Android não estão isentos da [C-2-7].
[C-2-8] PRECISA ter um pipeline de processamento seguro para que uma violação do sistema operacional ou do kernel não permita que os dados sejam injetados diretamente para autenticação falsa como o usuário.

Observação: se as implementações de dispositivos já tiverem sido lançadas no Android versão 9 ou anterior e não atenderem ao requisito [C-2-8] por uma atualização de software do sistema, elas PODEM ser isentas do requisito.
[C-SR-10] É ALTAMENTE RECOMENDADO incluir detecção de atividade para todas as modalidades biométricas e detecção de atenção para biometria facial.
[C-2-9] DEVE disponibilizar o sensor biométrico para aplicativos de terceiros.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 3 (antes Forte), elas precisam:

[C-3-1] PRECISA atender a todos os requisitos da Classe 2 acima, exceto [C-1-7] e [C-1-8].
[C-3-2] PRECISA ter uma implementação de keystore com suporte de hardware.
[C-3-3] DEVE 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) 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 ou senha) a cada 72 horas ou menos.
[C-3-5] É OBRIGATÓRIO gerar novamente o ID do autenticador para todas as biometrias de classe 3 compatíveis com o dispositivo se alguma delas for registrada novamente.
[C-3-6] É necessário ativar chaves do keystore com suporte biométrico para aplicativos de terceiros.
[C-SR-16] É ALTAMENTE RECOMENDÁVEL ter uma taxa de aceitação de falsificação e impostor não superior a 7% por espécie de instrumento de ataque de apresentação (PAI), conforme medido pelos Protocolos de teste de biometria do Android.

Se as implementações de dispositivos contiverem um sensor de impressão digital sob a tela (UDFPS), elas:

[C-SR-11] É ALTAMENTE RECOMENDADO para evitar que a área de toque do UDFPS interfira na navegação com três botões, que alguns usuários podem precisar para fins de acessibilidade.

7.3.11. Sensor de postura

Implementações de dispositivos:

PODE oferecer suporte a sensor de postura com 6 graus de liberdade.

Se as implementações de dispositivos forem compatíveis com o sensor de postura com 6 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 apenas o vetor de rotação.

7.3.12. Sensor de ângulo de articulação

Se as implementações de dispositivos forem compatíveis com um sensor de ângulo de articulação, elas:

[C-1-1] É OBRIGATÓRIO implementar e informar TYPE_HINGE_ANGLE.
[C-1-2] PRECISA oferecer suporte a pelo menos duas leituras entre 0 e 360 graus (inclusive, ou seja, incluindo 0 e 360 graus).
[C-1-3] PRECISA 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 de dispositivos incluírem suporte para 802.1.15.4 e expuserem a funcionalidade a um aplicativo de terceiros, elas:

[C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.uwb.
[C-1-3] PRECISA oferecer suporte a todos os seguintes conjuntos de configuração (combinações predefinidas de parâmetros da FIRA UCI) definidos na implementação do AOSP.
- CONFIG_ID_1: alcance de unicast STATIC STS DS-TWR definido pela FiRa, modo adiado, intervalo de alcance de 240 ms.
- CONFIG_ID_2: alcance de STATIC STS DS-TWR de um para muitos definido pela FiRa, modo adiado, intervalo de alcance de 200 ms. Caso de uso típico: um smartphone interage com muitos dispositivos inteligentes.
- CONFIG_ID_3: igual a CONFIG_ID_1, mas 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 controle individual e chave do P-STS está ativado.
[C-1-4] PRECISA oferecer uma opção para que o usuário alterne o estado de ativação/desativação do rádio UWB.
[C-1-5] É OBRIGATÓRIO 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 de padrões, incluindo FIRA, CCC e CSA, ajuda a garantir que o 802.1.15.4 funcione corretamente.

7.3.14. Sensores personalizados

Para ajudar a oferecer uma experiência diferenciada, as implementações de dispositivos PODEM incluir sensores adicionais não cobertos pelo Android ou Wear OS, que os apps pré-carregados podem acessar.

Para esses sensores, o ID do sensor:

[C-0-1] PRECISA ser maior que 65536.

Se o sensor personalizado for destinado a fins relacionados à saúde ou ao condicionamento físico, ele:

[C-0-2] PRECISA ser protegido por uma permissão de plataforma ou de sistema.

7.4. Conectividade de dados

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android e neste documento, refere-se 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). Um dispositivo compatível com "Telefonia" pode oferecer alguns ou todos os serviços de chamada, mensagens e dados, conforme a adequação ao 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] PRECISA declarar a flag de recurso android.hardware.telephony e outras flags de sub-recursos de acordo com a tecnologia.
[C-1-2] PRECISA implementar suporte total à API para essa tecnologia.
DEVE permitir todos os tipos de serviços de celular disponíveis (2G, 3G, 4G, 5G etc.) durante chamadas de emergência (independente dos tipos de rede definidos por SetAllowedNetworkTypeBitmap()).

Se as implementações de dispositivos não incluírem hardware de telefonia, elas:

[C-2-1] Precisa implementar as APIs completas como ambiente autônomo.

Se as implementações de dispositivos forem compatíveis com eUICCs ou eSIMs/chips integrados e incluírem um mecanismo proprietário para disponibilizar a funcionalidade de eSIM para desenvolvedores de terceiros, elas:

[C-3-1] PRECISA declarar a flag de recurso android.hardware.telephony.euicc.

Se as implementações de dispositivos não definirem a propriedade do sistema ro.telephony.iwlan_operation_mode como legacy, elas:

[C-4-1] NÃO PODE informar NETWORK_TYPE_IWLAN via NetworkRegistrationInfo#getAccessNetworkTechnology() quando NetworkRegistrationInfo#getTransportType() é informado como TRANSPORT_TYPE_WWAN para a mesma instância NetworkRegistrationInfo.

Se as implementações de dispositivos oferecerem suporte a um único registro do subsistema multimídia IP (IMS) para recursos de serviço de telefonia multimídia (MMTEL) e serviço de comunicação avançada (RCS) e precisarem obedecer aos requisitos da operadora de celular sobre o uso de um único registro do IMS para todo o tráfego de sinalização do IMS, elas:

[C-5-1] É OBRIGATÓRIO 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] É OBRIGATÓRIO 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 a HAL IRadio 1.6 e provisionamento pelo servidor de configuração automática (ACS) ou outro mecanismo de provisionamento proprietário usando a API IMS Configuration.

Se as implementações de dispositivos informarem o recurso android.hardware.telephony:

[C-6-1] SmsManager#sendTextMessage e SmsManager#sendMultipartTextMessage precisam resultar em chamadas correspondentes para CarrierMessagingService para fornecer funcionalidade de mensagens de texto. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer 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 do correio de voz visual aos usuários se ela for compatível com transcrições de correio de voz visual.
[C-6-5] PRECISA representar todas as SubscriptionInfo com UUIDs de grupo equivalentes como uma única assinatura em todas as opções visíveis ao usuário que mostram e controlam informações do chip. Exemplos dessas 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 PODE mostrar nem permitir o controle de nenhum SubscriptionInfo com um UUID de grupo não nulo e um bit oportunista em nenhuma affordance visível ao usuário que permita a configuração ou o controle das configurações do chip SIM.

Se as implementações de 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 do grupo para mostrar ao usuário em qualquer recurso que forneça informações sobre o status do SIM. Exemplos dessas affordances incluem o ícone de sinal celular na barra de status ou o bloco de Configurações Rápidas.
[C-SR-1] É ALTAMENTE RECOMENDADO que a assinatura representativa seja escolhida como a assinatura de dados ativa, a menos que o dispositivo esteja em uma chamada de voz. Nesse caso, é ALTAMENTE RECOMENDADO que a assinatura representativa seja a assinatura de voz ativa.

Se as implementações de dispositivos informarem o recurso android.hardware.telephony:

[C-6-7] PRECISA 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 a ETSI TS 102 221.
[C-6-8] NÃO PODE aplicar nenhum dos seguintes comportamentos a apps de operadora ativos (conforme designado por TelephonyManager#getCarrierServicePackageName) de forma automática ou sem 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 de dispositivo informarem o recurso android.hardware.telephony e todas as assinaturas não oportunistas ativas que compartilham um UUID de grupo forem desativadas, removidas fisicamente do dispositivo ou marcadas como oportunistas, o dispositivo:

[C-8-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.

Se as implementações de dispositivos incluírem telefonia GSM, mas não CDMA, elas:

[C-9-1] NÃO PODE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
[C-9-2] MUST lançar um IllegalArgumentException ao tentar definir qualquer tipo de rede 3GPP2 em máscaras de bits de tipo de rede preferencial ou permitida.
[C-9-3] MUST return an empty string from TelephonyManager#getMeid.

Se as implementações de dispositivos forem compatíveis com eUICC com várias portas e perfis, elas:

[C-10-1] PRECISA declarar a flag de recurso android.hardware.telephony.euicc.mep.

Se as implementações de dispositivos forem compatíveis com conectividade de dados móveis, elas:

[C-SR-11] É ALTAMENTE RECOMENDADO declarar o recurso android.hardware.telephony.data.

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

[C-12-1] PRECISA oferecer suporte a pelo menos duas conexões simultâneas de rede de dados móveis, como contextos PDP, conexões PDN e conexões DN.

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] PRECISA incluir suporte ao bloqueio de números
[C-1-2] PRECISA implementar totalmente BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.
[C-1-3] PRECISA bloquear todas as chamadas e mensagens de um número de telefone em BlockedNumberProvider sem qualquer interação com apps. A única exceção é quando o bloqueio de números é temporariamente suspenso, conforme descrito na documentação do SDK.
[C-1-4] É OBRIGATÓRIO gravar no provedor de registro de chamadas da plataforma uma chamada bloqueada e filtrar as chamadas com BLOCKED_TYPE da visualização padrão do registro de chamadas no app discador pré-instalado.
[C-1-5] NÃO PODE gravar no provedor de telefonia para uma mensagem bloqueada.
[C-1-6] É OBRIGATÓRIO 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 PODE permitir que usuários secundários vejam ou editem os números bloqueados no dispositivo, já que a plataforma Android pressupõe que o usuário principal tenha controle total dos serviços de telefonia, uma única instância, no dispositivo. Toda a interface relacionada ao bloqueio precisa ser ocultada para usuários secundários, e a lista de bloqueio ainda precisa ser respeitada.
DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.
DEVE oferecer ao usuário uma opção para mostrar as chamadas bloqueadas no app de discador pré-instalado.

7.4.1.2. API Telecom

Se as implementações de dispositivos declararem android.hardware.microphone e android.hardware.audio.output, mas não declararem android.hardware.type.television, elas:

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

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

[C-1-1] PRECISA oferecer suporte às APIs ConnectionService descritas no SDK.
[C-1-2] PRECISA mostrar uma nova chamada recebida e oferecer ao usuário a opção de aceitar ou rejeitar a chamada recebida quando ele estiver em uma chamada em andamento feita por um app de terceiros que não oferece suporte ao recurso de espera especificado via CAPABILITY_SUPPORT_HOLD.
[C-1-3] PRECISA ter um aplicativo que implemente InCallService.
[C-SR-1] É ALTAMENTE RECOMENDADO notificar o usuário de que atender uma chamada recebida vai 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 vai fazer com que a outra chamada seja desconectada.
[C-SR-2] É ALTAMENTE RECOMENDADO pré-carregar o app discador 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 como true.
[C-SR-3] É FORTEMENTE RECOMENDADO processar os eventos KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK do headset de áudio para as APIs android.telecom da seguinte forma:
- Chame Connection.onDisconnect() quando um toque rápido no evento principal for detectado durante uma chamada em andamento.
- Chame Connection.onAnswer() quando um toque rápido no evento principal for detectado durante uma chamada recebida.
- Chame Connection.onReject() quando uma pressão longa do evento principal for detectada durante uma chamada recebida.
- Ativar ou desativar o som do CallAudioState.

7.4.1.3. Descarga de sinal de atividade NAT-T celular

Implementações de dispositivos:

DEVE incluir suporte para o descarregamento de keepalive celular.

Se as implementações de dispositivos incluírem suporte para o descarregamento de keepalive celular e expuserem a funcionalidade a apps de terceiros, elas:

[C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
[C-1-2] PRECISA oferecer suporte a pelo menos um slot de keepalive simultâneo em redes celulares.
[C-1-3] DEVE oferecer suporte ao máximo de slots de manutenção de atividade celular simultâneos que a HAL de rádio celular oferece.
[C-SR-1] É FORTEMENTE RECOMENDADO que haja suporte para 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 para o descarregamento de keepalive celular, elas:

[C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementações de dispositivos:

DEVE incluir suporte para uma ou mais formas de 802.11.

Se as implementações de dispositivos incluírem suporte para 802.11 e expuserem a funcionalidade a um aplicativo de terceiros, elas:

[C-1-1] É necessário implementar a API Android correspondente.
[C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.wifi.
[C-1-3] É OBRIGATÓRIO implementar a API de multicast conforme descrito na documentação do SDK.
[C-1-4] DEVE oferecer suporte a mDNS e NÃO DEVE filtrar pacotes mDNS (224.0.0.251 ou ff02::fb) em nenhum momento da operação, incluindo quando a tela não está em um estado ativo, a menos que o bloqueio de multicast não esteja ativado e os pacotes sejam filtrados pelo APF. Os pacotes não precisam atender a nenhuma operação mDNS solicitada por aplicativos pelas APIs NsdManager. No entanto, o dispositivo PODE filtrar pacotes mDNS se isso for necessário para ficar dentro dos intervalos de consumo de energia exigidos por requisitos regulamentares aplicáveis ao mercado-alvo.
[C-1-5] NÃO PODE tratar a chamada de método da API WifiManager.enableNetwork() como uma indicação suficiente para alternar o Network ativo no momento, que é usado por padrão para o tráfego de aplicativos e retornado pelos métodos da API ConnectivityManager, como getActiveNetwork e registerDefaultNetworkCallback. Em outras palavras, eles SÓ PODEM 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 oferece mais acesso à Internet, mude para qualquer outra rede disponível (por exemplo, dados móveis) que ofereça acesso à Internet.
[C-1-7] DEVE aleatorizar 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] MUST use one consistent MAC address (SHOULD NOT randomize MAC address halfway through a scan).
[C-1-9] DEVE iterar o número de sequência da solicitação de sondagem normalmente (em sequência) entre as solicitações de sondagem em uma varredura.
[C-1-10] É OBRIGATÓRIO aleatorizar 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 após a 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 aleatorização por SSID (FQDN para Passpoint) com opções não aleatórias e aleatórias, e PRECISA definir o modo padrão para novas configurações de Wi-Fi como aleatório.
[C-SR-2] É ALTAMENTE RECOMENDADO usar um BSSID aleatório para qualquer AP que eles criarem.
- O endereço MAC PRECISA ser randomizado e mantido por SSID usado pelo AP.
- O DISPOSITIVO PODE oferecer ao usuário a opção de desativar esse recurso. Se uma opção desse tipo for fornecida, a randomização DEVERÁ 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:

DESATIVAR o modo de economia de energia do Wi-Fi sempre que um app adquirir um bloqueio WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY pelas APIs WifiManager.createWifiLock() eWifiManager.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 baixa latência do Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) PRECISA ser menor do que a latência durante o modo de bloqueio de alta performance do Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
[C-SR-3] SÃO FORTEMENTE RECOMENDADOS para minimizar a latência de ida e volta do Wi-Fi sempre que um bloqueio de baixa latência (WIFI_MODE_FULL_LOW_LATENCY) é adquirido e entra em vigor.

Se as implementações de dispositivos forem compatíveis com Wi-Fi e usarem Wi-Fi para a busca de localização, elas:

[C-2-1] PRECISA fornecer uma ação do usuário para ativar/desativar a leitura de valores 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 incluírem suporte para Wi-Fi Direct, elas:

[C-1-1] É OBRIGATÓRIO implementar a API Android correspondente conforme descrito na documentação do SDK.
[C-1-2] PRECISA informar o recurso de hardware android.hardware.wifi.direct.
[C-1-3] PRECISA oferecer suporte à operação normal de Wi-Fi.
[C-1-4] PRECISA oferecer suporte a operações simultâneas de Wi-Fi e Wi-Fi Direct.
[C-SR-1] É ALTAMENTE RECOMENDADO escolher o endereço MAC de origem de forma aleatória para todas as conexões Wi-Fi Direct recém-formadas.

7.4.2.2. Configuração de link direto em túnel Wi-Fi

Implementações de dispositivos:

DEVE incluir suporte para Configuração de link direto em túnel Wi-Fi (TDLS) conforme descrito na documentação do SDK do Android.

Se as implementações de dispositivos incluírem suporte para TDLS e o TDLS for ativado pela API WiFiManager, elas:

[C-1-1] É OBRIGATÓRIO declarar a compatibilidade com TDLS usando WifiManager.isTdlsSupported.
USE TDLS somente 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:

DEVE incluir suporte para Wi-Fi Aware.

Se as implementações de dispositivos incluírem suporte ao Wi-Fi Aware e expuserem 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] PRECISA declarar a flag de recurso android.hardware.wifi.aware.
[C-1-3] PRECISA oferecer suporte a operações simultâneas de Wi-Fi e Wi-Fi Aware.
[C-1-4] DEVE randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de no máximo 30 minutos e sempre que o Wi-Fi Aware estiver ativado, a menos que uma operação de alcance do Aware esteja em andamento ou um caminho de dados do Aware esteja ativo. A randomização não é esperada enquanto o caminho de dados estiver ativo.

Se as implementações de dispositivos incluírem suporte para Wi-Fi Aware e localização por Wi-Fi, conforme descrito na Seção 7.4.2.5, e expuserem essas funcionalidades a apps de terceiros, elas:

[C-2-1] É OBRIGATÓRIO implementar as APIs de descoberta com reconhecimento de local: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint do Wi-Fi

Se as implementações de dispositivos incluírem suporte para 802.11 (Wi-Fi), elas:

DEVE incluir suporte para Wi-Fi Passpoint.

Se as implementações de dispositivos incluírem suporte para o Wi-Fi Passpoint, elas:

[C-1-2] PRECISA implementar as APIs WifiManager relacionadas ao Passpoint conforme descrito na documentação do SDK.
[C-1-3] PRECISA oferecer suporte ao padrão IEEE 802.11u, especificamente relacionado à descoberta e seleção de rede, como o serviço de publicidade genérico (GAS) e o protocolo de consulta de rede de acesso (ANQP).
[C-1-4] PRECISA declarar a flag de recurso android.hardware.wifi.passpoint.
[C-1-5] PRECISA seguir a implementação do AOSP para descobrir, corresponder e associar a redes Passpoint.
[C-1-6] PRECISA oferecer suporte a pelo menos o seguinte subconjunto de protocolos de provisionamento de dispositivos, conforme definido no Passpoint R2 da Wi-Fi Alliance: autenticação EAP-TTLS e SOAP-XML.
[C-1-7] PRECISA processar o certificado do servidor AAA conforme descrito na especificação do Hotspot 2.0 R3.
[C-1-8] PRECISA oferecer suporte ao controle do usuário do provisionamento pelo seletor de Wi-Fi.
[C-1-9] É OBRIGATÓRIO manter as configurações do Passpoint persistentes durante as reinicializações.
[C-SR-1] É ALTAMENTE RECOMENDADO para oferecer suporte ao recurso de aceitação dos Termos e Condições.
[C-SR-2] É FORTEMENTE RECOMENDADO para oferecer suporte ao recurso de informações do local.

Se um interruptor de controle do usuário para desativação global do Passpoint for fornecido, as implementações:

[C-3-1] PRECISA ativar o Passpoint por padrão.

7.4.2.5. Localização de Wi-Fi (tempo de retorno do Wi-Fi - RTT)

Implementações de dispositivos:

DEVE incluir suporte para localização por Wi-Fi.

Se as implementações de dispositivos incluírem suporte para localização por Wi-Fi e expuserem 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] PRECISA declarar a flag de recurso android.hardware.wifi.rtt.
[C-1-3] É OBRIGATÓRIO escolher o endereço MAC de origem de forma aleatória para cada sequência de RTT executada enquanto a interface Wi-Fi em que o RTT está sendo executado não está associada a um ponto de acesso.
[C-1-4] PRECISA ter uma precisão de até 2 metros com largura de banda de 80 MHz no 68º percentil (calculado com a função de distribuição cumulativa).
[C-SR-1] É ALTAMENTE RECOMENDADO informar com precisão em até 1,5 metro na largura de banda de 80 MHz no percentil 68 (calculado com a função de distribuição cumulativa).

7.4.2.6. Descarga de sinal de atividade do Wi-Fi

Implementações de dispositivos:

DEVE incluir suporte para o descarregamento de keepalive do Wi-Fi.

Se as implementações de dispositivos incluírem suporte para o descarregamento de keepalive do Wi-Fi e expuserem a funcionalidade a apps de terceiros, elas:

[C-1-1] MUST support the SocketKeepAlive API.
[C-1-2] PRECISA oferecer 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 para o descarregamento de manutenção de atividade 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 para o Wi-Fi Easy Connect e expuserem 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 Wi-Fi empresarial

Se o certificado do servidor Wi-Fi não for validado ou o nome de domínio do servidor Wi-Fi não for definido, as implementações de dispositivo:

[C-SR-1] É FORTEMENTE RECOMENDADO não oferecer ao usuário uma opção para adicionar manualmente uma rede Wi-Fi empresarial no app Configurações.

7.4.2.9. Confiar no primeiro uso (TOFU)

Se as implementações de dispositivos forem compatíveis com a abordagem Trust on First Use (TOFU) e permitirem que o usuário defina configurações WPA/WPA2/WPA3-Enterprise, elas:

[C-4-1] PRECISA oferecer ao usuário uma opção para selecionar o uso do TOFU.

7.4.2.10. Detecção de proximidade por Wi-Fi

Se as implementações de dispositivos incluírem suporte para detecção de proximidade por Wi-Fi, elas:

[C-1-1] PRECISA incluir suporte à detecção de proximidade.
[C-1-2] PRECISA declarar a flag de recurso android.hardware.wifi.rtt.
[C-1-3] O método WifiRttManager#getProximityDetectionCharacteristics() PRECISA retornar um valor não nulo.
[C-1-4] É OBRIGATÓRIO implementar as APIs de alcance contínuo WifiRttManager.
[C-1-5] PRECISA oferecer suporte a operações de detecção de proximidade por Wi-Fi e Wi-Fi simultaneamente.
[C-1-6] PRECISA ter precisão de até 2 metros com largura de banda de 80 MHz no 68º percentil (calculado com a função de distribuição cumulativa).
[C-1-7] DEVE realizar a detecção de proximidade (PD) no intervalo de banda de frequência mais alta disponível (6 GHz, 5 GHz ou 2,4 GHz) usando a largura de banda máxima compatível na seguinte ordem de prioridade: 160 MHz, 80 MHz, 40 MHz e 20 MHz.
[C-SR-1] É ALTAMENTE RECOMENDADO informar com precisão em até 1,5 metro de largura de banda de 80 MHz no percentil 68 (calculado com a função de distribuição cumulativa).
[C-SR-2] SÃO ALTAMENTE RECOMENDADOS para oferecer suporte ao alcance NTB 802.11az.

7.4.3. Bluetooth

Se as implementações de dispositivos forem compatíveis com o perfil de áudio Bluetooth, elas:

DEVE oferecer suporte a codecs de áudio avançados e codecs de áudio Bluetooth (por exemplo, LDAC).

Se as implementações de dispositivos forem compatíveis com HFP, A2DP e AVRCP, elas:

PRECISA ser compatível com pelo menos cinco dispositivos conectados.

Se as implementações de dispositivos declararem o recurso android.hardware.vr.high_performance, elas:

[C-1-1] DEVE ser compatível com Bluetooth 4.2 e extensão de comprimento de dados Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.

Se as implementações de dispositivos incluírem 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 Bluetooth relevantes, como A2DP, AVRCP, OBEX, HFP etc., conforme apropriado para o dispositivo.

Se as implementações de dispositivos incluírem suporte para Bluetooth de baixa energia (BLE), elas:

[C-3-1] PRECISA declarar o recurso de hardware android.hardware.bluetooth_le.
[C-3-2] É OBRIGATÓRIO ativar as APIs Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e em android.bluetooth.
[C-3-3] PRECISA informar o valor correto para 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 para BluetoothAdapter.isMultipleAdvertisementSupported() e indicar se a publicidade de baixa energia é compatível.
[C-3-5] É OBRIGATÓRIO implementar um tempo limite de endereço particular resolúvel (RPA) de no máximo 15 minutos e alternar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo estiver usando ativamente o BLE para verificaçã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.
PRECISA 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 espaços.

Se as implementações de dispositivos forem compatíveis com Bluetooth LE e usarem esse recurso para verificação de localização, elas:

[C-4-1] PRECISA fornecer um recurso de usuário para ativar/desativar a leitura de valor pela API do sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se as implementações de dispositivos incluírem suporte para Bluetooth LE e o perfil de aparelhos auditivos, conforme descrito em Suporte para áudio de aparelho auditivo usando Bluetooth LE, elas:

[C-5-1] MUST return true for BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Se as implementações de dispositivos incluírem suporte para Bluetooth ou Bluetooth de baixa energia, elas:

[C-6-1] É OBRIGATÓRIO restringir o acesso a metadados do Bluetooth (como resultados de verificação) que possam ser usados para derivar a localização do dispositivo, a menos que o app solicitante passe em uma verificação de permissão android.permission.ACCESS_FINE_LOCATION com base no estado atual de primeiro/segundo plano.

Se as implementações de dispositivos incluírem suporte para Bluetooth ou Bluetooth de baixa energia e o manifesto do app não incluir uma declaração do desenvolvedor informando que não está derivando a localização do Bluetooth, elas:

[C-6-2] É OBRIGATÓRIO restringir o acesso ao Bluetooth usando o android.permission.ACCESS_FINE_LOCATION.

Se as implementações de dispositivos retornarem true para a API BluetoothAdapter.isLeAudioSupported(), elas:

[C-7-1] MUST support unicast client.
[C-7-2] DEVE oferecer suporte a PHY de 2M.
[C-7-3] PRECISA oferecer suporte à publicidade estendida LE.
[C-7-4] PRECISA oferecer suporte a pelo menos duas conexões CIS em um CIG.
[C-7-5] É OBRIGATÓRIO ativar simultaneamente o cliente unicast BAP, o coordenador do conjunto CSIP, o servidor MCP, o controlador VCP e o servidor CCP.
[C-SR-1] É ALTAMENTE RECOMENDÁVEL ativar o cliente unicast do HAP.

Se as implementações de dispositivos retornarem true para a API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), elas:

[C-8-1] É OBRIGATÓRIO oferecer suporte a pelo menos dois links BIS em um BIG.
[C-8-2] É OBRIGATÓRIO ativar a origem de transmissão BAP e o assistente de transmissão BAP simultaneamente.
[C-8-3] PRECISA oferecer suporte à publicidade periódica LE.

Se as implementações de dispositivos retornarem true para a API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), elas:

[C-9-1] Precisa ser compatível com PAST (Periodic Advertising Sync Transfer).
[C-9-2] PRECISA ser compatível com a publicidade periódica LE.

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

[C-10-1] As medições de RSSI PRECISAM estar dentro de +/-9 dB para 95% das medições a 1 m de distância de um dispositivo de referência transmitindo a ADVERTISE_TX_POWER_HIGH em um ambiente de linha de visão.
[C-10-2] DEVE incluir correções de Rx/Tx para reduzir os desvios por canal. Assim, as medições em cada um dos três canais e em cada uma das antenas (se várias forem usadas) ficam dentro de +/-3 dB umas das outras em 95% das medições.

Se as implementações de dispositivos declararem FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING, elas:

[C-11-1] MUST report the hardware feature flag android.hardware.bluetooth_le.channel_sounding.
[C-11-2] DEVE informar o intervalo com precisão de +/- 0,5 m no 90º percentil, conforme calculado com a função de distribuição cumulativa, a uma distância de 1 m.

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

[C-SR-2] É FORTEMENTE RECOMENDADO medir e compensar o deslocamento de Rx para garantir que o RSSI BLE mediano seja -60 dBm +/-10 dB a 1 m de distância de um dispositivo de referência transmitindo a ADVERTISE_TX_POWER_HIGH, em que os dispositivos são orientados de forma que estejam em "planos paralelos" com as telas voltadas para a mesma direção.
[C-SR-3] É ALTAMENTE RECOMENDADO medir e compensar o deslocamento de Tx para garantir que o RSSI BLE médio seja -60 dBm +/-10 dB ao fazer a leitura de um dispositivo de referência posicionado a 1 m de distância e transmitindo a ADVERTISE_TX_POWER_HIGH, em que os dispositivos são orientados de forma que estejam em "planos paralelos" com as telas voltadas para a mesma direção.

É ALTAMENTE RECOMENDADO 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

Implementações de dispositivos:

DEVE incluir um transceptor e hardware relacionado para comunicação a curta distância (NFC).
[C-0-1] É obrigatório implementar as APIs android.nfc.NdefMessage e android.nfc.NdefRecord, mesmo que elas não incluam suporte para NFC ou declare o recurso android.hardware.nfc, já que as classes representam um formato de representação de dados independente de protocolo.

Se as implementações de dispositivos incluírem hardware NFC e planejarem disponibilizá-lo para apps de terceiros, elas:

[C-1-1] PRECISA 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 um leitor/gravador do NFC Forum (conforme definido pela especificação técnica do NFC Forum NFCForum-TS-DigitalProtocol-1.0) usando os seguintes padrões de NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Tipos de tags 2, 3, 4 e 5 do NFC Forum (definidos pelo NFC Forum)
[C-SR-1] É ALTAMENTE RECOMENDADO que seja capaz de ler e gravar mensagens NDEF e dados brutos usando os seguintes padrões NFC. Embora os padrões NFC sejam FORTEMENTE RECOMENDADOS, a Definição de compatibilidade para uma versão futura planeja mudar isso para OBRIGATÓRIO. Esses padrões são opcionais nesta versão, mas serão obrigatórios em versões futuras. É altamente recomendável que os dispositivos atuais e novos que executam essa versão do Android atendam a esses requisitos agora para poderem fazer upgrade para as versões futuras da plataforma.
[C-1-13] É OBRIGATÓRIO fazer uma pesquisa de todas as tecnologias compatíveis no modo de descoberta NFC.
PRECISA estar no modo de descoberta NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.
PRECISA ser capaz de ler o código de barras e o URL (se codificado) dos produtos Thinfilm NFC Barcode.

Observe que os links disponíveis publicamente não estão disponíveis para as especificações JIS, ISO e NFC Forum citadas acima.

O Android inclui suporte ao modo de emulação de cartão host (HCE) do NFC.

Se as implementações de dispositivos incluírem um chipset de controlador NFC compatível com HCE (para NfcA e/ou NfcB) e forem compatíveis com o roteamento de ID do aplicativo (AID), elas:

[C-2-1] PRECISA informar a constante de recurso android.hardware.nfc.hce.
[C-2-2] DEVE oferecer suporte às APIs NFC HCE conforme definido no SDK do Android.

Se as implementações de dispositivos 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] PRECISA informar a constante de recurso android.hardware.nfc.hcef.
[C-3-2] PRECISA implementar as APIs de emulação de cartão NfcF conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem suporte geral a NFC, conforme descrito nesta seção, e forem compatíveis com tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) na função de leitor/gravador, elas:

[C-4-1] É OBRIGATÓRIO implementar as APIs 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, portanto, não aparece como uma constante na classe android.content.pm.PackageManager.

7.4.5. APIs e protocolos de rede

7.4.5.1. Capacidade mínima de rede

Implementações de dispositivos:

[C-0-1] PRECISA incluir suporte para uma ou mais formas de rede de dados. Especificamente, as implementações de dispositivos precisam incluir suporte para pelo menos um padrão de dados capaz 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.
Também DEVE incluir suporte para pelo menos um padrão comum de dados sem fio, como 802.11 (Wi-Fi), quando um padrão de rede física (como Ethernet) for a principal conexão de dados.
PODE implementar mais de uma forma de conectividade de dados.

7.4.5.2. IPv6

Implementações de dispositivos:

[C-0-2] PRECISA incluir uma pilha de rede IPv6 e oferecer suporte à comunicação IPv6 usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, além das APIs nativas, como sockets AF_INET6.
[C-0-3] PRECISA ativar o IPv6 por padrão.
É NECESSÁRIO garantir que a comunicação IPv6 seja tão confiável quanto o IPv4. Por exemplo:
[C-0-4] DEVE manter a conectividade IPv6 no modo Doze.
[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] DEVE fornecer aos aplicativos de terceiros conectividade IPv6 direta à rede quando conectados a uma rede IPv6, sem qualquer forma de tradução de endereço ou porta localmente no dispositivo. As APIs gerenciadas, como Socket#getLocalAddress ou Socket#getLocalPort, e as APIs do NDK, como getsockname() ou IPV6_PKTINFO, precisam retornar o endereço IP e a porta usados para enviar e receber pacotes na rede, 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 a 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] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.

Se as implementações de dispositivos forem compatíveis com Ethernet, elas:

[C-2-1] DEVE oferecer suporte à operação de pilha dupla e somente IPv6 em Ethernet.

Se as implementações de dispositivos forem compatíveis com dados móveis, elas:

[C-3-1] DEVE 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), elas:

[C-4-1] PRECISA atender simultaneamente aos requisitos acima em cada rede quando o dispositivo está conectado a mais de um tipo de rede.

7.4.5.3. Portais cativos

Um portal cativo é uma rede que exige login para acesso à Internet.

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

[C-1-1] PRECISA fornecer um aplicativo de portal cativo para processar a intent ACTION_CAPTIVE_PORTAL_SIGN_IN e mostrar a página de login do portal cativo, enviando essa intent, na chamada para a API do sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] PRECISA detectar portais cativos e oferecer suporte ao login pelo aplicativo de portal cativo quando o dispositivo está conectado a qualquer tipo de rede, incluindo rede celular/móvel, Wi-Fi, Ethernet ou Bluetooth.
[C-1-3] PRECISA 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 DNS criptografado, conforme a documentação do SDK para android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive em todo o tráfego de rede que não se comunica explicitamente com o portal cativo.
[C-1-5] É OBRIGATÓRIO garantir que, enquanto o usuário faz login em um portal cativo, a rede padrão usada pelos aplicativos (conforme retornado 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 forneça acesso à Internet, se disponível.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

[C-0-1] Precisa ter a configuração de sincronização automática principal 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 tarifada, elas serão:

[C-SR-1] É MUITO RECOMENDADO fornecer o modo de economia de dados.

Se as implementações de dispositivos oferecem o modo de economia de dados, elas:

[C-1-1] DEVE oferecer suporte a todas as APIs na classe ConnectivityManager conforme descrito na documentação do SDK

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

[C-2-1] MUST return the value RESTRICT_BACKGROUND_STATUS_DISABLED for ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] MUST NOT broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Elementos de segurança

Se as implementações de dispositivos forem compatíveis com elementos seguros Open Mobile API-capable 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] PRECISA declarar as flags de recursos corretas via 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 para 802.1.15.4 e expuserem a funcionalidade a um aplicativo de terceiros, elas:

[C-1-1] É OBRIGATÓRIO implementar a API Android correspondente em android.uwb.
[C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.uwb.
[C-1-3] PRECISA oferecer suporte a todos os perfis de UWB relevantes definidos na implementação do Android.
[C-1-4] PRECISA oferecer uma opção para que o usuário alterne o estado de ativação/desativação do rádio UWB.
[C-1-5] É OBRIGATÓRIO exigir 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 que passem nos testes de conformidade e certificação relevantes definidos por organizações de padrões, incluindo FIRA, CCC e CSA.
[C-1-6] DEVE 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] PRECISA 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 da borda superior do DUT.
[C-SR-2] É ALTAMENTE RECOMENDADO seguir as etapas de configuração de medição especificadas em Requisitos de calibragem de presença.

7.5. Câmeras

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

[C-1-1] PRECISA declarar a flag de recurso android.hardware.camera.any.
[C-1-2] É OBRIGATÓRIO que um aplicativo possa alocar simultaneamente 3 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 fins de visualização básica e captura de imagens estáticas.
[C-1-3] É OBRIGATÓRIO garantir que o aplicativo 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 o local do usuário nos metadados da imagem antes de enviá-la ao aplicativo de recebimento quando ele não tem ACCESS_FINE_LOCATION.

Se as implementações de dispositivos incluírem pelo menos uma câmera e o aplicativo de câmera pré-instalado processar as intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE ou MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, elas:

[C-1-4] É OBRIGATÓRIO garantir que, ao processar essas intents, o app de câmera pré-instalado remova a localização do usuário nos metadados da imagem antes de enviá-la para aplicativos receptores que não têm ACCESS_FINE_LOCATION.
[C-1-5] PRECISA garantir que a foto em movimento retornada use a especificação do formato 1.0.

[C-1-6] É OBRIGATÓRIO rotular cada tipo de dispositivo de câmera usando o campo CameraCharacteristics.INFO_DEVICE_TYPE como BUILT_IN, EXTERNAL ou VIRTUAL. Também é necessário rotular cada frame de saída da câmera usando o campo CaptureResult.INFO_DEVICE_TYPE.
Garantir que CaptureResult.INFO_DEVICE_TYPE esteja rotulado corretamente é especialmente importante em situações em que um ID de câmera é remapeado dinamicamente para uma fonte de câmera diferente.

Se as implementações de dispositivos forem compatíveis com a capacidade de saída HDR de 10 bits, elas:

[C-2-1] PRECISA oferecer suporte a pelo menos o perfil HLG HDR para todos os dispositivos de câmera que oferecem suporte a saída de 10 bits.
[C-2-2] PRECISA oferecer suporte a saída de 10 bits para a câmera traseira principal ou a câmera 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 de HDR para todas as subcâmeras físicas compatíveis com BACKWARD_COMPATIBLE de uma câmera lógica e para a própria câmera lógica.

Para dispositivos de câmera lógica que oferecem suporte a HDR de 10 bits e implementam a API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, eles:

[C-3-1] PRECISA oferecer suporte à troca entre todas as câmeras físicas compatíveis com versões anteriores usando o controle CONTROL_ZOOM_RATIO na câmera lógica.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera voltada para o mundo que captura imagens de cenas do lado oposto do dispositivo, como uma câmera tradicional. Em dispositivos portáteis, ela fica localizada no lado oposto à tela.

Implementações de dispositivos:

DEVE incluir uma câmera traseira.

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

[C-1-1] PRECISA 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 foco automático de hardware ou software implementado no driver da câmera (transparente para o software de 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 NÃO PODE ser acesa enquanto uma instância android.hardware.Camera.PreviewCallback estiver registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha ativado explicitamente o flash ao ativar 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 aplicativos 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 geralmente é usada para capturar imagens do usuário, como em videoconferências e aplicativos semelhantes. Em dispositivos portáteis, ela fica localizada no mesmo lado do dispositivo que a tela.

Implementações de dispositivos:

PODE incluir uma câmera frontal.

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

[C-1-1] PRECISA 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 PODE usar uma câmera frontal como padrão para a API Camera e NÃO PODE configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera no dispositivo.
[C-1-4] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo app quando ele tiver solicitado explicitamente que a tela da câmera seja girada com 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 com uma chamada ao método android.hardware.Camera.setDisplayOrientation().
[C-1-5] NÃO PODE espelhar a imagem estática ou os fluxos de vídeo capturados finais retornados aos callbacks do aplicativo ou armazenados na mídia.
[C-1-6] PRECISA espelhar a imagem mostrada pela pós-visualização da mesma forma que o fluxo de imagens da prévia 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 dispositivos puderem ser giradas pelo usuário (por exemplo, automaticamente por um acelerômetro ou manualmente por entrada do usuário):

[C-2-1] A prévia 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 é um dispositivo que pode ser conectado ou desconectado fisicamente da implementação a qualquer momento e pode ser apontado para qualquer direção, como câmeras USB.

Implementações de dispositivos:

PODE incluir suporte para uma câmera externa que não precisa estar sempre conectada.

Se as implementações de dispositivos incluírem suporte para uma câmera externa, elas:

[C-1-1] PRECISA declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
[C-1-2] DEVE oferecer suporte à classe de vídeo USB (UVC 1.0 ou mais recente) se a câmera externa se conectar pela porta de host USB.
[C-1-3] PRECISA passar nos testes de CTS da câmera com um dispositivo de câmera externa física conectado. Os detalhes dos testes do CTS da câmera estão disponíveis em source.android.com.
DEVE oferecer suporte a compactações de vídeo, como MJPEG, para permitir a transferência de streams não codificados de alta qualidade (ou seja, streams de imagem brutos ou compactados de forma independente).
PODE oferecer suporte a várias câmeras.
PODE oferecer suporte à codificação de vídeo baseada em câmera.

Se a codificação de vídeo baseada em câmera for compatível:

[C-2-1] Um fluxo simultâneo não codificado / MJPEG (QVGA ou resolução maior) PRECISA estar acessível à 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 ao app, incluindo fluxos eficientes de streaming/fotos em sequência sem cópia e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, remoçã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 deve estar 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 android.hardware.camera2 mais recente PRECISAM ter desempenho e qualidade equivalentes nas duas APIs. Por exemplo, com configurações equivalentes, a velocidade e a precisão do foco automático 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 DEVEM corresponder o mais próximo possível.

As implementações de dispositivos PRECISAM implementar os seguintes comportamentos para as APIs relacionadas à câmera, em 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évia fornecidos aos callbacks do aplicativo quando ele 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 de 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, NV21 PRECISA ser o padrão.
[C-0-3] PRECISA oferecer suporte ao formato YV12 (indicado pela constante android.graphics.ImageFormat.YV12) para prévias de câmera frontal e traseira no 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] PRECISA 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 a capacidade REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE em android.request.availableCapabilities.
[C-0-5] AINDA É NECESSÁRIO implementar a API Camera completa incluída na documentação do SDK do Android, independente de o dispositivo incluir foco automático por hardware ou outros recursos. Por exemplo, câmeras sem 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 também se aplica a câmeras frontais. Por exemplo, mesmo que a maioria delas não ofereça suporte a autofoco, os callbacks da API ainda precisam ser "falsificados" conforme descrito.
[C-0-6] PRECISA reconhecer e respeitar 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 DEVEM honrar ou reconhecer constantes de string transmitidas ao método android.hardware.Camera.setParameters() que não sejam 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 de parâmetros personalizados 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] TAMBÉM precisa declarar os recursos individuais de câmera de android.hardware.camera2 usando a propriedade android.request.availableCapabilities e declarar as flags de recursos adequadas. É OBRIGATÓRIO definir a flag de recurso se algum dos dispositivos de câmera conectados a ela for compatível com o recurso.
[C-0-9] PRECISA transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada da foto for adicionada à loja de mídia.
[C-0-10] DEVE transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da foto for adicionada à loja de mídia.
[C-0-11] Todas as câmeras acessíveis pela API android.hardware.Camera descontinuada também precisam estar acessíveis pela API android.hardware.camera2.
[C-0-12] É OBRIGATÓRIO garantir que a aparência facial NÃO seja alterada, incluindo, entre outros, a geometria, o tom de pele ou o alisamento da pele do rosto para qualquer API de android.hardware.camera2 ou android.hardware.Camera.
[C-SR-1] Para dispositivos com várias câmeras RGB próximas e apontando na mesma direção, é ALTAMENTE RECOMENDADO oferecer suporte a um dispositivo de câmera lógica que liste a capacidade CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, consistindo em todas as câmeras RGB apontando nessa direção como subdispositivos físicos.

Se as implementações de dispositivos fornecerem uma API de câmera proprietária para apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO implementar uma API de câmera usando a API android.hardware.camera2.
PODE fornecer tags e/ou extensões de fornecedores para a API android.hardware.camera2.

Se as implementações de dispositivos ajustarem o pipeline de câmera de terceiros para ficar em paridade com o pipeline de câmera integrada para as câmeras frontal e traseira principais, elas:

[C-2-1] PRECISA declarar a propriedade do sistema ro.camera.default_app_social_media_parity_enabled.

7.5.5. Orientação da câmera

Se as implementações de dispositivos 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 independente da orientação natural do dispositivo, ou seja, a dispositivos com orientação principal paisagem e retrato.

Os dispositivos que atendem a qualquer um dos seguintes critérios estão isentos desse requisito:
- O dispositivo implementa telas de geometria variável, como dobráveis ou articuladas, E quando o estado de dobra ou articulação do dispositivo muda, o dispositivo alterna entre as orientações retrato-primária e paisagem-primária (ou vice-versa).
- Implementações de dispositivos que não podem ser girados 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] DEVE incluir um gerenciador de downloads que os aplicativos PODEM usar para baixar arquivos de dados e DEVE ser capaz de baixar arquivos individuais de pelo menos 100 MB de tamanho para o local "cache" padrão.

7.6.2. Armazenamento compartilhado de aplicativos

Implementações de dispositivos:

[C-0-1] PRECISA oferecer armazenamento para ser compartilhado por aplicativos, também conhecido como "armazenamento externo compartilhado", "armazenamento compartilhado de aplicativos" ou pelo caminho do Linux "/sdcard" em que ele é montado.
[C-0-2] PRECISA ser configurado com armazenamento compartilhado montado por padrão, ou seja, "pronto para uso", independente 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 Secure Digital).
[C-0-3] É OBRIGATÓRIO montar o armazenamento compartilhado do aplicativo diretamente no caminho do Linux sdcard ou incluir um link simbólico do Linux de sdcard para o ponto de montagem real.
[C-0-4] É OBRIGATÓRIO ativar o armazenamento com escopo por padrão para todos os apps destinados ao nível 29 da API ou mais recente, exceto na seguinte situação:
- Quando o app tiver solicitado android:requestLegacyExternalStorage="true" no manifesto.
[C-0-5] É OBRIGATÓRIO editar metadados de localização, como tags GPS Exif, armazenados em arquivos de mídia quando esses arquivos são acessados pelo 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).
Uma parte do armazenamento interno (não removível) implementado no Android Open Source Project (AOSP).

Se as implementações de dispositivos usarem armazenamento removível para atender aos requisitos acima, elas:

[C-1-1] É OBRIGATÓRIO implementar uma interface do usuário de aviso em pop-up ou toast quando não houver um dispositivo de armazenamento inserido no slot.
[C-1-2] PRECISA incluir um meio de armazenamento formatado em FAT (por exemplo, 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 de dispositivos usarem uma parte do armazenamento não removível para atender aos requisitos acima, elas:

É RECOMENDADO usar a implementação do AOSP do armazenamento compartilhado interno do aplicativo.
PODE compartilhar o espaço de armazenamento com os dados particulares do aplicativo.

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

[C-3-1] DEVE fornecer um mecanismo para acessar os dados no armazenamento compartilhado do aplicativo em um computador host.
DEVE expor o conteúdo dos dois caminhos de armazenamento de forma transparente pelo serviço de scanner de mídia do Android e 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 de dispositivos tiverem uma porta USB com modo periférico USB e forem compatíveis com o protocolo de transferência de mídia, elas:

PRECISA ser compatível com o host MTP de referência do Android, o 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 de uma televisão, as implementações de 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 de dados/corrupção.

Se a porta do dispositivo de armazenamento removível estiver em um local estável de longo prazo, como dentro do compartimento da bateria ou outra capa de proteção, as implementações do dispositivo serão:

[C-SR-2] É ALTAMENTE RECOMENDÁVEL implementar o armazenamento adotável.

7.7. USB

Definições

O modo de host USB é quando uma implementação de dispositivo funciona como o host USB, fornece energia no barramento e se comunica com periféricos.
O modo de dispositivo USB (também conhecido como modo periférico USB) é quando uma implementação de dispositivo atua como um periférico USB, se conecta a um host por uma porta upstream e responde a solicitações do host.
Uma porta USB é definida como um mecanismo para fornecer conectividade USB, seja um receptáculo USB físico ou uma interface não padrão (por exemplo, pinos pogo).

Se as implementações de dispositivos tiverem uma porta USB, elas:

DEVE oferecer suporte ao modo dispositivo USB.
PRECISA ser compatível com o modo host USB.
DEVE oferecer suporte à desativação da sinalização de dados por USB.

7.7.1. Modo dispositivo USB

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo de dispositivo periférico:

[C-1-1] A porta PRECISA ser conectável a um host USB com uma porta USB padrão tipo A ou tipo C.
[C-1-2] MUST report the correct value of iSerialNumber in USB standard device descriptor through android.os.Build.SERIAL.
[C-1-3] DEVE detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão de resistor Type-C e DEVE detectar mudanças no anúncio se eles forem compatíveis com USB Type-C.

[C-SR-1] A porta DEVE usar o formato micro-B, micro-AB ou USB tipo C. É ALTAMENTE RECOMENDADO que os dispositivos Android novos e atuais atendam a esses requisitos para que possam fazer upgrade para as futuras versões 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 da 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. É FORTEMENTE RECOMENDADO que os dispositivos Android novos e atuais atendam a esses requisitos para que possam ser atualizados para versões futuras da plataforma.
[C-SR-3] DEVE implementar suporte para extrair uma corrente de 1,5 A durante o chirp 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 atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
[C-SR-4] É ALTAMENTE RECOMENDADO que não ofereçam suporte a métodos de carregamento proprietários que modifiquem a tensão Vbus além dos níveis padrão ou alterem as funções de coletor/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 chamado de "ALTAMENTE RECOMENDADO", em versões futuras do Android, talvez seja NECESSÁRIO que todos os dispositivos tipo C ofereçam suporte à interoperabilidade total com carregadores tipo C padrão.
[C-SR-5] É ALTAMENTE RECOMENDADO que eles ofereçam suporte ao fornecimento de energia para dados e troca de função de energia quando compatíveis com USB-C e modo host USB.
DEVE oferecer suporte ao fornecimento de energia para carregamento de alta tensão e a modos alternativos, como saída de tela.
DEVE implementar a API e a especificação do Android Open Accessory (AOA) conforme documentado na documentação do SDK do Android.

Se as implementações de dispositivos incluírem uma porta USB e implementarem a especificação AOA, elas:

[C-2-1] PRECISA 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 de descrição da interface iInterface do armazenamento em massa USB.

7.7.2. Modo host USB

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

[C-1-1] PRECISA implementar a API de host USB do Android conforme documentado no SDK do Android e DECLARAR suporte ao recurso de hardware android.hardware.usb.host.
[C-1-2] É OBRIGATÓRIO implementar suporte para conectar periféricos USB padrão. É necessário ter uma das seguintes opções:
- Uma porta USB-C no dispositivo ou com cabos que adaptam uma porta proprietária do dispositivo para uma porta USB-C padrão (dispositivo USB-C).
- Uma porta USB tipo A no dispositivo ou com cabos que adaptam uma porta proprietária do dispositivo a uma porta USB tipo A padrão.
- Uma porta micro-AB USB no dispositivo, que DEVE ser enviada com um cabo que se adapta a uma porta USB tipo A padrão.
[C-1-3] NÃO PODE ser enviado com um adaptador que converta portas USB Type-A ou micro-AB em uma porta USB Type-C (receptáculo).
[C-SR-1] É ALTAMENTE RECOMENDADO 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 "Parâmetros de encerramento" da Especificação do conector e cabo 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), conforme especificado nas Especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
DEVE implementar e oferecer suporte aos padrões USB Type-C.

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo host e a classe de áudio USB, elas:

[C-2-1] PRECISA oferecer suporte à classe USB HID.
[C-2-2] DEVE oferecer suporte à detecção e ao mapeamento dos seguintes campos de dados HID especificados nas Tabelas de uso de HID USB e na Solicitação de uso de 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 de dispositivos incluírem uma porta USB compatível com o modo host e o Framework de acesso ao armazenamento (SAF), elas:

[C-3-1] PRECISA reconhecer qualquer dispositivo MTP (protocolo de transferência de mídia) conectado remotamente e disponibilizar o conteúdo deles usando as intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT.

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

[C-4-1] PRECISA implementar a funcionalidade de alimentação de função dupla (DRP, na sigla em inglês) conforme definido pela especificação USB Type-C (seção 4.5.1.3.3). Para portas DRP em dispositivos que incluem uma entrada para fone de ouvido de 3, 5 mm, a detecção de dissipador de energia USB (modo host) PODE estar desativada por padrão, mas o usuário PRECISA poder ativá-la.
[C-SR-2] É ALTAMENTE RECOMENDADO que eles sejam compatíveis com DisplayPort.
- DEVE ser compatível com taxas de dados USB SuperSpeed.
- SÃO ALTAMENTE RECOMENDADOS para oferecer suporte ao fornecimento de energia para dados e troca de função de energia.
[C-SR-3] É FORTEMENTE RECOMENDADO NÃO oferecer suporte ao modo de acessório adaptador de áudio, conforme descrito no Apêndice A da Especificação do cabo e conector USB Type-C, revisão 1.2 (em inglês).
DEVE implementar o modelo Try.* mais adequado ao formato do dispositivo. Por exemplo, um dispositivo portátil DEVE implementar o modelo Try.SNK.

7.7.3. fornecimento de energia USB

Se as implementações de dispositivos incluírem uma porta USB-C, elas:

[C-SR-1] é FORTEMENTE RECOMENDADO para implementar a classe de conector USB Type-C do kernel e os nós necessários que descrevem as conexões USB Type-C e as funções de energia e dados. Consulte a documentação do Android USB Type-C para detalhes da implementação.

Se as implementações de dispositivos incluírem uma porta USB-C e forem compatíveis com transmissão de energia, elas:

[C-SR-2] É ALTAMENTE RECOMENDADO implementar todos os nós que descrevem o fornecimento de energia USB. Consulte a documentação do USB PD do Android para detalhes da implementação.

Se as implementações de dispositivos incluírem uma porta USB Type-C e forem compatíveis com modos alternativos, elas:

[C-SR-3] É ALTAMENTE RECOMENDADO implementar os modos alternativos e as propriedades relacionadas à identidade da classe de conector USB Type-C do kernel. Consulte a documentação do Android USB Type-C para detalhes da implementação.

Se as implementações de dispositivos incluírem uma porta USB Type-C e forem compatíveis com o modo alternativo Thunderbolt 3, elas:

[C-SR-4] É ALTAMENTE RECOMENDADO implementar a capacidade de substituir o modo alternativo atual pela classe de conector tipo C.

7.8. Áudio

7.8.1. Microfone

Se as implementações de dispositivos incluírem um microfone, elas:

[C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.microphone.
[C-1-2] PRECISA atender aos requisitos de gravação de áudio na seção 5.4.
[C-1-3] PRECISA atender aos requisitos de latência de áudio na seção 5.6.
[C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte à gravação quase ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos omitirem um microfone, elas:

[C-2-1] NÃO PODE informar a constante de recurso android.hardware.microphone.
[C-2-2] É OBRIGATÓRIO implementar a API de gravação de áudio pelo menos como no-ops, conforme a seção 7.

7.8.2. Saída de áudio

Se as implementações de dispositivos 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 um conector de áudio de 3,5 mm com quatro condutores ou uma porta de 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] PRECISA atender aos requisitos de reprodução de áudio na seção 5.5.
[C-1-3] PRECISA atender aos requisitos de latência de áudio na seção 5.6.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à reprodução quase ultrassônica, 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 PODE 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 para fone de ouvido de 3,5 mm, HDMI ou uma 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 "porta de saída".

7.8.2.1. Portas de áudio analógicas

Para serem compatíveis com fones de ouvido e outros acessórios de áudio que usam o conector de áudio de 3,5 mm em todo o ecossistema Android, se as implementações de dispositivos incluírem uma ou mais portas de áudio analógicas, elas:

[C-SR-1] É ALTAMENTE RECOMENDÁVEL incluir pelo menos uma das portas de áudio como uma entrada para fone de ouvido de 3,5 mm com quatro condutores.

Se as implementações de dispositivos tiverem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

[C-1-1] PRECISA oferecer suporte à reprodução de áudio em fones de ouvido estéreo e fones de ouvido estéreo com um microfone.
[C-1-2] PRECISA oferecer suporte a plugues de áudio TRRS com a ordem de pinagem da CTIA.
[C-1-3] DEVE oferecer suporte à detecção e ao mapeamento dos keycodes para os três intervalos a seguir de impedância equivalente entre o microfone e os condutores de aterramento no conector de áudio:
- 70 ohms ou menos: KEYCODE_HEADSETHOOK
- 210-290 ohm: KEYCODE_VOLUME_UP
- 360 a 680 ohm: KEYCODE_VOLUME_DOWN
[C-1-4] DEVE acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que todos os contatos do plugue tocarem os segmentos relevantes no conector.
[C-1-5] PRECISA ser capaz de gerar pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohms.
[C-1-6] PRECISA ter uma tensão de polarização do microfone entre 1,8 V e 2,9 V.
[C-1-7] DEVE detectar e mapear o keycode para o seguinte intervalo de impedância equivalente entre o microfone e os condutores de aterramento no conector de áudio:
- 110-180 ohm:KEYCODE_VOICE_ASSIST
[C-SR-2] É ALTAMENTE RECOMENDADO que eles ofereçam suporte a plugues de áudio com a ordem de pinagem OMTP.
[C-SR-3] É ALTAMENTE RECOMENDADO que eles sejam compatíveis com a gravação de áudio de fones de ouvido estéreo com microfone.

Se as implementações de dispositivos tiverem uma entrada para fone de ouvido de 3,5 mm com quatro condutores e forem compatíveis com um microfone, além de transmitirem o android.intent.action.HEADSET_PLUG com o valor extra do microfone definido como 1, elas:

[C-2-1] DEVE 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 requisitos específicos do dispositivo.

7.8.3. Quase ultrassom

O áudio quase ultrassônico está na banda de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

PRECISA informar corretamente a compatibilidade com recursos de áudio quase ultrassônicos usando a API AudioManager.getProperty da seguinte maneira:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND for "true", as fontes de áudio VOICE_RECOGNITION e UNPROCESSED precisarão atender aos seguintes requisitos:

[C-1-1] A resposta de potência média do microfone na banda de 18,5 kHz a 20 kHz NÃO PODE ser mais de 15 dB abaixo da resposta em 2 kHz.
[C-1-2] A relação sinal-ruído não ponderada do microfone em uma faixa de 18,5 kHz a 20 kHz para um tom de 19 kHz a -26 dBFS NÃO PODE ser inferior a 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 NÃO PODE ser inferior a 40 dB abaixo da resposta em 2 kHz.

7.8.4. Integridade do sinal

Implementações de dispositivos:

DEVE fornecer um caminho de sinal de áudio sem falhas para fluxos de entrada e saída em dispositivos móveis, conforme definido por zero falhas medidas durante um teste de um minuto por caminho. Teste usando o OboeTester "Automated Glitch Test".

O teste requer um dongle de loopback de áudio, usado diretamente em uma entrada para fone de ouvido 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 DEVEM ser testadas.

No momento, o OboeTester é compatível com caminhos da AAudio. Portanto, as seguintes combinações DEVEM ser testadas para falhas usando a AAudio:

Modo de desempenho	Compartilhamento	Taxa de amostragem externa	Em canais	Out Chans
LOW_LATENCY	EXCLUSIVOS	NÃO ESPECIFICADO	1	2
LOW_LATENCY	EXCLUSIVOS	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	16.000	1	2
NENHUMA	COMPARTILHADO	16.000	2	1

Um stream confiável PRECISA atender aos seguintes critérios de relação sinal-ruído (SNR) e distorção harmônica total (THD) para um senoide de 2.000 Hz.

Transdutor	THD	SNR
alto-falante principal integrado, medido usando um microfone de referência externo	< 3,0%	>= 50 dB
microfone integrado principal, medido usando um alto-falante de referência externo	< 3,0%	>= 50 dB
Entradas analógicas de 3,5 mm integradas, testadas com um adaptador de loopback	< 1%	>= 60 dB
Adaptadores USB fornecidos com o smartphone, testados com um adaptador de loopback	< 1,0%	>= 60 dB

7.9. Realidade virtual

O Android inclui APIs e recursos para criar aplicativos de realidade virtual (RV), incluindo experiências de RV móvel de alta qualidade. As implementações de dispositivos precisam implementar corretamente essas APIs e comportamentos, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android inclui suporte ao modo VR, um recurso que processa a renderização estereoscópica de notificações e desativa componentes monoculares da interface do sistema enquanto um aplicativo de realidade virtual está em foco.

7.9.2. Modo de realidade virtual: alto desempenho

Se as implementações de dispositivos forem compatíveis com o modo RV, elas:

[C-1-1] PRECISA ter pelo menos dois núcleos físicos.
[C-1-2] PRECISA declarar o recurso android.hardware.vr.high_performance.
[C-1-3] PRECISA oferecer suporte ao modo performance sustentado.
[C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.2.
[C-1-5] PRECISA oferecer suporte a android.hardware.vulkan.level 0.
DEVE oferecer suporte a android.hardware.vulkan.level 1 ou versões mais recentes.
[C-1-6] É OBRIGATÓ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] PRECISA 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 RECOMENDÁVEL oferecer suporte ao Vulkan 1.1.
[C-SR-3] É FORTEMENTE 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 buffer frontal compartilhado para que a renderização alternada de conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de tearing visíveis.
[C-1-9] É OBRIGATÓRIO implementar suporte para flags AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT conforme descrito no NDK.
[C-1-10] É OBRIGATÓRIO implementar suporte a AHardwareBuffers com qualquer combinação das 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] É FORTEMENTE RECOMENDADO para oferecer suporte à alocação de AHardwareBuffers com mais de uma camada e flags e formatos especificados em C-1-10.
[C-1-11] PRECISA oferecer suporte à decodificação H.264 de pelo menos 3840 x 2160 a 30 fps, comprimido a uma média de 40 Mbps (equivalente a quatro instâncias de 1920 x 1080 a 30 fps-10 Mbps ou duas instâncias de 1920 x 1080 a 60 fps-20 Mbps).
[C-1-12] PRECISA oferecer suporte a HEVC e VP9, PRECISA ser capaz de decodificar pelo menos 1920 x 1080 a 30 fps compactado para uma média de 10 Mbps e DEVE 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] PRECISA oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
[C-1-14] PRECISA ter uma tela incorporada, e a resolução dela PRECISA ser de pelo menos 1920 x 1080.
[C-SR-6] É ALTAMENTE RECOMENDADO que tenham uma resolução de tela de pelo menos 2560 x 1440.
[C-1-15] A tela PRECISA ser atualizada em pelo menos 60 Hz no modo VR.
[C-1-17] A tela PRECISA oferecer suporte a um modo de baixa persistência com persistência de ≤ 5 milissegundos, sendo a persistência definida como a quantidade de tempo em que um pixel emite luz.
[C-1-18] PRECISA ser compatível com Bluetooth 4.2 e extensão de comprimento de dados Bluetooth LE seção 7.4.3.
[C-1-19] PRECISA oferecer suporte e informar corretamente o Tipo de canal direto para todos os seguintes tipos de sensores padrão:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR-7] É ALTAMENTE RECOMENDADO que ofereçam suporte ao tipo de canal direto TYPE_HARDWARE_BUFFER para todos os tipos de canal direto listados acima.
[C-1-21] PRECISA atender aos requisitos relacionados a giroscópio, acelerômetro e magnetômetro para android.hardware.hifi_sensors, conforme especificado na seção 7.3.9.
[C-SR-8] É ALTAMENTE RECOMENDADO para oferecer suporte ao recurso android.hardware.sensor.hifi_sensors.
[C-1-22] PRECISA ter latência de movimento de ponta a ponta para fóton não superior a 28 milissegundos.
[C-SR-9] É FORTEMENTE RECOMENDADO que a latência de movimento de ponta a ponta para fóton não seja superior a 20 milissegundos.
[C-1-23] PRECISA ter uma proporção de primeiro frame, que é a proporção entre o brilho dos pixels no primeiro frame após uma transição do preto para o branco e o brilho dos pixels brancos em estado constante, de pelo menos 85%.
[C-SR-10] É ALTAMENTE RECOMENDADO ter uma proporção de primeiro frame de pelo menos 90%.
PODE fornecer um núcleo exclusivo para o aplicativo em primeiro plano e PODE oferecer suporte à API Process.getExclusiveCores para retornar os números dos núcleos da CPU exclusivos do aplicativo em primeiro plano principal.

Se o núcleo exclusivo for compatível, ele:

[C-2-1] NÃO PODE permitir que outros processos do espaço do usuário sejam executados nele (exceto drivers de dispositivo usados pelo aplicativo), mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

7.10. Funcionalidade tátil

Dispositivos portáteis ou vestíveis podem incluir um atuador háptico de uso geral, disponível para aplicativos com finalidades como chamar a atenção por toques, alarmes, notificações e feedback geral ao toque.

Se as implementações de dispositivos NÃO incluírem um atuador háptico de uso geral, elas:

[7.10/C] MUST return false for Vibrator.hasVibrator().

Se as implementações de dispositivos INCLUIREM pelo menos um atuador háptico de uso geral, elas:

[C-1-1] MUST return true for Vibrator.hasVibrator().
NÃO DEVE usar um atuador háptico (vibrador) de massa rotativa excêntrica (ERM).
IMPLEMENTE todas as constantes públicas para retorno tátil claro em android.view.HapticFeedbackConstants ou seja, (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START e GESTURE_END).
É RECOMENDADO implementar todas as constantes públicas para retorno tátil claro em android.os.VibrationEffect , ou seja, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e todas as constantes públicas PRIMITIVE_* viáveis para retorno tátil avançado em android.os.VibrationEffect.Composition , ou seja, (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Algumas dessas primitivas, como LOW_TICK e SPIN, só são viáveis se o vibrador for compatível com frequências relativamente baixas.
DEVE seguir a orientação para mapear constantes públicas em android.view.HapticFeedbackConstants para as constantes android.os.VibrationEffect recomendadas, com as relações de amplitude correspondentes.
DEVE usar esses mapeamentos de constantes hápticas vinculadas.
DEVE seguir a avaliação de qualidade para APIs createOneShot() e createWaveform().
DEVE verificar se o resultado da API pública android.os.Vibrator.hasAmplitudeControl() reflete corretamente as capacidades do vibrador.
VERIFIQUE as capacidades de escalonabilidade de amplitude executando android.os.Vibrator.hasAmplitudeControl().

Se as implementações de dispositivos seguirem o mapeamento de constantes hápticas, elas:

VERIFIQUE o status da implementação executando as APIs android.os.Vibrator.areAllEffectsSupported() e android.os.Vibrator.arePrimitivesSupported().
É RECOMENDADO fazer uma avaliação de qualidade para constantes hápticas.
VERIFIQUE e atualize, se necessário, a configuração de substituição para primitivos não compatíveis, conforme descrito nas orientações de implementação para constantes.
É RECOMENDADO fornecer suporte de substituição para mitigar o risco de falha, conforme descrito aqui.

7.11. Classe de performance de mídia

A classe de desempenho de mídia da implementação do dispositivo pode ser obtida na API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Os requisitos para a classe de desempenho de mídia são definidos para cada versão do Android a partir da R (versão 30). O valor especial 0 designa que o dispositivo não é de uma classe de desempenho de mídia.

Se as implementações de dispositivos retornarem um valor diferente de zero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

[C-1-1] PRECISA retornar pelo menos um valor de android.os.Build.VERSION_CODES.R.
[C-1-2] PRECISA ser uma implementação de dispositivo portátil.
[C-1-3] PRECISA atender a todos os requisitos da "Classe de desempenho de mídia" descritos na seção 2.2.7.

Em outras palavras, a classe de desempenho de mídia no Android T só é definida para dispositivos móveis nas versões T, S ou R.

Consulte a seção 2.2.7 para ver os requisitos específicos do dispositivo.

8. Desempenho e bateria

Alguns critérios mínimos de desempenho e energia são essenciais para a experiência do usuário e afetam as proposições básicas que os desenvolvedores teriam ao criar um app.

8.1. Consistência da experiência do usuário

Uma interface do usuário suave pode ser fornecida ao usuário final se houver determinados requisitos mínimos para garantir uma taxa de frames e tempos de resposta consistentes para aplicativos e jogos. As implementações de dispositivos, dependendo do tipo de dispositivo, PODEM ter requisitos mensuráveis para a latência da interface do usuário e a troca de tarefas, conforme descrito na seção 2.

8.2. Desempenho de acesso de E/S de arquivo

Fornecer uma base comum para uma performance consistente de acesso a arquivos no armazenamento de dados particulares do aplicativo (partição /data) permite que os desenvolvedores de apps estabeleçam uma expectativa adequada que ajude no design do software. As implementações de dispositivos, dependendo do tipo, PODEM ter determinados requisitos descritos na seção 2 para as seguintes operações de leitura e gravação:

Desempenho de gravação sequencial. Medido gravando um arquivo de 256 MB usando um buffer de gravação de 10 MB.
Desempenho de gravação aleatória. Medido gravando um arquivo de 256 MB usando um buffer de gravação de 4 KB.
Desempenho de leitura sequencial. Medido pela leitura de um arquivo de 256 MB usando um buffer de gravação de 10 MB.
Desempenho de leitura aleatória. Medido pela leitura de um arquivo de 256 MB usando um buffer de gravação de 4 KB.

8.3. Modos de economia de energia

Se as implementações de dispositivos incluírem recursos para melhorar o gerenciamento de energia que estão incluídos no AOSP (por exemplo, App Standby Bucket, Doze) ou estender os recursos para aplicar restrições mais fortes do que o bucket restrito para apps em espera, eles:

[C-1-1] NÃO PODE desviar da implementação do AOSP para os algoritmos de acionamento, manutenção e ativação e o uso de configurações globais do sistema ou DeviceConfig dos modos de economia de energia App em espera e Soneca.
[C-1-2] NÃO PODE desviar da implementação do AOSP para o uso de configurações globais ou DeviceConfig para gerenciar a limitação de tarefas, alarmes e rede para apps em cada bucket do modo de espera de apps.
[C-1-3] NÃO PODE desviar da implementação do AOSP para o número de buckets do App em espera usados para o recurso.
[C-1-4] PRECISA implementar Buckets do App em espera e o modo Soneca, conforme descrito em Gerenciamento de energia.
[C-1-5] MUST return true for PowerManager.isPowerSaveMode() when the device is on power save mode.
[C-1-6] DEVE oferecer ao usuário uma affordance para mostrar todos os apps isentos dos modos de economia de energia do App em espera e do Soneca ou de qualquer otimização da bateria e DEVE implementar a intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS para pedir que o usuário permita que um app ignore as otimizações da bateria.
[C-SR-1] É ALTAMENTE RECOMENDADO oferecer ao usuário a opção de ativar e desativar o recurso de economia de bateria.
[C-SR-2] É ALTAMENTE RECOMENDADO oferecer ao usuário a capacidade de exibir todos os apps que estão isentos dos modos de economia de energia do App em espera e do Doze.

Se as implementações de dispositivos estenderem os recursos de gerenciamento de energia incluídos no AOSP e essa extensão aplicar restrições mais rigorosas do que o bucket de App em espera raro, consulte a seção 3.5.1.

Além dos modos de economia de energia, as implementações de dispositivos Android PODEM implementar qualquer um ou todos os quatro estados de energia em espera definidos pela Interface avançada de energia e configuração (ACPI, na sigla em inglês).

Se as implementações de dispositivos implementarem estados de energia S4 conforme definido pela ACPI, elas:

[C-1-1] SÓ pode entrar nesse estado depois que o usuário realizar uma ação explícita para colocar o dispositivo em um estado inativo (por exemplo, fechando uma tampa que faz parte do dispositivo ou desligando um veículo ou uma televisão) e antes que o usuário reative o dispositivo (por exemplo, abrindo a tampa ou ligando o veículo ou a televisão novamente).

Se as implementações de dispositivos implementarem estados de energia S3 conforme definido pela ACPI, elas:

[C-2-1] PRECISA atender ao C-1-1 acima ou entrar no estado S3 somente quando aplicativos de terceiros não precisarem dos recursos do sistema (por exemplo, tela, CPU).

Por outro lado, DEVE sair do estado S3 quando aplicativos de terceiros precisarem dos recursos do sistema, conforme descrito neste SDK.

Por exemplo, enquanto os aplicativos de terceiros solicitam manter a tela ligada usando FLAG_KEEP_SCREEN_ON ou manter a CPU em execução usando PARTIAL_WAKE_LOCK, o dispositivo NÃO DEVE entrar no estado S3, a menos que, conforme descrito em C-1-1, o usuário tenha tomado uma ação explícita para colocar o dispositivo em um estado inativo. Por outro lado, quando uma tarefa implementada por apps de terceiros usando o JobScheduler é acionada ou o Firebase Cloud Messaging é entregue a apps de terceiros, o dispositivo PRECISA sair do estado S3, a menos que o usuário tenha colocado o dispositivo em um estado inativo. Esses não são exemplos abrangentes, e o AOSP implementa vários sinais de despertar que acionam uma ativação desse estado.

8.4. Contabilização do consumo de energia

Uma contabilidade e um relatório mais precisos do consumo de energia oferecem ao desenvolvedor de apps incentivos e ferramentas para otimizar o padrão de uso de energia do aplicativo.

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo elevado da bateria aproximado causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
[C-SR-2] É ALTAMENTE RECOMENDADO informar todos os valores de consumo de energia em miliampere-hora (mAh).
[C-SR-3] É ALTAMENTE RECOMENDADO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
[C-SR-4] É ALTAMENTE RECOMENDADO disponibilizar esse uso de energia usando o comando de shell adb shell dumpsys batterystats para o desenvolvedor de apps.
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.5. Desempenho consistente

O desempenho pode variar muito em apps de alto desempenho e longa duração, seja por causa dos outros apps em execução em segundo plano ou da limitação da CPU devido a limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo for capaz, o aplicativo em primeiro plano principal possa solicitar que o sistema otimize a alocação dos recursos para lidar com essas variações.

Implementações de dispositivos:

[C-0-1] DEVE informar com precisão a compatibilidade com o modo performance sustentado usando o método PowerManager.isSustainedPerformanceModeSupported() da API.
PRECISA ser compatível com o modo de desempenho sustentado.

Se as implementações de dispositivos informarem suporte ao modo performance sustentado, elas:

[C-1-1] DEVE fornecer ao aplicativo em primeiro plano um nível consistente de desempenho por pelo menos 30 minutos, quando o app solicitar.
[C-1-2] PRECISA obedecer à API Window.setSustainedPerformanceMode() e outras APIs relacionadas.

Se as implementações de dispositivos incluírem dois ou mais núcleos de CPU, elas:

DEVE fornecer pelo menos um núcleo exclusivo que possa ser reservado pelo aplicativo em primeiro plano principal.

Se as implementações de dispositivos permitirem reservar um núcleo exclusivo para o aplicativo em primeiro plano, elas:

[C-2-1] MUST report through the Process.getExclusiveCores() API method the ID numbers of the exclusive cores that can be reserved by the top foreground application.
[C-2-2] NÃO PODE permitir processos de espaço do usuário, exceto os drivers de dispositivo usados pelo aplicativo para execução nos núcleos exclusivos, mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

Se as implementações de dispositivos não forem compatíveis com um núcleo exclusivo, elas:

[C-3-1] PRECISA retornar uma lista vazia usando o método da API Process.getExclusiveCores().

8.6. Limites de memória do app

O MemoryLimiter, um novo componente do ActivityManagerService, e os limites de memória padrão do app, que são derivados da memória física disponível, vão impor limites à quantidade de DRAM usada por processo individual do app. Essa restrição se aplica a toda a memória alocada no processo do app, garantindo que os limites funcionem como um comportamento contratual crítico com os desenvolvedores de apps.

Implementações de dispositivos:

[C-0-1] NÃO PODE usar métodos, listas de permissão ou políticas para evitar os limites de memória de tempo de execução definidos para aplicativos.

9. Compatibilidade do modelo de segurança

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no Documento de referência de segurança e permissões nas APIs da documentação para desenvolvedores Android.
[C-0-2] É OBRIGATÓRIO oferecer suporte à instalação de aplicativos autassinados sem exigir permissões/certificados adicionais de terceiros/autoridades.

Se as implementações de dispositivos declararem o recurso android.hardware.security.model.compatible, elas:

[C-1-1] PRECISA oferecer suporte aos requisitos listados nas subseções a seguir.

9.1. Permissões

Implementações de dispositivos:

[C-0-1] PRECISA oferecer suporte ao modelo de permissões do Android e ao modelo de funções do Android conforme definido na documentação para desenvolvedores Android. Especificamente, eles PRECISAM aplicar cada permissão e função definida conforme descrito na documentação do SDK. Nenhuma permissão e nenhuma função pode ser omitida, alterada ou ignorada.
PODE adicionar outras permissões, desde que as novas strings de ID de permissão não estejam no namespace android.\*.
[C-0-2] As permissões com um protectionLevel de PROTECTION_FLAG_PRIVILEGED SÓ podem ser concedidas a apps pré-instalados nos caminhos privilegiados da imagem do sistema (bem como arquivos APEX) e estar no subconjunto de permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito lendo e respeitando as permissões permitidas para cada app nos arquivos do caminho etc/permissions/ e usando o caminho system/priv-app como o caminho privilegiado.
[C-SR-1] É ALTAMENTE RECOMENDADO que as permissões com um protectionLevel de PROTECTION_SIGNATURE sejam concedidas apenas a:
- Apps pré-instalados na imagem do sistema (bem como arquivos APEX).
- Apps na lista de permissões com permissões permitidas, se não estiverem incluídos na imagem do sistema.
Observação: a implementação do AOSP atende a esse requisito lendo e respeitando as permissões na lista de permissões de cada app nos arquivos do caminho etc/permissions/.

Permissões com um nível de proteção perigoso são permissões de execução. Aplicativos com targetSdkVersion > 22 solicitam permissões no momento da execução.

Implementações de dispositivos:

[C-0-3] PRECISA mostrar uma interface dedicada para o usuário decidir se quer conceder as permissões de execução solicitadas e também fornecer uma interface para gerenciar essas permissões.
[C-0-5] NÃO PODE conceder permissões de ambiente de execução a apps, a menos que:
- Eles são instalados no momento do envio do dispositivo, E
- O consentimento do usuário pode ser obtido antes que o aplicativo use a permissão.
OU
- As permissões de execução são concedidas pela política de concessão de permissão padrão ou por ter uma função da plataforma.
[C-0-6] PRECISA conceder a permissão android.permission.RECOVER_KEYSTORE somente a apps do sistema que registram um agente de recuperação adequadamente protegido. Um agente de recuperação adequadamente protegido é definido como um agente de software no dispositivo que sincroniza com um armazenamento remoto fora do dispositivo, equipado com hardware seguro com proteção equivalente ou mais forte do que o descrito no Serviço Google Cloud Key Vault para evitar ataques de força bruta no fator de conhecimento da tela de bloqueio.

Implementações de dispositivos:

[C-0-7] PRECISA obedecer às propriedades de permissão de localização do Android quando um app solicita os dados de localização ou dados de atividade pela API padrão do Android ou por um mecanismo proprietário. Esses dados incluem, entre outros:
- Localização do dispositivo (por exemplo, latitude e longitude), conforme descrito na Seção 9.8.8.
- Informações que podem ser usadas para determinar ou estimar a localização do dispositivo (por exemplo, SSID, BSSID, ID da célula ou localização da rede a que o dispositivo está conectado).
- Atividade física do usuário ou classificação da atividade física.

Mais especificamente, implementações de dispositivos:

[C-0-8] É OBRIGATÓRIO obter o consentimento do usuário para permitir que um app acesse os dados de localização ou de atividade física.
[C-0-9] PRECISA conceder uma permissão de execução SOMENTE ao app que tem permissão suficiente, conforme descrito no SDK. Por exemplo, TelephonyManager#getServiceState exige android.permission.ACCESS_FINE_LOCATION.

As únicas exceções às propriedades de permissão de localização do Android acima são para apps que não acessam a localização para derivar ou identificar o local do usuário, especificamente:

Quando os apps têm a permissão RADIO_SCAN_WITHOUT_LOCATION.
Para fins de configuração e instalação de dispositivos, em que os apps do sistema têm a permissão NETWORK_SETTINGS ou NETWORK_SETUP_WIZARD.

As permissões podem ser marcadas como restritas, alterando o comportamento delas.

[C-0-10] As permissões marcadas com a flag hardRestricted NÃO PODEM ser concedidas a um app, a menos que:
- Um arquivo APK do app está na partição do sistema.
- O usuário atribui a um app uma função associada às permissões hardRestricted.
- O instalador concede a hardRestricted a um app.
- Um app recebe a permissão hardRestricted em uma versão anterior do Android.
[C-0-11] Os apps que têm uma permissão softRestricted SÓ podem receber acesso limitado e NÃO podem ter acesso total até serem adicionados à lista de permissões, conforme descrito no SDK, em que o acesso total e limitado é definido para cada permissão softRestricted (por exemplo, READ_EXTERNAL_STORAGE).
[C-0-12] NÃO PODE fornecer funções ou APIs personalizadas para ignorar as restrições de permissão definidas nas APIs setPermissionPolicy e setPermissionGrantState.
[C-0-13] É OBRIGATÓRIO usar as APIs AppOpsManager para registrar e rastrear todos os acessos programáticos a dados protegidos por permissões perigosas de atividades e serviços do Android.
[C-0-14] SÓ atribua papéis a aplicativos com funcionalidades que atendam aos requisitos do papel.
[C-0-15] NÃO PODE definir papéis que sejam duplicados ou um superconjunto de funcionalidades de papéis definidos pela plataforma.

Se os dispositivos incluírem sensores de dados que exponham biometrias relacionadas à saúde, como frequência cardíaca ou temperatura da pele, essas biometrias:

[C-0-16] PRECISA ser protegido por permissões de plataforma de android.permission-group.HEALTH, se houver uma permissão correspondente em HealthPermissions.
[C-0-17] DEVE, se nenhuma permissão da plataforma corresponder ao tipo de dados desejado, ser protegida por uma permissão personalizada do sistema. Por exemplo, ELECTROCARDIOGRAM.

Se os dispositivos informarem android.software.managed_users, eles:

[C-1-1] NÃO PODE ter as seguintes permissões concedidas silenciosamente pelo administrador:
- Local (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Câmera (CAMERA)
- Microfone (RECORD_AUDIO)
- Sensor corporal (BODY_SENSORS)
- Saúde (HealthPermissions)
- Atividade física (ACTIVITY_RECOGNITION)

Se os dispositivos informarem android.software.managed_users, eles:

[C-1-1] NÃO PODE ter as seguintes permissões concedidas silenciosamente pelo administrador:
- Local (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Câmera (CAMERA)
- Microfone (RECORD_AUDIO)
- Sensor corporal (BODY_SENSORS)
- Atividade física (ACTIVITY_RECOGNITION)

Se as implementações de dispositivos oferecerem ao usuário a opção de escolher quais apps podem aparecer sobre outros apps com uma atividade que processa a intent ACTION_MANAGE_OVERLAY_PERMISSION, eles:

[C-2-1] É OBRIGATÓRIO garantir que todas as atividades com filtros de intent para a intent ACTION_MANAGE_OVERLAY_PERMISSION tenham a mesma tela de UI, independente do app iniciador ou de qualquer informação fornecida por ele.

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

[C-3-1] DEVE mostrar uma exoneração de responsabilidade durante a configuração de um dispositivo totalmente gerenciado (configuração do proprietário do dispositivo) informando que o administrador de TI poderá permitir que os apps controlem as configurações do smartphone, incluindo microfone, câmera e localização, com opções para o usuário continuar ou sair da configuração, A MENOS QUE o administrador tenha desativado o controle de permissões no dispositivo.

Se as implementações de dispositivos pré-instalarem pacotes que contenham qualquer uma das funções de Inteligência da interface do sistema, Inteligência de áudio ambiente do sistema, Inteligência de áudio do sistema, Inteligência de notificações do sistema, Inteligência de texto do sistema, ou Inteligência visual do sistema, os pacotes:

[C-4-1] PRECISA atender a todos os requisitos descritos para implementações de dispositivos nas seções 9.8.6. no nível do SO e dados ambientais e 9.8.15. Implementações de API em sandbox.

9.2. UID e isolamento de processos

Implementações de dispositivos:

[C-0-1] PRECISA oferecer suporte ao modelo de sandbox de apps Android, em que cada aplicativo é executado como um UID exclusivo no estilo Unix e em um processo separado.
[C-0-2] DEVE oferecer suporte à execução de vários aplicativos como o mesmo ID de usuário do Linux, desde que os aplicativos estejam devidamente assinados e construídos, conforme definido na referência de segurança e permissões.

9.3. Permissões do sistema de arquivos

Implementações de dispositivos:

[C-0-1] PRECISA oferecer suporte ao modelo de permissões de acesso a arquivos do Android, conforme definido na referência de segurança e permissões.

9.4. Ambientes de execução alternativos

As implementações de dispositivos PRECISAM manter a consistência do modelo de segurança e permissões do Android, mesmo que incluam ambientes de execução que executem aplicativos usando outro software ou tecnologia que não seja o formato executável Dalvik ou código nativo. Resumindo:

[C-0-1] Os runtimes alternativos PRECISAM ser aplicativos Android e obedecer ao modelo de segurança padrão do Android, conforme descrito em seção 9.
[C-0-2] Os runtimes alternativos NÃO PODEM receber acesso a recursos protegidos por permissões não solicitadas no arquivo AndroidManifest.xml do runtime pelo mecanismo <uses-permission>.
[C-0-3] Os runtimes alternativos NÃO PODEM permitir que os aplicativos usem recursos protegidos pelo Android por permissões restritas a aplicativos do sistema.
[C-0-4] Runtimes alternativos PRECISAM obedecer ao modelo de sandbox do Android, e aplicativos instalados usando um runtime alternativo NÃO PODEM reutilizar o sandbox de nenhum outro app instalado no dispositivo, exceto pelos mecanismos padrão do Android de ID de usuário compartilhado e certificado de assinatura.
[C-0-5] Os ambientes de execução alternativos NÃO PODEM ser iniciados com, conceder ou receber acesso aos sandboxes correspondentes a outros apps Android.
[C-0-6] Os ambientes de execução alternativos NÃO PODEM ser iniciados, receber ou conceder a outros aplicativos privilégios de superusuário (raiz) ou de qualquer outro ID de usuário.
[C-0-7] Quando os arquivos .apk de runtimes alternativos são incluídos na imagem do sistema de implementações de dispositivos, eles PRECISAM ser assinados com uma chave diferente da usada para assinar outros aplicativos incluídos nas implementações de dispositivos.
[C-0-8] Ao instalar aplicativos, os ambientes de execução alternativos PRECISAM obter o consentimento do usuário para as permissões do Android usadas pelo aplicativo.
[C-0-9] Quando um aplicativo precisar usar um recurso do dispositivo para o qual há uma permissão correspondente do Android (como câmera, GPS etc.), o tempo de execução alternativo PRECISA informar ao usuário que o aplicativo poderá acessar esse recurso.
[C-0-10] Quando o ambiente de execução não registra os recursos do aplicativo dessa maneira, ele PRECISA listar todas as permissões mantidas pelo próprio ambiente de execução ao instalar qualquer aplicativo usando esse ambiente.
Os runtimes alternativos DEVEM instalar apps pelo PackageManager em sandboxes separados do Android (IDs de usuário do Linux etc.).
Os ambientes de execução alternativos PODEM fornecer um único sandbox do Android compartilhado por todos os aplicativos que usam o ambiente de execução alternativo.

9.5. Suporte a vários usuários

O Android inclui suporte para vários usuários e oferece suporte para isolamento total de usuários e perfis de usuários clonados com isolamento parcial (ou seja, um único perfil de usuário adicional do tipo android.os.usertype.profile.CLONE).

As implementações de dispositivos PODEM, mas NÃO DEVEM ativar o multiusuário se usarem mídia removível para armazenamento externo principal.

Se as implementações de dispositivos incluírem suporte para vários usuários, elas:

[C-1-2] DEVE, para cada usuário, implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs.
[C-1-3] PRECISA ter diretórios separados e isolados de armazenamento de aplicativos compartilhados (também conhecidos como /sdcard) para cada instância de usuário.
[C-1-4] DEVE garantir que os aplicativos de propriedade de um determinado usuário e executados em nome dele não possam listar, ler ou gravar nos arquivos de propriedade de qualquer outro usuário, mesmo que os dados dos dois usuários estejam armazenados no mesmo volume ou sistema de arquivos.
[C-1-5] É OBRIGATÓRIO criptografar o conteúdo do cartão SD quando o modo multiusuário está ativado usando uma chave armazenada apenas em mídia não removível acessível somente ao sistema se as implementações de dispositivos usarem mídia removível para as APIs de armazenamento externo. Como isso vai tornar a mídia ilegível para um PC host, as implementações de dispositivos precisarão mudar para MTP ou um sistema semelhante para fornecer aos PCs host acesso aos dados do usuário atual.

Se as implementações de dispositivos incluírem suporte para vários usuários, então, para todos os usuários, exceto aqueles criados especificamente para executar instâncias duplas do mesmo app, eles:

[C-2-1] PRECISA ter diretórios de armazenamento de aplicativos compartilhados separados e isolados (também conhecidos como /sdcard) para cada instância de usuário.
[C-2-2] PRECISA garantir que os aplicativos de propriedade de um determinado usuário e executados em nome dele não possam listar, ler ou gravar nos arquivos de propriedade de qualquer outro usuário, mesmo que os dados de ambos os usuários estejam armazenados no mesmo volume ou sistema de arquivos.

As implementações de dispositivos PODEM criar um único perfil de usuário adicional do tipo android.os.usertype.profile.CLONE em relação ao usuário principal (e somente em relação ao usuário principal) com o objetivo de executar duas instâncias do mesmo app. Essas duas instâncias compartilham armazenamento parcialmente isolado, são apresentadas ao usuário final no iniciador ao mesmo tempo e aparecem na mesma visualização de apps recentes. Por exemplo, isso pode ser usado para permitir que o usuário instale duas instâncias separadas de um único app em um dispositivo com dois chips.

Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, elas:

[C-3-1] SÓ PODE dar acesso ao armazenamento ou aos dados que já estão acessíveis ao perfil de usuário principal ou que são de propriedade direta desse perfil de usuário adicional.
[C-3-2] NÃO PODE ter isso como um perfil de trabalho.
[C-3-3] DEVE ter diretórios de dados de apps particulares isolados da conta de usuário principal.
[C-3-4] NÃO PODE permitir a criação do perfil de usuário adicional se houver um proprietário do dispositivo provisionado (consulte a seção 3.9.1) nem permitir que um proprietário do dispositivo seja provisionado sem remover primeiro o perfil de usuário adicional.

Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, elas:

[C-4-1] PRECISA permitir que os intents abaixo originados do perfil adicional sejam processados por aplicativos do usuário principal no dispositivo:
- Intent.ACTION_VIEW
- Intent.ACTION_SENDTO
- Intent.ACTION_SEND
- Intent.ACTION_EDIT
- Intent.ACTION_INSERT
- Intent.ACTION_INSERT_OR_EDIT
- Intent.ACTION_SEND_MULTIPLE
- Intent.ACTION_PICK
- Intent.ACTION_GET_CONTENT
- MediaStore.ACTION_IMAGE_CAPTURE
- MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] DEVE herdar todas as restrições de usuário da política de dispositivo e o restrictions(list below) não usuário selecionado aplicado ao usuário principal do dispositivo a esse perfil de usuário adicional.
[C-4-3] SÓ PODE permitir a gravação de contatos desse perfil adicional usando as seguintes intents:
[C-4-4] NÃO PODE ter sincronizações de contatos em execução para aplicativos executados neste perfil de usuário adicional.
[C-4-5] SÓ PODE permitir que aplicativos no perfil adicional que tenham uma atividade de inicialização acessem contatos que já estão acessíveis ao perfil de usuário principal.

Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, incluírem pelo menos uma câmera e o aplicativo de câmera pré-instalado processar as intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE ou MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, elas:

[C-5-1] PRECISA permitir que os aplicativos do usuário principal processem essas intents originadas desse perfil de usuário adicional.

9.6. Aviso sobre SMS premium

O Android inclui suporte para avisar os usuários sobre qualquer mensagem SMS premium enviada. As mensagens de SMS premium são mensagens de texto enviadas para um serviço registrado em uma operadora que pode gerar uma cobrança para o usuário.

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

[C-1-1] DEVE alertar os usuários antes de enviar uma mensagem SMS para números identificados por expressões regulares definidas no arquivo /data/misc/sms/codes.xml do dispositivo. O projeto upstream Android Open Source Project oferece uma implementação que atende a esse requisito.

9.7. Recursos de segurança

As implementações de dispositivos PRECISAM garantir a conformidade com os recursos de segurança no kernel e na plataforma, conforme descrito abaixo.

O sandbox do Android inclui recursos que usam o sistema de controle de acesso obrigatório (MAC) do Security-Enhanced Linux (SELinux), o sandbox seccomp e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:

[C-0-1] DEVE manter a compatibilidade com aplicativos atuais, mesmo quando o SELinux ou outros recursos de segurança forem implementados abaixo da estrutura do Android.
[C-0-2] NÃO PODE ter uma interface visível quando uma violação de segurança é detectada e bloqueada pelo recurso de segurança implementado abaixo da estrutura do Android, mas PODE ter uma interface visível quando uma violação de segurança não bloqueada resulta em uma exploração bem-sucedida.
[C-0-3] NÃO PODE tornar o SELinux ou qualquer outro recurso de segurança implementado abaixo da estrutura do Android configurável para o usuário ou desenvolvedor de apps.
[C-0-4] NÃO PODE permitir que um aplicativo que possa afetar outro aplicativo por uma API (como uma API Device Administration) configure uma política que quebre a compatibilidade.
[C-0-5] É OBRIGATÓRIO dividir a estrutura de mídia em vários processos para que seja possível conceder acesso de forma mais restrita a cada processo, conforme descrito no site do Android Open Source Project.
[C-0-6] É OBRIGATÓRIO implementar um mecanismo de sandbox de aplicativos do kernel que permita a filtragem de chamadas de sistema usando uma política configurável de programas multithread. O Android Open Source Project upstream atende a esse requisito ao ativar o seccomp-BPF com sincronização de threadgroup (TSYNC), conforme descrito na seção "Configuração do kernel" de source.android.com.

A integridade do kernel e os recursos de autoproteção são essenciais para a segurança do Android. Implementações de dispositivos:

[C-0-7] É OBRIGATÓRIO implementar mecanismos de proteção contra estouro de buffer de pilha do kernel. Exemplos desses mecanismos são CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] É OBRIGATÓRIO implementar proteções estritas de memória do kernel em que o código executável seja somente leitura, os dados somente leitura não sejam executáveis nem graváveis, e os dados graváveis não sejam executáveis (por exemplo, rodata e CONFIG_STRICT_KERNEL_RWX estão ativados).
[C-0-9] PRECISA implementar a verificação estática e dinâmica dos limites de tamanho de objetos de cópias entre o espaço do usuário e o espaço do kernel (por exemplo, CONFIG_HARDENED_USERCOPY) em dispositivos originalmente enviados com nível da API 28 ou mais recente.
[C-0-10] NÃO PODE executar memória do espaço do usuário ao executar no modo kernel (por exemplo, PXN de hardware ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente enviados com o nível da API 28 ou mais recente.
[C-0-11] NÃO PODE ler ou gravar memória do espaço do usuário no kernel fora das APIs de acesso usercopy normais (por exemplo, PAN de hardware ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente enviados com o nível da API 28 ou mais recente.
[C-0-12] É OBRIGATÓRIO implementar o isolamento da tabela de páginas do kernel se o hardware for vulnerável à CVE-2017-5754 em todos os dispositivos originalmente enviados com nível da API 28 ou mais recente (por exemplo, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] É OBRIGATÓRIO implementar o reforço da proteção contra previsão de ramificação se o hardware for vulnerável à CVE-2017-5715 em todos os dispositivos originalmente enviados com nível da API 28 ou mais recente (por exemplo, CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] É ALTAMENTE RECOMENDADO manter os dados do kernel gravados apenas durante a inicialização marcados como somente leitura após a inicialização (por exemplo, __ro_after_init).
[C-SR-2] É FORTEMENTE RECOMENDADO randomizar o layout do código do kernel e da memória, além de evitar exposições que comprometam a randomização (por exemplo, CONFIG_RANDOMIZE_BASE com entropia do carregador de inicialização via /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).
[C-SR-3] É ALTAMENTE RECOMENDADO ativar a integridade do fluxo de controle (CFI) no kernel para oferecer proteção adicional contra ataques de reutilização de código (por exemplo, CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).
[C-SR-4] É ALTAMENTE RECOMENDADO não desativar a integridade do fluxo de controle (CFI), a pilha de chamadas de sombra (SCS) ou a limpeza de estouro de números inteiros (IntSan) em componentes que têm esses recursos ativados.
[C-SR-5] É ALTAMENTE RECOMENDADO ativar CFI, SCS e IntSan para outros componentes do espaço do usuário sensíveis à segurança, conforme explicado em CFI e IntSan.
[C-SR-6] É ALTAMENTE RECOMENDÁVEL ativar a inicialização de pilha no kernel para evitar o uso de variáveis locais não inicializadas (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). Além disso, as implementações de dispositivos NÃO DEVEM presumir o valor usado pelo compilador para inicializar as variáveis locais.
[C-SR-7] É ALTAMENTE RECOMENDÁVEL ativar a inicialização do heap no kernel para evitar usos de alocações de heap não inicializadas (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NÃO PRESUMIR o valor usado pelo kernel para inicializar essas alocações.

Se as implementações de dispositivos usarem um kernel do Linux capaz de oferecer suporte ao SELinux, elas:

[C-1-1] É OBRIGATÓRIO implementar o SELinux.
[C-1-2] PRECISA definir o SELinux como modo de imposição global.
[C-1-3] É OBRIGATÓRIO configurar todos os domínios no modo de aplicação. Nenhum domínio de modo permissivo é permitido, incluindo domínios específicos de um dispositivo/fornecedor.

[C-1-4] NÃO PODE:
- Modificar, omitir ou substituir as regras neverallow presentes na pasta system/sepolicy fornecida no Android Open Source Project (AOSP) upstream
- Anexar incorretamente rótulos do SELinux do AOSP a componentes que não são do AOSP
A política PRECISA ser compilada com todas as regras neverallow presentes, tanto para domínios SELinux do AOSP quanto para domínios específicos do dispositivo/fornecedor.

[C-1-5] É OBRIGATÓRIO executar aplicativos de terceiros destinados ao nível da API 28 ou mais recente em sandboxes SELinux por aplicativo com restrições SELinux por app no diretório de dados particulares de cada aplicativo.
DEVE manter a política SELinux padrão fornecida na pasta system/sepolicy do Android Open Source Project upstream e adicionar a essa política apenas a configuração específica do dispositivo.

Se as implementações de dispositivos usarem um kernel diferente do Linux ou o Linux sem SELinux, elas:

[C-2-1] É OBRIGATÓRIO usar um sistema de controle de acesso obrigatório equivalente ao SELinux.

Se as implementações de dispositivos usarem dispositivos de E/S capazes de DMA, elas:

[C-SR-9] É ALTAMENTE RECOMENDADO isolar cada dispositivo de E/S capaz de DMA, usando uma IOMMU (por exemplo, a SMMU ARM).

O Android tem vários recursos de defesa em profundidade que são essenciais para a segurança do dispositivo. Além disso, o Android se concentra em reduzir as principais classes de bugs comuns que contribuem para a baixa qualidade e segurança.

Para reduzir bugs de memória, as implementações de dispositivos:

[C-SR-10] É ALTAMENTE RECOMENDADO que sejam testados usando ferramentas de detecção de erros de memória do espaço do usuário, como MTE para dispositivos ARMv9, HWASan para dispositivos ARMv8+ ou ASan para outros tipos de dispositivos.
[C-SR-11] É ALTAMENTE RECOMENDADO testar usando ferramentas de detecção de erros de memória do kernel, como KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS para dispositivos ARMv9, CONFIG_KASAN_SW_TAGS para dispositivos ARMv8 ou CONFIG_KASAN_GENERIC para outros tipos de dispositivos).
[C-SR-12] É ALTAMENTE RECOMENDÁVEL usar ferramentas de detecção de erros de memória em produção, como MTE, GWP-ASan e KFENCE.

Se as implementações de dispositivos usarem um TEE baseado no Arm TrustZone, elas:

[C-SR-13] É ALTAMENTE RECOMENDADO usar um protocolo padrão para compartilhamento de memória entre o Android e o TEE, como o Arm Firmware Framework para Armv8-A (FF-A).
[C-SR-14] É ALTAMENTE RECOMENDADO restringir aplicativos confiáveis para acessar apenas a memória que foi compartilhada explicitamente com eles pelo protocolo acima. Se o dispositivo tiver suporte para o nível de exceção Arm S-EL2, isso será aplicado pelo gerenciador de partição segura. Caso contrário, isso será aplicado pelo SO do TEE.

Uma tecnologia de segurança de memória é aquela que reduz pelo menos as seguintes classes de bugs com uma alta probabilidade (> 90%) em aplicativos que usam a opção de manifesto android:memtagMode:

estouro de buffer de heap
uso após liberação
liberação dupla
wild free (livre de um ponteiro não malloc)

Implementações de dispositivos:

[C-SR-15] É ALTAMENTE RECOMENDÁVEL definir ro.arm64.memtag.bootctl_supported.

Se as implementações de dispositivos definirem a propriedade do sistema ro.arm64.memtag.bootctl_supported como "true", elas:

[C-3-1] DEVE permitir que a propriedade do sistema arm64.memtag.bootctl aceite uma lista separada por vírgulas dos seguintes valores, com o efeito desejado aplicado na próxima reinicialização subsequente:
- memtag: uma tecnologia de segurança de memória, conforme definido acima, está ativada.
- memtag-once: uma tecnologia de segurança de memória, conforme definido acima, é ativada temporariamente e desativada automaticamente na próxima reinicialização.
- memtag-off: uma tecnologia de segurança de memória, conforme definido acima, está desativada
[C-3-2] DEVE permitir que o usuário do shell defina arm64.memtag.bootctl.
[C-3-3] DEVE permitir que qualquer processo leia arm64.memtag.bootctl.
[C-3-4] Precisa definir arm64.memtag.bootctl como o estado solicitado no momento na inicialização. Também precisa atualizar a propriedade se a implementação do dispositivo permitir modificar o estado sem mudar a propriedade do sistema.
[C-SR-16] É ALTAMENTE RECOMENDADO mostrar uma configuração de desenvolvedor que defina memtag-once e reinicie o dispositivo. Com um carregador de inicialização compatível, o Android Open Source Project atende aos requisitos acima usando o protocolo de carregador de inicialização MTE.

Se um dispositivo declarar android.hardware.telephony, oferecer suporte ao recurso de rádio CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK e incluir um modem celular compatível com conexões 2G, a implementação do dispositivo:

[C-SR-17] É ALTAMENTE RECOMENDADO oferecer ao usuário a opção de desativar e ativar o 2G.
[C-SR-18] É ALTAMENTE RECOMENDADO não substituir a capacidade do usuário de desativar e ativar o 2G por qualquer outra entidade de dispositivo, exceto por um administrador de dispositivo usando UserManager.DISALLOW_CELLULAR_2G.
[C-SR-19] É ALTAMENTE RECOMENDADO chamar TelephonyManager.setAllowedNetworkTypesForReason com o motivo ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G para atender a esse requisito.
[C-SR-20] É ALTAMENTE RECOMENDADO determinar o suporte do modem celular para 2G ligando para TelephonyManager.getSupportedRadioAccessFamily. Consulte Desativar 2G para mais detalhes.

9.8. Privacidade

9.8.1. Histórico de uso

O Android armazena o histórico de escolhas do usuário e o gerencia usando o UsageStatsManager.

Implementações de dispositivos:

[C-0-1] DEVE manter um período de armazenamento razoável desse histórico do usuário.
[C-SR-1] É ALTAMENTE RECOMENDADO manter o período de armazenamento de 14 dias conforme configurado por padrão na implementação do AOSP.

O Android armazena os eventos do sistema usando os identificadores StatsLog e gerencia esse histórico pela StatsManager e pela API IncidentManager System.

Implementações de dispositivos:

[C-0-2] SÓ PODE incluir os campos marcados com DEST_AUTOMATIC no relatório de incidente criado pela classe IncidentManager da API System.
[C-0-3] NÃO PODE usar os identificadores de eventos do sistema para registrar qualquer outro evento que não seja o descrito nos documentos do SDK StatsLog. Se outros eventos do sistema forem registrados, eles PODERÃO usar um identificador de átomo diferente no intervalo entre 100.000 e 200.000.

9.8.2. Gravando

Implementações de dispositivos:

[C-0-1] NÃO PODE pré-carregar ou distribuir componentes de software prontos para uso que enviem informações particulares do usuário (por exemplo, pressionamentos de tecla, texto exibido na tela, bugreport) do dispositivo sem o consentimento do usuário ou notificações claras e contínuas.
[C-0-2] É OBRIGATÓRIO mostrar um aviso ao usuário e obter consentimento do usuário explícito dele para permitir que qualquer informação sensível mostrada na tela do usuário seja capturada sempre que uma sessão de captura de tela ou gravação de tela for ativada por MediaProjection.createVirtualDisplay() ou APIs proprietárias.
[C-0-3] DEVE ter uma notificação em andamento para o usuário enquanto a transmissão de tela ou a gravação de tela estiver ativada. O AOSP atende a esse requisito mostrando um ícone de notificação em andamento na barra de status.
[C-SR-1] É ALTAMENTE RECOMENDADO mostrar um aviso ao usuário que seja exatamente a mesma mensagem implementada no AOSP, mas PODE ser alterado desde que a mensagem avise claramente ao usuário que qualquer informação sensível na tela dele será capturada.
[C-0-4] Requisito removido no Android 16.

Implementações de dispositivos:

[C-0-7] NÃO PODE gravar, projetar ou transmitir informações sensíveis, como:
- Conteúdo de notificação sensível listado na Seção 3.8.3.4 Proteção de notificações sensíveis
- Janelas de atividade do app que contêm senhas únicas
- Conteúdo sensível, como nome de usuário, senha e informações de cartão de crédito

Se as implementações de dispositivos incluírem funcionalidades no sistema que capturam o conteúdo exibido na tela e/ou gravam o stream de áudio reproduzido no dispositivo, exceto pela API do sistema ContentCaptureService, ou outros meios proprietários descritos na Seção 9.8.6 Dados ambientais e no nível do SO, eles:

[C-1-1] DEVE ter uma notificação em andamento para o usuário sempre que essa funcionalidade estiver ativada e capturando/gravando ativamente.

Se as implementações de dispositivos incluírem um componente ativado de fábrica capaz de gravar áudio ambiente e/ou gravar o áudio reproduzido no dispositivo para inferir informações úteis sobre o contexto do usuário, elas:

[C-2-1] NÃO PODE armazenar em armazenamento persistente no dispositivo nem transmitir para fora do dispositivo o áudio bruto gravado ou qualquer formato que possa ser convertido de volta para o áudio original ou um fac-símile próximo, exceto com o consentimento explícito do usuário.

Um "indicador de microfone" se refere a uma visualização na tela que fica constantemente visível para o usuário e não pode ser ocultada. Os usuários entendem que um microfone está em uso por um texto, cor, ícone ou alguma combinação exclusiva.

Um "indicador de câmera" se refere a uma visualização na tela, que fica constantemente visível para o usuário e não pode ser ocultada. Os usuários entendem que uma câmera está em uso por um texto, cor, ícone ou alguma combinação exclusiva.

Depois do primeiro segundo exibido, um indicador pode mudar visualmente, como ficar menor, e não precisa aparecer como foi apresentado e entendido originalmente.

O indicador de microfone pode ser mesclado com um indicador de câmera ativo, desde que texto, ícones ou cores indiquem ao usuário que o uso do microfone começou.

O Indicador de câmera pode ser mesclado com um indicador de microfone ativo desde que texto, ícones ou cores indiquem ao usuário que o uso da câmera começou.

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

[C-SR-1] É FORTEMENTE RECOMENDADO mostrar o indicador de 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 têm as funções mencionadas na seção 9.1 Permissões com identificador do CDD [C-3-X].
[C-SR-2] É ALTAMENTE RECOMENDADO mostrar a lista de apps recentes e ativos que usam o microfone, conforme retornado de PermissionManager.getIndicatorAppOpUsageData(), junto com as mensagens de atribuição associadas a eles.
[C-SR-3] É FORTEMENTE RECOMENDADO não ocultar o indicador de microfone para apps do sistema que têm interfaces de usuário visíveis ou interação direta com o usuário.

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

[C-SR-4] É ALTAMENTE RECOMENDADO mostrar o indicador de câmera quando um app está acessando dados de câmera ao vivo, mas não quando a câmera está sendo acessada por apps que têm as funções mencionadas na Seção 9.1 Permissões com identificador CDD [C-3-X].
[C-SR-5] É ALTAMENTE RECOMENDADO mostrar apps recentes e ativos usando a câmera conforme retornado de PermissionManager.getIndicatorAppOpUsageData(), além de mensagens de atribuição associadas a eles.
[C-SR-6] É FORTEMENTE RECOMENDADO não ocultar o indicador de câmera para apps do sistema que têm interfaces de usuário visíveis ou interação direta do usuário.

9.8.3. Conectividade

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

[C-1-1] PRECISA apresentar uma interface do usuário pedindo o consentimento do usuário antes de permitir o acesso ao conteúdo do armazenamento compartilhado pela porta USB.

9.8.4. Tráfego de rede

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO pré-instalar os mesmos certificados raiz para o repositório de autoridade certificadora (CA) confiável do sistema fornecido no Android Open Source Project upstream.
[C-0-2] Precisa ser enviado com um armazenamento de CA raiz do usuário vazio.
[C-0-3] DEVE mostrar um aviso ao usuário indicando que o tráfego de rede pode ser monitorado quando uma CA raiz do usuário é adicionada.

Se o tráfego do dispositivo for encaminhado por uma VPN, as implementações do dispositivo:

[C-1-1] DEVE mostrar um aviso ao usuário indicando uma das seguintes opções:
- Esse tráfego de rede pode ser monitorado.
- Esse tráfego de rede está sendo roteado pelo aplicativo específico que fornece a VPN.

Se as implementações de dispositivos tiverem um mecanismo ativado por padrão que roteia o tráfego de dados de rede por um servidor proxy ou gateway de VPN (por exemplo, pré-carregando um serviço de VPN com android.permission.CONTROL_VPN concedido), elas:

[C-2-1] É OBRIGATÓRIO pedir o consentimento do usuário antes de ativar esse mecanismo, a menos que a VPN seja ativada pelo controlador de política de dispositivo via DevicePolicyManager.setAlwaysOnVpnPackage(), caso em que o usuário não precisa dar um consentimento separado, mas SÓ precisa ser notificado.

Se as implementações de dispositivos implementarem uma conveniência do usuário para ativar a função "VPN sempre ativa" de um app de VPN de terceiros, elas:

[C-3-1] É OBRIGATÓRIO desativar essa facilidade para apps que não oferecem suporte ao serviço de VPN sempre ativada no arquivo AndroidManifest.xml definindo o atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON como false.

9.8.5. Identificadores de dispositivo

Implementações de dispositivos:

[C-0-1] DEVE impedir o acesso ao número de série do dispositivo e, quando aplicável, ao IMEI/MEID, número de série do SIM e Identidade Internacional de Assinante Móvel (IMSI) de um app, a menos que ele atenda a um dos seguintes requisitos:
- é um app da operadora assinado e verificado pelos fabricantes de dispositivos.
- recebeu a permissão READ_PRIVILEGED_PHONE_STATE.
- tem privilégios de operadora, conforme definido em Privilégios da operadora UICC.
- é um proprietário de dispositivo ou perfil que recebeu a permissão READ_PHONE_STATE.
- (Somente para número de série do SIM/ICCID) tem a exigência das regulamentações locais de que o app detecte mudanças na identidade do assinante.

9.8.6. Protetor de dados ambientais e no nível do SO

O Android, pelas APIs do sistema, oferece suporte a um mecanismo para que as implementações de dispositivos capturem os seguintes dados sensíveis:

Texto e gráficos renderizados na tela, incluindo, mas não se limitando a, notificações e dados de assistência via API AssistStructure , atividades de captura de buffer de tela e gravação do conteúdo da tela de um dispositivo.

Dados de mídia, como áudio ou vídeo, gravados ou reproduzidos pelo dispositivo.
Eventos de entrada (por exemplo, tecla, mouse, gesto, voz, vídeo e acessibilidade).
Qualquer tela ou outros dados enviados via AugmentedAutofillService para o sistema.
Qualquer tela ou outros dados acessíveis pelas APIs Content Capture.
Todos os dados de aplicativos transmitidos ao sistema pela API AppSearchManager e acessíveis pela AppSearchGlobalManager.query.
Qualquer texto ou outros dados enviados via TextClassifier API para o TextClassifier do sistema, ou seja, para o serviço do sistema entender o significado do texto, além de gerar as próximas ações previstas com base no texto.
Dados indexados pela implementação da plataforma AppSearch, incluindo, mas não se limitando a, texto, gráficos, dados de mídia ou outros dados semelhantes.
Dados de áudio obtidos como resultado do uso de SpeechRecognizer#onDeviceSpeechRecognizer() pela implementação do reconhecedor de fala.
Dados de áudio obtidos em segundo plano (continuamente) por AudioRecord, SoundTrigger ou outras APIs de áudio, sem resultar em um indicador visível para o usuário
Dados da câmera obtidos em segundo plano (continuamente) pelo CameraManager ou outras APIs Camera, sem resultar em um indicador visível para o usuário

Todos os dados capturados pelo DynamicInstrumentationEventService

Se as implementações de dispositivos capturarem ou compartilharem qualquer um dos dados sensíveis acima, elas: sem uma intenção clara, discreta ou visível do usuário ou um indicador de privacidade visível para o usuário, os dados PRECISAM ser tratados em um ambiente de execução protegido. Este ambiente:

[C-1-1] PRECISA criptografar todos esses dados quando armazenados no dispositivo ou em trânsito. Essa criptografia PODE ser realizada usando a criptografia baseada em arquivos do Android ou qualquer uma das cifras listadas como versão 26 ou mais recente da API, conforme descrito no SDK de cifras.
[C-1-2] NÃO PODE fazer backup de dados brutos ou criptografados usando métodos de backup do Android ou qualquer outro método de backup dados sensíveis, conforme descrito acima.

[C-1-3] NÃO PODE enviar esses dados para fora do dispositivo, exceto em uma das seguintes condições:
- Quando explicitamente iniciada pela intenção do usuário ^* para o cálculo específico sempre que os dados são compartilhados.
- Ao usar um mecanismo que preserva a privacidade, como tecnologias de privacidade diferencial, como RAPPOR ou computações federadas confidenciais.
- Quando os dados são tratados em um ambiente de execução protegido que os protege do provedor de serviços e da infraestrutura, como sem acesso de administrador, VM confidencial, comprovação remota, sem saída de dados particulares, registro em log desativado, ocultação de IP e criptografia.
  - Qualquer implementação que use esse método precisa oferecer uma opção de desativação para os usuários.

[C-1-3] PODE processar dados em um ambiente de nuvem de base de computação confiável que os protege do provedor de serviços e da infraestrutura (por exemplo, sem acesso de administrador, VM confidencial, comprovação remota, sem saída de dados particulares, registro desativado, mascaramento de IP e criptografia). Qualquer implementação que use este método:
- PRECISA oferecer uma opção para os usuários desativarem e
- É OBRIGATÓRIO fornecer aos usuários um método para gerar registros acessíveis e abrangentes que detalham a entrada e saída de dados do ambiente.

[C-1-4] NÃO ASSOCIAR esses dados a nenhuma identidade de usuário (como Account) no dispositivo, exceto com o consentimento explícito do usuário a cada vez que os dados forem associados.

[C-1-4] PODE mostrar esses dados em superfícies da interface do usuário pertencentes ao sistema.

[C-1-5] NÃO PODE compartilhar nem associar esses dados a qualquer identidade de usuário (como Account), exceto com consentimento explícito do usuário sempre que forem compartilhados cada vez que os dados forem associados, ou a associação não será transmitida para outros componentes do SO que não seguem os requisitos descritos nesta seção (9.8.6 Dados ambientais e no nível do SO) sempre que forem compartilhados. A menos que essa funcionalidade seja criada como uma API do SDK do Android (AmbientContext, HotwordDetectionService).
[C-1-6] PRECISA oferecer ao usuário a possibilidade de apagar os dados que a implementação ou os meios proprietários coletam quando os dados são armazenados de qualquer forma no dispositivo ou no ambiente de nuvem da base de computação confiável. Se o usuário escolher apagar os dados, todos os dados históricos coletados DEVERÃO ser removidos.

[C-1-7] PRECISA oferecer uma opção para o usuário desativar a exibição dos dados coletados pelo AppSearch ou por meios proprietários na plataforma Android (por exemplo, o launcher).

[C-1-8] DEVE fornecer um método para gerar registros acessíveis e abrangentes que detalham a entrada e saída de dados do ambiente.
[C-1-9] NÃO PODE ter acesso direto à Internet.
[C-1-10] PODE mostrar a interface remotamente, desde que nenhum dado seja disponibilizado para o APK do host que mostra a interface.
[C-1-11] PRECISA manter os serviços separados de outros componentes do sistema (por exemplo, não vinculando o serviço ou compartilhando IDs de processo com implementações que não estão no ambiente de execução protegida).
[C-1-12] SÓ É PERMITIDO que dados sensíveis saiam quando:
- Iniciada explicitamente pela intenção do usuário* para o cálculo específico sempre que os dados são compartilhados; OU
- Usando um mecanismo que preserva a privacidade (por exemplo, tecnologias de privacidade diferencial, como RAPPOR / computações federadas confidenciais).
[C-1-13] SÓ PODE permitir a exfiltração de dados sensíveis por:
- Um serviço do sistema que está na lista de permissões do serviço do sistema PCCSandbox E segue os requisitos de um ambiente de execução protegido (9.8.6), OU
- Um APK de gateway do Private Compute Core (PCC) designado (definido em 9.8.15).
[C-1-14] NÃO PODE fazer backups na nuvem de dados inferidos de dados sensíveis, a menos que sejam criptografados de ponta a ponta (por exemplo, usando o Android Backup Service).

[C-SR-1] É FORTEMENTE RECOMENDADO NÃO solicitar a permissão de INTERNET.
[C-SR-2] É ALTAMENTE RECOMENDADO acessar a Internet apenas por APIs estruturadas com suporte de implementações de código aberto disponíveis publicamente.
[C-SR-4] É ALTAMENTE RECOMENDADO que sejam implementadas com a API do SDK do Android ou um repositório de código aberto semelhante de propriedade do OEM e / ou sejam realizadas em uma implementação em sandbox (consulte 9.8.15 Implementações de API em sandbox).

Se as implementações de dispositivos incluírem um serviço que implementa a API System ContentCaptureService, AppSearchManager.index, DynamicInstrumentationEventService, ou qualquer serviço reservado que capture os dados conforme descrito acima, eles:

[C-2-1] NÃO PODE permitir que os usuários substituam os serviços por um aplicativo ou serviço instalável pelo usuário e SÓ PODE permitir que os serviços pré-instalados capturem esses dados.
[C-2-2] NÃO PODE permitir que outros apps, além do mecanismo de serviços pré-instalados, capturem esses dados.
[C-2-3] PRECISA oferecer uma capacidade de uso clara e acessível para desativar os serviços.
[C-2-4] NÃO PODE omitir a capacidade do usuário de gerenciar permissões do Android mantidas pelos serviços e seguir o modelo de permissões do Android conforme descrito na Seção 9.1. Permissão.
[C-SR-3] É ALTAMENTE RECOMENDADO manter os serviços separados de outros componentes do sistema (por exemplo, não vinculando o serviço nem compartilhando IDs de processo), exceto nos seguintes casos:
- Telefonia, contatos, interface do sistema e mídia

9.8.7. Acesso à área de transferência

Implementações de dispositivos:

[C-0-1] NÃO PODE retornar dados cortados da área de transferência (por exemplo, pela API ClipboardManager ) a menos que o app de terceiros seja o IME padrão ou esteja em foco no momento.
[C-0-2] É OBRIGATÓRIO limpar os dados da área de transferência no máximo 60 minutos após a última vez em que foram colocados ou lidos de uma área de transferência.

9.8.8. Local

A localização inclui informações na classe de localização do Android( como latitude, longitude e altitude), além de identificadores que podem ser convertidos em localização. A localização pode ser tão precisa quanto o DGPS (Sistema de Posicionamento Global Diferencial) ou tão aproximada quanto a localização no nível do país (como o código do país para dispositivos móveis, MCC).

A seguir, uma lista de tipos de local que derivam diretamente a localização de um usuário ou podem ser convertidos na localização de um usuário. Esta não é uma lista completa, mas deve ser usada como um exemplo do que pode ser derivado direta ou indiretamente da localização:

GPS/GNSS/DGPS/PPP
- Solução de posicionamento global, sistema global de navegação por satélite ou solução de posicionamento global diferencial
- Isso também inclui medições GNSS brutas e status do GNSS.
  - A localização precisa pode ser derivada das medições GNSS brutas
Tecnologias sem fio com identificadores exclusivos, como:
- Pontos de acesso Wi-Fi (MAC, BSSID, nome ou SSID)
- Bluetooth/BLE (MAC, BSSID, nome ou SSID)
- UWB (MAC, BSSID, nome ou SSID)
- ID da torre de celular (3G, 4G, 5G etc., incluindo todas as tecnologias futuras de modem celular que têm identificadores exclusivos)

Como ponto de referência principal, consulte as APIs do Android que exigem permissões ACCESS_FINE_Location ou ACCESS_COARSE_Location.

Implementações de dispositivos:

[C-0-1] NÃO PODE ativar/desativar a configuração de local do dispositivo e as configurações de verificação de Wi-Fi/Bluetooth sem o consentimento explícito ou a iniciação do usuário.
[C-0-2] PRECISA oferecer ao usuário a possibilidade de acessar informações relacionadas à localização, incluindo solicitações recentes de localização, permissões no nível do app e uso da busca por Bluetooth/Wi-Fi para determinar a localização.
[C-0-3] PRECISA garantir que o aplicativo que usa a API Emergency Location Bypass LocationRequest.setLocationSettingsIgnored() seja uma sessão de emergência iniciada pelo usuário (por exemplo, ligar para 190 ou enviar uma mensagem de texto para 190). No entanto, para o setor automotivo, um veículo PODE iniciar uma sessão de emergência sem interação ativa do usuário caso seja detectada uma colisão/acidente (como para atender aos requisitos do eCall).
[C-0-4] É OBRIGATÓRIO preservar a capacidade das APIs de substituição de localização de emergência de substituir as configurações de localização do dispositivo sem alterá-las.
[C-0-5] PRECISA programar uma notificação que lembre o usuário depois que um app em segundo plano acessar a localização dele usando a permissão ACCESS_BACKGROUND_LOCATION.

Quando um aplicativo em primeiro plano que não é do sistema acessa o local exato de um dispositivo, ele:

[C-SR-1] É ALTAMENTE RECOMENDÁVEL mostrar um indicador visível para o usuário

9.8.9. Apps instalados

Os apps Android destinados ao nível 30 da API ou mais recente não podem ver detalhes sobre outros apps instalados por padrão. Consulte Visibilidade do pacote na documentação do SDK do Android.

Implementações de dispositivos:

[C-0-1] NÃO PODE expor a nenhum app destinado ao nível 30 da API ou mais recente detalhes sobre qualquer outro app instalado, a menos que o app já possa ver detalhes sobre o outro app instalado pelas APIs gerenciadas. Isso inclui, entre outros, detalhes expostos por APIs personalizadas adicionadas pelo implementador do dispositivo ou acessíveis pelo sistema de arquivos.
[C-0-2] NÃO PODE conceder a nenhum app acesso de leitura ou gravação a arquivos no diretório dedicado e específico do app de outro aplicativo no armazenamento externo. As únicas exceções são:
- A autoridade do provedor de armazenamento externo (por exemplo, apps como o DocumentsUI).
- Download Provider, que usa a autoridade do provedor "downloads" para baixar arquivos para o armazenamento do app.
- Apps de protocolo de transferência de mídia (MTP) assinados pela plataforma que usam a permissão privilegiada ACCESS_MTP para permitir a transferência de arquivos para outro dispositivo.
- Os apps que instalam outros apps e têm a permissão INSTALL_PACKAGES podem acessar apenas diretórios "obb" para gerenciar arquivos de expansão do APK.

9.8.10. Relatório de bug de conectividade

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

[C-1-1] PRECISA oferecer suporte à geração de relatórios de bugs de conectividade via BUGREPORT_MODE_TELEPHONY com o BugreportManager.
[C-1-2] É OBRIGATÓRIO obter o consentimento do usuário sempre que BUGREPORT_MODE_TELEPHONY for usado para gerar um relatório e NÃO É PERMITIDO pedir que o usuário concorde com todas as solicitações futuras do aplicativo.
[C-1-3] NÃO PODE retornar o relatório gerado ao app solicitante sem o consentimento explícito do usuário.
[C-1-4] Os relatórios gerados usando BUGREPORT_MODE_TELEPHONY precisam conter pelo menos as seguintes informações:
- Dump de TelephonyDebugService
- Dump de TelephonyRegistry
- Dump de WifiService
- Dump de ConnectivityService
- Um despejo da instância CarrierService do pacote de chamada (se vinculada)
- Buffer de registro de rádio
- Dump de SubscriptionManagerService
[C-1-5] NÃO PODE incluir o seguinte nos relatórios gerados:
- Qualquer tipo de informação que não esteja diretamente relacionada à depuração de conectividade.
- Qualquer tipo de registro de tráfego de aplicativos instalados pelo usuário ou perfis detalhados de aplicativos/pacotes instalados pelo usuário (UIDs são permitidos, nomes de pacotes não).
PODE incluir informações adicionais que não estão associadas a nenhuma identidade de usuário. (por exemplo, registros do fornecedor).

Se as implementações de dispositivos incluírem informações adicionais (por exemplo, registros de fornecedores) em relatórios de bugs e essas informações tiverem impacto na privacidade/segurança/bateria/armazenamento/memória, elas:

[C-SR-1] É FORTEMENTE RECOMENDADO que uma configuração de desenvolvedor seja desativada por padrão. A implementação de referência do AOSP atende a esse requisito ao fornecer a opção Enable verbose vendor logging nas configurações do desenvolvedor para incluir registros adicionais específicos do dispositivo nos relatórios de bugs.

9.8.11. Compartilhamento de blobs de dados

O Android, pelo BlobStoreManager, permite que os apps contribuam com blobs de dados para o sistema, que serão compartilhados com um conjunto selecionado de apps.

Se as implementações de dispositivos forem compatíveis com blobs de dados pessoais compartilhados, conforme descrito na documentação do SDK, elas:

[C-1-1] NÃO PODE compartilhar blobs de dados pertencentes a apps além do que eles pretendiam permitir (ou seja, o escopo do acesso padrão e os outros modos de acesso que podem ser especificados usando BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), ou BlobStoreManager.session#allowPublicAccess() NÃO PODE ser modificado). A implementação de referência do AOSP atende a esses requisitos.
[C-1-2] NÃO PODE enviar para fora do dispositivo nem compartilhar com outros apps os hashes seguros de blobs de dados (usados para controlar o acesso).

9.8.12. Identificação de música

O Android, pela API do sistema MusicRecognitionManager, oferece suporte a um mecanismo para que as implementações de dispositivos solicitem o reconhecimento de músicas, considerando uma gravação de áudio, e deleguem o reconhecimento de músicas a um app privilegiado que implementa a API MusicRecognitionService.

Se as implementações de dispositivos incluírem um serviço que implementa o MusicRecognitionManager da API System ou qualquer serviço proprietário que transmita dados de áudio conforme descrito acima, elas:

[C-1-1] PRECISA exigir que o autor da chamada de MusicRecognitionManager tenha a permissão MANAGE_MUSIC_RECOGNITION.
[C-1-2] É OBRIGATÓRIO que um único aplicativo de reconhecimento de música pré-instalado implemente MusicRecognitionService.
[C-1-3] NÃO PODE permitir que os usuários substituam o MusicRecognitionManagerService ou MusicRecognitionService por um aplicativo ou serviço instalável pelo usuário.
[C-1-4] É OBRIGATÓRIO garantir que, quando o MusicRecognitionManagerService acessa a gravação de áudio e a encaminha para o aplicativo que implementa o MusicRecognitionService, o acesso ao áudio seja rastreado por invocações de AppOpsManager.noteOp / startOp.

Se as implementações de dispositivo do MusicRecognitionManagerService ou MusicRecognitionService armazenarem dados de áudio capturados, elas:

[C-2-1] NÃO PODE armazenar áudio bruto ou impressões digitais de áudio em disco ou na memória por mais de 14 dias.
[C-2-2] NÃO PODE compartilhar esses dados fora do MusicRecognitionService, exceto com o consentimento explícito do usuário a cada compartilhamento.

9.8.13. SensorPrivacyManager

Se as implementações de dispositivos oferecerem ao usuário uma opção de software para desativar a entrada de câmera e/ou microfone para a implementação do dispositivo, elas:

[C-1-1] PRECISA retornar "true" com precisão para o método relevante da API supportsSensorToggle().
[C-1-2] Quando um app tentar acessar um microfone ou uma câmera bloqueados, É OBRIGATÓRIO apresentar ao usuário uma opção não dispensável que indique claramente que o sensor está bloqueado e exige uma escolha para continuar bloqueando ou desbloqueando, de acordo com a implementação do AOSP que atende a esse requisito.
[C-1-3] SÓ pode transmitir dados de áudio e câmera em branco (ou falsos) para apps e não informar um código de erro porque o usuário não ativou a câmera nem o microfone usando a opção apresentada em [C-1-2] acima.

9.8.14. N/A

9.8.15. Implementações do Private Compute Core e do aplicativo de gateway

O Android, por meio de um conjunto de APIs delegadas, oferece um mecanismo para processar dados seguros no nível do SO e do ambiente. Esse processamento pode ser delegado a um APK pré-instalado com acesso privilegiado e recursos de comunicação reduzidos, conhecido como uma implementação de API em sandbox.

É ALTAMENTE RECOMENDADO que as implementações de dispositivos que incluem aplicativos que realizam o processamento no dispositivo de dados sensíveis descritos na seção 9.8.6 (dados ambientais e no nível do SO) usem o framework do Private Compute Core (PCC, na sigla em inglês) descrito abaixo.

Todos os componentes de implementação de API no modo sandbox no ambiente do PCC:

[C-0-1] NÃO PODE solicitar a permissão INTERNET.

[C-0-1] PRECISA ser declarado com um atributo android:isPrivateComputeCoreProcess="true" na declaração do manifesto.

[C-0-2] SÓ PODE acessar a Internet por APIs estruturadas com suporte de implementações de código aberto disponíveis publicamente usando mecanismos que preservam a privacidade ou indiretamente por APIs do SDK do Android. O mecanismo que preserva a privacidade é definido como "aqueles que permitem apenas a análise agregada e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais", para evitar que os dados por usuário sejam introspectáveis (por exemplo, implementados usando uma tecnologia de privacidade diferencial, como o RAPPOR).

[C-0-2] PRECISA ser pré-carregado na imagem do sistema do dispositivo.

[C-0-3] É OBRIGATÓRIO manter os serviços separados de outros componentes do sistema (por exemplo, não vinculando o serviço ou compartilhando IDs de processo exceto nos seguintes casos:
- Telefonia, contatos, interface do sistema e mídia com implementações que não são executadas como um UID do PCC).
[C-0-4] NÃO PODE permitir que os usuários substituam os serviços por um aplicativo ou serviço instalável pelo usuário.
[C-0-5] SÓ É PERMITIDO que os serviços pré-instalados designados pelo OEM (com uma função de sistema adequada definida no serviço do sistema do PCC Manager) e com as permissões adequadas capturem esses dados. A menos que a capacidade de substituição seja integrada ao AOSP (por exemplo, para apps de assistente digital) dados ambientais sensíveis, conforme descrito em 9.8.6.
[C-0-6] NÃO PODE permitir que outros apps, além do mecanismo de serviços pré-instalados, capturem esses dados. A menos que essa capacidade de captura seja implementada com uma API do SDK do Android.
[C-0-7] É NECESSÁRIO oferecer ao usuário a possibilidade de desativar os serviços.
[C-0-8] NÃO PODE omitir a capacidade do usuário de gerenciar permissões do Android mantidas pelos serviços e seguir o modelo de permissões do Android, conforme descrito na Seção 9.1. Permissão.

[C-0-9] PRECISA ser executado em um processo dedicado com um UID exclusivo atribuído pelo framework, separado do processo principal do aplicativo e de outros componentes em sandbox.

Todo acesso à rede exigido pelos componentes do ambiente PCC PRECISA ser encaminhado por proxy por um APK designado que atua como um aplicativo de gateway do PCC. O(s) componente(s) designado(s):

[C-1-1] PRECISA receber a permissão privilegiada android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES. Essa permissão designa o aplicativo como um aplicativo de gateway PCC.
[C-1-2] PRECISA ter o código-fonte disponibilizado para verificação pública.
[C-1-3] PRECISA usar mecanismos que preservam a privacidade para qualquer saída de dados, conforme definido na seção 9.8.6
[C-1-4] PRECISA oferecer suporte ao modo de auditoria da estrutura do PCC, que inclui o registro de solicitações de rede, endpoints do servidor e outros dados relevantes para verificar o comportamento de preservação da privacidade quando ativado.

9.8.16. Dados contínuos de áudio e câmera

Se as implementações de dispositivos capturarem qualquer um dos dados descritos nas seções 9.8.2 ou 9.8.6 e se essas implementações usarem dados de áudio obtidos em segundo plano (continuamente) por AudioRecord, SoundTrigger ou outras APIs de áudio OU dados de câmera obtidos em segundo plano (continuamente) por CameraManager ou outras APIs de câmera, elas:

[C-0-1] É OBRIGATÓRIO aplicar um indicador correspondente (câmera e/ou microfone, conforme a seção 9.8.2 Gravação), a menos que:
- Esse acesso é realizado em uma implementação em sandbox (consulte 9.8.15 Implementação de API em sandbox), por um pacote que contém uma ou mais das seguintes funções: Inteligência da interface do sistema, Inteligência de áudio ambiente do sistema, Inteligência de áudio do sistema, Inteligência de notificações do sistema, Inteligência de texto do sistema, ou Inteligência visual do sistema.
- O acesso é feito por um sandbox, implementado e aplicado por mecanismos no AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
- O acesso ao áudio é feito para fins de acessibilidade pelo aplicativo Assistente digital, fornecendo SOURCE_HOTWORD como uma fonte de áudio.
- O acesso é realizado pelo sistema e implementado com código de código aberto.
[C-SR-1] É FORTEMENTE RECOMENDADO exigir o consentimento do usuário para cada funcionalidade que utiliza esses dados e ser desativado por padrão.
[C-SR-2] É ALTAMENTE RECOMENDADO aplicar o mesmo tratamento (ou seja, seguir as restrições descritas em 9.8.2 Gravação, 9.8.6 Dados ambientais e no nível do SO, 9.8.15 Implementações de API em sandbox e 9.8.16 Dados contínuos de áudio e câmera) aos dados da câmera provenientes de um dispositivo wearable remoto.

Se as implementações de dispositivos receberem dados de câmera ou microfone de um dispositivo wearable remoto e os dados forem acessados de forma não criptografada fora do SO Android, da implementação em sandbox ou de uma funcionalidade em sandbox criada pela WearableSensingManager, elas:

[C-1-1] PRECISA indicar ao dispositivo wearable remoto para mostrar um indicador adicional.

Se os dispositivos oferecerem a capacidade de interagir com um aplicativo de assistente digital sem a palavra-chave atribuída (lidando com consultas genéricas do usuário ou analisando a presença do usuário pela câmera), eles:

[C-2-1] PRECISA garantir que essa implementação seja fornecida por um pacote que tenha a função android.app.role.ASSISTANT.
[C-2-2] PRECISA garantir que essa implementação use as APIs Android HotwordDetectionService e/ou VisualQueryDetectionService.

9.8.17. Telemetria

O Android armazena registros do sistema e de apps usando as APIs StatsLog. Esses registros são gerenciados pelas APIs StatsManager, que podem ser usadas por aplicativos de sistema privilegiados.

O StatsManager também oferece uma maneira de coletar dados categorizados como sensíveis à privacidade de dispositivos com um mecanismo de preservação da privacidade. Em particular, a API StatsManager::query permite consultar categorias de métricas restritas definidas no StatsLog.

Qualquer implementação que consulte e colete métricas restritas do StatsManager:

[C-0-1] PRECISA ser o único aplicativo/implementação no dispositivo e ter a permissão READ_RESTRICTED_STATS.
[C-0-2] SÓ pode enviar dados de telemetria e o registro do dispositivo usando um mecanismo que preserva a privacidade. O mecanismo que preserva a privacidade é definido como "aqueles que permitem apenas a análise agregada e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais", para evitar que os dados por usuário sejam introspectáveis (por exemplo, implementados usando uma tecnologia de privacidade diferencial como o RAPPOR).
[C-0-3] NÃO PODE associar esses dados a nenhuma identidade de usuário (como Conta) no dispositivo.
[C-0-4] NÃO PODE compartilhar esses dados com outros componentes do SO que não seguem os requisitos descritos na seção atual (9.8.17. Telemetria).
[C-0-5] É NECESSÁRIO oferecer ao usuário uma opção para ativar/desativar a coleta, o uso e o compartilhamento de telemetria que preserva a privacidade.
[C-0-6] DEVE oferecer ao usuário a possibilidade de apagar os dados coletados pela implementação se eles forem armazenados de alguma forma no dispositivo. Se o usuário escolher apagar os dados, REMOVA todas as informações armazenadas no dispositivo.
[C-0-7] É OBRIGATÓRIO divulgar a implementação do protocolo subjacente que preserva a privacidade em um repositório de código aberto.
[C-0-8] É OBRIGATÓRIO aplicar políticas de saída de dados nesta seção para controlar a coleta de dados em categorias de métricas restritas definidas no StatsLog.

9.8.18. Privacidade das funções agênticas

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO garantir que todos os componentes que executam AppFunctions tenham a permissão EXECUTE_APP_FUNCTIONS ou EXECUTE_APP_FUNCTIONS_SYSTEM.
[C-0-2] É OBRIGATÓRIO invocar uma chamada AppFunction apenas como resultado direto de uma ação explícita do usuário, e isso PRECISA indicar claramente ao usuário qual aplicativo é invocado e a ação principal a ser realizada nele.
[C-0-3] NÃO PODE fazer proxy ou modificar a solicitação de um app de terceiros para descobrir ou executar AppFunctions, a menos que [C-0-1] e [C-0-2] sejam atendidos.
[C-0-4] NÃO PODE permitir que dados sensíveis no nível do SO ou ambientais (conforme definido em 9.8.6 Proteções de dados ambientais e no nível do SO) ou seus derivados sejam usados por componentes do sistema para gerar ou parametrizar sugestões, a menos que os componentes do sistema operem em um ambiente de execução protegida, conforme definido em 9.8.6.

Termo principal: "Incentivo" é definido como um ponto de entrada gerado de forma proativa em um app de uma superfície do sistema iniciada sem uma ação direta do usuário anterior. Os lembretes sugerem ou orientam o usuário a realizar uma ação sem restringir a liberdade de escolha.

9.9. Criptografia de armazenamento de dados

Todos os dispositivos PRECISAM atender aos requisitos da seção 9.9.1. Dispositivos lançados em um nível da API anterior ao deste documento estão isentos dos requisitos das seções 9.9.2 e 9.9.3. Em vez disso, eles PRECISAM atender aos requisitos da seção 9.9 do Documento de definição de compatibilidade do Android correspondente ao nível da API em que o dispositivo foi lançado.

9.9.1. Inicialização direta

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO implementar as APIs do modo de inicialização direta, mesmo que não haja suporte para criptografia de armazenamento.
[C-0-2] As intents ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED AINDA precisam ser transmitidas para sinalizar aos aplicativos compatíveis com a inicialização direta que os locais de armazenamento criptografados pelo dispositivo (DE) e criptografados por credenciais (CE) estão disponíveis para o usuário.

9.9.2. Requisitos de criptografia

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO criptografar os dados particulares do aplicativo (partição /data), bem como a partição de armazenamento compartilhado do aplicativo (partição /sdcard) se ela for uma parte permanente e não removível do dispositivo.
[C-0-2] É OBRIGATÓRIO ativar a criptografia de armazenamento de dados por padrão no momento em que o usuário concluir a experiência de configuração inicial.
[C-0-3] PRECISA atender ao requisito acima de criptografia de armazenamento de dados implementando um dos dois métodos de criptografia a seguir:
- Criptografia baseada em arquivos (FBE) e criptografia de metadados conforme descrito na seção 9.9.3.1.
- Criptografia no nível do bloco por usuário, conforme descrito na seção 9.9.3.2.

9.9.3. Métodos de criptografia

Se as implementações de dispositivos estiverem criptografadas, elas:

[C-1-1] PRECISA inicializar sem pedir credenciais ao usuário e permitir que apps compatíveis com a inicialização direta acessem o armazenamento criptografado pelo dispositivo (DE) depois que a mensagem ACTION_LOCKED_BOOT_COMPLETED for transmitida.
[C-1-2] NÃO PODE permitir o acesso ao armazenamento de credenciais criptografadas (CE) até que:
- O usuário desbloqueia o dispositivo usando um método de autenticação principal (como senha, padrão ou PIN).
- A mensagem ACTION_USER_UNLOCKED é transmitida.
[C-1-13] NÃO PODE oferecer nenhum método para desbloquear o armazenamento protegido por CE sem as credenciais fornecidas pelo usuário, uma chave de custódia registrada ou uma implementação de retomada na reinicialização que atenda aos requisitos da seção 9.9.4.
[C-1-4] PRECISA usar a Inicialização verificada.

9.9.3.1. Criptografia baseada em arquivos com criptografia de metadados

Se as implementações de dispositivos usarem criptografia baseada em arquivos com criptografia de metadados, elas:

[C-1-5] É OBRIGATÓRIO criptografar o conteúdo do arquivo e os metadados do sistema de arquivos usando AES-256-XTS ou Adiantum. AES-256-XTS se refere ao Padrão de criptografia avançada com um comprimento de chave de criptografia de 256 bits, operado no modo XTS. O comprimento total da chave é de 512 bits. Adiantum se refere a Adiantum-XChaCha12-AES, conforme especificado em https://github.com/google/adiantum. Os metadados do sistema de arquivos são dados como tamanhos, propriedade, modos e atributos estendidos (xattrs) de arquivos.
[C-1-6] É OBRIGATÓRIO criptografar nomes de arquivos usando AES-256-CBC-CTS, AES-256-HCTR2 ou Adiantum.
[C-1-12] Se o dispositivo tiver instruções do Padrão avançado de criptografia (AES, na sigla em inglês), como extensões de criptografia ARMv8 em dispositivos baseados em ARM ou AES-NI em dispositivos baseados em x86, as opções baseadas em AES acima para nome de arquivo, conteúdo do arquivo e criptografia de metadados do sistema de arquivos DEVERÃO ser usadas, e não o Adiantum.
[C-1-13] MUST use a cryptographically strong and non-reversible key derivation function (e.g. HKDF-SHA512) to derive any needed subkeys (e.g. per-file keys) from the CE and DE keys. "Criptograficamente forte e irreversível" significa que a função de derivação de chaves tem uma força de segurança de pelo menos 256 bits e se comporta como uma família de funções pseudorrandômicas nas entradas.
[C-1-14] NÃO PODE usar as mesmas chaves ou subchaves de criptografia baseada em arquivos (FBE, na sigla em inglês) para diferentes finalidades criptográficas (por exemplo, para criptografia e derivação de chaves ou para dois algoritmos de criptografia diferentes).
[C-1-15] É OBRIGATÓRIO garantir que todos os blocos não excluídos de conteúdo de arquivos criptografados no armazenamento permanente foram criptografados usando combinações de chave de criptografia e vetor de inicialização (IV) que dependem do arquivo e do deslocamento dentro dele. Além disso, todas essas combinações precisam ser distintas, exceto quando a criptografia é feita usando hardware de criptografia inline que só aceita um comprimento de IV de 32 bits.
[C-1-16] É OBRIGATÓRIO garantir que todos os nomes de arquivos criptografados não excluídos no armazenamento permanente em diretórios distintos foram criptografados usando combinações distintas de chave de criptografia e vetor de inicialização (IV).
[C-1-17] DEVE garantir que todos os blocos de metadados criptografados do sistema de arquivos no armazenamento persistente foram criptografados usando combinações distintas de chave de criptografia e vetor de inicialização (IV).
Chaves que protegem áreas de armazenamento de CE e DE e metadados do sistema de arquivos:
- [C-1-7] PRECISA ser vinculado criptograficamente a um armazenamento de chaves com suporte de hardware. Esse keystore precisa estar vinculado à Inicialização verificada e à raiz de confiança do hardware do dispositivo.
- [C-1-8] As chaves CE PRECISAM estar vinculadas às credenciais da tela de bloqueio de um usuário.
- [C-1-9] As chaves CE PRECISAM ser vinculadas a uma senha padrão quando o usuário não especificou credenciais da tela de bloqueio.
- [C-1-10] PRECISA ser único e distinto. Em outras palavras, a chave CE ou DE de um usuário não pode corresponder às chaves CE ou DE de outro usuário.
- [C-1-11] MUST use the mandatorily supported ciphers, key lengths and modes.
- [C-1-12] PRECISA ser apagado com segurança durante o desbloqueio e bloqueio do carregador de inicialização, conforme descrito aqui.
DEVE tornar os apps essenciais pré-instalados (por exemplo, Alarme, Telefone, Messenger) compatíveis com a inicialização direta.

O projeto upstream Android Open Source oferece uma implementação preferencial de criptografia baseada em arquivos com base no recurso de criptografia "fscrypt" do kernel do Linux e de criptografia de metadados com base no recurso "dm-default-key" do kernel do Linux.

9.9.3.2. Criptografia no nível de bloco por usuário

Se as implementações de dispositivos usarem criptografia no nível de bloco por usuário, elas:

[C-1-1] PRECISA ativar o suporte multiusuário, conforme descrito na seção 9.5.
[C-1-2] É OBRIGATÓRIO fornecer partições por usuário, usando partições brutas ou volumes lógicos.
[C-1-3] PRECISA usar chaves de criptografia exclusivas e distintas por usuário para criptografia dos dispositivos de bloco subjacentes.
[C-1-4] É OBRIGATÓRIO usar AES-256-XTS para criptografia no nível de bloco das partições do usuário.
As chaves que protegem os dispositivos criptografados no nível do bloco por usuário:
- [C-1-5] PRECISA ser vinculado criptograficamente a um armazenamento de chaves com suporte de hardware. Esse keystore precisa estar vinculado à Inicialização verificada e à raiz de confiança do hardware do dispositivo.
- [C-1-6] PRECISA estar vinculado às credenciais da tela de bloqueio do usuário correspondente.

A criptografia no nível do bloco por usuário pode ser implementada usando o recurso "dm-crypt" do kernel do Linux em partições por usuário.

9.9.4. Retomar na reinicialização

A retomada na reinicialização permite desbloquear o armazenamento CE de todos os apps, incluindo aqueles que ainda não oferecem suporte à inicialização direta, após uma reinicialização iniciada por uma OTA. Com esse recurso, os usuários recebem notificações dos apps instalados após a reinicialização.

Uma implementação de Resume-on-Reboot precisa continuar garantindo que, quando um dispositivo cair nas mãos de um invasor, seja extremamente difícil para ele recuperar os dados criptografados por CE do usuário, mesmo que o dispositivo esteja ligado, o armazenamento de CE esteja desbloqueado e o usuário tenha desbloqueado o dispositivo após receber uma OTA. Para resistência a ataques internos, também presumimos que o invasor tenha acesso às chaves de assinatura criptográfica de transmissão.

Especificamente:

[C-0-1] O armazenamento de CE NÃO PODE ser legível, mesmo para o invasor que tem o dispositivo fisicamente e tem estas capacidades e limitações:
- Pode usar a chave de assinatura de qualquer fornecedor ou empresa para assinar mensagens arbitrárias.
- Pode fazer com que o dispositivo receba uma atualização OTA.
- Pode modificar a operação de qualquer hardware (AP, flash etc.), exceto conforme detalhado abaixo, mas essa modificação envolve um atraso de pelo menos uma hora e um ciclo de energia que destrói o conteúdo da RAM.
- Não é possível modificar a operação de hardware resistente a violações (por exemplo, Titan M).
- Não é possível ler a RAM do dispositivo ativo.
- Não é possível obter a credencial do usuário (PIN, padrão, senha) ou fazer com que ela seja inserida.

Por exemplo, uma implementação de dispositivo que implementa e obedece a todas as descrições encontradas aqui vai obedecer a [C-0-1].

9.10. Integridade do dispositivo

Os requisitos a seguir garantem a transparência do status da integridade do dispositivo. Implementações de dispositivos:

[C-0-1] DEVE informar corretamente pelo método da API System PersistentDataBlockManager.getFlashLockState() se o estado do carregador de inicialização permite a atualização da imagem do sistema.
[C-0-2] PRECISA oferecer suporte à Inicialização Verificada para integridade do dispositivo.

Se as implementações de dispositivos já tiverem sido lançadas sem suporte à inicialização verificada em uma versão anterior do Android e não for possível adicionar suporte a esse recurso com uma atualização de software do sistema, elas PODERÃO ser isentas da exigência.

A Inicialização Verificada é um recurso que garante a integridade do software do dispositivo. Se as implementações de dispositivos forem compatíveis com o recurso, elas:

[C-1-1] PRECISA declarar a flag de recurso da plataforma android.software.verified_boot.
[C-1-2] É OBRIGATÓRIO realizar a verificação em todas as sequências de inicialização.
[C-1-3] DEVE iniciar a verificação com uma chave de hardware imutável que seja a raiz de confiança e ir até a partição do sistema.
[C-1-4] PRECISA implementar cada etapa de verificação para conferir a integridade e a autenticidade de todos os bytes na próxima etapa antes de executar o código na próxima etapa.
[C-1-5] DEVE usar algoritmos de verificação tão fortes quanto as recomendações atuais do NIST para algoritmos de hash (SHA-256) e tamanhos de chave pública (RSA-2048).
[C-1-6] NÃO PODE permitir que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário concorde em tentar inicializar de qualquer maneira. Nesse caso, os dados de qualquer bloco de armazenamento não verificado NÃO PODEM ser usados.
[C-1-7] NÃO PODE permitir que partições verificadas no dispositivo sejam modificadas, a menos que o usuário tenha desbloqueado explicitamente o carregador de inicialização.
[C-1-8] É OBRIGATÓRIO usar armazenamento inviolável para armazenar se o carregador de inicialização está desbloqueado. O armazenamento à prova de violação significa que o carregador de inicialização pode detectar se o armazenamento foi adulterado de dentro do Android.
[C-1-9] PRECISA solicitar ao usuário, enquanto usa o dispositivo, e exigir confirmação física antes de permitir uma transição do modo bloqueado para desbloqueado do carregador de inicialização.
[C-1-10] É obrigatório implementar a proteção contra reversão para partições usadas pelo Android (por exemplo, partições de inicialização e do sistema) e usar armazenamento inviolável para armazenar os metadados usados para determinar a versão mínima permitida do SO.
[C-1-11] É OBRIGATÓRIO apagar todos os dados do usuário de forma segura durante o desbloqueio e bloqueio do carregador de inicialização, conforme "9.12. Exclusão de dados" (incluindo a partição de dados do usuário e todos os espaços de NVRAM).
[C-1-14] É OBRIGATÓRIO verificar a assinatura pelo menos uma vez por inicialização para pacotes na lista de permissões que estão listados como require-strict-signature na configuração do sistema.
[C-SR-2] É ALTAMENTE RECOMENDADO verificar todos os arquivos APK de apps privilegiados com uma cadeia de confiança baseada em partições protegidas pela Inicialização verificada.
[C-SR-3] É ALTAMENTE RECOMENDADO verificar todos os artefatos executáveis carregados por um app privilegiado de fora do arquivo APK (como código carregado dinamicamente ou compilado) antes de executá-los ou ALTAMENTE RECOMENDADO não executá-los de forma alguma.
IMPLEMENTE a proteção contra reversão para qualquer componente com firmware persistente (por exemplo, modem, câmera) e USE armazenamento inviolável para armazenar os metadados usados para determinar a versão mínima permitida.

O Android Open Source Project upstream oferece uma implementação preferencial desse recurso no repositório external/avb/, que pode ser integrado ao carregador de inicialização usado para carregar o Android.

Se as implementações de dispositivos puderem verificar o conteúdo do arquivo por página, elas:

[C-2-1] suporte à verificação criptográfica do conteúdo do arquivo sem ler o arquivo inteiro.
[C-2-2] NÃO PODE permitir que as solicitações de leitura em um arquivo protegido sejam bem-sucedidas quando o conteúdo lido não for verificado de acordo com [C-2-1] acima.
[C-2-4] MUST return file checksum in O(1) for enabled files.

Se as implementações de dispositivos já tiverem sido lançadas sem a capacidade de verificar o conteúdo do arquivo em relação a uma chave confiável em uma versão anterior do Android e não for possível adicionar suporte a esse recurso com uma atualização de software do sistema, elas PODERÃO ser isentas do requisito. O projeto upstream Android Open Source oferece uma implementação preferencial desse recurso com base no recurso fs-verity do kernel do Linux.

9.11. Chaves e credenciais

O Android Keystore System permite que os desenvolvedores de apps armazenem chaves criptográficas em um contêiner e as usem em operações criptográficas pela API KeyChain ou pela API Keystore. Implementações de dispositivos:

[C-0-1] DEVE permitir a importação ou geração de pelo menos 8.192 chaves.
[C-0-2] A autenticação da tela de bloqueio PRECISA implementar um intervalo de tempo entre tentativas com falha. Com n como a contagem de tentativas malsucedidas, o intervalo de tempo PRECISA ser de pelo menos 30 segundos para 9 < n < 30. Para n > 29, o valor do intervalo de tempo PRECISA ser de pelo menos 30*2^floor((n-30)/10) segundos ou pelo menos 24 horas, o que for menor.
NÃO DEVE limitar o número de chaves que podem ser geradas.

Quando a implementação do dispositivo oferece suporte a uma tela de bloqueio segura, ela:

[C-1-1] É OBRIGATÓRIO fazer backup da implementação do keystore com um ambiente de execução isolado.

[C-1-2] PRECISA ter implementações de algoritmos criptográficos RSA, AES, ECDSA, ECDH (se IKeyMintDevice for compatível), 3DES e HMAC e funções de hash MD5, SHA-1 e SHA-2 os algoritmos criptográficos e as funções de hash exigidos pela versão compatível de IKeyMintDevice ou IKeymasterDevice para oferecer suporte adequado aos algoritmos compatíveis do sistema Android Keystore em uma área isolada de maneira segura do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais pelos quais o kernel ou o código do espaço do usuário podem acessar o estado interno do ambiente isolado, incluindo DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada no ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.

[C-1-3] É OBRIGATÓRIO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e permitir o uso das chaves vinculadas à autenticação somente quando ela for bem-sucedida. As credenciais da tela de bloqueio precisam ser armazenadas de forma que apenas o ambiente de execução isolado possa fazer a autenticação da tela de bloqueio. O Android Open Source Project upstream fornece a camada de abstração de hardware (HAL) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
[C-1-4] PRECISA oferecer suporte ao atestado de chaves em que a chave de assinatura do atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado NÃO PODEM ser usadas como identificadores permanentes de dispositivo.

Observação: para atender a esse requisito, é necessário compartilhar a mesma chave de atestado para uma determinada SKU,a menos que pelo menos 100.000 unidades dessa 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 chaves remotas pode ser usada para provisionar chaves de atestação de curta duração no dispositivo.

[C-1-5] DEVE permitir que o usuário escolha o tempo limite de suspensão para a transição do estado desbloqueado para bloqueado, com um tempo limite mínimo permitido de até 15 segundos. Dispositivos automotivos que bloqueiam a tela sempre que a unidade principal é desligada ou o usuário é trocado NÃO PODEM ter a configuração de tempo limite de suspensão.
[C-1-6] PRECISA ser compatível com IKeymasterDevice 3.0 ou mais recente ou IKeyMintDevice versão 1 ou mais recente.

[C-SR-1] É FORTEMENTE RECOMENDADO que os métodos de autenticação primários (como PIN, padrão ou senha) exijam um intervalo mínimo entre tentativas únicas com falha, com base no seguinte:

Número de tentativas com falha exclusivas	Tempo limite mínimo
0-4	0
5	1 minuto
6	5 minutos
7	15 minutos
8	30 minutos
9	90 minutos
10	4 horas
11	12 horas
12	24 horas
13	4 dias
14	13 dias
15	41 dias
16	123 dias
17	1 ano
18	3 anos
19	9 anos

9.11.1. Tela de bloqueio segura, autenticação e dispositivos virtuais

A implementação do AOSP segue um modelo de autenticação em camadas em que uma autenticação principal baseada em um fator de conhecimento pode ser respaldada por uma biometria secundária forte ou por modalidades terciárias mais fracas.

Implementações de dispositivos:

[C-SR-1] É ALTAMENTE RECOMENDADO definir apenas um dos seguintes como o método de autenticação principal:
- Um PIN numérico
- Uma senha alfanumérica
- Um padrão de deslize em uma grade de exatamente 3x3 pontos
Observe que os métodos de autenticação acima são chamados de métodos de autenticação primários recomendados neste documento.
[C-0-1] É OBRIGATÓRIO limitar o número de tentativas de autenticação principal com falha.
[C-SR-5] É ALTAMENTE RECOMENDADO implementar um limite máximo de 20 tentativas de autenticação primária com falha e, se os usuários consentirem e ativarem o recurso, realizar uma "Redefinição de fábrica" após exceder o limite de tentativas de autenticação primária com falha.

Se as implementações de dispositivos definirem um PIN numérico como o método de autenticação principal recomendado, então:

[C-SR-6] É ALTAMENTE RECOMENDADO que um PIN tenha pelo menos 6 dígitos ou o equivalente a uma entropia de 20 bits.
[C-SR-7] É FORTEMENTE RECOMENDADO que um PIN com menos de seis dígitos NÃO permita a entrada automática sem interação do usuário para evitar revelar o comprimento do PIN.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação primária recomendados e usarem um novo método de autenticação como uma maneira segura de bloquear a tela, o novo método de autenticação:

[C-2-1] PRECISA ser o método de autenticação do usuário, conforme descrito em Exigir autenticação do usuário para o uso de chaves.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio com base em um segredo conhecido e usarem um novo método de autenticação para serem tratados como uma maneira segura de bloquear a tela:

[C-3-1] A entropia do menor tamanho permitido de entradas PRECISA ser maior que 10 bits.
[C-3-2] A entropia máxima de todas as entradas possíveis PRECISA ser maior que 18 bits.
[C-3-3] O novo método de autenticação NÃO PODE substituir nenhum dos métodos de autenticação primários recomendados (ou seja, PIN, padrão, senha) implementados e fornecidos no AOSP.
[C-3-4] O novo método de autenticação PRECISA ser desativado quando o aplicativo Device Policy Controller (DPC) tiver definido a política de requisitos de senha usando DevicePolicyManager.setRequiredPasswordComplexity() com uma constante de complexidade mais restritiva do que PASSWORD_COMPLEXITY_NONE ou usando o método DevicePolicyManager.setPasswordQuality() com uma constante mais restritiva do que PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-3-5] Os novos métodos de autenticação PRECISAM voltar aos métodos de autenticação primários recomendados (ou seja, PIN, padrão, senha) a cada 72 horas ou menos OU divulgar claramente ao usuário que alguns dados não serão armazenados em backup para preservar a privacidade dos dados.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação primária recomendados para desbloquear a tela de bloqueio e usarem um novo método de autenticação baseado em biometria para ser tratado como uma maneira segura de bloquear a tela, o novo método:

[C-4-1] PRECISA atender a todos os requisitos descritos na seção 7.3.10 para Classe 1 (antiga Conveniência).
[C-4-2] PRECISA ter um mecanismo de substituição para usar um dos métodos de autenticação primária recomendados, que se baseia em um segredo conhecido.
[C-4-3] PRECISA ser desativado e permitir apenas a autenticação primária recomendada para desbloquear a tela quando o aplicativo controlador de política de dispositivo (DPC) tiver definido a política de recursos do keyguard chamando o método DevicePolicyManager.setKeyguardDisabledFeatures(), com qualquer uma das flags biométricas associadas (ou seja, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Se os métodos de autenticação biométrica não atenderem aos requisitos da Classe 3 (antiga Forte), conforme descrito na seção 7.3.10:

[C-5-1] Os métodos precisam ser desativados se o aplicativo do controlador de política de dispositivo (DPC, na sigla em inglês) tiver definido a política de qualidade de requisitos de senha usando o DevicePolicyManager.setRequiredPasswordComplexity() com um bucket de complexidade mais restritivo do que PASSWORD_COMPLEXITY_LOW ou usando o método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] O usuário PRECISA ser desafiado para a autenticação primária recomendada (como PIN, padrão ou senha), conforme descrito em [C-1-7] e [C-1-8] na seção 7.3.10.
[C-5-3] Os métodos NÃO DEVEM ser tratados como uma tela de bloqueio segura e DEVEM atender aos requisitos que começam com C-8 na seção abaixo.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio e um novo método de autenticação for baseado em um token físico ou no local:

[C-6-1] Eles PRECISAM ter um mecanismo de substituição para usar um dos métodos de autenticação primária recomendados, que se baseia em um segredo conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
[C-6-2] O novo método PRECISA ser desativado e permitir apenas um dos métodos de autenticação primária recomendados para desbloquear a tela quando o aplicativo controlador de política de dispositivo (DPC) tiver definido a política com:
- O método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS).
- O método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_NONE.
- O método DevicePolicyManager.setRequiredPasswordComplexity() com um bucket de complexidade mais restritivo do que PASSWORD_COMPLEXITY_NONE.
[C-6-3] O usuário PRECISA ser desafiado a usar um dos métodos de autenticação primários recomendados (como PIN, padrão ou senha) pelo menos uma vez a cada 4 horas ou menos. Quando um token físico atende aos requisitos para implementações do TrustAgent em C-X, as restrições de tempo limite definidas em [C-9-5] são aplicadas.
[C-6-4] O novo método NÃO DEVE ser tratado como uma tela de bloqueio segura e PRECISA seguir as restrições listadas em C-8 abaixo.

Se as implementações de dispositivos tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que implementam a API TrustAgentService System, eles:

[C-7-1] DEVE ter uma indicação clara no menu de configurações e na tela de bloqueio quando o bloqueio do dispositivo é adiado ou pode ser desbloqueado por agentes de confiança. Por exemplo, o AOSP atende a esse requisito mostrando uma descrição de texto para a "Configuração de bloqueio automático" e "O botão liga/desliga bloqueia instantaneamente" no menu de configurações e um ícone distinguível na tela de bloqueio.
[C-7-2] PRECISA respeitar e implementar totalmente todas as APIs de agente de confiança na classe DevicePolicyManager, como a constante KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] NÃO PODE implementar totalmente a função TrustAgentService.addEscrowToken() em um dispositivo usado como principal para uso pessoal (por exemplo, portátil), mas PODE implementar totalmente a função em dispositivos que geralmente são compartilhados (por exemplo, Android TV ou dispositivo automotivo).
[C-7-4] É OBRIGATÓRIO criptografar todos os tokens armazenados adicionados por TrustAgentService.addEscrowToken().
[C-7-5] NÃO PODE armazenar a chave de criptografia ou o token de depósito no mesmo dispositivo em que a chave é usada. Por exemplo, uma chave armazenada em um smartphone pode desbloquear uma conta de usuário em uma TV. Em dispositivos automotivos, não é permitido armazenar o token de depósito em garantia em nenhuma parte do veículo.
[C-7-6] É OBRIGATÓRIO informar ao usuário sobre as implicações de segurança antes de ativar o token de depósito para descriptografar o armazenamento de dados.
[C-7-7] PRECISA ter um mecanismo de substituição para usar um dos métodos de autenticação primários recomendados.
[C-7-9] O usuário PRECISA ser desafiado para um dos métodos de autenticação primária recomendados (como PIN, padrão ou senha), conforme descrito em [C-1-7] e [C-1-8] na seção 7.3.10, a menos que a segurança do usuário (por exemplo, distração do motorista) seja uma preocupação.
[C-7-10] NÃO DEVE ser tratado como uma tela de bloqueio segura e DEVE seguir as restrições listadas em C-8 abaixo.
[C-7-11] NÃO PODE permitir que TrustAgents em dispositivos pessoais principais (por exemplo, portáteis) desbloqueiem o dispositivo e só podem usá-los para manter um dispositivo já desbloqueado nesse estado por até um máximo de 4 horas. A implementação padrão do TrustManagerService no AOSP atende a esse requisito.
[C-7-12] É OBRIGATÓRIO usar um canal de comunicação criptograficamente seguro (por exemplo, UKEY2) para transmitir o token de custódia do dispositivo de armazenamento para o dispositivo de destino.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio que não seja uma tela de bloqueio segura, conforme descrito acima, e usarem um novo método de autenticação para desbloquear o keyguard:

[C-8-1] O novo método PRECISA ser desativado quando o aplicativo controlador de política de dispositivo (DPC) tiver definido a política de qualidade de senha usando o método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_NONE ou usando o método DevicePolicyManager.setRequiredPasswordComplexity() com uma constante de complexidade mais restritiva do que PASSWORD_COMPLEXITY_NONE.
[C-8-2] Eles NÃO DEVEM redefinir os timers de expiração de senha definidos por DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] Eles NÃO DEVEM expor uma API para uso por apps de terceiros para mudar o estado de bloqueio.

Se as implementações de dispositivos permitirem que os aplicativos criem displays virtuais secundários e não forem compatíveis com eventos de entrada associados, como por VirtualDeviceManager, eles:

[C-9-1] É OBRIGATÓRIO bloquear esses displays virtuais secundários quando o display padrão do dispositivo estiver bloqueado e desbloquear esses displays virtuais secundários quando o display padrão do dispositivo estiver desbloqueado.

Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e ofereçam suporte a eventos de entrada associados, como por meio do VirtualDeviceManager, eles:

[C-10-1] MUST support separate lock states per virtual device
[C-10-2] Requisito removido no Android 16.
[C-10-3] Requisito removido no Android 16.
[C-10-4] DEVE bloquear todas as telas quando o usuário iniciar um bloqueio total, inclusive pela ação do usuário de bloqueio total necessária para dispositivos móveis (consulte Seção 2.2.5[9.11/H-1-2])
[C-10-5] É obrigatório ter instâncias separadas de dispositivos virtuais por usuário
[C-10-6] É OBRIGATÓRIO desativar o streaming de apps, conforme indicado por DevicePolicyManager.setNearbyAppStreamingPolicy.
[C-10-7] Requisito removido no Android 16.
[C-10-11] É OBRIGATÓRIO desativar a interface de autenticação em dispositivos virtuais, incluindo entrada de fator de conhecimento e solicitação biométrica
[C-10-12] Requisito removido no Android 16.
[C-10-13] NÃO PODE usar um estado de bloqueio de dispositivo virtual como autorização de autenticação do usuário com o sistema Android Keystore. Consulte KeyGenParameterSpec.Builder.setUserAuthentication*.
[C-10-14] É OBRIGATÓRIO oferecer uma opção para o usuário ativar o compartilhamento da área de transferência entre dispositivos antes de compartilhar dados da área de transferência entre dispositivos físicos e virtuais se o dispositivo estiver implementando uma área de transferência compartilhada.
[C-10-15] DEVE mostrar notificações quando os dados da área de transferência forem acessados no dispositivo em que foram acessados e no dispositivo em que a área de transferência foi criada.

Quando as implementações de dispositivos permitem que o usuário transfira o fator de conhecimento de autenticação principal de um dispositivo de origem para um dispositivo de destino, como na configuração inicial do dispositivo de destino, elas:

[C-11-1] É OBRIGATÓRIO criptografar o fator de conhecimento com garantias de proteção semelhantes às descritas no artigo sobre segurança do Serviço de Key Vault do Google Cloud ao transferir o fator de conhecimento do dispositivo de origem para o dispositivo de destino. Assim, o fator de conhecimento não pode ser descriptografado ou usado remotamente para desbloquear qualquer um dos dispositivos.
[C-11-2] DEVE, no dispositivo de origem , pedir ao usuário para confirmar o fator de conhecimento do dispositivo de origem antes de transferir o fator de conhecimento para o dispositivo de destino.
[C-11-3] DEVE, em um dispositivo de destino sem um fator de conhecimento de autenticação primária definido, pedir que o usuário confirme um fator de conhecimento transferido no dispositivo de destino antes de definir esse fator como o fator de conhecimento de autenticação primária para o dispositivo de destino e antes de disponibilizar os dados transferidos de um dispositivo de origem.

Se as implementações de dispositivos tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que chamam a API TrustAgentService.grantTrust() do sistema com a flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, eles:

[C-12-1] SÓ pode chamar grantTrust() com a flag quando conectado a um dispositivo físico próximo com uma tela de bloqueio própria e quando o usuário autenticou a identidade dele nessa tela de bloqueio. Dispositivos próximos podem usar mecanismos de detecção no pulso ou no corpo após um desbloqueio único do usuário para atender ao requisito de autenticação do usuário.
[C-12-2] É OBRIGATÓRIO colocar a implementação do dispositivo no estado TrustState.TRUSTABLE quando a tela é desligada (por exemplo, ao pressionar um botão ou por tempo limite de exibição) e o TrustAgent não revogou a confiança. O AOSP atende a esse requisito.
[C-12-3] SÓ DEVE mover o dispositivo do estado TrustState.TRUSTABLE para TrustState.TRUSTED se o TrustAgent ainda estiver concedendo confiança com base nos requisitos em [C-12-1].

[C-12-4] DEVE chamar TrustManagerService.revokeTrust() se as implementações não estiverem usando intervalos criptograficamente seguros e precisos, conforme definido em [C-12-5]:
- Após um máximo de 24 horas desde a concessão da confiança ou
- Após uma janela de inatividade de 8 horas ou
- Se as implementações não usarem alcance criptograficamente seguro e preciso, conforme definido em [C-12-5], Quando a conexão subjacente com o dispositivo físico próximo for perdida.

[C-12-5] As implementações que dependem de alcance seguro e preciso para atender aos requisitos de [C-12-4] DEVEM usar uma das seguintes soluções:
- Implementações usando UWB:
  - PRECISA atender aos requisitos de conformidade, certificação, precisão e calibragem para UWB descritos em 7.4.9.
  - É preciso usar um dos modos de segurança do P-STS listados em 7.4.9.
- Implementações que usam o Wi-Fi Neighborhood Awareness Networking (NAN):
  - Precisa atender aos requisitos de acurácia em 2.2.1 [7.4.2.5/H-SR-1], usar a largura de banda de 160 MHz (ou superior) e seguir as etapas de configuração de medição especificadas em Calibragem de presença.
  - É necessário usar o LTF seguro, conforme definido no IEEE 802.11az.

Se as implementações de dispositivos permitirem que os aplicativos criem displays virtuais secundários e ofereçam suporte a eventos de entrada associados, como por VirtualDeviceManager, e se os displays não estiverem marcados com VIRTUAL_DISPLAY_FLAG_SECURE, eles:

[C-13-8] É OBRIGATÓRIO bloquear o início no dispositivo virtual de atividades com o atributo android:canDisplayOnRemoteDevices ou os metadados android.activity.can_display_on_remote_devices definidos como "false".
[C-13-9] É OBRIGATÓRIO bloquear atividades que não ativam explicitamente o streaming e indicam que mostram conteúdo sensível, inclusive por SurfaceView#setSecure e FLAG_SECURE no dispositivo virtual.

Se as implementações de dispositivos forem compatíveis com estados de energia de tela separados por DeviceStateManager E com estados de bloqueio de tela separados por KeyguardDisplayManager, elas:

[C-SR-2] É FORTEMENTE RECOMENDADO usar uma credencial que atenda aos requisitos definidos na seção 9.11.1 ou uma biometria que atenda pelo menos às especificações da Classe 1 definidas na seção 7.3.10 para permitir o desbloqueio independente da tela padrão do dispositivo.
[C-SR-3] É ALTAMENTE RECOMENDADO restringir o desbloqueio da tela separada usando um tempo limite de exibição definido.
[C-SR-4] É ALTAMENTE RECOMENDADO permitir que o usuário bloqueie globalmente todas as telas por bloqueio do dispositivo portátil principal.

9.11.2. StrongBox

O Android Keystore System permite que os desenvolvedores de apps armazenem chaves criptográficas em um processador seguro dedicado, além do ambiente de execução isolado descrito acima. Esse processador seguro dedicado é chamado de "StrongBox". Os requisitos C-1-3 a C-1-11 abaixo definem os requisitos que um dispositivo precisa atender para se qualificar como StrongBox.

Implementações de dispositivos com um processador seguro dedicado:

[C-SR-1] São ALTAMENTE RECOMENDADOS para oferecer suporte ao StrongBox. É provável que o StrongBox se torne um requisito em uma versão futura.

Se as implementações de dispositivos forem compatíveis com o StrongBox, elas:

[C-1-1] PRECISA declarar FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] PRECISA fornecer hardware seguro dedicado usado para fazer backup do keystore e proteger a autenticação do usuário. O hardware seguro dedicado também pode ser usado para outras finalidades.
[C-1-3] PRECISA ter uma CPU discreta que não compartilhe cache, DRAM, coprocessadores ou outros recursos principais com o processador de aplicativos (AP).
[C-1-4] DEVE garantir que os periféricos compartilhados com o AP não alterem o processamento do StrongBox de forma alguma nem obtenham informações do StrongBox. O AP PODE desativar ou bloquear o acesso ao StrongBox.
[C-1-5] PRECISA ter um relógio interno com precisão razoável (+/- 10%) que seja imune à manipulação pelo PA.
[C-1-6] PRECISA ter um gerador de números aleatórios real que produza resultados imprevisíveis e com distribuição uniforme.
[C-1-7] Precisa ter resistência a violações, incluindo resistência a penetração física e falhas.
[C-1-8] PRECISA ter resistência a canais laterais, incluindo resistência contra vazamento de informações por canais laterais de energia, tempo, radiação eletromagnética e radiação térmica.
[C-1-9] PRECISA ter armazenamento seguro que garanta a confidencialidade, integridade, autenticidade, consistência e atualização do conteúdo. O armazenamento NÃO PODE ser lido ou alterado, exceto conforme permitido pelas APIs StrongBox.

Para validar a conformidade com [C-1-3] a [C-1-9], as implementações de dispositivo:

[C-1-10] PRECISA incluir o hardware certificado de acordo com o Perfil de proteção de CI seguro BSI-CC-PP-0084-2014 ou BSI-CC-PP-0117-2022, ou ser avaliado por um laboratório de testes credenciado nacionalmente que incorpore avaliação de vulnerabilidade de alto potencial de ataque de acordo com a Aplicação do potencial de ataque do Common Criteria a smartcards.
[C-1-11] PRECISA incluir o firmware avaliado por um laboratório de testes credenciado nacionalmente que incorpore uma avaliação de vulnerabilidade de alto potencial de ataque de acordo com os Critérios Comuns de Aplicação do Potencial de Ataque a Smartcards.
[C-SR-2] É FORTEMENTE RECOMENDADO incluir o hardware avaliado usando uma meta de segurança, um nível de garantia de avaliação (EAL) 5, aumentado por AVA_VAN.5. A certificação EAL 5 provavelmente vai se tornar um requisito em uma versão futura.
[C-SR-3] É ALTAMENTE RECOMENDADO fornecer resistência a ataques internos (IAR, na sigla em inglês), o que significa que uma pessoa com informações privilegiadas com acesso a chaves de assinatura de firmware não pode produzir um firmware que faça com que o StrongBox vaze segredos, ignore requisitos de segurança funcionais ou permita o acesso a dados sensíveis do usuário. A maneira recomendada de implementar o IAR é permitir atualizações de firmware somente quando a senha do usuário principal for fornecida pela HAL IAuthSecret.

9.11.3. Credencial de identidade

O sistema de credenciais de identidade é definido e alcançado com a implementação de todas as APIs no pacote android.security.identity.*. Com elas, os desenvolvedores de apps podem armazenar e recuperar documentos de identidade do usuário. Implementações de dispositivos:

[C-SR-1] são FORTEMENTE RECOMENDADOS para implementar o sistema de credenciais de identidade.

Se as implementações de dispositivos implementarem o sistema de credenciais de identidade, elas:

[C-1-1] Precisa retornar um valor não nulo para o método IdentityCredentialStore#getInstance().
[C-1-2] É OBRIGATÓRIO implementar o sistema de credenciais de identidade (por exemplo, as APIs android.security.identity.*) com código que se comunica com um aplicativo de confiança em uma área isolada com segurança do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos possíveis pelos quais o kernel ou o código do espaço do usuário podem acessar o estado interno do ambiente isolado, incluindo DMA.
[C-1-3] As operações criptográficas necessárias para implementar o sistema de credenciais de identidade (por exemplo, as APIs android.security.identity.*) PRECISAM ser realizadas inteiramente no aplicativo confiável, e o material de chave privada NUNCA pode sair do ambiente de execução isolado, a menos que seja especificamente exigido por APIs de nível superior (por exemplo, o método createEphemeralKeyPair()).
[C-1-4] O aplicativo confiável PRECISA ser implementado de forma que as propriedades de segurança dele não sejam afetadas (por exemplo, os dados de credenciais não são divulgados, a menos que as condições de controle de acesso sejam atendidas, os MACs não podem ser produzidos para dados arbitrários) mesmo que o Android esteja com comportamento inadequado ou comprometido.

O Android Open Source Project upstream fornece uma implementação de referência de um aplicativo confiável (libeic) que pode ser usado para implementar o sistema de credenciais de identidade.

9.12. Exclusão de dados

Todas as implementações de dispositivos:

[C-0-1] DEVE oferecer aos usuários um mecanismo para realizar uma "redefinição de fábrica".
[C-0-2] É OBRIGATÓRIO excluir todos os dados no sistema de arquivos userdata ao realizar uma "Redefinição de fábrica".
[C-0-3] É OBRIGATÓRIO excluir os dados de forma a atender aos padrões relevantes do setor, como o NIST SP800-88, ao realizar uma "redefinição de dados de fábrica".
[C-0-4] DEVE acionar o processo "Redefinição de dados de fábrica" acima quando a API DevicePolicyManager.wipeData() for chamada pelo app Controlador de política de dispositivo do usuário principal.
PODE oferecer uma opção de limpeza rápida de dados que realiza apenas uma exclusão lógica de dados.

9.13. Modo de inicialização segura

O Android oferece o modo de inicialização segura, que permite aos usuários iniciar um modo em que apenas apps do sistema pré-instalados podem ser executados e todos os apps de terceiros são desativados. Esse modo, conhecido como "Modo de inicialização segura", permite que o usuário desinstale apps de terceiros potencialmente nocivos.

As implementações de dispositivos são:

[C-SR-1] É ALTAMENTE RECOMENDADO implementar o modo de inicialização segura.

Se as implementações de dispositivos implementarem o modo de inicialização segura, elas:

[C-1-1] DEVE oferecer ao usuário uma opção para entrar no modo de inicialização segura de forma ininterrupta por apps de terceiros instalados no dispositivo, exceto quando o app de terceiros for um controlador de políticas de dispositivo e tiver definido a flag UserManager.DISALLOW_SAFE_BOOT como "true".
[C-1-2] DEVE oferecer ao usuário a capacidade de desinstalar apps de terceiros no modo de segurança.
PRECISA oferecer ao usuário uma opção para entrar no modo de inicialização segura no menu de inicialização usando um fluxo de trabalho diferente de uma inicialização normal.

9.14. Isolamento do sistema de veículos automotivos

Espera-se que os dispositivos Android Automotive troquem dados com subsistemas críticos do veículo usando a HAL veicular para enviar e receber mensagens em redes de veículos, como o barramento CAN.

A troca de dados pode ser protegida com a implementação de recursos de segurança abaixo das camadas da estrutura do Android para evitar interações maliciosas ou não intencionais com esses subsistemas.

9.15. Planos de assinatura

"Planos de assinatura" se referem aos detalhes do plano de relacionamento de faturamento fornecidos por uma operadora de celular em SubscriptionManager.setSubscriptionPlans().

Todas as implementações de dispositivos:

[C-0-1] PRECISA retornar planos de assinatura apenas para o app da operadora de celular que os forneceu originalmente.
[C-0-2] NÃO PODE fazer backup ou upload remoto de planos de assinatura.
[C-0-3] SÓ PODE permitir substituições, como SubscriptionManager.setSubscriptionOverrideCongested(), do app da operadora de celular que oferece planos de assinatura válidos.

9.16. Migração de dados de aplicativos

Se as implementações de dispositivos incluírem a capacidade de migrar dados de um dispositivo para outro e não limitarem os dados do aplicativo copiados ao que é configurado pelo desenvolvedor no manifesto usando o atributo android:fullBackupContent, elas:

[C-1-1] NÃO PODE iniciar transferências de dados de aplicativos de dispositivos em que o usuário não definiu uma autenticação principal, conforme descrito em 9.11.1 Tela de bloqueio e autenticação seguras.
[C-1-2] É OBRIGATÓRIO confirmar com segurança a autenticação principal no dispositivo de origem e confirmar com a intenção do usuário de copiar os dados no dispositivo de origem antes que qualquer dado seja transferido.
[C-1-3] É OBRIGATÓRIO usar o atestado de chave de segurança para garantir que o dispositivo de origem e o dispositivo de destino na migração de dispositivo para dispositivo sejam dispositivos Android legítimos e tenham um carregador de inicialização bloqueado.
[C-1-4] SÓ PODE migrar dados do aplicativo para o mesmo aplicativo no dispositivo de destino, com o mesmo nome de pacote E certificado de assinatura.
[C-1-5] DEVE mostrar uma indicação de que os dados do dispositivo de origem foram migrados por uma migração de dados de dispositivo para dispositivo no menu de configurações. Um usuário NÃO DEVE poder remover essa indicação.

9.17. Framework de virtualização do Android

As APIs do Framework de virtualização do Android (AVF) (android.system.virtualmachine.*) permitem que os aplicativos criem máquinas virtuais (VMs) no dispositivo, protegidas (pVMs) e não protegidas (non-pVMs) que carregam e executam binários nativos como payloads.

Se as implementações de dispositivos definirem FEATURE_VIRTUALIZATION_FRAMEWORK como true, elas:

[C-1-1] PRECISA garantir que android.system.virtualmachine.VirtualMachineManager.getCapabilities() retorne um dos seguintes valores:
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. Verificação do desenvolvedor

Implementações de dispositivos que declaram o nível 36.1 da API ou mais recente:

PODE incluir suporte para um serviço de verificação de desenvolvedor para certificar que os aplicativos são de um desenvolvedor conhecido.

Implementações de dispositivos que declaram o nível 36.1 da API ou mais recente e configuram um verificador de desenvolvedor definindo config_developerVerificationServiceProviderPackageName em config.xml:

[9.18/C-1-1] É OBRIGATÓRIO invocar o android.content.pm.verify.developer.DeveloperVerifierService configurado para cada instalação de pacote de aplicativo, incluindo novas instalações e atualizações de aplicativos existentes.

Implementações de dispositivos que declaram o nível 36.1 da API ou mais recente:

MAY também pode configurar um delegado para definir a política ativa definindo config_developerVerificationPolicyDelegatePackageName em config.xml.

Se um verificador de desenvolvedor estiver configurado, as implementações de dispositivo:

[9.18/C-2-1] SÓ é permitido que o verificador de desenvolvedores ou o delegado configurado defina a política de instalação conforme definido em android.content.pm.PackageInstaller.

Se um verificador for invocado como parte de uma sessão de instalação de pacote, as implementações de dispositivo:

[9.18/C-3-1] É OBRIGATÓRIO impedir a instalação de um pacote de aplicativo se:
- A instalação falha na verificação de identidade do desenvolvedor.
- A política de verificação de desenvolvedor para a sessão de instalação está definida como qualquer valor diferente de DEVELOPER_VERIFICATION_POLICY_NONE.
- A menos que 9.18/C-3-2 ou 9.18/C-3-3 se apliquem.

[9.18/C-3-2] NÃO PODE impedir a instalação de um pacote de aplicativo independente da política ou do status de verificação quando:
- O pacote é instalado pelo Android Debug Bridge (adb).
- O pacote é o verificador de desenvolvedor configurado ou o instalador dele.

[9.18/C-3-3] NÃO PODE impedir a instalação de um pacote de aplicativo quando todas as condições a seguir forem atendidas:
- A política está definida como DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN ou DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.
- A verificação é informada como incompleta.
- O instalador indica que o usuário pediu explicitamente para continuar a instalação informando DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

PODE permitir a instalação de um pacote de aplicativo, independente da política ou do status de verificação para instalações iniciadas pelo proprietário do dispositivo em um dispositivo gerenciado ou pelo proprietário do perfil em um perfil gerenciado, mas é FORTEMENTE RECOMENDADO impedir instalações conforme descrito em 9.18/C-3-1.

10. Teste de compatibilidade de software

As implementações de dispositivos PRECISAM passar em todos os testes descritos nesta seção. No entanto, nenhum pacote de teste de software é totalmente abrangente. Por isso, RECOMENDAMOS FORTEMENTE que os implementadores de dispositivos façam o menor número possível de mudanças na implementação de referência e preferida do Android disponível no Android Open Source Project. Isso minimiza o risco de introduzir bugs que criam incompatibilidades e exigem retrabalho e possíveis atualizações de dispositivos.

10.1. Conjunto de teste de compatibilidade

Implementações de dispositivos:

[C-0-1] PRECISA ser aprovado no conjunto de teste de compatibilidade do Android (CTS) disponível no Android Open Source Project, usando o software final de envio no dispositivo.
[C-0-2] É OBRIGATÓRIO garantir a compatibilidade em casos de ambiguidade no CTS e em qualquer reimplementação de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. O CTS terá versões independentes dessa definição de compatibilidade, e várias revisões do CTS poderão ser lançadas para o Android 17.

Implementações de dispositivos:

[C-0-3] PRECISA passar na versão mais recente do CTS disponível no momento em que o software do dispositivo é concluído.
É RECOMENDADO usar a implementação de referência na árvore do Android Open Source o máximo possível.

10.2. Verificador do CTS

O CTS Verifier está incluído no conjunto de teste de compatibilidade e foi criado para ser executado por um operador humano para testar funcionalidades que não podem ser testadas por um sistema automatizado, como o funcionamento correto de uma câmera e sensores.

Implementações de dispositivos:

[C-0-1] PRECISA executar corretamente todos os casos aplicáveis no verificador do CTS.

O Verificador do CTS tem testes para vários tipos de hardware, incluindo alguns que são opcionais.

Implementações de dispositivos:

[C-0-2] PRECISA passar em todos os testes de hardware que possui. Por exemplo, se um dispositivo tiver um acelerômetro, ele PRECISA executar corretamente o caso de teste do acelerômetro no CTS Verifier.

Os casos de teste para recursos observados como opcionais por este documento de definição de compatibilidade PODEM ser ignorados ou omitidos.

[C-0-2] Todos os dispositivos e builds PRECISAM executar corretamente o CTS Verifier, conforme indicado acima. No entanto, como muitas versões são muito semelhantes, não é esperado que os implementadores de dispositivos executem explicitamente o CTS Verifier em versões que diferem apenas de maneiras triviais. Especificamente, as implementações de dispositivos que diferem de uma implementação que passou no Verificador do CTS apenas pelo conjunto de locais, branding etc. incluídos PODEM omitir o teste do Verificador do CTS.

11. Software atualizável

[C-0-1] As implementações de dispositivos PRECISAM incluir um mecanismo para substituir todo o software do sistema. O mecanismo não precisa realizar upgrades "ao vivo", ou seja, talvez seja necessário reiniciar o dispositivo. Qualquer método pode ser usado, desde que substitua todo o software pré-instalado no dispositivo. Por exemplo, qualquer uma das seguintes abordagens atende a esse requisito:
- Downloads "over-the-air (OTA)" com atualização off-line por reinicialização.
- Atualizações "conectadas" via USB de um PC host.
- Atualizações "off-line" por uma reinicialização e atualização de um arquivo em um armazenamento removível.
[C-0-2] O mecanismo de atualização usado PRECISA oferecer suporte a atualizações sem limpar os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados particulares e compartilhados do aplicativo. Observe que o software Android upstream inclui um mecanismo de atualização que atende a esse requisito.
[C-0-3] Toda a atualização PRECISA ser assinada, e o mecanismo de atualização no dispositivo PRECISA verificar a atualização e a assinatura em relação a uma chave pública armazenada no dispositivo.
[C-SR-1] É ALTAMENTE RECOMENDADO que o mecanismo de assinatura faça hash da atualização com SHA-256 e valide o hash com a chave pública usando ECDSA NIST P-256.

Se as implementações de dispositivos incluírem suporte para uma conexão de dados sem medição, como 802.11 ou perfil Bluetooth PAN (rede de área pessoal), elas:

[C-1-1] PRECISA oferecer suporte a downloads OTA com atualização off-line via reinicialização.

As implementações de dispositivos DEVEM verificar se a imagem do sistema é binariamente idêntica ao resultado esperado após uma OTA. A implementação de OTA baseada em blocos no Android Open Source Project upstream, adicionada desde o Android 5.1, atende a esse requisito.

Além disso, as implementações de dispositivos DEVEM oferecer suporte a atualizações do sistema A/B. O AOSP implementa esse recurso usando a HAL de controle de inicialização.

Se um erro for encontrado na implementação de um dispositivo após o lançamento, mas dentro da vida útil razoável do produto, determinada em consulta com a equipe de compatibilidade do Android, e afetar a compatibilidade de aplicativos de terceiros, então:

[C-2-1] O implementador do dispositivo PRECISA corrigir o erro com uma atualização de software disponível que pode ser aplicada de acordo com o mecanismo descrito acima.

O Android inclui recursos que permitem ao app proprietário do dispositivo (se presente) controlar a instalação de atualizações do sistema. Se o subsistema de atualização do sistema para dispositivos informar android.software.device_admin, ele:

[C-3-1] É OBRIGATÓRIO implementar o comportamento descrito na classe SystemUpdatePolicy.

12. Registro de alterações do documento

A partir do Android 16, não há um changelog mantido separadamente. Todas as mudanças da versão anterior estão destacadas neste documento.

13. Fale conosco

Participe do fórum de compatibilidade do Android e peça esclarecimentos ou levante problemas que você acha que o documento não aborda.

Definição de compatibilidade do Android 17 [PRÉVIA] Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

1. Introdução

1.1 Estrutura do documento

1.1.1. Requisitos por tipo de dispositivo

1.1.2. ID do requisito

1.1.3. ID do requisito na seção 2

2. Tipos de dispositivos

2.1 Configurações do dispositivo

2.2. Requisitos para dispositivos portáteis

2.2.1. Hardware

2.2.2. Multimídia

2.2.3. Software

2.2.3. Software

2.2.4. Desempenho e bateria

2.2.5. Modelo de segurança

Configurações restritas

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

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

2.2.7.1. Mídia

2.2.7.2. Câmera

2.2.7.3. Hardware

2.2.7.4. Desempenho

2.2.7.5. Gráficos

2.3. Requisitos de televisão

2.3.1. Hardware

2.3.2. Multimídia

2.3.3. Software

2.3.4. Desempenho e bateria

2.3.5. Modelo de segurança

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

2.4. Requisitos do relógio

2.4.1. Hardware

2.4.2. Multimídia

2.4.3. Software

2.4.4. Desempenho e bateria

2.4.5. Modelo de segurança

2.5. Requisitos automotivos

2.5.1. Hardware

2.5.2. Multimídia

2.5.3. Software

2.5.4. Desempenho e bateria

2.5.5. Modelo de segurança

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

2.6. Requisitos para tablets

2.6.1. Hardware

2.6.2. Modelo de segurança

2.6.2. Software

3. Software

3.1. Compatibilidade gerenciada de API

3.1.1. Extensões Android

3.1.2. Biblioteca do Android

3.2. Compatibilidade flexível de API

3.2.1. Permissões

3.2.2. Parâmetros de build

3.2.3. Compatibilidade de intents

3.2.3.1. Intents comuns de aplicativos

3.2.3.2. Resolução de intents

3.2.3.3. Namespaces de intents

3.2.3.4. Intents de transmissão

3.2.3.5. Intents de aplicativos condicionais

3.2.4. Atividades em telas secundárias/múltiplas

3.3. Compatibilidade da API nativa

3.3.1. Interfaces binárias de aplicativos

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

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com WebView

3.4.2. Compatibilidade de navegadores

3.5. Compatibilidade comportamental da API

3.5.1. Restrição de aplicativo

3.5.2. Hibernação de aplicativos

3.6. Namespaces de API

3.7. Compatibilidade com o ambiente de execução

3.8. Compatibilidade com a interface do usuário

3.8.1. Tela de início (Launcher)

3.8.2. Widgets

3.8.3. Notificações

3.8.3.1. Apresentação de notificações

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

3.8.3.3. NP (Não perturbe) / Modo de prioridade

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

Definição de compatibilidade do Android 17 [PRÉVIA]