Definição de compatibilidade do Android 13

1. Introdução

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

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

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

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

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

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

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

1.1 Estrutura do documento

1.1.1. Requisitos por tipo de dispositivo

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

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

1.1.2. ID do requisito

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

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

Cada ID é definido da seguinte forma:

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

1.1.3. ID do requisito na seção 2

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

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

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

2. Tipos de dispositivo

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

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

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

2.1 Configurações do dispositivo

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

2.2. Requisitos para dispositivos portáteis

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

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

• Ter uma fonte de energia que ofereça mobilidade, como uma bateria.
• Ter um tamanho físico de tela diagonal na faixa de 3,3 polegadas (ou 2,5 polegadas para implementações de dispositivo enviadas no nível 29 da API ou anterior) a 8 polegadas.

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

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

2.2.1. Hardware

Implementações de dispositivos portáteis:

• [7.1.1.1/H-0-1] É PRECISO ter pelo menos uma tela compatível com o Android que atenda a todos os requisitos descritos neste documento.

• [7.1.1.3/H-SR-1] É ALTAMENTE RECOMENDADO oferecer aos usuários uma capacidade de mudar o tamanho da tela (densidade da tela).

• [7.1.1.1/H-0-2] É PRECISO oferecer suporte à composição de GPU de buffers gráficos com pelo menos o tamanho da resolução mais alta de qualquer tela integrada.

Se as implementações de dispositivos portáteis oferecerem suporte à rotação da tela do software, elas:

• [7.1.1.1/H-1-1]* É OBRIGATÓRIO que a tela lógica disponibilizada para aplicativos de terceiros tenha pelo menos 5 cm nas bordas curtas e 6,3 cm nas bordas longas. Os dispositivos enviados com o nível 29 da API do Android ou versões anteriores podem ser isentos desse requisito.

Se as implementações de dispositivos portáteis não oferecerem suporte à rotação de tela de software, elas:

• [7.1.1.1/H-2-1]* É OBRIGATÓRIO que a tela lógica disponibilizada para aplicativos de terceiros tenha pelo menos 2,7 polegadas na borda curta. Os dispositivos enviados com o nível 29 da API do Android ou versões anteriores podem ser isentos desse requisito.

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

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

Implementações de dispositivos portáteis:

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

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

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

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

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

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

Implementações de dispositivos portáteis:

• [7.3.11/H-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao sensor de pose com 6 graus de liberdade.
• [7.4.3/H] DEVE incluir suporte a Bluetooth e Bluetooth LE.

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

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

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

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

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

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

Implementações de dispositivos portáteis:

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

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

• [7.6.1/H-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 416 MB se a tela padrão usar resoluções de framebuffer de até qHD (por exemplo, FWVGA).

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

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

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

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

• [7.6.1/H-5-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 816 MB se a tela padrão usar resoluções de framebuffer de até qHD (por exemplo, FWVGA).

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

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

• [7.6.1/H-8-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1824 MB se a tela padrão usar resoluções de framebuffer de até QHD (por exemplo, QWXGA).

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

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

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

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

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

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

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

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

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

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

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

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

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

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

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

• [7.8.2.2/H-4-1] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e a função isSink() se o campo de tipo de terminal de áudio USB for 0x0302.

• [7.8.2.2/H-4-2] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e role isSink() se o campo de tipo de terminal de áudio USB for 0x0402.

• [7.8.2.2/H-4-3] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e role isSource() se o campo de tipo de terminal de áudio USB for 0x0402.

• [7.8.2.2/H-4-4] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e role isSink() se o campo de tipo de terminal de áudio USB for 0x603.

• [7.8.2.2/H-4-5] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e role isSource() se o campo de tipo de terminal de áudio USB for 0x604.

• [7.8.2.2/H-4-6] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e role isSink() se o campo de tipo de terminal de áudio USB for 0x400.

• [7.8.2.2/H-4-7] É PRECISO listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e role isSource() se o campo de tipo de terminal de áudio USB for 0x400.

• [7.8.2.2/H-SR-1] É ALTAMENTE RECOMENDADO, após a conexão de um periférico de áudio USB-C, realizar a enumeração de descritores USB, identificar tipos de terminal e transmitir a Intent ACTION_HEADSET_PLUG em menos de 1.000 milissegundos.

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

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

• [5.6/H-1-2] É PRECISO ter uma latência média de Tap-to-Tone de 500 milissegundos ou menos em pelo menos cinco medições no caminho de dados do alto-falante para o microfone.

Se as implementações de dispositivos portáteis incluírem pelo menos um atuador háptico, elas:

• [7.10/H]* NÃO use um atuador háptico (vibrador) de massa excêntrica rotativa (ERM, na sigla em inglês).
• [7.10/H]* DEVE posicionar o atuador perto do local em que o dispositivo normalmente é segurado ou tocado pelas mãos.
• [7.10/H]* DEVE implementar todas as constantes públicas para haptics claros 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.
• [7.10/H]* DEVE implementar todas as constantes públicas para haptics claras em android.os.VibrationEffect, ou seja, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e todas as constantes PRIMITIVE_* públicas possíveis para haptics avançados 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ó podem ser viáveis se o vibrador puder oferecer suporte a frequências relativamente baixas.

• [7.10/H]* DEVE seguir as orientações para mapeamento de constantes públicas em android.view.HapticFeedbackConstants para as constantes recomendadas de android.os.VibrationEffect, com as relações de amplitude correspondentes.

• [7.10/H]* DEVE seguir a avaliação de qualidade para as APIs createOneShot() e createWaveform().

• [7.10/H]* DEVE verificar se o resultado da API pública android.os.Vibrator.hasAmplitudeControl() reflete corretamente os recursos do vibrador.

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

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

• [7.10/H]* PRECISA mover o atuador háptico no eixo X (esquerda-direita) da orientação retrato.

Se as implementações de dispositivos portáteis tiverem um atuador háptico que é um atuador de ressonância linear (LRA, na sigla em inglês) do eixo X, elas:

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

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

• [7.10/H]* É necessário verificar o status da implementação executando android.os.Vibrator.areAllEffectsSupported() e android.os.Vibrator.arePrimitivesSupported() da API.

• [7.10/H]* DEVE realizar uma avaliação de qualidade para constantes hápticas.

• [7.10/H]* DEVE verificar e atualizar, se necessário, a configuração substituta para primitivas sem suporte, conforme descrito nas orientações de implementação para constantes.

2.2.2. Multimídia

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

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

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

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

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

2.2.3. Software

Implementações de dispositivos portáteis:

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

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

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

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

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

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

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

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

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

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

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

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

• [3.8.16/H-1-1] É PRECISO declarar a flag de recurso android.software.controls e defini-la como true.
• [3.8.16/H-1-2] É PRECISO fornecer uma affordance ao usuário com a capacidade de adicionar, editar, selecionar e operar os controles de dispositivo favoritos do usuário entre os controles registrados pelos aplicativos de terceiros usando as APIs ControlsProviderService e Control.
• [3.8.16/H-1-3] É PRECISO fornecer acesso a essa característica do usuário em três interações de uma tela de início padrão.

• [3.8.16/H-1-4] É PRECISO renderizar com precisão o nome e o ícone de cada app de terceiros que oferece controles pela API ControlsProviderService e todos os campos especificados fornecidos pelas APIs Control.

• [3.8.16/H-1-5] É PRECISO fornecer ao usuário uma capacidade de uso para desativar os controles de dispositivo simples de autenticação designados pelo app dos controles registrados pelos aplicativos de terceiros usando ControlsProviderService e a API Control.isAuthRequired Control.

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

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

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

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

Implementações de dispositivos portáteis:

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

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

• [3.16/H-1-1] É necessário oferecer suporte ao recurso de pareamento de dispositivo complementar.

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

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

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

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

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

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

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

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

Se a implementação de configurações do dispositivo portátil implementar uma funcionalidade dividida usando a incorporação de atividades, ela:

• [3.2.3.1/ H-1-1] É PRECISO 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 em Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

2.2.4. Desempenho e bateria

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

Implementações de dispositivos portáteis:

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

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

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

Implementações de dispositivos portáteis:

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

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

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

Implementações de dispositivos portáteis:

• [8.5/H-0-1] É OBRIGATÓRIO fornecer uma capacidade de uso do usuário no menu "Configurações" com a capacidade de interromper um app que está executando um serviço em primeiro plano e mostrar todos os apps que têm serviços em primeiro plano ativos e a duração de cada um desses serviços desde que ele foi iniciado, conforme descrito no documento do SDK.
  • Alguns apps podem ser dispensados da interrupção ou da listagem em uma affordance do usuário, conforme descrito no documento do SDK.

2.2.5. Modelo de segurança

Implementações de dispositivos portáteis:

• [9.1/H-0-1] É PRECISO permitir que apps de terceiros acessem as estatísticas de uso pela permissão android.permission.PACKAGE_USAGE_STATS e oferecer 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.

Implementações de dispositivos portáteis:

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

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

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

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

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

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

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

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

O Android, por meio da API System VoiceInteractionService, oferece suporte a um mecanismo de detecção segura de palavras de ativação sempre ativadas sem indicação de acesso ao microfone.

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

• [9.8/H-1-1] É PRECISO garantir que o serviço de detecção de palavras-chave só possa transmitir dados para o sistema ou o ContentCaptureService.
• [9.8/H-1-2] É OBRIGATÓRIO garantir que o serviço de detecção de palavras-chave possa transmitir apenas dados de áudio do microfone ou dados derivados dele para o servidor do sistema pela API HotwordDetectionService ou para ContentCaptureService pela API ContentCaptureManager.
• [9.8/H-1-3] NÃO é permitido fornecer áudio do microfone com mais de 30 segundos para uma solicitação individual acionada por hardware ao serviço de detecção de palavras-chave.
• [9.8/H-1-4] NÃO é permitido fornecer áudio de microfone em buffer com mais de 8 segundos para uma solicitação individual ao serviço de detecção de hotword.
• [9.8/H-1-5] NÃO é permitido fornecer áudio de microfone em buffer com mais de 30 segundos para o serviço de interação por voz ou entidade semelhante.
• [9.8/H-1-6] NÃO É PERMITIDO que mais de 100 bytes de dados não audio sejam transmitidos pelo serviço de detecção de palavras-chave em cada resultado de palavra-chave.
• [9.8/H-1-7] NÃO É PERMITIDO que mais de 5 bits de dados sejam transmitidos fora do serviço de detecção de palavras-chave em cada resultado negativo.
• [9.8/H-1-8] SOMENTE é permitido permitir a transmissão de dados para fora do serviço de detecção de palavras-chave em uma solicitação de validação de palavras-chave do servidor do sistema.
• [9.8/H-1-9] NÃO é permitido que um aplicativo instalável pelo usuário forneça o serviço de detecção de palavras-chave.
• [9.8/H-1-10] NÃO É PERMITIDO mostrar na interface dados quantitativos sobre o uso do microfone pelo serviço de detecção de palavras-chave.
• [9.8/H-1-11] É OBRIGATÓRIO registrar o número de bytes incluídos em cada transmissão do serviço de detecção de palavras-chave para permitir a inspeção por pesquisadores de segurança.
• [9.8/H-1-12] É PRECISO oferecer suporte a um modo de depuração que registre o conteúdo bruto de cada transmissão do serviço de detecção de palavras-chave para permitir a inspeção por pesquisadores de segurança.
• [9.8/H-1-14] É PRECISO mostrar o indicador do microfone, conforme descrito na seção 9.8.2, quando um resultado de palavra de ativação bem-sucedida é transmitido ao serviço de interação por voz ou entidade semelhante.
• [9.8/H-SR-1] É ALTAMENTE RECOMENDADO notificar os usuários antes de definir um aplicativo como o provedor do serviço de detecção de palavras-chave.
• [9.8/H-SR-2] É ALTAMENTE RECOMENDADO não permitir a transmissão de dados não estruturados do serviço de detecção de hotword.
• [9.8/H-SR-3] É ALTAMENTE RECOMENDADO reiniciar o processo que hospeda o serviço de detecção de palavras-chave pelo menos uma vez a cada hora ou a cada 30 eventos de gatilho de hardware, o que ocorrer primeiro.

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

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

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

• [9.8.2/H-4-1] É PRECISO mostrar o indicador do microfone quando um app estiver acessando dados de áudio do microfone, mas não quando o microfone for acessado apenas por HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService ou apps com as funções mencionadas na seção 9.1 com o identificador CDD [C-4-X].
• [9.8.2/H-4-2] É PRECISO mostrar a lista de apps recentes e ativos usando o microfone conforme retornado por PermissionManager.getIndicatorAppOpUsageData(), junto com as mensagens de atribuição associadas a eles.

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

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

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

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

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

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

• Perfetto
  • [6.1/H-0-2]* É PRECISO expor um binário /system/bin/perfetto ao usuário do shell, em que o cmdline está 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 obedeça ao esquema definido na documentação do perfetto.
  • [6.1/H-0-4]* O binário do perfetto PRECISA gravar como saída um trace de protobuf que obedeça ao esquema definido na documentação do perfetto.
  • [6.1/H-0-5]* É PRECISO 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 de rastreamento do perfetto PRECISA ser ativado por padrão (propriedade do sistema persist.traced.enable).

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

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

2.2.7.1. Mídia

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

• É PRECISO atender aos requisitos de mídia listados na seção 2.2.7.1 do CDD do Android 12.

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

• [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 codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] É PRECISO oferecer suporte a 6 instâncias de sessões de decodificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 1080p a 30 fps.
• [5.1/H-1-3] É OBRIGATÓRIO anunciar o número máximo de sessões de codificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] É PRECISO oferecer suporte a 6 instâncias de sessões de codificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 1080p a 30 fps.
• [5.1/H-1-5] É OBRIGATÓRIO anunciar o número máximo de sessões de codificador e decodificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] É PRECISO oferecer suporte a 6 instâncias de decodificador de vídeo de hardware e sessões de codificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente na resolução 1080p a 30 fps.
• [5.1/H-1-7] É PRECISO ter uma latência de inicialização de codec de 40 ms ou menos para uma sessão de codificação de vídeo de 1080p ou menor para todos os codificadores de vídeo de hardware quando sob carga. O carregamento aqui é definido como uma sessão de transcodificação de vídeo simultânea de 1080p para 720p usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo de 1080p. Para o codec Dolby Vision, a latência de inicialização do codec PRECISA ser de 50 ms ou menos.
• [5.1/H-1-8] É PRECISO ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de codificação de áudio de 128 kbps ou menos para todos os codificadores de áudio durante a carga. O carregamento aqui é definido como uma sessão de transcodificação de vídeo de 1080p para 720p simultânea usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo de 1080p.
• [5.1/H-1-9] É PRECISO oferecer suporte a duas instâncias de sessões de decodificador de vídeo de hardware seguras (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 1080p a 30 fps.
• [5.1/H-1-10] É PRECISO oferecer suporte a três instâncias de sessões de decodificador de vídeo de hardware não seguras com uma instância de sessão de decodificador de vídeo de hardware segura (4 instâncias no total) (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 1080p a 30 fps.
• [5.1/ H-1-11] É PRECISO oferecer suporte a um decodificador seguro para cada decodificador AVC, HEVC, VP9 ou AV1 de hardware no dispositivo.
• [5.1/H-1-12] É PRECISO ter uma latência de inicialização de codec de 40 ms ou menos para uma sessão de decodificação de vídeo de 1080p ou menor para todos os decodificadores de vídeo de hardware quando em carga. O carregamento aqui é definido como uma sessão de transcodificação de vídeo simultânea de 1080p para 720p usando codecs de vídeo de hardware com a inicialização de reprodução de áudio e vídeo de 1080p. Para o codec Dolby Vision, a latência de inicialização do codec PRECISA ser de 50 ms ou menos.
• [5.1/H-1-13] É OBRIGATÓRIO ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de decodificação de áudio de 128 kbps ou menos para todos os decodificadores de áudio durante o carregamento. O carregamento aqui é definido como uma sessão de transcodificação de vídeo concorrente de 1080p para 720p usando codecs de vídeo de hardware com a inicialização de reprodução de áudio-vídeo de 1080p.
• [5.1/H-1-14] É PRECISO oferecer suporte ao decodificador de hardware AV1 Main 10, nível 4.1.
• [5.1/H-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte a granulação de filme para decodificador de hardware AV1.
• [5.1/H-1-15] É PRECISO ter pelo menos 1 decodificador de vídeo de hardware compatível com 4K60.
• [5.1/H-1-16] É PRECISO ter pelo menos 1 codificador de vídeo de hardware compatível com 4K60.
• [5.3/H-1-1] NÃO PODE haver mais de 1 frame em 10 segundos (ou seja, menos de 0,167% de queda de frames) para uma sessão de vídeo de 1080p 60 fps sob carga. A carga é definida como uma sessão de transcodificação simultânea de 1080p para 720p somente em vídeo usando codecs de vídeo de hardware, além de uma reprodução de áudio AAC de 128 kbps.
• [5.3/H-1-2] NÃO É PERMITIDO perder mais de 1 frame em 10 segundos durante uma mudança de resolução de vídeo em uma sessão de vídeo de 60 fps sob carga. A carga é definida como uma sessão de transcodificação de vídeo simultânea de 1080p para 720p usando codecs de vídeo de hardware, além de uma reprodução de áudio AAC de 128 kbps.
• [5.6/H-1-1] É PRECISO ter uma latência de toque para tom de 80 milissegundos ou menos usando o teste de toque para tom do OboeTester ou o teste de toque para tom do CTS Verifier.
• [5.6/H-1-2] É PRECISO ter uma latência de áudio de ida e volta de 80 milissegundos ou menos em pelo menos um caminho de dados compatível.
• [5.6/H-1-3] É PRECISO oferecer suporte a áudio de 24 bits ou mais para saída estéreo por meio de conectores de áudio de 3,5 mm, se presentes, e por áudio USB, se houver suporte em todo o caminho de dados para configurações de baixa latência e streaming. Para a configuração de baixa latência, a AAudio precisa ser usada pelo app no modo de callback de baixa latência. Para a configuração de streaming, o app precisa usar um Java AudioTrack. Nas configurações de baixa latência e streaming, o sink de saída do HAL precisa aceitar AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT ou AUDIO_FORMAT_PCM_FLOAT como formato de saída de destino.
• [5.6/H-1-4] É PRECISO ter suporte a dispositivos de áudio USB de 4 canais ou mais (usado por controladores de DJ para visualizar músicas).
• [5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar a flag de recurso MIDI.
• [5.7/H-1-2] É PRECISO oferecer suporte a MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL com os recursos de descriptografia de conteúdo abaixo.

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

2.2.7.2. Câmera

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.S 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 12.

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

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

2.2.7.3. Hardware

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.S 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 12.

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

• [7.1.1.1/H-2-1] É PRECISO ter uma resolução de tela de pelo menos 1080p.
• [7.1.1.3/H-2-1] É NECESSÁRIO ter uma densidade de tela de pelo menos 400 dpi.
• [7.6.1/H-2-1] É PRECISO ter pelo menos 8 GB de memória física.

2.2.7.4. Desempenho

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

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

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

• [8.2/H-1-1] É PRECISO garantir um desempenho de gravação sequencial de pelo menos 125 MB/s.
• [8.2/H-1-2] É PRECISO garantir um desempenho de gravação aleatória de pelo menos 10 MB/s.
• [8.2/H-1-3] É PRECISO garantir um desempenho de leitura sequencial de pelo menos 250 MB/s.
• [8.2/H-1-4] É PRECISO garantir uma performance de leitura aleatória de pelo menos 40 MB/s.

2.3. Requisitos de televisão

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

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

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

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

2.3.1. Hardware

Implementações de dispositivos de TV:

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

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

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

Implementações de dispositivos de TV:

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

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

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

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

• [7.6.1/T-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se qualquer uma das densidades a seguir for usada:

  • 400 dpi ou mais em telas pequenas/normais
  • xhdpi ou superior em telas grandes
  • tvdpi ou superior em telas extragrandes

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

• [7.6.1/T-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB se qualquer uma das densidades a seguir for usada:

  • 400 dpi ou mais em telas pequenas/normais
  • xhdpi ou superior em telas grandes
  • tvdpi ou superior em telas extragrandes

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

Implementações de dispositivos de TV:

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

2.3.2. Multimídia

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

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

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

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

Implementações de dispositivos de TV:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementações de dispositivos de TV:

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

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

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

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

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

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

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

2.3.3. Software

Implementações de dispositivos de TV:

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

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

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

Implementações de dispositivos de TV:

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

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

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

Implementações de dispositivos de TV:

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

2.3.4. Desempenho e bateria

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

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

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

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

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

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

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

Implementações de dispositivos de TV:

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

2.3.5. Modelo de segurança

Implementações de dispositivos de TV:

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementações de dispositivos de TV:

• Perfetto
  • [6.1/T-0-1] É PRECISO expor um binário /system/bin/perfetto ao usuário do shell que o cmdline obedece à documentação do perfetto.
  • [6.1/T-0-2] O binário do perfetto PRECISA aceitar como entrada uma configuração protobuf que obedeça ao esquema definido na documentação do perfetto.
  • [6.1/T-0-3] O binário do perfetto PRECISA gravar como saída um trace de protobuf que obedeça ao esquema definido na documentação do perfetto.
  • [6.1/T-0-4] É PRECISO fornecer, pelo binário do perfetto, pelo menos as origens de dados descritas na documentação do perfetto.

2.4. Requisitos do relógio

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

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

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

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

2.4.1. Hardware

Implementações de dispositivos de relógio:

• [7.1.1.1/W-0-1] PRECISA ter uma tela com o tamanho físico da diagonal no intervalo de 1,1 a 2,5 polegadas.

• [7.2.3/W-0-1] A função "Início" e a função "Voltar" precisam estar disponíveis para o usuário, exceto quando estiverem em UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] É PRECISO oferecer suporte à entrada por touchscreen.

• [7.3.1/W-SR-1] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

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

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

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

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

Implementações de dispositivos de relógio:

• [7.4.3/W-0-1] É PRECISO ter suporte a Bluetooth.

• [7.6.1/W-0-1] É PRECISO ter pelo menos 1 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecidos como partição "/data").

• [7.6.1/W-0-2] É PRECISO ter pelo menos 416 MB de memória disponível para o kernel e o espaço do usuário.

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

• [7.8.2/W] PODE ter saída de áudio.

2.4.2. Multimídia

Nenhum requisito extra.

2.4.3. Software

Implementações de dispositivos de relógio:

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

Implementações de dispositivos de relógio:

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

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

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

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

• [3.11/W-SR-1] É ALTAMENTE RECOMENDADO incluir um motor de TTS que ofereça suporte aos idiomas disponíveis no dispositivo.

• [3.11/W-0-1] É PRECISO oferecer suporte à instalação de motores de TTS de terceiros.

2.4.4. Desempenho e bateria

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

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

Implementações de dispositivos de relógio:

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

2.4.5. Modelo de segurança

Implementações de dispositivos de relógio:

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

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

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

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

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

2.5. Requisitos automotivos

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

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

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

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

2.5.1. Hardware

Implementações de dispositivos automotivos:

• [7.1.1.1/A-0-1] É PRECISO ter uma tela com pelo menos 6 polegadas de tamanho físico na diagonal.

• [7.1.1.1/A-0-2] É PRECISO ter um layout de tamanho de tela de pelo menos 750 dp x 480 dp.

• [7.2.3/A-0-1] É OBRIGATÓRIO fornecer a função "Início" e PODE fornecer as funções "Voltar" e "Recentes".

• [7.2.3/A-0-2] É PRECISO enviar o evento de pressionamento normal e longo da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano.

• [7.3/A-0-1] É OBRIGATÓRIO implementar e informar GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.

• [7.3/A-0-2] O valor da flag NIGHT_MODE PRECISA ser consistente com o modo dia/noite do painel e DEVE ser baseado na entrada do sensor de luz ambiente. O sensor de luz ambiente pode ser o mesmo que o fotômetro.

• [7.3/A-0-3] É OBRIGATÓRIO fornecer o campo de informações adicionais do sensor TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor fornecido.

• [7.3/A-SR1] PODE estimar a localização combinando o GPS/GNSS com outros sensores. Se o local for calculado, é ALTAMENTE RECOMENDADO implementar e informar os tipos de sensor correspondentes e/ou os IDs de propriedade do veículo usados.

• [7.3/A-0-4] O local solicitado por LocationManager#requestLocationUpdates() NÃO PODE ser associado ao mapa.

• [7.3.1/A-0-4] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor do carro do Android.

• [7.3/A-SR-1] É _RECOMENDADO_INCLUSIVO incluir um acelerômetro de três eixos e um giroscópio de três eixos.

• [7.3/A-SR-2] É STRONGLY_RECOMMENDED implementar e informar o sensor TYPE_HEADING.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementações de dispositivos automotivos:

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

• [7.4.3/A-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao perfil de acesso a mensagens (MAP).

• [7.4.5/A] DEVE incluir suporte para conectividade de dados celular baseada em rede.

• [7.4.5/A] PODE usar a constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID da API do sistema para redes que precisam estar disponíveis para apps do sistema.

Uma câmera de visão externa é uma câmera que captura imagens de cenas fora da implementação do dispositivo, como a câmera traseira.

Implementações de dispositivos automotivos:

• DEVE incluir uma ou mais câmeras de visão externa.

Se as implementações de dispositivos automotivos incluírem uma câmera de visão externa, para essa câmera, elas:

• [7.5/A-1-1] NÃO é permitido ter câmeras de visão externa acessíveis pelas APIs de câmera do Android, a menos que elas obedeçam aos requisitos básicos da câmera.

• [7.5/A-SR-1] É ALTAMENTE RECOMENDADO não girar ou espelhar horizontalmente a visualização da câmera.

• [7.5/A-SR-2] É ALTAMENTE RECOMENDADO ter uma resolução de pelo menos 1,3 megapixels.

• DEVE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).

• PODE ter o foco automático de hardware ou de software implementado no driver da câmera.

Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras de visão externa e carregarem o serviço do sistema de visualização externa (EVS, na sigla em inglês), para essa câmera, elas:

• [7.5/A-2-1] A visualização da câmera NÃO PODE ser girada ou espelhada horizontalmente.

Implementações de dispositivos automotivos:

• PODE incluir uma ou mais câmeras disponíveis para aplicativos de terceiros.

Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera e a disponibilizarem para aplicativos de terceiros, elas:

• [7.5/A-3-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera.any.
• [7.5/A-3-2] NÃO DECLARAR a câmera como uma câmera do sistema.
• PODE aceitar câmeras externas descritas na seção 7.5.3.
• PODE incluir recursos (como foco automático etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

Implementações de dispositivos automotivos:

• [7.6.1/A-0-1] É PRECISO ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecidos como 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 oferecerem armazenamento externo compartilhado por meio de uma parte do armazenamento interno não removível, elas:

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

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 se qualquer uma das densidades a seguir for usada:

  • 280 dpi ou menos em telas pequenas/normais
  • ldpi ou menor em telas extragrandes
  • mdpi ou menor em telas grandes

• [7.6.1/A-2-2] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 944 MB se qualquer uma das densidades a seguir for usada:

  • xhdpi ou superior em telas pequenas/normais
  • hdpi ou superior em telas grandes
  • mdpi ou superior em telas extragrandes

• [7.6.1/A-2-3] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.280 MB se qualquer uma das densidades a seguir for usada:

  • 400 dpi ou mais em telas pequenas/normais
  • xhdpi ou superior em telas grandes
  • tvdpi ou superior em telas extragrandes

• [7.6.1/A-2-4] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1824 MB se qualquer uma 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

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

2.5.2. Multimídia

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

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

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

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

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

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

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

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

2.5.3. Software

Implementações de dispositivos automotivos:

• [3/A-0-1] É OBRIGATÓRIO declarar o recurso android.hardware.type.automotive.

• [3/A-0-2] É necessário oferecer suporte a uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] É PRECISO oferecer suporte a todas as APIs públicas no namespace android.car.*.

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

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

Implementações de dispositivos automotivos:

• [3.2.1/A-0-1] É PRECISO oferecer suporte e aplicar todas as constantes de permissão, conforme documentado na página de referência de permissões automotivas.

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

• [3.4.1/A-0-1] É PRECISO fornecer uma implementação completa da API android.webkit.Webview.

• [3.8.3/A-0-1] É PRECISO mostrar notificações que usam a API Notification.CarExtender quando solicitadas por aplicativos de terceiros.

• [3.8.4/A-SR-1] É altamente recomendável implementar um assistente no dispositivo para processar a ação de assistência.

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

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

Implementações de dispositivos automotivos:

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

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

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

Implementações de dispositivos automotivos:

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

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

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

Implementações de dispositivos automotivos:

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

2.5.4. Desempenho e bateria

Implementações de dispositivos automotivos:

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

2.5.5. Modelo de segurança

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

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

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

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

Implementações de dispositivos automotivos:

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

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

Implementações de dispositivos automotivos:

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

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

Implementações de dispositivos automotivos:

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

2.6. Requisitos para tablets

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

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

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

2.6.1. Hardware

Giroscópio

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

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

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

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

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

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

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

Modo de realidade virtual (seção 7.9.1)

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

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

2.6.2. Modelo de segurança

Chaves e credenciais (seção 9.11)

Consulte a seção [9.11].

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

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

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

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

2.6.2. Software

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

3. Software

3.1. Compatibilidade com a API gerenciada

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

Implementações de dispositivos:

• [C-0-1] É necessário fornecer implementações completas, incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo SDK do Android ou qualquer API decorada com o marcador "@SystemApi" no código-fonte do Android upstream.

• [C-0-2] É PRECISO oferecer suporte/preservar todas as classes, métodos e elementos associados marcados pela anotação TestApi (@TestApi).

• [C-0-3] NÃO PODE omitir APIs gerenciadas, alterar interfaces ou assinaturas de API, desviar do comportamento documentado ou incluir no-ops, exceto quando especificamente permitido por esta definição de compatibilidade.

• [C-0-4] AS APIs ainda precisam estar presentes e se comportar de maneira razoável, mesmo quando alguns recursos de hardware para os quais o Android inclui APIs são omitidos. Consulte a seção 7 para ver os requisitos específicos deste cenário.

• [C-0-5] NÃO É PERMITIDO que apps de terceiros usem interfaces que não sejam do SDK, que são definidas como métodos e campos nos pacotes de linguagem Java que estão no caminho de classe de inicialização no AOSP e que não fazem parte do SDK público. Isso inclui APIs decoradas com a anotação @hide, mas não com uma @SystemAPI, conforme descrito nos documentos do SDK e nos membros de classe privados e de pacote-privado.

• [C-0-6] É OBRIGATÓRIO enviar todas as interfaces não SDK nas mesmas listas restritas, conforme fornecido pelas flags provisórias e de negação na pasta prebuilts/runtime/appcompat/hiddenapi-flags.csv do branch de nível de API apropriado no AOSP.

• [C-0-7] É PRECISO oferecer suporte ao mecanismo de atualização dinâmica de configuração assinada para remover interfaces que não sejam do SDK de uma lista restrita incorporando a configuração assinada em qualquer APK, usando as chaves públicas presentes no AOSP.

  No entanto, eles:

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

3.1.1. Extensões Android

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

Implementações de dispositivos Android:

• [C-0-1] É OBRIGATÓRIO pré-carregar a implementação do AOSP da biblioteca compartilhada ExtShared e dos serviços ExtServices com versões maiores ou iguais às versões mínimas permitidas para cada nível de API. Por exemplo, implementações de dispositivos do Android 7.0 com o nível 24 da API precisam incluir pelo menos a versão 1.

• [C-0-2] SOMENTE deve retornar o número da versão da extensão válida que foi definido pelo AOSP.

• [C-0-3] É PRECISO oferecer suporte a todas as APIs definidas pelas versões de extensão retornadas por android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) da mesma maneira que outras APIs gerenciadas são compatíveis, seguindo os requisitos da seção 3.1.

3.1.2. Biblioteca Android

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

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

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

3.2. Compatibilidade de API flexível

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

3.2.1. Permissões

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

3.2.2. Parâmetros do build

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

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

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

3.2.3. Compatibilidade de intents

3.2.3.1. Intents comuns de apps

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

Implementações de dispositivos:

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

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

3.2.3.2. Resolução de intents

• [C-0-1] Como o Android é uma plataforma extensível, as implementações de dispositivos PRECISAM permitir que cada padrão de intent referenciado na seção 3.2.3.1 , exceto as Configurações, seja substituído por aplicativos de terceiros. A implementação de código aberto upstream do Android permite isso por padrão.

• [C-0-2] Os implementadores de dispositivos PRECISAM NÃO anexar privilégios especiais ao uso de aplicativos do sistema desses padrões de intent ou impedir que aplicativos de terceiros se associem e assumam o controle desses padrões. Essa proibição inclui especificamente, mas não se limita a, desativar a interface do usuário "Chooser", que permite ao usuário selecionar entre vários aplicativos que processam o mesmo padrão de intent.

• [C-0-3] As implementações de dispositivo precisam fornecer uma interface do usuário para que os usuários modifiquem a atividade padrão para intents.

• No entanto, as implementações de dispositivos PODEM fornecer atividades padrão para padrões específicos de URI (por exemplo, http://play.google.com) quando a atividade padrão fornece um atributo mais específico para o URI de dados. Por exemplo, um padrão de filtro de intent que especifica o URI de dados "http://www.android.com" é mais específico 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 autorizado para determinados tipos de intents de URI da Web. Quando essas declarações oficiais são definidas nos padrões de filtro de intent de um app, as implementações do dispositivo:

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

3.2.3.3. Namespaces de intent

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

3.2.3.4. Intents de transmissão

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

Implementações de dispositivos:

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

3.2.3.5. Intents de aplicativo condicionais

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

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

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

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

Se as implementações do dispositivo informarem android.hardware.telephony.calling, elas:

• [C-2-1] É necessário fornecer um menu de configurações que chame a intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar uma caixa de diálogo para mudar o app de SMS padrão.

• [C-2-2] É PRECISO honrar a intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar uma caixa de diálogo que permita ao usuário mudar o aplicativo de telefone padrão.

  • É OBRIGATÓRIO usar a interface do app Telefone padrão selecionada pelo usuário para chamadas recebidas e realizadas, exceto para chamadas de emergência, que usam o app Telefone pré-instalado.

• [C-2-3] É PRECISO honrar a intent android.telecom.action.CHANGE_PHONE_ACCOUNTS para fornecer ao usuário a capacidade de configurar o ConnectionServices associado ao PhoneAccounts, bem como uma PhoneAccount padrão que o provedor de serviços de telecomunicações usará para fazer chamadas. A implementação do AOSP atende a esse requisito incluindo uma opção "Calling Accounts" no menu de configurações "Calls".

• [C-2-4] É PRECISO permitir android.telecom.CallRedirectionService para um app que tenha o papel android.app.role.CALL_REDIRECTION.

• [C-2-5] É OBRIGATÓRIO fornecer ao usuário a capacidade de escolher um app que tenha a função android.app.role.CALL_REDIRECTION.

• [C-2-6] É OBRIGATÓRIO honrar as intents android.intent.action.SENDTO e android.intent.action.VIEW e fornecer uma atividade para enviar/exibir mensagens SMS.

• [C-SR-1] É ALTAMENTE RECOMENDADO honrar as intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL com um aplicativo de discagem pré-carregado, que pode processar essas intents e oferecer o fulfillment conforme descrito no SDK.

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-9-1] É 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 do dispositivo oferecerem o modo de Economia de dados, elas:

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

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

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

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

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

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

• [C-13-1] É OBRIGATÓRIO honrar a intent android.app.action.ADD_DEVICE_ADMIN para invocar uma interface que ajude o usuário a adicionar o administrador do dispositivo ao sistema (ou permitir que ele o rejeite).

• [C-13-2] É PRECISO honrar as intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION e ter uma atividade para fornecer a realização dessas intents, conforme descrito no SDK neste link.

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

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

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

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

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

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

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

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

• [C-17-1] [Moved to 2.2.3]

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

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

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

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

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

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

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

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

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

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

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

3.3. Compatibilidade com a API nativa

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

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

3.3.1. Interfaces binárias do aplicativo

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

Implementações de dispositivos:

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

• [C-0-6] É OBRIGATÓRIO informar, pelos parâmetros acima, um subconjunto da lista de ABIs abaixo e NÃO informar nenhuma ABI que não esteja na lista.

  • armeabi (não é mais compatível como destino do NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [C-0-7] É OBRIGATÓRIO disponibilizar todas as bibliotecas a seguir, que fornecem APIs nativas, para apps que incluem código nativo:

  • libaaudio.so (suporte de áudio nativo do AAudio)
  • libamidi.so (suporte MIDI nativo, se o recurso android.software.midi for reivindicado conforme descrito na seção 5.9)
  • libandroid.so (suporte nativo à atividade do Android)
  • libc (biblioteca C)
  • libcamera2ndk.so
  • libdl (vinculador dinâmico)
  • libEGL.so (gerenciamento de superfície OpenGL nativa)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (geração de registros do Android)
  • libmediandk.so (suporte a APIs de mídia nativas)
  • libm (biblioteca matemática)
  • libneuralnetworks.so (API Neural Networks)
  • libOpenMAXAL.so (suporte ao OpenMAX AL 1.0.1)
  • libOpenSLES.so (suporte a áudio do OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (suporte mínimo para C++)
  • libvulkan.so (Vulkan)
  • libz (compactação Zlib)
  • Interface JNI

• [C-0-8] NÃO é permitido adicionar ou remover as funções públicas das bibliotecas nativas listadas acima.

• [C-0-9] É OBRIGATÓRIO listar outras bibliotecas que não são do AOSP expostas diretamente a apps de terceiros em /vendor/etc/public.libraries.txt.

• [C-0-10] NÃO EXPORÃO NENHUM OUTRO TIPO DE BIBLIOTECA NATIVA, IMPLEMENTADA E OFERECIDA NO AOSP COMO BIBLIOTECAS DO SISTEMA, PARA APLICATIVOS DE TERCEIROS DIRIGIDOS AO NÍVEL 24 DA API OU SUPERIOR, POIS ELAS ESTÃO RESERVADAS.

• [C-0-11] É OBRIGATÓRIO exportar todos os símbolos de função do OpenGL ES 3.1 e do Android Extension Pack, conforme definido no NDK, pela biblioteca libGLESv3.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.1 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.

• [C-0-12] É PRECISO exportar símbolos de função para os símbolos de função do núcleo do Vulkan 1.0, bem como as extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 pela biblioteca libvulkan.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.2 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.

• DEVE ser criado usando o código-fonte e os arquivos de cabeçalho disponíveis no projeto upstream do Android Open Source.

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

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

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

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

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

• [C-2-1] PRECISA incluir as linhas a seguir em /proc/cpuinfo e NÃO alterar os valores no mesmo dispositivo, mesmo quando eles são lidos por outras ABIs.

  • Features:, seguido por uma lista de recursos opcionais de CPU ARMv7 compatíveis com o dispositivo.
  • CPU architecture:, seguido por um número inteiro que descreve a arquitetura ARM mais recente com suporte do dispositivo (por exemplo, "8" para dispositivos ARMv8).

• [C-2-2] É PRECISO manter as operações abaixo disponíveis, mesmo quando a ABI é implementada em uma arquitetura ARMv8, seja com suporte a CPU nativa ou emulação de software:

  • Instruções SWP e SWPB.
  • Operações de barreira CP15ISB, CP15DSB e CP15DMB.

• [C-2-3] É PRECISO incluir suporte para a extensão Advanced SIMD (também conhecida como NEON).

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView

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

• [C-1-1] É OBRIGATÓRIO informar android.software.webview.
• [C-1-2] É OBRIGATÓRIO usar o build do projeto Chromium do upstream do Android Open Source Project na ramificação do Android 13 para a implementação da API android.webkit.WebView.

• [C-1-3] A string do user agent informada pela WebView PRECISA estar neste formato:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, como Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
  • A string $(MODEL) PODE estar vazia, mas, se não estiver, ela PRECISA ter o mesmo valor de android.os.Build.MODEL.
  • "Build/$(BUILD)" PODE ser omitido, mas, se estiver presente, a string $(BUILD) PRECISA ser igual ao valor de android.os.Build.ID.
  • O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium no projeto de código aberto do Android upstream.
  • As implementações de dispositivos PODEM omitir "Mobile" na string do user agent.

• O componente WebView PRECISA incluir suporte para o maior número possível de recursos HTML5 e, se ele oferecer suporte ao recurso, PRECISA estar em conformidade com a especificação HTML5.

• [C-1-4] É NECESSÁRIO renderizar o conteúdo fornecido ou o conteúdo do URL remoto em um processo que seja diferente do aplicativo que instancia a WebView. Especificamente, o processo de renderizador separado PRECISA ter privilégios mais baixos, ser executado como um ID de usuário separado, não ter acesso ao diretório de dados do app, não ter acesso direto à rede e ter acesso apenas aos serviços do sistema necessários mínimos pelo Binder. A implementação do AOSP da WebView atende a esse requisito.

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

3.4.2. Compatibilidade de navegadores

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

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

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

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

3.5. Compatibilidade comportamental da API

Implementações de dispositivos:

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

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

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

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

3.5.1. Restrição de aplicativo

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

• [C-1-1] É PRECISO permitir que o usuário veja a lista de apps restritos.
• [C-1-2] É PRECISO oferecer ao usuário a capacidade de ativar / desativar todas essas restrições exclusivas em cada app.

• [C-1-3] É PROIBIDO aplicar automaticamente essas restrições reservadas sem evidências de comportamento de integridade do sistema ruim, mas é PERMITIDO aplicar as restrições em apps após a detecção de comportamento de integridade do sistema ruim, como wakelocks presos, serviços de execução longa e outros critérios. Os critérios podem ser determinados pelos implementadores do dispositivo, mas precisam estar relacionados ao impacto do app na integridade do sistema. Outros critérios que não estejam relacionados apenas à integridade do sistema, como a falta de popularidade do app no mercado, NÃO devem ser usados como critérios.

• [C-1-4] NÃO é permitido aplicar automaticamente essas restrições reservadas a apps quando um usuário desativou as restrições de apps manualmente e PODE sugerir ao usuário que aplique essas restrições reservadas.

• [C-1-5] É OBRIGATÓRIO informar aos usuários se essas restrições de propriedade intelectual são aplicadas a um app automaticamente. Essas informações precisam ser fornecidas no período de 24 horas anterior à aplicação dessas restrições reservadas.

• [C-1-6] PRECISA retornar "true" para o método ActivityManager.isBackgroundRestricted() em todas as chamadas de API de um app.

• [C-1-7] NÃO DEVE restringir o app em primeiro plano que é usado explicitamente pelo usuário.

• [C-1-8] É OBRIGATÓRIO suspender essas restrições proprietárias em um app sempre que um usuário começar a usá-lo explicitamente, tornando-o o aplicativo em primeiro plano principal.

• [C-1-10] É OBRIGATÓRIO fornecer um documento ou site público e claro que descreva como as restrições de propriedade são aplicadas. Esse documento ou site PRECISA ser vinculado nos documentos do SDK do Android e PRECISA incluir:

  • Acionar condições para restrições de propriedade.
  • O que e como um app pode ser restrito.
  • Como um app pode ser isento dessas restrições.
  • Como um app pode solicitar uma isenção de restrições de propriedade, se elas oferecerem essa isenção para apps que o usuário pode instalar.

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

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

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

3.5.2. Hibernação do app

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

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

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

3.6. Namespaces de API

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

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

Ou seja, eles:

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

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

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

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

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

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

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

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

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

3.7. Compatibilidade com o ambiente de execução

Implementações de dispositivos:

• [C-0-1] É PRECISO oferecer suporte ao formato completo do Dalvik Executable (DEX) e à especificação e semântica do bytecode do Dalvik.

• [C-0-2] É OBRIGATÓRIO configurar os ambientes de execução do Dalvik para alocar memória de acordo com a plataforma upstream do Android e conforme especificado na tabela a seguir. Consulte a seção 7.1.1 para definições de tamanho e densidade da tela.

• DEVE usar o Android RunTime (ART), a implementação upstream de referência do formato executável Dalvik e o sistema de gerenciamento de pacotes da implementação de referência.

• EXECUTAR testes de fuzz em vários modos de execução e arquiteturas de destino para garantir a estabilidade do ambiente de execução. Consulte JFuzz e DexFuzz no site do Android Open Source Project.

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

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

3.8. Compatibilidade com a interface do usuário

3.8.1. Acesso rápido (tela inicial)

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. Widgets

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

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

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

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

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

3.8.3. Notificações

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

3.8.3.1. Apresentação das notificações

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

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

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

Implementações de dispositivos:

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

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

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

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

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

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

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

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

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

Implementações de dispositivos:

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

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

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

3.8.3.3. Modo "Não perturbe"/Prioridade

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

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

3.8.4. APIs Assist

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

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

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

3.8.5. Alertas e avisos

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

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

• [C-1-1] É necessário fornecer uma característica para o usuário impedir que um app exiba janelas de alerta que usam o TYPE_APPLICATION_OVERLAY. A implementação do AOSP atende a esse requisito com controles na sombra de notificação.

• [C-1-2] É OBRIGATÓRIO honrar a API Toast e exibir notificações do aplicativo para os usuários finais de maneira muito visível.

3.8.6. Temas

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

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

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

• [C-1-1] NENHUM dos atributos do tema Holo expostos aos aplicativos PODE SER ALTERADO.
• [C-1-2] PRECISA oferecer suporte à família de temas "Material" e NÃO pode alterar nenhum dos atributos do tema do Material Design ou os recursos expostos aos aplicativos.

• [C-1-3] É OBRIGATÓRIO definir a família de fontes "sans-serif" como Roboto versão 2.x para os idiomas com suporte a Roboto ou fornecer uma característica para o usuário mudar a fonte usada para a família de fontes "sans-serif" como Roboto versão 2.x para os idiomas com suporte a Roboto.

• [C-1-4] É OBRIGATÓRIO gerar paletas de tons de cores dinâmicas, conforme especificado na documentação do AOSP de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.system_palette e android.theme.customization.theme_style).

• [C-1-5] É NECESSÁRIO gerar paletas de tons de cores dinâmicas usando estilos de tema de cores enumerados na documentação Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.theme_styles), ou seja, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD.

  "Cor de origem" usada para gerar paletas de tons de cores dinâmicas quando enviada com android.theme.customization.system_palette (como documentado em Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

• [C-1-6] É PRECISO ter um valor de croma CAM16 de 5 ou maior.

  • DEVE ser derivado do plano de fundo por meio de com.android.systemui.monet.ColorScheme#getSeedColors, que fornece várias cores de origem válidas para escolher uma.

  • DEVE usar o valor 0xFF1B6EF3 se nenhuma das cores fornecidas atender ao requisito de cor de origem acima.

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

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

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

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

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

3.8.7. Planos fundo interativos

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

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

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

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

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

3.8.8. Troca de atividades

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

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

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

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

3.8.9. Gerenciamento de entrada

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

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

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

3.8.10. Controle de mídia na tela de bloqueio

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

3.8.11. Protetores de tela (antes chamados de Sonhos)

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

3.8.12. Local

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

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

3.8.13. Unicode e fonte

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

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

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

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

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

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

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

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

3.8.14. Várias janelas

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

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

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

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

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

• [C-3-1] É OBRIGATÓRIO iniciar atividades no modo picture-in-picture em várias janelas quando o app: * Segmenta o nível 26 da API ou mais recente e declara android:supportsPictureInPicture * Segmenta o nível 25 da API ou versões anteriores e declara android:resizeableActivity e android:supportsPictureInPicture.
• [C-3-2] É OBRIGATÓRIO expor as ações no SystemUI conforme especificado pela atividade PIP atual pela API setActions().
• [C-3-3] É PRECISO oferecer suporte a proporções maiores ou iguais a 1:2,39 e menores ou iguais a 2,39:1, conforme especificado pela atividade PIP pela API setAspectRatio().
• [C-3-4] É OBRIGATÓRIO usar KeyEvent.KEYCODE_WINDOW para controlar a janela PIP. Se o modo PIP não for implementado, a chave PRECISA estar disponível para a atividade em primeiro plano.
• [C-3-5] É necessário fornecer uma affordance do usuário para impedir que um app seja exibido no modo PIP. A implementação do AOSP atende a esse requisito com controles na sombra de notificação.

• [C-3-6] É NECESSÁRIO alocar a seguinte largura e altura mínima para a janela PIP quando um aplicativo não declarar nenhum valor para AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight:

  • Dispositivos com o Configuration.uiMode definido como diferente de UI_MODE_TYPE_TELEVISION PRECISAM alocar uma largura e altura mínimas de 108 dp.
  • Dispositivos com o Configuration.uiMode definido como UI_MODE_TYPE_TELEVISION PRECISAM alocar uma largura mínima de 240 dp e uma altura mínima de 135 dp.

3.8.15. Corte de tela

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

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

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

3.8.16. Controles do dispositivo

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

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

3.8.17. Área de transferência

Implementações de dispositivos:

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

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

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

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

3.9. Administração do dispositivo

O Android inclui recursos que permitem que aplicativos com segurança executem funções de administração de dispositivos no nível do sistema, como a aplicação de políticas de senha ou a exclusão remota, usando a API Android Device Administration.

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

• [C-1-1] É OBRIGATÓRIO declarar android.software.device_admin.
• [C-1-2] É PRECISO oferecer suporte ao provisionamento de proprietários de dispositivos, conforme descrito na seção 3.9.1 e seção 3.9.1.1.

3.9.1 Provisionamento de dispositivo

3.9.1.1 Provisionamento de proprietário do dispositivo

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

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

Se as implementações do dispositivo declararem android.software.device_admin, mas também incluírem uma solução de gerenciamento de dispositivo reservada e fornecerem um mecanismo para promover um aplicativo configurado na solução como um "equivalente ao proprietário do dispositivo" ao padrão "proprietário do dispositivo" reconhecido pelas APIs DevicePolicyManager do Android padrão, elas:

• [C-2-1] É PRECISO ter um processo em vigor para verificar se o app específico que está sendo promovido pertence a uma solução legítima de gerenciamento de dispositivos corporativos e foi configurado na solução proprietária para ter direitos equivalentes como "proprietário do dispositivo".
• [C-2-2] É PRECISO mostrar a mesma declaração de consentimento do proprietário do dispositivo do AOSP que o fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o aplicativo DPC como "proprietário do dispositivo".
• [C-2-3] O consentimento não pode ser codificado rigidamente nem impedir o uso de outros apps de proprietário do dispositivo.

3.9.1.2 Provisionamento de perfil gerenciado

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

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

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

• [C-1-3] É OBRIGATÓRIO fornecer as seguintes características de usuário nas Configurações para indicar ao usuário quando uma função específica do sistema foi desativada pelo Controlador de política de dispositivo (DPC):

  • Um ícone consistente ou outra característica de uso (por exemplo, o ícone de informações do AOSP upstream) para representar quando uma configuração específica é restrita por um administrador de dispositivos.
  • Uma mensagem de explicação curta, fornecida pelo administrador do dispositivo pelo setShortSupportMessage.
  • Ícone do aplicativo DPC.

• [C-1-4] É OBRIGATÓRIO iniciar o gerenciador da intent ACTION_PROVISIONING_SUCCESSFUL no perfil de trabalho se um proprietário de perfil for estabelecido quando o provisionamento for iniciado pela intent android.app.action.PROVISION_MANAGED_PROFILE e o DPC tiver implementado o gerenciador.

• [C-1-5] É PRECISO enviar a transmissão ACTION_PROFILE_PROVISIONING_COMPLETE para o DPC do perfil de trabalho quando o provisionamento for iniciado pela intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-6] É PRECISO enviar a intent ACTION_GET_PROVISIONING_MODE depois que o provisionamento do proprietário do perfil for acionado para que o app DPC possa escolher se quer se tornar um proprietário do dispositivo ou do perfil, exceto quando o provisionamento for acionado pela intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] É PRECISO enviar a intent ACTION_ADMIN_POLICY_COMPLIANCE para o perfil de trabalho quando um proprietário de perfil é estabelecido durante o provisionamento, independentemente do método de provisionamento usado, exceto quando o provisionamento é acionado pela intent android.app.action.PROVISION_MANAGED_PROFILE. O usuário não pode prosseguir no assistente de configuração até que o app de proprietário de perfil seja concluído.

• [C-1-8] É PRECISO enviar a transmissão ACTION_MANAGED_PROFILE_PROVISIONED para o DPC do perfil pessoal quando um proprietário de perfil for estabelecido, independentemente do método de provisionamento usado.

3.9.2 Suporte a perfis gerenciados

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

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

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

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

3.9.3 Suporte gerenciado ao usuário

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

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

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

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

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

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

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

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

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

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

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

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

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

3.10. Acessibilidade

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

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

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

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

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

3.11. Conversão de texto em voz

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

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

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

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

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

3.12. TV Input Framework

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

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

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

3.13. Configurações rápidas

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

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

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

3.14. Interface de mídia

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

• [C-1-2] É PRECISO mostrar claramente os ícones recebidos por getIconBitmap() ou getIconUri() e os títulos recebidos por getTitle(), conforme descrito em MediaDescription. Pode encurtar títulos para obedecer a regulamentações de segurança (por exemplo, distração do motorista).

• [C-1-3] É OBRIGATÓRIO mostrar o ícone do aplicativo de terceiros sempre que conteúdo fornecido por esse aplicativo for exibido.

• [C-1-4] É OBRIGATÓRIO permitir que o usuário interaja com toda a hierarquia de MediaBrowser. PODE restringir o acesso a parte da hierarquia para obedecer a regulamentos de segurança (por exemplo, distração do motorista), mas NÃO PODE dar tratamento preferencial com base no conteúdo ou no provedor de conteúdo.

• [C-1-5] É PRECISO considerar o toque duplo de KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent.

3.15. Instant Apps

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

• [C-1-1] Os apps instantâneos PRECISAM receber apenas permissões com o android:protectionLevel definido como "instant".
• [C-1-2] Os apps instantâneos NÃO PODEM interagir com apps instalados por meio de intenções implícitas a menos que uma das seguintes condições seja verdadeira:
  • O filtro de padrão de intent do componente é exposto e tem CATEGORY_BROWSABLE
  • A ação é uma das seguintes: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE.
  • O destino é exposto explicitamente com android:visibleToInstantApps
• [C-1-3] Os apps instantâneos NÃO PODEM interagir explicitamente com apps instalados, a menos que o componente seja exposto por android:visibleToInstantApps.
• [C-1-4] Os apps instalados NÃO PODEM ver detalhes sobre apps instantâneos no dispositivo, a menos que o app instantâneo se conecte explicitamente ao aplicativo instalado.

• As implementações de dispositivos precisam fornecer as seguintes características para o usuário interagir com os apps instantâneos. O AOSP atende aos requisitos com a interface do sistema, as configurações e o iniciador padrão. Implementações de dispositivos:

  • [C-1-5] É OBRIGATÓRIO fornecer uma ação do usuário para visualizar e excluir apps instantâneos armazenados em cache localmente para cada pacote de app individual.
  • [C-1-6] É necessário fornecer uma notificação persistente do usuário que possa ser reduzida enquanto um app instantâneo está em execução em primeiro plano. Essa notificação precisa incluir que os apps instantâneos não exigem instalação e fornecer um affordance que direcione o usuário para a tela de informações do aplicativo nas Configurações. Para apps instantâneos iniciados por intents da Web, conforme definido usando uma intent com a ação definida como Intent.ACTION_VIEW e com um esquema de "http" ou "https", uma característica adicional do usuário DEVE permitir que o usuário não inicie o app instantâneo e abra o link associado com o navegador da Web configurado, se um navegador estiver disponível no dispositivo.
  • [C-1-7] É PRECISO permitir que os apps instantâneos em execução sejam acessados pela função Recentes se ela estiver disponível no dispositivo.

• [C-1-8] É OBRIGATÓRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para as intents listadas no SDK aqui e tornar as intents visíveis para apps instantâneos.

3.16. Pareamento de dispositivo complementar

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

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

• [C-1-1] É PRECISO declarar a flag de recurso FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] É OBRIGATÓRIO garantir que as APIs no pacote android.companion sejam totalmente implementadas.
• [C-1-3] É PRECISO fornecer recursos para o usuário selecionar/confirmar que um dispositivo complementar está presente e operacional.

3.17. Apps pesados

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

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

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

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

3.18. Contatos

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

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

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

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

Implementações de dispositivos:

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

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

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

4. Compatibilidade de empacotamento de apps

Implementações de dispositivos:

• [C-0-1] PRECISA ser capaz de instalar e executar arquivos ".apk" do Android conforme gerados pela ferramenta "aapt" incluída no SDK oficial do Android.

  • Como o requisito acima pode ser desafiador, é RECOMENDADO que as implementações de dispositivos usem o sistema de gerenciamento de pacotes da implementação de referência do AOSP.

• [C-0-2] É PRECISO oferecer suporte à verificação de arquivos ".apk" usando o esquema de assinatura de APK v3.1, esquema de assinatura de APK v3, esquema de assinatura de APK v2 e assinatura JAR.

• [C-0-3] NÃO É PERMITIDO estender os formatos .apk, Android Manifest, bytecode do Dalvik ou bytecode do RenderScript de forma que impeça a instalação e a execução correta desses arquivos em outros dispositivos compatíveis.

• [C-0-4] NÃO É PERMITIDO que apps, exceto o "instalador de registro" atual do pacote, desinstalem o app silenciosamente sem nenhuma confirmação do usuário, conforme documentado no SDK para a permissão DELETE_PACKAGE. As únicas exceções são o app verificador de pacotes do sistema que processa a intent PACKAGE_NEEDS_VERIFICATION e o app gerenciador de armazenamento que processa a intent ACTION_MANAGE_STORAGE.

• [C-0-5] PRECISA ter uma atividade que processe a intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• [C-0-6] NÃO PODE instalar pacotes de aplicativos de origens desconhecidas, a menos que o app que solicita a instalação cumpra todos os requisitos a seguir:

  • Ele PRECISA declarar a permissão REQUEST_INSTALL_PACKAGES ou ter o android:targetSdkVersion definido como 24 ou menos.
  • O usuário precisa ter concedido permissão para instalar apps de fontes desconhecidas.

• DEVE fornecer uma capacidade do usuário para conceder/revogar a permissão para instalar apps de fontes desconhecidas por aplicativo, mas PODE escolher implementar isso como uma operação nula e retornar RESULT_CANCELED para startActivityForResult(), se a implementação do dispositivo não quiser permitir que os usuários tenham essa escolha. No entanto, mesmo nesses casos, eles DEVEM indicar ao usuário por que essa opção não está sendo apresentada.

• [C-0-7] É OBRIGATÓRIO mostrar uma caixa de diálogo de aviso com a string de aviso que é fornecida pelo PackageManager.setHarmfulAppWarning da API do sistema ao usuário antes de iniciar uma atividade em um aplicativo que foi marcado pela mesma API do sistema PackageManager.setHarmfulAppWarning como potencialmente prejudicial.

• DEVE fornecer uma capacidade para o usuário escolher desinstalar ou iniciar um aplicativo na caixa de diálogo de aviso.

• [C-0-8] É PRECISO implementar suporte para o sistema de arquivos incrementais, conforme documentado aqui.

• [C-0-9] PRECISA oferecer suporte à verificação de arquivos .apk usando o Esquema de assinatura de APK v4 e o Esquema de assinatura de APK v4.1.

Observação: as implementações de dispositivos enviados com o Android versão 10 ou anterior que não atendem aos requisitos [C-0-8] e [C-0-9] por meio de uma atualização do software do sistema podem ser isentos desses requisitos.

5. Compatibilidade com multimídia

Implementações de dispositivos:

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

Implementações de dispositivos:

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

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

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

5.1. Codecs de mídia

5.1.1. Codificação de áudio

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

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

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

Todos os codificadores de áudio precisam ter suporte a:

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

5.1.2. Decodificação de áudio

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1.3. Detalhes dos codecs de áudio

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

5.1.4. Codificação de imagem

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

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

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

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

• [C-1-1] É necessário fornecer um codec de codificador HEVC com aceleração de hardware que ofereça suporte ao modo de controle de taxa de bits BITRATE_MODE_CQ, ao perfil HEVCProfileMainStill e ao tamanho de 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 oferecer suporte à decodificação da seguinte codificação de imagem:

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Bruto

Se as implementações do dispositivo oferecerem suporte à decodificação de vídeo HEVC, elas: * [C-1-1] PRECISAM oferecer suporte à decodificação de imagem HEIF (HEIC).

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

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

5.1.6. Detalhes dos codecs de imagem

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

Codificadores e decodificadores de imagem expostos pela API MediaCodec

• [C-1-1] É PRECISO oferecer suporte ao formato de cor flexível YUV420 8:8:8 (COLOR_FormatYUV420Flexible) por meio de CodecCapabilities.

• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao formato de cor RGB888 para o modo de entrada da Surface.

• [C-1-3] É OBRIGATÓRIO oferecer suporte a pelo menos um formato de cor planar ou semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). É ALTAMENTE RECOMENDÁVEL oferecer suporte a ambos.

5.1.7. Codecs de vídeo

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

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

• [C-1-1] Os codecs de vídeo precisam ter suporte a tamanhos de buffer de bytes de saída e entrada que aceitem o maior frame possível compactado e descompactado, conforme determinado pelo padrão e pela configuração, mas sem alocar em excesso.

• [C-1-2] Os codificadores e decodificadores de vídeo PRECISAM oferecer suporte aos formatos de cor flexível YUV420 8:8:8 (COLOR_FormatYUV420Flexible) por meio de CodecCapabilities.

• [C-1-3] Os codificadores e decodificadores de vídeo PRECISAM oferecer suporte a pelo menos um formato de cor planar ou semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). É ALTAMENTE RECOMENDÁVEL que eles ofereçam suporte a ambos.

• [C-SR-1] É ALTAMENTE RECOMENDÁVEL que os codificadores e decodificadores de vídeo ofereçam suporte a pelo menos um dos formatos de cor planar ou semiplanar YUV420 8:8:8 otimizado para hardware (YV12, NV12, NV21 ou formato otimizado para o fornecedor equivalente).

• [C-1-5] Os decodificadores de vídeo que oferecem suporte a um formato de alta profundidade de bits (9 bits ou mais por canal) PRECISAM oferecer suporte à saída de um formato equivalente de 8 bits, se solicitado pelo aplicativo. Isso PRECISA ser refletido com suporte a um formato de cor YUV420 8:8:8 por android.media.MediaCodecInfo.

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

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

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

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

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

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

5.1.8. Lista de codecs de vídeo

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

5.1.9. Segurança do codec de mídia

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

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

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

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

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

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

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

• [C-3-1] É OBRIGATÓRIO incluir o codec de software Codec 2.0 correspondente do Projeto de código aberto do Android (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) aceito pelo dispositivo.
• [C-3-2] É OBRIGATÓRIO hospedar os codecs de software Codec 2.0 no processo de codec de software, conforme fornecido no Projeto de código aberto do Android, para permitir o acesso mais restrito a codecs de software.
• [C-3-3] Codecs que têm nomes que começam com "c2.android". PRECISAM ser baseadas no código-fonte do Projeto Android Open Source.

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

Se as implementações do dispositivo oferecerem suporte a codecs de mídia, elas:

• [C-1-1] PRECISA retornar valores corretos de caracterização do codec de mídia pela API MediaCodecInfo.

Especificamente, as seguintes:

• [C-1-2] Codecs com nomes que começam com "OMX." É OBRIGATÓRIO usar as APIs OMX e ter nomes que estejam em conformidade com as diretrizes de nomenclatura do OMX IL.
• [C-1-3] Codecs com nomes que começam com "c2". PRECISA usar a API Codec 2.0 e ter nomes que estejam em conformidade com as diretrizes de nomenclatura do Codec 2.0 para Android.
• [C-1-4] Codecs com nomes que começam com "OMX.google." ou "c2.android." NÃO pode ser caracterizado como fornecedor ou com aceleração de hardware.
• [C-1-5] Codecs executados em um processo de codec (fornecedor ou sistema) que tenham acesso a drivers de hardware, exceto alocadores de memória e mapeadores, NÃO podem ser caracterizados como somente software.
• [C-1-6] Os codecs que não estão presentes no Android Open Source Project ou não são baseados no código-fonte desse projeto PRECISAM ser caracterizados como fornecedor.
• [C-1-7] Os codecs que usam aceleração de hardware precisam ser caracterizados como acelerados por hardware.
• [C-1-8] Os nomes dos codecs NÃO podem ser enganosos. Por exemplo, codecs com o nome "decoders" precisam ter suporte à decodificação, e aqueles com o nome "encoders" precisam ter suporte à codificação. Os codecs com nomes que contêm formatos de mídia precisam ter suporte a esses formatos.

Se as implementações do dispositivo oferecerem suporte a codecs de vídeo:

• [C-2-1] Todos os codecs de vídeo precisam publicar dados de taxa de frames alcançáveis para os seguintes tamanhos, se o codec oferecer suporte:

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (codificador MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (outro)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (codificador MPEG4) 720 x 480 px (outro)	1408 x 1152 px (H263) 1280 x 720 px (outro)	1920 x 1080 px (exceto MPEG4)	3840 x 2160 px (HEVC, VP9)

• [C-2-2] Os codecs de vídeo caracterizados como acelerados por hardware precisam publicar informações de pontos de desempenho. Elas PRECISAM listar todos os pontos de desempenho padrão com suporte (listados na API PerformancePoint), a menos que sejam cobertos por outro ponto de desempenho padrão com suporte.
• Além disso, eles precisam publicar pontos de performance estendidos se oferecerem suporte a performance de vídeo sustentada diferente de um dos padrões listados.

5.2. Codificação de vídeo

Se as implementações de dispositivos oferecerem suporte a qualquer codificador de vídeo e o disponibilizarem para apps de terceiros, elas:

• NÃO deve ser, em duas janelas deslizantes, mais de 15% do bitrate entre intervalos intraframe (I-frame).
• NÃO pode ser mais de 100% do que o bitrate em uma janela deslizante de 1 segundo.

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

• [C-1-1] É PRECISO incluir o suporte a pelo menos um dos codificadores de vídeo VP8 ou H.264 e disponibilizá-lo para aplicativos de terceiros.
• DEVE oferecer suporte aos codificadores de vídeo VP8 e H.264 e disponibilizá-los para aplicativos de terceiros.

Se as implementações de dispositivos oferecerem suporte a qualquer um dos codificadores de vídeo H.264, VP8, VP9 ou HEVC e disponibilizá-los para aplicativos de terceiros, elas:

• [C-2-1] É PRECISO oferecer suporte a taxas de bits configuráveis dinamicamente.
• DEVE oferecer suporte a taxas de frames variáveis, em que o codificador de vídeo DEVE determinar a duração instantânea do frame com base nos carimbos de data/hora dos buffers de entrada e alocar o bucket de bits com base nessa duração.

Se as implementações de dispositivos oferecerem suporte ao codificador de vídeo MPEG-4 SP e o disponibilizarem para apps de terceiros, elas:

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

Se as implementações do dispositivo oferecem codificadores de vídeo ou imagem com aceleração de hardware e oferecem suporte a uma ou mais câmeras de hardware anexadas ou conectadas expostas pelas APIs android.camera:

• [C-4-1] Todos os codificadores de vídeo e imagem com aceleração de hardware precisam oferecer suporte à codificação de frames das câmeras de hardware.
• DEVE oferecer suporte à codificação de frames das câmeras de hardware em todos os codificadores de vídeo ou imagem.

Se as implementações do dispositivo oferecerem codificação HDR, elas:

• [C-SR-1] É ALTAMENTE RECOMENDADO fornecer um plug-in para a API de transcodificação perfeita para converter do formato HDR para SDR.

5.2.1. H.263

Se as implementações de dispositivos oferecerem suporte a codificadores H.263 e os disponibilizarem para apps de terceiros, elas:

• [C-1-1] É PRECISO oferecer suporte ao nível 45 do perfil de referência.
• DEVE oferecer suporte a taxas de bits configuráveis dinamicamente para o codificador compatível.

5.2.2. H.264

Se as implementações de dispositivos oferecem suporte ao codec H.264, elas:

• [C-1-1] É PRECISO oferecer suporte ao perfil de referência de nível 3. No entanto, o suporte a ASO (ordenação arbitrária de fatias), FMO (ordenação flexível de macroblocos) e RS (fatias redundantes) é OPCIONAL. Além disso, para manter a compatibilidade com outros dispositivos Android, é RECOMENDÁVEL que ASO, FMO e RS não sejam usados para o perfil de referência pelos codificadores.
• [C-1-2] É PRECISO oferecer suporte aos perfis de codificação de vídeo SD (definição padrão) na tabela a seguir.
• DEVE oferecer suporte ao nível 4 do perfil principal.
• DEVE oferecer suporte aos perfis de codificação de vídeo em HD (alta definição), conforme indicado na tabela a seguir.

Se as implementações de dispositivos informarem suporte à codificação H.264 para vídeos de resolução 720p ou 1080p pelas APIs de mídia, elas:

• [C-2-1] É PRECISO oferecer suporte aos perfis de codificação na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 240 px	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	20 qps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

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

• [C-1-1] PRECISA oferecer suporte aos perfis de codificação de vídeo SD.
• DEVE oferecer suporte aos seguintes perfis de codificação de vídeo em HD (alta definição).
• [C-1-2] É PRECISO oferecer suporte à gravação de arquivos WebM do Matroska.
• DEVEM fornecer um codec VP8 de hardware que atenda aos requisitos de codificação de hardware do RTC do projeto WebM, para garantir qualidade aceitável de streaming de vídeo na Web e serviços de videoconferência.

Se as implementações de dispositivos informarem suporte à codificação VP8 para vídeos com resolução de 720p ou 1080p pelas APIs de mídia, elas:

• [C-2-1] É PRECISO oferecer suporte aos perfis de codificação na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 180 px	640 x 360 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	800 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.4. VP9

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

• [C-1-2] É PRECISO oferecer suporte ao perfil 0 de nível 3.
• [C-1-1] É PRECISO oferecer suporte à gravação de arquivos WebM do Matroska.
• [C-1-3] É PRECISO gerar dados CodecPrivate.
• DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.
• [C-SR-1] RECOMENDA-SE FORTEMENTE o suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.

	SD	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se as implementações do dispositivo afirmarem oferecer suporte ao Perfil 2 ou 3 pelas APIs de mídia:

• O suporte ao formato de 12 bits é OPCIONAL.

5.2.5. H.265

Se as implementações de dispositivos oferecerem suporte ao codec H.265, elas:

• [C-1-1] É PRECISO oferecer suporte ao nível 3 do perfil principal.
• DEVE oferecer suporte aos perfis de codificação em HD, conforme indicado na tabela a seguir.
• [C-SR-1] RECOMENDA-SE FORTEMENTE o suporte aos perfis de codificação em HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.

	SD	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3. Decodificação de vídeo

Se as implementações de dispositivos oferecerem suporte aos codecs VP8, VP9, H.264 ou H.265, elas:

• [C-1-1] É NECESSÁRIO oferecer suporte à resolução dinâmica de vídeo e à alternância de frame rate por meio das APIs padrão do Android no mesmo fluxo para todos os codecs VP8, VP9, H.264 e H.265 em tempo real e com a resolução máxima compatível com cada codec no dispositivo.

5.3.1. MPEG-2

Se as implementações de dispositivos oferecerem suporte a decodificadores MPEG-2, elas:

• [C-1-1] PRECISA oferecer suporte ao nível alto do perfil principal.

5.3.2. H.263

Se as implementações de dispositivos oferecerem suporte a decodificadores H.263, elas:

• [C-1-1] É PRECISO oferecer suporte ao nível 30 e 45 do perfil de referência.

5.3.3. MPEG-4

Se as implementações do dispositivo tiverem decodificadores MPEG-4, elas:

• [C-1-1] É PRECISO oferecer suporte ao perfil simples de nível 3.

5.3.4. H.264

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

• [C-1-1] É PRECISO oferecer suporte ao perfil principal de nível 3.1 e ao perfil de referência. O suporte para ASO (ordenação arbitrária de fatias), FMO (ordenação flexível de macroblocos) e RS (fatias redundantes) é OPCIONAL.
• [C-1-2] PRECISA ser capaz de decodificar vídeos com os perfis SD (definição padrão) listados na tabela a seguir e codificados com o perfil de referência e o perfil principal de nível 3.1 (incluindo 720p30).
• DEVE ser capaz de decodificar vídeos com os perfis de alta definição (HD, na sigla em inglês) conforme indicado na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, as implementações do dispositivo:

• [C-2-1] É PRECISO oferecer suporte aos perfis de decodificação de vídeo HD 720p na tabela a seguir.
• [C-2-2] É PRECISO oferecer suporte aos perfis de decodificação de vídeo HD 1080p na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 240 px	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	30 fps	30 fps	60 qps	30 qps (60 qps^televisão)
Taxa de bits do vídeo	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

Se as implementações de dispositivos oferecerem suporte ao codec H.265, elas:

• [C-1-1] É PRECISO oferecer suporte ao nível principal do perfil principal de nível 3 e aos perfis de decodificação de vídeo SD conforme indicado na tabela a seguir.
• DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.
• [C-1-2] É PRECISO oferecer suporte aos perfis de decodificação em HD conforme indicado na tabela abaixo, se houver um decodificador de hardware.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, faça o seguinte:

• [C-2-1] As implementações de dispositivos precisam oferecer suporte a pelo menos uma das decodificações H.265 ou VP9 dos perfis 720p, 1080p e UHD.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	352 x 288 px	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30/60 fps (60 fps^TV com decodificador de hardware H.265)	60 qps
Taxa de bits do vídeo	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se as implementações do dispositivo afirmarem que oferecem suporte a um perfil HDR pelas APIs de mídia:

• [C-3-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR necessários do aplicativo, além de oferecer suporte à extração e saída dos metadados HDR necessários do fluxo de bits e/ou contêiner.
• [C-3-2] As implementações de dispositivos PRECISAM exibir conteúdo HDR corretamente na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

5.3.6. VP8

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

• [C-1-1] É PRECISO oferecer suporte aos perfis de decodificação SD na tabela a seguir.
• DEVE usar um codec VP8 de hardware que atenda aos requisitos.
• DEVE oferecer suporte aos perfis de decodificação em HD na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, faça o seguinte:

• [C-2-1] As implementações de dispositivos precisam oferecer suporte a perfis de 720p na tabela a seguir.
• [C-2-2] As implementações de dispositivos precisam oferecer suporte a perfis de 1080p na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 180 px	640 x 360 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	30 fps	30 fps	30 qps (60 qps^televisão)	30 (60 fps^Televisão)
Taxa de bits do vídeo	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

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

• [C-1-1] PRECISA oferecer suporte aos perfis de decodificação de vídeo SD conforme indicado na tabela a seguir.
• DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.

Se as implementações de dispositivos forem compatíveis com o codec VP9 e um decodificador de hardware:

• [C-2-1] É PRECISO oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, faça o seguinte:

• [C-3-1] As implementações de dispositivos precisam oferecer suporte a pelo menos um dos decodificadores VP9 ou H.265 dos perfis 720p, 1080p e UHD.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	320 x 180 px	640 x 360 px	1.280 x 720 px	1.920 x 1.080 px	3840 x 2160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps (60 fps^TV com decodificação de hardware VP9)	60 qps
Taxa de bits do vídeo	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se as implementações do dispositivo afirmarem que oferecem suporte a VP9Profile2 ou VP9Profile3 pelas APIs de mídia CodecProfileLevel, faça o seguinte:

• O suporte ao formato de 12 bits é OPCIONAL.

Se as implementações do dispositivo afirmarem ter suporte a um perfil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) pelas APIs de mídia:

• [C-4-1] As implementações de dispositivos precisam aceitar os metadados HDR necessários (KEY_HDR_STATIC_INFO para todos os perfis HDR, bem como 'KEY_HDR10_PLUS_INFO' para perfis HDR10Plus) do aplicativo. Eles também precisam oferecer suporte à extração e saída dos metadados HDR necessários do fluxo de bits e/ou contêiner.
• [C-4-2] As implementações de dispositivos PRECISAM mostrar conteúdo HDR corretamente na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

5.3.8. Dolby Vision

Se as implementações do dispositivo declararem suporte ao decodificador Dolby Vision usando HDR_TYPE_DOLBY_VISION, elas:

• [C-1-1] É PRECISO fornecer um extrator com tecnologia Dolby Vision.
• [C-1-2] É NECESSÁRIO exibir corretamente o conteúdo do Dolby Vision na tela do dispositivo ou em uma porta de saída de vídeo padrão, como HDMI.
• [C-1-3] É PRECISO definir o ID da faixa das camadas básicas compatíveis com versões anteriores (se houver) para que ele seja igual ao ID da faixa da camada Dolby Vision combinada.

5.3.9. AV1

Se as implementações do dispositivo oferecerem suporte ao codec AV1, elas:

• [C-1-1] É PRECISO oferecer suporte ao Perfil 0, incluindo conteúdo de 10 bits.

5.4. Gravação em áudio

Embora alguns dos requisitos descritos nesta seção sejam listados como DEVE desde o Android 4.3, a definição de compatibilidade para versões futuras está planejada para mudar para OBRIGATÓRIO. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos listados como "DEVE", ou não será possível alcançar a compatibilidade com o Android quando eles forem atualizados para a versão futura.

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

Se as implementações do dispositivo declararem android.hardware.microphone, elas:

• [C-1-1] É OBRIGATÓRIO permitir a captura de conteúdo de áudio bruto para qualquer stream de ENTRADA AudioRecord ou AAudio que seja aberto com sucesso. No mínimo, as seguintes características precisam ser compatíveis:

  • Formato:PCM linear, 16 bits
  • Taxas de amostragem:8.000, 11.025, 16.000, 44.100, 48.000 Hz
  • Canais:mono
  • Fontes de áudio:DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. Isso também se aplica às predefinições de entrada equivalentes em AAudio, por exemplo, AAUDIO_INPUT_PRESET_CAMCORDER.

• DEVE permitir a captura de conteúdo de áudio bruto com as seguintes características:

  • Formato: PCM linear, de 16 e 24 bits
  • Taxas de amostragem: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 Hz
  • Canais: o mesmo número de canais que o número de microfones no dispositivo.

• [C-1-2] É NECESSÁRIO capturar acima das taxas de amostragem sem upsampling.

• [C-1-3] É necessário incluir um filtro anti-aliasing adequado quando as taxas de amostragem fornecidas acima forem capturadas com redução de amostragem.

• DEVE permitir a captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, o que significa as seguintes características:

  • Formato: PCM linear, 16 bits
  • Taxas de amostragem: 22.050, 48.000 Hz
  • Canais: estéreo

• [C-1-4] É PRECISO honrar a API MicrophoneInfo e preencher corretamente as informações dos microfones disponíveis no dispositivo acessíveis aos aplicativos de terceiros pela API AudioManager.getMicrophones(), para AudioRecord ativo usando MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE.

Se as implementações de dispositivos permitirem a captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, elas:

• [C-2-1] É PRECISO capturar sem upsampling em qualquer proporção maior que 16000:22050 ou 44100:48000.
• [C-2-2] É OBRIGATÓRIO incluir um filtro anti-aliasing adequado para qualquer upsampling ou downsampling.

5.4.2. Captura para reconhecimento de voz

Se as implementações do dispositivo declararem android.hardware.microphone, elas:

• [C-1-1] É OBRIGATÓRIO capturar a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION em uma das taxas de amostragem, 44100 e 48000.
• [C-1-2] É OBRIGATÓRIO desativar, por padrão, qualquer processamento de áudio de redução de ruído ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.

• [C-1-3] É OBRIGATÓRIO desativar por padrão qualquer controle de ganho automático ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.

• DEVEM apresentar características aproximadamente planas de amplitude versus frequência na faixa de frequência média: especificamente ±3dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.

• [C-SR-1] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de frequência baixa: especificamente de ±20 dB de 30 Hz a 100 Hz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.

• [C-SR-2] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de frequência alta: especificamente de ±30 dB de 4.000 Hz a 22 KHz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.

• DEVERÁ definir a sensibilidade de entrada de áudio de modo que uma fonte de tom senoidal de 1000 Hz tocada a 90 dB de nível de pressão sonora (SPL, na sigla em inglês) (medido ao lado do microfone) produza uma resposta ideal de RMS 2500 em um intervalo de 1770 e 3530 para 16 amostras de bits (ou -22,35 dB ±3dB de escala completa para ponto flutuante/amostras de precisão dupla) para cada microfone usado para gravar a fonte de áudio do reconhecimento de voz.

• DEVE gravar o stream de áudio de reconhecimento de voz para que os níveis de amplitude PCM acompanhem linearmente as mudanças de SPL de entrada em pelo menos um intervalo de 30 dB de -18 dB a +12 dB em relação a 90 dB SPL no microfone.

• DEVE gravar o fluxo de áudio de reconhecimento de voz com distorção harmônica total (THD, na sigla em inglês) menor que 1% para 1 kHz em 90 dB SPL de nível de entrada no microfone.

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

• [C-2-1] PRECISA permitir que esse efeito de áudio seja controlável com a API android.media.audiofx.NoiseSuppressor.
• [C-2-2] É OBRIGATÓRIO identificar exclusivamente cada implementação de tecnologia de supressão de ruído pelo campo AudioEffect.Descriptor.uuid.

5.4.3. Captura para redirecionamento da reprodução

A classe android.media.MediaRecorder.AudioSource inclui a fonte de áudio REMOTE_SUBMIX.

Se as implementações do dispositivo declararem android.hardware.audio.output e android.hardware.microphone, elas:

• [C-1-1] É PRECISO implementar corretamente a fonte de áudio REMOTE_SUBMIX para que, quando um aplicativo use a API android.media.AudioRecord para gravar dessa fonte de áudio, ele capture uma mistura de todos os streams de áudio, exceto os seguintes:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. Cancelamento de eco acústico

Se as implementações do dispositivo declararem android.hardware.microphone, elas:

• DEVE implementar uma tecnologia de cancelamento de eco acústico (AEC) ajustada para comunicação por voz e aplicada ao caminho de captura ao capturar usando AudioSource.VOICE_COMMUNICATION.

Se as implementações do dispositivo fornecerem um Acoustic Echo Canceler que é inserido no caminho de áudio de captura quando AudioSource.VOICE_COMMUNICATION for selecionado, elas:

• [C-SR-1] É _RECOMENDADO_ declarar isso pelo método da API AcousticEchoCanceler AcousticEchoCanceler.isAvailable().
• [C-SR-2] são STRONGLY_RECOMMENDED para permitir que esse efeito de áudio seja controlável com a API AcousticEchoCanceler.
• [C-SR-3] É FORTEMENTE_RECOMENDADO identificar de forma exclusiva cada implementação de tecnologia AEC pelo campo AudioEffect.Descriptor.uuid.

5.4.5. Captura simultânea

Se as implementações do dispositivo declararem android.hardware.microphone, elas PRECISAM implementar a captura simultânea, conforme descrito neste documento. Especificamente:

• [C-1-1] É PRECISO permitir o acesso simultâneo ao microfone por um serviço de acessibilidade que capture com AudioSource.VOICE_RECOGNITION e pelo menos uma captura de aplicativo com qualquer AudioSource.
• [C-1-2] É PRECISO permitir o acesso simultâneo ao microfone por um app pré-instalado que tenha uma função do Google Assistente e pelo menos um app capturando com qualquer AudioSource, exceto AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
• [C-1-3] A captura de áudio de qualquer outro aplicativo, exceto um serviço de acessibilidade, precisa ser silenciada enquanto um aplicativo está capturando com AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. No entanto, quando um app está capturando via AudioSource.VOICE_COMMUNICATION, outro app pode capturar a chamada de voz se ele for privilegiado (pré-instalado) com permissão CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Se dois ou mais aplicativos estiverem capturando simultaneamente e se nenhum deles tiver uma IU na parte de cima, o que tiver iniciado a captura mais recentemente vai receber o áudio.

5.4.6. Níveis de ganho do microfone [Movido para 5.4.2]

5.5. Reprodução de áudio

O Android inclui suporte para permitir que os apps reproduzam áudio pelo periférico de saída de áudio, conforme definido na seção 7.8.2.

5.5.1. Reprodução de áudio bruto

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

• [C-1-1] É PRECISO permitir a reprodução de conteúdo de áudio bruto com as seguintes características:

  • Formatos de origem: PCM linear, 16 bits, 8 bits, ponto flutuante
  • Canais: mono, estéreo, configurações válidas de multicanal com até 8 canais
  • Taxas de amostragem (em Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 nas configurações do canal listadas acima
    • 96000 em mono e estéreo

5.5.2. Efeitos sonoros

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

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

• [C-1-1] PRECISA oferecer suporte às implementações EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controláveis pelas subclasses Equalizer e LoudnessEnhancer do AudioEffect.
• [C-1-2] PRECISA oferecer suporte à implementação da API do visualizador, controlável pela classe Visualizer.
• [C-1-3] PRECISA oferecer suporte à implementação de EFFECT_TYPE_DYNAMICS_PROCESSING controlável pela subclasse AudioEffect DynamicsProcessing.
• DEVE oferecer suporte às implementações EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controláveis pelas subclasses AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.
• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte a efeitos em ponto flutuante e multicanal.

5.5.3. Volume de saída de áudio

Implementações de dispositivos automotivos:

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

5.5.4. Offload de áudio

Se as implementações do dispositivo oferecerem suporte à reprodução de transferência de áudio, elas:

• [C-SR-1] É ALTAMENTE RECOMENDADO cortar o conteúdo de áudio sem intervalos entre dois clipes com o mesmo formato, quando especificado pela API AudioTrack gapless e pelo contêiner de mídia do MediaPlayer.

5.6. Latência de áudio

A latência de áudio é o tempo de atraso enquanto um sinal de áudio passa por um sistema. Muitas classes de aplicativos dependem de latências curtas para conseguir efeitos sonoros em tempo real.

Para os fins desta seção, use as seguintes definições:

• Latência de saída. O intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e o momento em que o som correspondente é apresentado ao ambiente em um transdutor no dispositivo ou o sinal sai do dispositivo por uma porta e pode ser observado externamente.
• Latência de saída fria. O tempo entre o início de um stream de saída e o tempo de apresentação do primeiro frame com base em carimbos de data/hora, quando o sistema de saída de áudio estava inativo e desligado antes da solicitação.
• latência de saída contínua. A latência de saída para frames subsequentes, depois que o dispositivo estiver reproduzindo áudio.
• latência de entrada. O intervalo entre o momento em que um som é apresentado pelo ambiente ao dispositivo em um transdutor no dispositivo ou o sinal entra no dispositivo por uma porta e o momento em que um aplicativo lê o frame correspondente de dados codificados em PCM.
• perda de entrada. A parte inicial de um sinal de entrada que é inutilizável ou indisponível.
• Latência de entrada fria. O tempo entre o início da transmissão e o momento em que o primeiro frame válido é recebido, quando o sistema de entrada de áudio está inativo e desligado antes da solicitação.
• latente de entrada contínua. A latência de entrada para frames subsequentes, enquanto o dispositivo está capturando áudio.
• latência de ida e volta contínua. A soma da latência de entrada contínua mais a latência de saída contínua mais um período de buffer. O período de buffer permite tempo para o app processar o sinal e tempo para o app reduzir a diferença de fase entre os streams de entrada e saída.
• API da fila de buffer de PCM do OpenSL ES. O conjunto de APIs OpenSL ES relacionadas ao PCM no Android NDK.
• API de áudio nativa AAudio. O conjunto de APIs AAudio no Android NDK.
• Carimbo de data/hora. Um par que consiste em uma posição de frame relativa em um stream e o tempo estimado em que esse frame entra ou sai do pipeline de processamento de áudio no endpoint associado. Consulte também AudioTimestamp.
• glitch. Uma interrupção temporária ou valor de amostra incorreto no sinal de áudio, normalmente causada por um buffer underrun para saída, buffer overrun para entrada ou qualquer outra fonte de ruído digital ou analógico.
• desvio absoluto médio. A média do valor absoluto dos desvios da média de um conjunto de valores.
• Latência de toque para tom. O tempo entre o toque na tela e o som do toque gerado.

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

• [C-1-1] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp e AAudioStream_getTimestamp é preciso com precisão de +/- 2 ms.

• [C-1-2] Latência de saída fria de 500 milissegundos ou menos.

• [C-1-3] Abrir um stream de saída usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

Se as implementações do dispositivo declararem android.hardware.audio.output, é ALTAMENTE RECOMENDÁVEL que elas atendam ou excedam os seguintes requisitos:

• [C-SR-1] Latência de saída fria de 100 milissegundos ou menos no caminho de dados do alto-falante.

• [C-SR-2] Latência de toque para tom de 80 milissegundos ou menos.

• [C-SR-4] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp e AAudioStream_getTimestamp é preciso com precisão de +/- 1 ms.

Se as implementações do dispositivo atenderem aos requisitos acima, após a calibração inicial, ao usar a API de áudio nativa AAudio, para latência de saída contínua e latência de saída fria em pelo menos um dispositivo de saída de áudio com suporte, elas são:

• [C-SR-5] É ALTAMENTE RECOMENDADO informar áudio de baixa latência declarando a flag de recurso android.hardware.audio.low_latency.
• [C-SR-6] É FORTEMENTE RECOMENDADO atender aos requisitos de áudio de baixa latência usando a API AAudio.
• [C-SR-7] É ALTAMENTE RECOMENDADO garantir que, para streams que retornam AAUDIO_PERFORMANCE_MODE_LOW_LATENCY de AAudioStream_getPerformanceMode(), o valor retornado por AAudioStream_getFramesPerBurst() seja menor ou igual ao valor retornado por android.media.AudioManager.getProperty(String) para a chave de propriedade AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Se as implementações do dispositivo não atenderem aos requisitos de áudio de baixa latência pela API de áudio nativa AAudio, elas:

• [C-2-1] NÃO é necessário informar suporte para áudio de baixa latência.

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

• [C-3-1] Limitar o erro nas marcações de tempo de entrada, conforme retornado por AudioRecord.getTimestamp ou AAudioStream_getTimestamp, a +/- 2 ms. "Erro" significa aqui a variação em relação ao valor correto.

• [C-3-2] Latência de entrada fria de 500 milissegundos ou menos.

• [C-3-3] Abrir um stream de entrada usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

Se as implementações do dispositivo incluírem android.hardware.microphone, é ALTAMENTE RECOMENDÁVEL que elas atendam a estes requisitos de áudio de entrada:

• [C-SR-8] Latência de entrada fria de 100 milissegundos ou menos no caminho de dados do microfone.

• [C-SR-11] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp ou AAudioStream_getTimestamp, para +/- 1 ms.

Se as implementações do dispositivo declararem android.hardware.audio.output e android.hardware.microphone, elas:

• [C-SR-12] É ALTAMENTE RECOMENDADO ter uma latência média contínua de ida e volta de 50 milissegundos ou menos em 5 medições, com uma média absoluta de desvio menor que 10 milissegundos em pelo menos um caminho com suporte.

5.7. Protocolos de rede

As implementações de dispositivos precisam oferecer suporte aos protocolos de rede de mídia para reprodução de áudio e vídeo, conforme especificado na documentação do SDK do Android.

Para cada codec e formato de contêiner que uma implementação de dispositivo precisa oferecer suporte, a implementação do dispositivo:

• [C-1-1] É PRECISO ter suporte a esse codec ou contêiner por HTTP e HTTPS.

• [C-1-2] É PRECISO oferecer suporte aos formatos de segmento de mídia correspondentes, conforme mostrado na tabela de formatos de segmento de mídia abaixo sobre o protocolo de rascunho de transmissão ao vivo em HTTP, versão 7.

• [C-1-3] PRECISA oferecer suporte aos formatos de payload RTSP correspondentes, conforme mostrado na tabela RTSP abaixo. Para exceções, consulte as notas de rodapé da tabela na seção 5.1.

Formatos de segmento de mídia

Formatos de segmentos	Referência(s)	Suporte a codec obrigatório
Stream de transporte MPEG-2	ISO 13818	Codecs de vídeo: H264 AVC MPEG-4 SP MPEG-2 Consulte a seção 5.1.8 para saber mais sobre o H.264 AVC, o MPEG2-4 SP, e o MPEG-2. Codecs de áudio: AAC Consulte a seção 5.1.3 para saber mais sobre o AAC e as variantes.
AAC com enquadramento ADTS e tags ID3	ISO 13818-7	Consulte a seção 5.1.1 para detalhes sobre o AAC e as variantes dele.
WebVTT	WebVTT

RTSP (RTP, SDP)

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

5.8. Secure Media

Se as implementações do dispositivo oferecerem suporte à saída de vídeo segura e forem capazes de oferecer suporte a superfícies seguras, elas:

• [C-1-1] É PRECISO declarar suporte para Display.FLAG_SECURE.

Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE e ao protocolo de exibição sem fio, elas:

• [C-2-1] É OBRIGATÓRIO proteger a vinculação com um mecanismo criptograficamente seguro, como o HDCP 2.x ou mais recente, para as telas conectadas por protocolos sem fio, como o Miracast.

Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE e suportarem a tela externa com fio, elas:

• [C-3-1] É NECESSÁRIO oferecer suporte ao HDCP 1.2 ou mais recente para todas as telas externas conectadas por uma porta com fio acessível ao usuário.

5.9. Interface digital para instrumentos musicais (MIDI)

Se as implementações de dispositivo informarem suporte ao recurso android.software.midi pela classe android.content.pm.PackageManager, elas:

• [C-1-1] É PRECISO oferecer suporte a MIDI por todos os transportes de hardware compatíveis com MIDI para os quais eles oferecem conectividade genérica que não é MIDI, em que esses transportes são:

  • Modo de host USB, seção 7.7
  • MIDI por Bluetooth LE atuando no papel central, seção 7.4.3

• [C-1-2] É PRECISO oferecer suporte ao transporte de software MIDI entre apps (dispositivos MIDI virtuais)

• [C-1-3] É PRECISO incluir libamidi.so (suporte MIDI nativo).

• DEVE ter suporte a MIDI no modo periférico USB, seção 7.7

5.10. Áudio profissional

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

• [C-1-1] É OBRIGATÓRIO informar o suporte ao recurso android.hardware.audio.low_latency.
• [C-1-2] É PRECISO ter a latência de áudio de ida e volta contínua, conforme definido na seção 5.6 Latência de áudio, de 25 milissegundos ou menos em pelo menos um caminho com suporte.
• [C-1-3] É PRECISO incluir uma ou mais portas USB com suporte para o modo de host USB e o modo de periférico USB.
• [C-1-4] É PRECISO informar o suporte ao recurso android.software.midi.
• [C-1-5] É NECESSÁRIO atender às latências e aos requisitos de áudio USB usando a API AAudio native audio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] A latência de saída fria PRECISA ser de 200 milissegundos ou menos.
• [C-1-7] A latência de entrada fria PRECISA ser de 200 milissegundos ou menos.
• [C-1-8] É OBRIGATÓRIO ter uma latência média de Tap-to-Tone de 80 milissegundos ou menos em pelo menos cinco medições no caminho de dados do alto-falante para o microfone.
• [C-SR-1] É ALTAMENTE RECOMENDADO atender às latências conforme definido na seção 5.6 Latência de áudio, de 20 milissegundos ou menos, em mais de cinco medições com uma Desvio absoluto médio inferior a 5 milissegundos no caminho do alto-falante para o microfone.
• [C-SR-2] É ALTAMENTE RECOMENDADO atender aos requisitos do Pro Audio para latívia contínua de ida e volta de áudio, latência de entrada fria e latência de saída fria e requisitos de áudio USB usando a API AAudio native audio no caminho MMAP.

• [C-SR-3] É ALTAMENTE RECOMENDADO fornecer um nível consistente de desempenho da CPU enquanto o áudio está ativo e a carga da CPU está variando. Isso precisa ser testado usando o app Android SynthMark. O SynthMark usa um sintetizador de software executado em um framework de áudio simulado que mede o desempenho do sistema. Consulte a documentação do SynthMark para uma explicação dos comparativos. O app SynthMark precisa ser executado usando a opção "Teste automatizado" e alcançar os seguintes resultados:

  • voicemark.90 >= 32 vozes
  • latencymark.fixed.little <= 15 msec
  • latencymark.dynamic.little <= 50 msec

• DEVE minimizar a imprecisão e a deriva do relógio de áudio em relação ao horário padrão.

• DEVE minimizar a deriva do relógio de áudio em relação à CLOCK_MONOTONIC da CPU quando ambos estão ativos.

• DEVE minimizar a latência de áudio em transdutores no dispositivo.

• DEVE minimizar a latência de áudio por áudio digital USB.

• DEVE documentar as medições de latência de áudio em todos os caminhos.

• DEVE minimizar o jitter nos tempos de entrada de callback de conclusão do buffer de áudio, já que isso afeta a porcentagem utilizável da largura de banda total da CPU pelo callback.

• DEVE não apresentar falhas de áudio no uso normal com a latência informada.

• DEVE fornecer zero diferença de latência entre canais.

• DEVE minimizar a latência média do MIDI em todos os transportes.

• DEVE minimizar a variabilidade da latência MIDI sob carga (jitter) em todos os transportes.

• DEVE fornecer carimbos de data/hora MIDI precisos em todos os transportes.

• DEVE minimizar o ruído do sinal de áudio em transdutores no dispositivo, incluindo o período imediatamente após a inicialização a frio.

• DEVEM fornecer zero diferença de relógio de áudio entre os lados de entrada e saída dos pontos finais correspondentes, quando ambos estiverem ativos. Exemplos de pontos finais correspondentes incluem o microfone e o alto-falante no dispositivo ou a entrada e a saída do conector de áudio.

• DEVE processar callbacks de conclusão de buffer de áudio para os lados de entrada e saída dos endpoints correspondentes na mesma linha de execução quando ambos estão ativos e entrar no callback de saída imediatamente após o retorno do callback de entrada. Ou, se não for viável processar os callbacks na mesma linha de execução, insira o callback de saída logo após inserir o callback de entrada para permitir que o aplicativo tenha um tempo consistente dos lados de entrada e saída.

• DEVE minimizar a diferença de fase entre o buffer de áudio HAL para os lados de entrada e saída dos endpoints correspondentes.

• DEVE minimizar a latência de toque.

• DEVE minimizar a variabilidade da latência do toque sob carga (jitter).

Se as implementações do dispositivo atenderem a todos os requisitos acima, elas:

• [C-SR-4] É ALTAMENTE RECOMENDADO informar o suporte para o recurso android.hardware.audio.pro usando a classe android.content.pm.PackageManager.

Se as implementações do dispositivo incluírem um conector de áudio de 3,5 mm com quatro condutores, elas:

• [C-2-1] É PRECISO ter uma latência de áudio de ida e volta contínua média, conforme definido na seção 5.6 Latência de áudio, de 20 milissegundos ou menos, em 5 medições com uma Média absoluta de desvio inferior a 5 milissegundos no caminho da entrada de áudio usando um dongle de retorno de áudio.
• [C-SR-5] É ALTAMENTE RECOMENDÁVEL obedecer à seção Especificações do dispositivo móvel (jack) da Especificação de fone de ouvido com áudio por fio (v1.1).

Se as implementações do dispositivo omitirem uma entrada de áudio de 3,5 mm com quatro condutores e incluírem portas USB com suporte ao modo host USB, elas:

• [C-3-1] É PRECISO implementar a classe de áudio USB.
• [C-3-2] É PRECISO ter uma latência de áudio de ida e volta contínua média de 25 milissegundos ou menos, em 5 medições com uma média absoluta de desvio menor que 5 milissegundos na porta do modo host USB usando a classe de áudio USB. Isso pode ser medido usando um adaptador USB-3, 5 mm e um dongle de áudio loopback ou usando uma interface de áudio USB com cabos de patch conectando as entradas às saídas.
• [C-SR-6] É ALTAMENTE RECOMENDADO que ofereça suporte a E/S simultânea de até 8 canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usado com periféricos de áudio USB que também oferecem suporte a esses requisitos.
• [C-SR-7] É ALTAMENTE RECOMENDADO atender a esse grupo de requisitos usando a API de áudio nativa AAudio no caminho MMAP.

Se as implementações do dispositivo incluem uma porta HDMI, elas:

• DEVE oferecer suporte à saída em estéreo e oito canais com profundidade de 20 ou 24 bits e 192 kHz sem perda de profundidade de bits ou reamostragem, em pelo menos uma configuração.

5.11. Captura para "Não processado"

O Android inclui suporte para gravação de áudio não processado pela fonte de áudio android.media.MediaRecorder.AudioSource.UNPROCESSED. No OpenSL ES, ele pode ser acessado com a predefinição de gravação SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Se as implementações de dispositivos tiverem a intenção de oferecer suporte à fonte de áudio não processada e disponibilizá-la para apps de terceiros, elas:

• [C-1-1] É OBRIGATÓRIO informar o suporte usando a propriedade android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] É PRECISO mostrar características aproximadamente planas de amplitude em relação à frequência na faixa de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz para cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-3] É PRECISO mostrar níveis de amplitude no intervalo de baixa frequência: especificamente de ±20 dB de 5 z a 100 Hz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-4] É PRECISO mostrar níveis de amplitude no intervalo de alta frequência: especificamente de ±30 dB de 7000 Hz a 22 kHz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-5] É PRECISO definir a sensibilidade de entrada de áudio de modo que uma fonte de tom senoidal de 1000 Hz tocada a 94 dB de nível de pressão sonora (SPL, na sigla em inglês) gere uma resposta com RMS de 520 para amostras de 16 bits (ou -36 dB em escala completa para amostras de ponto flutuante/dupla precisão) para cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-6] É OBRIGATÓRIO ter uma proporção de sinal-ruído (SNR) de 60 dB ou mais para cada microfone usado para gravar a fonte de áudio não processada. O SNR é medido como a diferença entre 94 dB SPL e SPL equivalente do ruído próprio, ponderado em A.

• [C-1-7] É PRECISO ter uma distorção harmônica total (THD) menor que 1% para 1 kHZ a 90 dB SPL de nível de entrada em cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-8] NÃO é permitido ter nenhum outro processamento de sinal (por exemplo, controle de ganho automático, filtro passa-alta ou cancelamento de eco) no caminho, exceto um multiplicador de nível para levar o nível ao intervalo desejado. Resumindo:

  • [C-1-9] Se qualquer processamento de sinal estiver presente na arquitetura por qualquer motivo, ele PRECISA ser desativado e efetivamente introduzir zero atraso ou latência extra no caminho do sinal.
  • [C-1-10] O multiplicador de nível, embora permitido no caminho, NÃO PODE introduzir atraso ou latência no caminho do sinal.

Todas as medições de SPL são feitas diretamente ao lado do microfone em teste. Para várias configurações de microfone, esses requisitos se aplicam a cada microfone.

Se as implementações do dispositivo declararem android.hardware.microphone, mas não oferecerem suporte à fonte de áudio não processada, elas:

• [C-2-1] DEVE retornar null para o método da API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) para indicar corretamente a falta de suporte.
• [C-SR-1] ainda é FORTEMENTE RECOMENDADO para atender a tantos requisitos quanto possível para o caminho do sinal da fonte de gravação não processada.

5.12. Vídeo HDR

O Android 13 oferece suporte às tecnologias HDR conforme descrito em um documento futuro.

Formato de pixel

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

• [C-1-1] DEVE oferecer suporte ao formato P010 para leitura de CPU (ImageReader, MediaImage, ByteBuffer). No Android 13, o P010 foi relaxado para permitir o passo arbitrário para os planos Y e UV.

• [C-1-2] O buffer de saída P010 PRECISA ser amostrado pela GPU (quando alocado com o uso de GPU_SAMPLING). Isso permite a composição da GPU e o mapeamento de tons personalizados pelos apps.

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

• [C-2-1] É PRECISO oferecer suporte ao formato RGBA_1010102 para a superfície de saída e ser legível pela CPU (saída ByteBuffer).

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

• [C-3-1] PRECISA oferecer suporte ao formato P010 para entrada de superfície e entrada (ImageWriter, MediaImage, ByteBuffer) gravável pela CPU.

Observação: no Android 13, o P010 foi relaxado para permitir o passo arbitrário para os planos Y e UV. Esse formato P010 PODE ser otimizado e diferente do formato P010 da Camera2.

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

• [C-4-1] PRECISA oferecer suporte ao formato RGBA_1010102 para a superfície de entrada e a entrada (ImageWriter, ByteBuffer) gravável pela CPU. Observação: a conversão entre várias curvas de transferência NÃO é necessária para codificadores.

Requisitos de captura HDR

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

• [C-5-1] NÃO é permitido presumir que os metadados HDR sejam precisos. Por exemplo, o frame codificado pode ter pixels além do nível máximo de luminância ou o histograma pode não ser representativo do frame.

• AGREGAR metadados dinâmicos HDR para gerar metadados estáticos HDR adequados para streams codificados e exibir esses metadados no final de cada sessão de codificação.

Se as implementações do dispositivo oferecerem suporte à captura HDR usando as APIs CamcorderProfile, elas:

• [C-6-1] PRECISA oferecer suporte à captura HDR pelas APIs Camera2.

• [C-6-2] É PRECISO oferecer suporte a pelo menos um codificador de vídeo com aceleração de hardware para cada tecnologia HDR com suporte.

• [C-6-3] É OBRIGATÓRIO oferecer suporte (no mínimo) à captura HLG.

• [C-6-4] É PRECISO oferecer suporte à gravação dos metadados HDR (se aplicável à tecnologia HDR) no arquivo de vídeo capturado. Para AV1, HEVC e DolbyVision, isso significa incluir os metadados no fluxo de bits codificado.

• [C-6-5] PRECISA oferecer suporte a P010 e COLOR_FormatYUVP010.

• [C-6-6] É PRECISO oferecer suporte ao mapeamento de tons HDR para SDR no decodificador padrão com aceleração de hardware para o perfil capturado. Em outras palavras, se um dispositivo pode capturar HDR10+ HEVC, o decodificador HEVC padrão PRECISA ser capaz de decodificar o stream capturado em SDR.

Requisitos de edição em HDR

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

• DEVE usar a latência mínima para gerar os metadados HDR quando eles não estiverem presentes e DEVE lidar com situações em que os metadados estiverem presentes em alguns frames e não em outros. Esses metadados precisam ser precisos (por exemplo, representar a luminância máxima real e o histograma do frame).

Se a implementação do dispositivo incluir codecs com suporte a 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 por esse codec. Em outras palavras, eles PRECISAM oferecer suporte à geração de metadados HDR quando não estiverem presentes em todos os perfis HDR com suporte que usam metadados HDR.

• [C-7-3] É PRECISO oferecer suporte aos seguintes formatos de entrada do codificador de vídeo que preservem totalmente o sinal descodificado HDR:

  • RGBA_1010102 (já na curva de transferência de destino) para a superfície de entrada e ByteBuffer e PRECISA anunciar suporte para COLOR_Format32bitABGR2101010.

Se a implementação do dispositivo incluir codecs com suporte a FEATURE_HdrEditing, o dispositivo:

• [C-7-4] É PRECISO anunciar suporte para a extensão OpenGL EXT_YUV_target.

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

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

• [C-0-1] É PRECISO oferecer suporte às Ferramentas para Desenvolvedores Android fornecidas no SDK do Android.

• Android Debug Bridge (adb)

  • [C-0-2] É PRECISO oferecer suporte ao adb conforme documentado no SDK do Android e aos comandos shell fornecidos no AOSP, que podem ser usados por desenvolvedores de apps, incluindo dumpsys cmd stats
  • [C-0-11] É PRECISO ter suporte ao comando de shell cmd testharness. A atualização de implementações de dispositivos de uma versão anterior do Android sem um bloqueio de dados persistente PODE ser isenta da C-0-11.
  • [C-0-3] NÃO mude o formato ou o conteúdo dos eventos do sistema do dispositivo (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrados pelo comando dumpsys.
  • [C-0-10] É OBRIGATÓRIO registrar, sem omissão, e tornar os eventos a seguir acessíveis e disponíveis para o comando de shell cmd stats e a classe da API System StatsManager.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] O demônio adb do dispositivo PRECISA estar inativo por padrão, e PRECISA haver um mecanismo acessível ao usuário para ativar a ponte de depuração do Android.
  • [C-0-5] É PRECISO oferecer suporte ao adb seguro. O Android inclui suporte para o adb seguro. O adb seguro ativa o adb em hosts autenticados conhecidos.
  • [C-0-6] É PRECISO fornecer um mecanismo que permita que o adb seja conectado de uma máquina host. Especificamente:

  Se as implementações de dispositivos sem uma porta USB oferecerem suporte ao modo periférico, elas:

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

  Se as implementações do dispositivo oferecerem suporte a conexões adb para uma máquina host via Wi-Fi ou Ethernet, elas:

  • [C-4-1] O método AdbManager#isAdbWifiSupported() PRECISA retornar true.

  Se as implementações do dispositivo oferecerem suporte a conexões adb para uma máquina host via Wi-Fi ou Ethernet e incluírem pelo menos uma câmera, elas:

  • [C-5-1] O método AdbManager#isAdbWifiQrSupported() PRECISA retornar true.

• Serviço de monitoramento de depuração do Dalvik (ddms)

  • [C-0-7] É PRECISO oferecer suporte a todos os recursos do ddms, conforme documentado no SDK do Android. Como os ddms usam o adb, o suporte a eles DEVE estar inativo por padrão, mas PRECISA ser compatível sempre que o usuário tiver ativado a ponte de depuração do Android, como acima.

• SysTrace

  • [C-0-9] PRECISA oferecer suporte à ferramenta systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão, e é PRECISO ter um mecanismo acessível ao usuário para ativar o Systrace.

• Perfetto

  • [C-SR-1] É ALTAMENTE RECOMENDADO expor um binário /system/bin/perfetto ao usuário do shell, em que o cmdline obedece à documentação do perfetto.
  • [C-SR-2] O binário do perfetto é ALTAMENTE RECOMENDADO para aceitar como entrada uma configuração protobuf que obedece ao esquema definido na documentação do perfetto.
  • [C-SR-3] O binário do Perfetto é ALTAMENTE RECOMENDADO para gravar como saída um traço protobuf que obedece ao esquema definido na documentação do Perfetto.
  • [C-SR-4] É ALTAMENTE RECOMENDADO fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto.

• Low Memory Killer

  • [C-0-12] É PRECISO gravar um átomo LMK_KILL_OCCURRED_FIELD_NUMBER no registro statsd quando um app é encerrado pelo Low Memory Killer.

• Modo de teste do arcabouço Se as implementações do dispositivo oferecem suporte ao comando de shell cmd testharness e executam cmd testharness enable, elas:

  • [C-2-1] PRECISA retornar true para ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] É OBRIGATÓRIO implementar o modo de arcabouço de testes conforme descrito na documentação do modo de arcabouço de testes.

• Informações de trabalho da GPU

  Implementações de dispositivos:

  • [C-0-13] É PRECISO implementar o comando de shell dumpsys gpu --gpuwork para mostrar os dados de trabalho da GPU agregados retornados pelo ponto de rastreamento do kernel power/gpu_work_period ou não mostrar dados se o ponto de rastreamento não tiver suporte. A implementação do AOSP é frameworks/native/services/gpuservice/gpuwork/.

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

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

6.2. Opções do desenvolvedor

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

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

• [C-0-1] É PRECISO honrar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar as configurações relacionadas ao desenvolvimento do aplicativo. A implementação upstream do Android esconde o menu "Opções do desenvolvedor" por padrão e permite que os usuários acessem as opções do desenvolvedor depois de pressionar sete (7) vezes no item de menu Configurações > Sobre o dispositivo > Número da versão.
• [C-0-2] É OBRIGATÓRIO ocultar as opções de desenvolvedor por padrão.
• [C-0-3] É necessário fornecer um mecanismo claro que não dê tratamento preferencial a um app de terceiros em vez de outro para ativar as opções para desenvolvedores. É necessário fornecer um documento ou site visível publicamente que descreva como ativar as opções para desenvolvedores. Esse documento ou site PRECISA ser vinculado a documentos do SDK do Android.
• DEVE ter uma notificação visual contínua para o usuário quando as opções de desenvolvedor estiverem ativadas e a segurança do usuário for uma preocupação.
• PODE limitar temporariamente o acesso ao menu de opções para desenvolvedores, ocultando ou desativando o menu visualmente, para evitar distrações em cenários em que a segurança do usuário é uma preocupação.

7. Compatibilidade de hardware

Se um dispositivo incluir um componente de hardware específico que tenha uma API correspondente para desenvolvedores terceirizados:

• [C-0-1] A implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android.

Se uma API no SDK interagir com um componente de hardware declarado como opcional e a implementação do dispositivo não tiver esse componente:

• [C-0-2] As definições de classe completas (como documentado pelo SDK) para as APIs do componente AINDA PRECISAM ser apresentadas.
• [C-0-3] Os comportamentos da API precisam ser implementados como no-ops de maneira razoável.
• [C-0-4] Os métodos da API precisam retornar valores nulos quando permitido pela documentação do SDK.
• [C-0-5] Os métodos da API precisam retornar implementações sem operação de classes em que valores nulos não são permitidos pela documentação do SDK.
• [C-0-6] Os métodos da API NÃO PODEM gerar exceções não documentadas pela documentação do SDK.
• [C-0-7] As implementações de dispositivos PRECISAM informar consistentemente informações precisas de configuração de hardware usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para o mesmo fingerprint de build.

Um exemplo típico de um cenário em que esses requisitos se aplicam é a API de telefonia: mesmo em dispositivos que não são smartphones, essas APIs precisam ser implementadas como no-ops razoáveis.

7.1. Tela e gráficos

O Android inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts da interface para o dispositivo, garantindo que os apps de terceiros funcionem bem em várias configurações de hardware. Nas telas compatíveis com Android em que todos os apps de terceiros compatíveis com Android podem ser executados, as implementações de dispositivos PRECISAM implementar corretamente essas APIs e comportamentos, conforme detalhado nesta seção.

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

• tamanho físico diagonal. A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
• pontos por polegada (dpi). O número de pixels englobados por uma extensão linear horizontal ou vertical de 1". Quando os valores de dpi são listados, o dpi horizontal e vertical precisa estar dentro do intervalo.
• proporção. A proporção dos pixels da dimensão maior em relação à dimensão menor da tela. Por exemplo, uma tela de 480 x 854 pixels seria 854/480 = 1,779, ou aproximadamente "16:9".
• pixel independente de densidade (dp). A unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como: pixels = dps * (density/160).

7.1.1. Configuração da tela

7.1.1.1. Tamanho e forma da tela

O framework de interface do Android oferece suporte a vários tamanhos de layout lógico de tela e permite que os aplicativos consultem o tamanho do layout da tela da configuração atual usando Configuration.screenLayout com SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

Implementações de dispositivos:

• [C-0-1] É OBRIGATÓRIO informar o tamanho correto do layout para o Configuration.screenLayout, conforme definido na documentação do SDK do Android. Especificamente, as implementações de dispositivo precisam informar as dimensões corretas de pixels (dp) independentes de densidade lógica, conforme abaixo:

  • Dispositivos com o Configuration.uiMode definido como qualquer valor diferente de UI_MODE_TYPE_WATCH e que informem um tamanho small para o Configuration.screenLayout, PRECISAM ter pelo menos 426 dp x 320 dp.
  • Os dispositivos que informam um tamanho normal para o Configuration.screenLayout PRECISAM ter pelo menos 480 dp x 320 dp.
  • Os dispositivos que informam um tamanho large para o Configuration.screenLayout PRECISAM ter pelo menos 640 dp x 480 dp.
  • Os dispositivos que informam um tamanho xlarge para o Configuration.screenLayout PRECISAM ter pelo menos 960 dp x 720 dp.

• [C-0-2] É PRECISO respeitar corretamente o suporte declarado dos aplicativos para tamanhos de tela usando o atributo <supports-screens> no AndroidManifest.xml, conforme descrito na documentação do SDK do Android.

• PODE ter telas compatíveis com Android com cantos arredondados.

Se as implementações de dispositivos oferecerem suporte a UI_MODE_TYPE_NORMAL e incluirem telas compatíveis com o Android com cantos arredondados, elas:

• [C-1-1] É OBRIGATÓRIO garantir que pelo menos um dos seguintes requisitos seja atendido:

  • O raio dos cantos arredondados é menor ou igual a 38 dp.
  • Quando uma caixa de 15 dp por 15 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 incluem uma tela compatível com o Android que é dobrável ou inclui uma articulação dobrável entre vários painéis de exibição e disponibiliza essas telas para renderizar apps de terceiros, elas:

• [C-2-1] É PRECISO implementar a versão estável mais recente disponível da API Extensions ou a versão estável da API Sidecar para ser usada pela biblioteca Window Manager Jetpack.

Se as implementações de dispositivos incluem uma tela compatível com Android que é dobrável ou inclui uma articulação dobrável entre vários painéis de exibição e se a articulação ou dobra cruza uma janela de aplicativo em tela cheia, elas:

• [C-3-1] É OBRIGATÓRIO informar a posição, os limites e o estado da articulação ou da dobra por extensões ou APIs sidecar para o aplicativo.

Para detalhes sobre como implementar corretamente as APIs sidecar ou de extensão, consulte a documentação pública do Jetpack Window Manager.

7.1.1.2. Proporção da tela

Embora não haja restrição à proporção da tela física para as telas compatíveis com o Android, a proporção da tela lógica em que os apps de terceiros são renderizados, que pode ser derivada dos valores de altura e largura informados pelas APIs view.Display e Configuração, PRECISA atender aos seguintes requisitos:

• [C-0-1] As implementações de dispositivo com Configuration.uiMode definido como UI_MODE_TYPE_NORMAL PRECISAM ter um valor de proporção menor ou igual a 1,86 (aproximadamente 16:9), a menos que o app atenda a uma das seguintes condições:

  • O app declarou que oferece suporte a uma proporção de tela maior pelo valor de metadados android.max_aspect.
  • O app declara que é redimensionável pelo atributo android:resizeableActivity.
  • O app é direcionado ao nível 24 da API ou mais recente e não declara um android:maxAspectRatio que restrinja a proporção permitida.

• [C-0-3] As implementações de dispositivo com Configuration.uiMode definido como UI_MODE_TYPE_WATCH PRECISAM ter um valor de proporção definido como 1,0 (1:1).

7.1.1.3. Densidade da tela

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

• [C-0-1] Por padrão, as implementações de dispositivo PRECISAM informar apenas uma das densidades do framework do Android listadas em DisplayMetrics pela API DENSITY_DEVICE_STABLE. Esse valor PRECISA permanecer o mesmo. No entanto, o dispositivo PODE informar uma densidade arbitrária diferente de acordo com as mudanças de configuração de exibição feitas pelo usuário (por exemplo, tamanho da tela) definidas após a inicialização inicial.

• As implementações de dispositivo DEVEM definir a densidade padrão do framework do Android que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica empurre o tamanho da tela informado abaixo do mínimo suportado. Se a densidade do framework padrão do Android que é numericamente mais próxima da densidade física resultar em um tamanho de tela menor do que o menor tamanho de tela compatível (largura de 320 dp), as implementações de dispositivo precisarão informar a próxima densidade padrão mais baixa do framework do Android.

Se houver uma affordance para mudar o tamanho da tela do dispositivo:

• [C-1-1] O tamanho da tela NÃO PODE ser dimensionado em mais de 1,5 vezes a densidade nativa ou produzir uma dimensão mínima de tela menor que 320 dp (equivalente ao qualificador de recurso sw320dp), o que ocorrer primeiro.
• [C-1-2] O tamanho da tela NÃO PODE ser dimensionado para menos de 0,85 vezes a densidade nativa.
• Para garantir uma boa usabilidade e tamanhos de fonte consistentes, é RECOMENDÁVEL que a escalação a seguir das opções de exibição nativa seja fornecida (atendendo aos limites especificados acima)
  • Pequeno: 0,85x
  • Padrão: 1x (escala de tela nativa)
  • Grande: 1,15x
  • Maior: 1,3x
  • Maior: 1,45x

7.1.2. Métricas de tela

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

• [C-1-1] É PRECISO informar os valores corretos para todas as métricas de exibição compatíveis com o Android definidas na API android.util.DisplayMetrics.

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

• [C-2-1] É PRECISO informar os valores corretos da tela compatível com Android conforme definido na API android.util.DisplayMetrics para o view.Display padrão emulado.

7.1.3. Orientação da tela

Implementações de dispositivos:

• [C-0-1] É OBRIGATÓRIO informar quais orientações de tela são compatíveis (android.hardware.screen.portrait e/ou android.hardware.screen.landscape) e é OBRIGATÓRIO informar pelo menos uma orientação compatível. Por exemplo, um dispositivo com uma tela de orientação paisagem fixa, como uma televisão ou um laptop, DEVE informar apenas android.hardware.screen.landscape.
• [C-0-2] É OBRIGATÓRIO informar o valor correto para a orientação atual do dispositivo sempre que for consultado pela android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.

Se as implementações do dispositivo oferecerem suporte a ambas as orientações da tela, elas:

• [C-1-1] PRECISA oferecer suporte à orientação dinâmica por aplicativos para orientação de tela retrato ou paisagem. Ou seja, o dispositivo precisa respeitar a solicitação do aplicativo para uma orientação de tela específica.
• [C-1-2] O tamanho ou a densidade da tela NÃO PODEM mudar quando a orientação é alterada.
• PODE selecionar a orientação retrato ou paisagem como padrão.

7.1.4. Aceleração gráfica 2D e 3D

7.1.4.1 OpenGL ES

Implementações de dispositivos:

• [C-0-1] É PRECISO identificar corretamente as versões OpenGL ES com suporte (1.1, 2.0, 3.0, 3.1, 3.2) pelas APIs gerenciadas (como pelo método GLES10.getString()) e pelas APIs nativas.
• [C-0-2] É PRECISO incluir o suporte a todas as APIs gerenciadas e nativas correspondentes para todas as versões do OpenGL ES identificadas.

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

• [C-1-1] PRECISA oferecer suporte ao OpenGL ES 1.1 e 2.0, conforme detalhado na documentação do SDK do Android.
• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao OpenGL ES 3.1.
• DEVE ter suporte ao OpenGL ES 3.2.

Os testes dEQP do OpenGL ES são divididos em várias listas de teste, cada uma com um número de data/versão associado. Eles estão na árvore de origem do Android em external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt. Um dispositivo que oferece suporte ao OpenGL ES em um nível informado por ele mesmo indica que pode passar nos testes dEQP em todas as listas de teste a partir desse nível.

Se as implementações do dispositivo forem compatíveis com qualquer uma das versões do OpenGL ES, elas:

• [C-2-1] É OBRIGATÓRIO informar por meio das APIs gerenciadas e nativas do OpenGL ES outras extensões do OpenGL ES que foram implementadas e, inversamente, NÃO é permitido informar strings de extensão que não são compatíveis.
• [C-2-2] PRECISA oferecer suporte às extensões EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
• [C-2-3] É OBRIGATÓRIO informar a versão máxima dos testes dEQP do OpenGL ES com suporte à flag de recurso android.software.opengles.deqp.level.
• [C-2-4] É PRECISO oferecer suporte à versão 132383489 (de 1º de março de 2020) como informado na flag de recurso android.software.opengles.deqp.level.
• [C-2-5] É PRECISO passar em todos os testes dEQP do OpenGL ES nas listas de teste entre a versão 132383489 e a versão especificada na flag de recurso android.software.opengles.deqp.level, para cada versão do OpenGL ES com suporte.
• [C-SR-2] É ALTAMENTE RECOMENDADO oferecer suporte às extensões EGL_KHR_partial_update e OES_EGL_image_external.
• DEVE informar com precisão, pelo método getString(), qualquer formato de compactação de textura compatível, que geralmente é específico do fornecedor.
• DEVEM oferecer suporte às extensões EGL_IMG_context_priority e EGL_EXT_protected_content.

Se as implementações do dispositivo declararem suporte ao OpenGL ES 3.0, 3.1 ou 3.2, elas:

• [C-3-1] É OBRIGATÓRIO exportar os símbolos de função correspondentes para essas versões, além dos símbolos de função do OpenGL ES 2.0 na biblioteca libGLESv2.so.
• [C-SR-3] É ALTAMENTE RECOMENDADO oferecer suporte à extensão OES_EGL_image_external_essl3.

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

• [C-4-1] PRECISA oferecer suporte ao pacote de extensão OpenGL ES para Android na íntegra.

Se as implementações do dispositivo oferecerem suporte ao pacote de extensões para Android do OpenGL ES na íntegra, elas:

• [C-5-1] É OBRIGATÓRIO identificar o suporte usando a flag de recurso android.hardware.opengles.aep.

Se as implementações do dispositivo oferecerem suporte à extensão EGL_KHR_mutable_render_buffer, elas:

• [C-6-1] É PRECISO ter suporte à extensão EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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

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

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

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

• [C-SR-2] É ALTAMENTE RECOMENDADO incluir suporte ao Vulkan 1.3.

Os testes dEQP do Vulkan são divididos em várias listas de teste, cada uma com uma data/versão associada. Eles estão na árvore de origem do Android em external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt. Um dispositivo que oferece suporte ao Vulkan em um nível informado por ele mesmo indica que pode passar nos testes dEQP em todas as listas de teste a partir desse nível.

Se as implementações do dispositivo incluem suporte ao Vulkan 1.0 ou mais recente, elas:

• [C-1-1] É OBRIGATÓRIO informar o valor inteiro correto com os flags de recursos android.hardware.vulkan.level e android.hardware.vulkan.version.
• [C-1-2] É PRECISO enumerar pelo menos um VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] É PRECISO implementar totalmente as APIs Vulkan 1.0 para cada VkPhysicalDevice enumerado.
• [C-1-4] É NECESSÁRIO enumerar camadas contidas em bibliotecas nativas nomeadas como libVkLayer*.so no diretório de biblioteca nativa do pacote de aplicativos, através das APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties().
• [C-1-5] NÃO É PERMITIDO enumerar camadas fornecidas por bibliotecas fora do pacote do aplicativo ou fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o atributo android:debuggable definido como true.
• [C-1-6] É PRECISO informar todas as strings de extensão com suporte pelo APIs nativas do Vulkan e, inversamente, NÃO é PRECISO informar strings de extensão que não têm suporte.
• [C-1-7] É PRECISO oferecer suporte às extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
• [C-1-8] É PRECISO informar a versão máxima dos testes dEQP do Vulkan com suporte à flag de recurso android.software.vulkan.deqp.level.
• [C-1-9] É PRECISO oferecer suporte à versão 132317953 (de 1º de março de 2019) conforme informado na flag de recurso android.software.vulkan.deqp.level.
• [C-1-10] É PRECISO passar em todos os testes dEQP do Vulkan nas listas de teste entre a versão 132317953 e a versão especificada na flag de recurso android.software.vulkan.deqp.level.
• [C-1-11] NÃO É PERMITIDO enumerar o suporte para as extensões VK_KHR_video_queue, VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.
• [C-SR-3] É ALTAMENTE RECOMENDADO oferecer suporte às extensões VK_KHR_driver_properties e VK_GOOGLE_display_timing.
• DEVE ser compatível com VkPhysicalDeviceProtectedMemoryFeatures e VK_EXT_global_priority.
• [C-1-12] NÃO É PERMITIDO enumerar o suporte à extensão VK_KHR_performance_query.
• [C-SR-4] É FORTEMENTE RECOMENDADO atender aos requisitos especificados pelo perfil de referência do Android 2021.

Se as implementações do dispositivo não incluírem suporte ao Vulkan 1.0, elas:

• [C-2-1] NÃO declarar nenhuma das flags de recursos do Vulkan (por exemplo, android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NÃO É PERMITIDO enumerar nenhum VkPhysicalDevice para a API nativa vkEnumeratePhysicalDevices() do Vulkan.

Se as implementações do dispositivo incluírem suporte ao Vulkan 1.1 e declararem qualquer uma das flags de recursos do Vulkan, elas:

• [C-3-1] PRECISA expor suporte para o semáforo externo SYNC_FD e processar tipos e a extensão VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] As implementações de dispositivos PRECISAM oferecer suporte ao Android RenderScript, conforme detalhado na documentação do Android SDK.

7.1.4.4 Aceleração gráfica 2D

O Android inclui um mecanismo para que os aplicativos declarem que querem ativar a aceleração de hardware para gráficos 2D no nível do aplicativo, da atividade, da janela ou da visualização usando uma tag de manifesto android:hardwareAccelerated ou chamadas diretas de API.

Implementações de dispositivos:

• [C-0-1] PRECISA ativar a aceleração de hardware por padrão e PRECISA desativar a aceleração de hardware se o desenvolvedor solicitar isso definindo android:hardwareAccelerated="false" ou desativando a aceleração de hardware diretamente pelas APIs de visualização do Android.
• [C-0-2] PRECISA apresentar um comportamento consistente com a documentação do SDK do Android sobre aceleração de hardware.

O Android inclui um objeto TextureView que permite que os desenvolvedores integrem diretamente texturas OpenGL ES aceleradas por hardware como destinos de renderização em uma hierarquia de IU.

Implementações de dispositivos:

• [C-0-3] PRECISA oferecer suporte à API TextureView e PRECISA apresentar comportamento consistente com a implementação upstream do Android.

7.1.4.5 Telas de ampla gama

Se as implementações de dispositivos declararem suporte a telas de ampla gama de cores usando Configuration.isScreenWideColorGamut() , elas:

• [C-1-1] É PRECISO ter uma tela com cores calibradas.
• [C-1-2] É OBRIGATÓRIO ter uma tela com uma gama que cubra toda a gama de cores sRGB no espaço CIE 1931 xyY.
• [C-1-3] É PRECISO ter uma tela com uma gama de pelo menos 90% de DCI-P3 no espaço CIE 1931 xyY.
• [C-1-4] PRECISA oferecer suporte a OpenGL ES 3.1 ou 3.2 e informar corretamente.
• [C-1-5] É PRECISO anunciar suporte para as extensões EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear e EGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte a GL_EXT_sRGB.

Por outro lado, se as implementações de dispositivos não oferecerem suporte a telas de ampla gama de cores, elas:

• [C-2-1] DEVE abranger 100% ou mais do sRGB no espaço CIE 1931 xyY, embora a gama de cores da tela seja indefinida.

7.1.5. Modo de compatibilidade de aplicativo legado

O Android especifica um "modo de compatibilidade" em que a estrutura opera em um modo de tamanho de tela "normal" equivalente (largura de 320 dp) para beneficiar aplicativos legados que não foram desenvolvidos para versões antigas do Android que antecedem a independência do tamanho da tela.

7.1.6. Tecnologia da tela

A plataforma Android inclui APIs que permitem que os aplicativos renderizem gráficos avançados em uma tela compatível com o Android. Os dispositivos precisam oferecer suporte a todas essas APIs, conforme definido pelo SDK do Android, a menos que seja permitido especificamente neste documento.

Todas as telas compatíveis com Android de uma implementação de dispositivo:

• [C-0-1] PRECISA ser capaz de renderizar gráficos coloridos de 16 bits.
• DEVE oferecer suporte a telas com gráficos coloridos de 24 bits.
• [C-0-2] PRECISA ser capaz de renderizar animações.
• [C-0-3] PRECISA ter uma proporção de pixels (PAR) entre 0,9 e 1,15. Ou seja, a proporção de pixels PRECISA estar próxima do quadrado (1,0) com uma tolerância de 10 a 15%.

7.1.7. Telas secundárias

O Android inclui suporte a telas secundárias compatíveis com o Android para ativar recursos de compartilhamento de mídia e APIs para desenvolvedores acessarem telas externas.

Se as implementações de dispositivos oferecerem suporte a uma tela externa por uma conexão de tela adicional embutida, com ou sem fio, elas:

• [C-1-1] É OBRIGATÓRIO implementar o serviço do sistema e a API DisplayManager conforme descrito na documentação do SDK do Android.

7.2. Dispositivos de entrada

Implementações de dispositivos:

• [C-0-1] É PRECISO incluir um mecanismo de entrada, como uma tela tátil ou navegação sem toque, para navegar entre os elementos da interface.

7.2.1. Teclado

Se as implementações de dispositivos incluírem suporte a aplicativos de Editor de método de entrada (IME) de terceiros, elas:

• [C-1-1] É PRECISO declarar a flag de recurso android.software.input_methods.
• [C-1-2] É PRECISO implementar totalmente o Input Management Framework.
• [C-1-3] É OBRIGATÓRIO ter um teclado de software pré-instalado.

Implementações de dispositivos:

• [C-0-1] NÃO É PERMITIDO incluir um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.keyboard (QWERTY ou 12 teclas).
• DEVE incluir outras implementações de teclado virtual.
• PODE incluir um teclado de hardware.

7.2.2. Navegação sem toque

O Android inclui suporte para botão direcional, trackball e roda como mecanismos para navegação sem toque.

Implementações de dispositivos:

• [C-0-1] É OBRIGATÓRIO informar o valor correto para android.content.res.Configuration.navigation.

Se as implementações de dispositivos não tiverem navegações sem toque, elas:

• [C-1-1] É OBRIGATÓRIO fornecer um mecanismo de interface do usuário alternativo razoável para a seleção e edição de texto, compatível com mecanismos de gerenciamento de entrada. A implementação de código aberto upstream do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação não táctil.

7.2.3. Teclas de navegação

As funções Home, Recentes e Voltar normalmente fornecidas por uma interação com um botão físico dedicado ou uma parte distinta da tela touchscreen são essenciais para o paradigma de navegação do Android e, portanto, para implementações de dispositivos:

• [C-0-1] É necessário fornecer uma capacidade do usuário para iniciar aplicativos instalados que tenham uma atividade com o <intent-filter> definido com ACTION=MAIN e CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER para implementações de dispositivos de TV. A função "Início" DEVE ser o mecanismo para essa affordance do usuário.
• DEVE fornecer botões para a função "Recentes" e "Voltar".

Se as funções "Início", "Recentes" ou "Voltar" forem fornecidas, elas:

• [C-1-1] PRECISA ser acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando qualquer uma delas for acessível.
• [C-1-2] É PRECISO indicar claramente qual ação única aciona cada função. Exemplos de indicações são ter um ícone visível impresso no botão, mostrar um ícone de software na parte da barra de navegação da tela ou guiar o usuário por um fluxo de demonstração guiado durante a experiência de configuração pronta para uso.

Implementações de dispositivos:

• [C-SR-1] É ALTAMENTE RECOMENDADO não fornecer o mecanismo de entrada para a função Menu, já que ela foi descontinuada em favor da barra de ações desde o Android 4.0.

• [C-SR-2] É ALTAMENTE RECOMENDADO fornecer todas as funções de navegação como canceláveis. "Cancelável" é definido como a capacidade do usuário de impedir a execução da função de navegação (por exemplo, voltar à tela inicial, voltar, etc.) se o deslize não for liberado após um determinado limite.

Se as implementações do dispositivo oferecerem a função Menu, elas:

• [C-2-1] É OBRIGATÓRIO mostrar o botão de menu flutuante de ação sempre que o pop-up do menu flutuante de ação não estiver vazio e a barra de ação estiver visível.
• [C-2-2] NÃO MODIFIQUE a posição do pop-up de acúmulo de ações exibido ao selecionar o botão de acúmulo na barra de ações, mas PODE renderizar o pop-up de acúmulo de ações em uma posição modificada na tela quando ele é exibido ao selecionar a função de menu.

Se as implementações do dispositivo não fornecerem a função Menu, para compatibilidade retroativa, elas: * [C-3-1] PRECISAM 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 ser acessível, a menos que esteja oculta com outras funções de navegação.

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

• [C-4-1] A função Assist precisa ser acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando outras teclas de navegação estiverem acessíveis.
• [C-SR-3] É ALTAMENTE RECOMENDADO usar o toque longo na função HOME como essa interação designada.

Se as implementações do dispositivo usarem uma parte distinta da tela para mostrar as teclas de navegação, elas:

• [C-5-1] As teclas de navegação PRECISAM usar uma parte distinta da tela, que não esteja disponível para aplicativos, e NÃO PODEM obscurecer ou interferir de outra forma na parte da tela disponível para aplicativos.
• [C-5-2] PRECISA disponibilizar uma parte da tela para aplicativos que atendem aos requisitos definidos na seção 7.1.1.
• [C-5-3] É OBRIGATÓRIO honrar as flags definidas pelo app pelo método de API View.setSystemUiVisibility(), para que essa parte distinta da tela (também conhecida como barra de navegação) seja oculta corretamente, conforme documentado no SDK.

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

• [C-6-1] O WindowInsets#getMandatorySystemGestureInsets() SÓ pode ser usado para informar a área de reconhecimento de gestos da tela inicial.
• [C-6-2] Os gestos que começam em um retângulo de exclusão, conforme fornecido pelo aplicativo em primeiro plano por meio de View#setSystemGestureExclusionRects(), mas fora de WindowInsets#getMandatorySystemGestureInsets(), NÃO PODEM ser interceptados para a função de navegação, desde que o retângulo de exclusão seja permitido dentro do limite máximo de exclusão, conforme especificado na documentação de View#setSystemGestureExclusionRects().
• [C-6-3] É OBRIGATÓRIO enviar ao app em primeiro plano um evento MotionEvent.ACTION_CANCEL quando os toques começarem a ser interceptados para um gesto do sistema, se o app em primeiro plano tiver recebido anteriormente um evento MotionEvent.ACTION_DOWN.
• [C-6-4] É OBRIGATÓRIO fornecer uma affordance para o usuário mudar para uma navegação baseada em botões na tela (por exemplo, nas Configurações).
• DEVE fornecer a função "Início" como um deslizar para cima da borda inferior da orientação atual da tela.
• DEVE fornecer a função "Recentes" como um gesto de deslizar para cima e segurar antes da liberação, na mesma área do gesto de "Início".
• Os gestos que começam dentro WindowInsets#getMandatorySystemGestureInsets() NÃO PODEM ser afetados por retângulos de exclusão fornecidos pelo aplicativo em primeiro plano usando View#setSystemGestureExclusionRects().

Se uma função de navegação for fornecida em qualquer lugar nas bordas esquerda e direita da orientação atual da tela:

• [C-7-1] A função de navegação PRECISA ser "Voltar" e ser fornecida como um deslizar das bordas esquerda e direita da orientação atual da tela.
• [C-7-2] Se painéis do sistema deslizáveis personalizados forem fornecidos nas bordas esquerda ou direita, eles PRECISAM ser colocados na parte superior de um terço da tela com uma indicação visual clara e persistente de que arrastar para dentro invocaria os painéis mencionados e, portanto, não a opção "Voltar". Um painel do sistema PODE ser configurado por um usuário para que ele fique abaixo da 1/3 superior das bordas da tela, mas o painel do sistema NÃO PODE usar mais de 1/3 das bordas.
• [C-7-3] Quando o app em primeiro plano tem as flags View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE definidas, o gesto de deslizar nas bordas PRECISA se comportar como implementado no AOSP, que é documentado no SDK.
• [C-7-4] Quando o app em primeiro plano tem as flags View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE definidas, painéis de sistema deslizáveis personalizados precisam ser ocultados até que o usuário os traga ou desfoque as barras do sistema (também conhecidas como barra de navegação e de status) conforme implementado no AOSP.

Se a função de navegação de volta for fornecida e o usuário cancelar o gesto "Voltar", então:

• [C-8-1] OnBackInvokedCallback.onBackCancelled() PRECISA ser chamado.
• [C-8-2] OnBackInvokedCallback.onBackInvoked() NÃO PODE ser chamado.
• [C-8-3] O evento KEYCODE_BACK NÃO deve ser enviado.

Se a função de navegação de retorno for fornecida, mas o aplicativo em primeiro plano NÃO tiver um OnBackInvokedCallback registrado, faça o seguinte:

• O sistema DEVE fornecer uma animação para o aplicativo em primeiro plano que sugere que o usuário está voltando, conforme fornecido no AOSP.

Se as implementações do dispositivo oferecerem suporte à API setNavBarMode do sistema para permitir que qualquer app do sistema com permissão android.permission.STATUS_BAR defina o modo da barra de navegação, elas:

• [C-9-1] É NECESSÁRIO oferecer suporte a ícones adequados para crianças ou navegação baseada em botões, conforme fornecido no código do AOSP.

7.2.4. Entrada por touchscreen

O Android oferece suporte a vários sistemas de entrada de ponteiro, como telas sensíveis ao toque, touchpads e dispositivos de entrada falsos. As implementações de dispositivos baseadas em tela touchscreen são associadas a uma tela de modo que o usuário tem a impressão de manipular itens diretamente na tela. Como o usuário toca diretamente na tela, o sistema não exige recursos adicionais para indicar os objetos que estão sendo manipulados.

Implementações de dispositivos:

• DEVE ter um sistema de entrada de ponteiro de algum tipo (semelhante a um mouse ou por toque).
• DEVE oferecer suporte a ponteiros rastreados de forma totalmente independente.

Se as implementações do dispositivo incluírem uma tela touchscreen (single-touch ou melhor) em uma tela principal compatível com o Android, elas:

• [C-1-1] É OBRIGATÓRIO informar TOUCHSCREEN_FINGER para o campo da API Configuration.touchscreen.
• [C-1-2] É OBRIGATÓRIO informar as flags de recursos android.hardware.touchscreen e android.hardware.faketouch.

Se as implementações do dispositivo incluírem uma tela touchscreen que pode rastrear mais de um toque em uma tela principal compatível com o Android, elas:

• [C-2-1] É OBRIGATÓRIO informar os flags de recursos apropriados android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct e android.hardware.touchscreen.multitouch.jazzhand correspondentes ao tipo de tela tátil específica no dispositivo.

Se as implementações do dispositivo dependerem de um dispositivo de entrada externo, como mouse ou trackball (ou seja, não tocar diretamente na tela) para entrada em uma tela principal compatível com Android e atender aos requisitos de toque falso na seção 7.2.5, elas:

• [C-3-1] NÃO DEVE informar nenhuma flag de recurso iniciada com android.hardware.touchscreen.
• [C-3-2] É PRECISO informar apenas android.hardware.faketouch.
• [C-3-3] É OBRIGATÓRIO informar TOUCHSCREEN_NOTOUCH para o campo Configuration.touchscreen da API.

7.2.5. Entrada por toque falsa

A interface de toque simulada fornece um sistema de entrada do usuário que aproxima um subconjunto de recursos de tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela se aproxima do toque, mas exige que o usuário primeiro aponte ou foco e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse aéreo baseado em giroscópio, ponteiro de giroscópio, joystick e trackpad multitoque, podem oferecer suporte a interações de toque falsas. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada não táctil (baseado em ponteiro) de alta fidelidade, como um mouse ou trackpad que pode emular adequadamente a entrada baseada em toque (incluindo suporte a gestos básicos) e indica que o dispositivo oferece suporte a um subconjunto emulado de recursos de tela touchscreen.

Se as implementações de dispositivos não incluírem uma tela touchscreen, mas incluírem outro sistema de entrada de ponteiro que elas queiram disponibilizar, elas:

• DEVE declarar suporte à flag de recurso android.hardware.faketouch.

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

• [C-1-1] É OBRIGATÓRIO informar as posições absolutas X e Y da tela do local do ponteiro e exibir um ponteiro visual na tela.
• [C-1-2] É OBRIGATÓRIO informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre no ponteiro descendo ou subindo na tela.
• [C-1-3] É NECESSÁRIO oferecer suporte ao ponteiro para baixo e para cima em um objeto na tela, o que permite que os usuários simulem o toque em um objeto na tela.
• [C-1-4] É PRECISO oferecer suporte ao ponteiro para baixo, ponteiro para cima, ponteiro para baixo e ponteiro para cima no mesmo local em um objeto na tela dentro de um limite de tempo, o que permite que os usuários emulem o toque duplo em um objeto na tela.
• [C-1-5] É PRECISO oferecer suporte ao ponteiro para baixo em um ponto arbitrário na tela, movimento do ponteiro para qualquer outro ponto arbitrário na tela, seguido por um ponteiro para cima, o que permite que os usuários emulem um arrasto por toque.
• [C-1-6] PRECISA oferecer suporte ao ponteiro para baixo e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, o ponteiro para cima na tela, permitindo que os usuários joguem um objeto na tela.

Se as implementações de dispositivos declararem suporte para android.hardware.faketouch.multitouch.distinct, elas:

• [C-2-1] É PRECISO declarar suporte para android.hardware.faketouch.
• [C-2-2] É NECESSÁRIO oferecer suporte a um rastreamento distinto de duas ou mais entradas de ponteiro independentes.

Se as implementações de dispositivos declararem suporte para android.hardware.faketouch.multitouch.jazzhand, elas:

• [C-3-1] É PRECISO declarar suporte para android.hardware.faketouch.
• [C-3-2] É NECESSÁRIO oferecer suporte a rastreamento distinto de 5 (rastreamento de uma mão de dedos) ou mais entradas de ponteiro de forma totalmente independente.

7.2.6. Suporte a controles de jogos

7.2.6.1. Mapeamentos de botões

Implementações de dispositivos:

• [C-1-1] É PRECISO que o sistema seja capaz de mapear eventos HID para as constantes InputEvent correspondentes, conforme listado nas tabelas abaixo. A implementação upstream do Android atende a esse requisito.

Se as implementações de dispositivos incorporarem um controlador ou forem enviadas com um controlador separado na caixa que ofereça meios para inserir todos os eventos listados nas tabelas abaixo, elas:

• [C-2-1] É PRECISO declarar a flag de recurso android.hardware.gamepad

Botão	Uso de HID^2	Botão do Android
A^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B^1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
S^1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Botão direcional para cima^1 Botão direcional para baixo^1	0x01 0x0039^3	AXIS_HAT_Y^4
D-pad para a esquerda1 D-pad para a direita^1	0x01 0x0039^3	AXIS_HAT_X^4
Botão de ombro esquerdo^1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Botão de ombro direito^1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clique no botão esquerdo^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clique no botão direito^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Voltar^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Os usos de HID acima precisam ser declarados em uma CA de gamepad (0x01 0x0005).

3 Esse uso precisa ter um mínimo lógico de 0, um máximo lógico de 7, um mínimo físico de 0, um máximo físico de 315, unidades em graus e um tamanho de relatório de 4. O valor lógico é definido como a rotação no sentido horário para longe do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e esquerda pressionadas.

4 MotionEvent

Controles analógicos^1	Uso de HID	Botão do Android
Gatilho esquerdo	0x02 0x00C5	AXIS_LTRIGGER
Gatilhos direito	0x02 0x00C4	AXIS_RTRIGGER
Joystick esquerdo	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick direito	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

Consulte a Seção 2.3.1 para ver os requisitos específicos do dispositivo.

7.3. Sensores

Se as implementações de dispositivo incluem um tipo de sensor específico que tem uma API correspondente para desenvolvedores de terceiros, a implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android e na documentação do Android Open Source sobre sensores.

Implementações de dispositivos:

• [C-0-1] É PRECISO informar com precisão a presença ou ausência de sensores por classe android.content.pm.PackageManager.
• [C-0-2] É PRECISO retornar uma lista precisa de sensores compatíveis usando SensorManager.getSensorList() e métodos semelhantes.
• [C-0-3] PRECISA se comportar de maneira razoável para todas as outras APIs de sensor (por exemplo, retornando true ou false conforme apropriado quando os aplicativos tentam registrar listeners, não chamando listeners de sensor quando os sensores correspondentes não estão presentes etc.).

Se as implementações de dispositivos incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, eles:

• [C-1-1] É OBRIGATÓRIO informar todas as medições do sensor usando os valores relevantes do Sistema Internacional de Unidades (métrico) para cada tipo de sensor, conforme definido na documentação do Android SDK.
• [C-1-2] É OBRIGATÓRIO informar dados do sensor com uma latência máxima de 100 milissegundos + 2 * sample_time para o caso de um fluxo de sensor com uma latência máxima solicitada de 0 ms quando o processador do aplicativo está ativo. Esse atraso não inclui atrasos de filtragem.
• [C-1-3] É OBRIGATÓRIO informar a primeira amostra do sensor em 400 milissegundos + 2 * sample_time do sensor sendo ativado. É aceitável que essa amostra tenha uma precisão de 0.
• [C-1-4] Para que qualquer API indicada pela documentação do SDK do Android seja um sensor contínuo, as implementações do dispositivo PRECISAM fornecer continuamente amostras de dados periódicas que DEVEM ter um jitter abaixo de 3%, em que o jitter é definido como a variação padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.
• [C-1-5] É NECESSÁRIO garantir que a transmissão de eventos do sensor NÃO impeça a CPU do dispositivo de entrar em um estado de suspensão ou de sair de um estado de suspensão.
• [C-1-6] É OBRIGATÓRIO informar o horário do evento em nanossegundos, conforme definido na documentação do SDK do Android, representando o horário em que o evento ocorreu e sincronizado com o SystemClock.elapsedRealtimeNano().
• [C-SR-1] É ALTAMENTE RECOMENDADO que o erro de sincronização de carimbo de data/hora seja inferior a 100 milissegundos e que o erro de sincronização de carimbo de data/hora seja inferior a 1 milissegundo.
• Quando vários sensores são ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia informado pelo sensor individual.

A lista acima não é abrangente. O comportamento documentado do SDK do Android e da documentação de código aberto do Android sobre sensores é considerado autorizado.

Se as implementações de dispositivos incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, eles:

• [C-1-6] É OBRIGATÓRIO definir uma resolução diferente de zero para todos os sensores e informar o valor pelo método da API Sensor.getResolution().

Alguns tipos de sensores são compostos, ou seja, podem ser derivados de dados fornecidos por um ou mais outros sensores. Por exemplo, o sensor de orientação e o sensor de aceleração linear.

Implementações de dispositivos:

• IMPLEMENTAR esses tipos de sensores, quando eles incluem os sensores físicos necessários, conforme descrito em tipos de sensores.

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

• [C-2-1] É PRECISO implementar o sensor conforme descrito na documentação de código aberto do Android sobre sensores compostos.

Se as implementações de dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados e o sensor informar apenas um valor, as implementações de dispositivo:

• [C-3-1] É OBRIGATÓRIO definir a resolução como 1 para o sensor e informar o valor pelo método de API Sensor.getResolution().

Se as implementações do dispositivo incluírem um tipo de sensor específico que ofereça suporte a SensorAdditionalInfo#TYPE_VEC3_CALIBRATION e o sensor for exposto a desenvolvedores terceirizados, eles:

• [C-4-1] NÃO inclua parâmetros de calibração fixos e determinados pela fábrica nos dados fornecidos.

Se as implementações do dispositivo incluem uma combinação de acelerômetro de três eixos, um sensor de giroscópio de três eixos ou um sensor de magnetômetro, elas são:

• [C-SR-2] É ALTAMENTE RECOMENDADO garantir que o acelerômetro, o giroscópio e o magnetômetro tenham uma posição relativa fixa, de modo que, se o dispositivo for transformável (por exemplo, dobrável), os eixos do sensor permaneçam alinhados e consistentes com o sistema de coordenadas do sensor em todos os estados de transformação possíveis do dispositivo.

7.3.1. Acelerômetro

Implementações de dispositivos:

• [C-SR-1] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

Se as implementações do dispositivo incluírem um acelerômetro, elas:

• [C-1-1] É PRECISO que o sistema consiga informar eventos com frequência de pelo menos 50 Hz.
• [C-1-3] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor Android conforme detalhado nas APIs do Android.
• [C-1-4] É PRECISO medir a queda livre até quatro vezes a gravidade(4g) ou mais em qualquer eixo.
• [C-1-5] PRECISA ter uma resolução de pelo menos 12 bits.
• [C-1-6] É OBRIGATÓRIO ter uma variação padrão não superior a 0,05 m/s^, em que a variação padrão precisa ser calculada por eixo em amostras coletadas durante um período de pelo menos 3 segundos na taxa de amostragem mais rápida.
• DEVE informar eventos de até 200 Hz.
• DEVE ter uma resolução de pelo menos 16 bits.
• DEVEM ser calibrados durante o uso se as características mudarem ao longo do ciclo de vida e forem compensadas, e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• DEVE ser compensada pela temperatura.

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

• [C-2-1] É PRECISO implementar e informar o sensor TYPE_ACCELEROMETER.
• [C-SR-4] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
• [C-SR-5] É ALTAMENTE RECOMENDADO implementar e informar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. É FORTEMENTE RECOMENDADO que os dispositivos Android atendam a esse requisito para que possam fazer upgrade para a versão futura da plataforma, quando isso se tornar OBRIGATÓRIO.
• DEVE implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER conforme descrito no documento do SDK do Android.

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

• [C-3-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
• [C-SR-6] É STRONGLY_RECOMMENDED implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos e qualquer um dos sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER forem implementados:

• [C-4-1] A soma do consumo de energia PRECISA ser sempre menor que 4 mW.
• CADA UM DEVE ESTAR ABAIXO DE 2 mW E 0,5 mW QUANDO O DISPOSITIVO ESTIVER EM UMA CONDIÇÃO DINÂMICA OU ESTÁTICA.

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

• [C-5-1] É OBRIGATÓRIO implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR-7] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos, um sensor de giroscópio de três eixos e um sensor de magnetômetro, elas:

• [C-6-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

7.3.2. Magnetômetro

Implementações de dispositivos:

• [C-SR-1] É ALTAMENTE RECOMENDADO incluir um magnetômetro de 3 eixos (bússola).

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

• [C-1-1] É PRECISO implementar o sensor TYPE_MAGNETIC_FIELD.
• [C-1-2] PRECISA ser capaz de informar eventos com frequência de pelo menos 10 Hz e DEVE informar eventos com frequência de pelo menos 50 Hz.
• [C-1-3] É NECESSÁRIO obedecer ao sistema de coordenadas do sensor Android, conforme detalhado nas APIs do Android.
• [C-1-4] É PRECISO medir entre -900 µT e +900 µT em cada eixo antes da saturação.
• [C-1-5] É PRECISO ter um valor de deslocamento de ferro rígido menor que 700 µT e um valor abaixo de 200 µT, colocando o magnetômetro longe de campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímã).
• [C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 µT.
• [C-1-7] É PRECISO oferecer suporte à calibração on-line e compensação da polarização de ferro rígido e preservar os parâmetros de compensação entre reinicializações do dispositivo.
• [C-1-8] A compensação de ferro macio PRECISA ser aplicada. A calibração pode ser feita durante o uso ou durante a produção do dispositivo.
• [C-1-9] É PRECISO ter uma variação padrão, calculada por eixo em amostras coletadas por um período de pelo menos 3 segundos na taxa de amostragem mais rápida, não superior a 1,5 µT. É NECESSÁRIO ter uma variação padrão não superior a 0,5 µT.
• [C-1-10] É PRECISO implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se as implementações do dispositivo incluem um magnetômetro de três eixos, um sensor de acelerômetro e um sensor de giroscópio de três eixos, elas:

• [C-2-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

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

• PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

• [C-3-1] PRECISA consumir menos de 10 mW.
• CONSUMARÁ menos de 3 mW quando o sensor estiver registrado para o modo lote a 10 Hz.

7.3.3. GPS

Implementações de dispositivos:

• [C-SR-1] É ALTAMENTE RECOMENDADO incluir um receptor GPS/GNSS.

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

• [C-1-1] É PRECISO oferecer suporte a saídas de localização com uma taxa de pelo menos 1 Hz quando solicitado por LocationManager#requestLocationUpdate.
• [C-1-2] É PRECISO determinar o local em condições de céu aberto (sinais fortes, multicaminho desprezível, HDOP < 2) em até 10 segundos (tempo rápido até a primeira correção), quando conectado a uma conexão de Internet de dados de 0,5 Mbps ou mais rápida. Esse requisito geralmente é atendido pelo uso de alguma técnica de GPS/GNSS assistida ou prevista para minimizar o tempo de bloqueio do GPS/GNSS. Os dados de assistência incluem a hora de referência, a localização de referência e a efeméride/relógio do satélite.
  • [C-1-6] Depois de fazer esse cálculo de localização, as implementações do dispositivo PRECISAM determinar a localização, em céu aberto, em até 5 segundos, quando as solicitações de localização forem reiniciadas, até uma hora após o cálculo inicial de localização, mesmo quando a solicitação subsequente for feita sem uma conexão de dados e/ou após um ciclo de energia.

• Em condições de céu aberto, depois de determinar o local, enquanto estiver parado ou se movendo com menos de 1 metro por segundo ao quadrado de aceleração:

  • [C-1-3] É PRECISO determinar a localização em até 20 metros e a velocidade em até 0, 5 metro por segundo, pelo menos 95% do tempo.
  • [C-1-4] É necessário rastrear e informar simultaneamente via GnssStatus.Callback pelo menos 8 satélites de uma constelação.
  • DEVE ser capaz de rastrear simultaneamente pelo menos 24 satélites de várias constelações (por exemplo, GPS + pelo menos um de Glonass, Beidou, Galileu).

• [C-SR-2] É ALTAMENTE RECOMENDADO continuar a fornecer saídas de localização GPS/GNSS normais usando a API GNSS Location Provider durante uma chamada de emergência por telefone.

• [C-SR-3] É ALTAMENTE RECOMENDADO informar as medições GNSS de todas as constelações rastreadas (conforme informado nas mensagens GnssStatus), com exceção do SBAS.

• [C-SR-4] É ALTAMENTE RECOMENDADO informar o AGC e a frequência da medição do GNSS.

• [C-SR-5] É ALTAMENTE RECOMENDADO informar todas as estimativas de precisão (incluindo a direção, a velocidade e a vertical) como parte de cada local de GPS/GNSS.

• [C-SR-6] É ALTAMENTE RECOMENDADO informar as medições GNSS assim que elas forem encontradas, mesmo que um local calculado pelo GPS/GNSS ainda não tenha sido informado.

• [C-SR-7] É ALTAMENTE RECOMENDADO informar pseudorastros e taxas de pseudorastro do GNSS que, em condições de céu aberto após a determinação do local, estacionados ou em movimento com menos de 0,2 metros por segundo ao quadrado de aceleração, são suficientes para calcular a posição em até 20 metros e a velocidade em até 0, 2 metros por segundo, pelo menos 95% do tempo.

7.3.4. Giroscópio

Implementações de dispositivos:

• [C-SR-1] É ALTAMENTE RECOMENDADO incluir um sensor de giroscópio.

Se as implementações do dispositivo incluírem um giroscópio, elas:

• [C-1-1] É PRECISO que o sistema consiga informar eventos com frequência de pelo menos 50 Hz.
• [C-1-4] PRECISA ter uma resolução de 12 bits ou mais.
• [C-1-5] É PRECISO compensar a temperatura.
• [C-1-6] DEVE ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• [C-1-7] PRECISA ter uma variação não maior que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar com a taxa de amostragem, mas PRECISA ser limitada por esse valor. Em outras palavras, se você medir a variação do giroscópio com uma taxa de amostragem de 1 Hz, ela NÃO PODE ser maior do que 1e-7 rad^2/s^2.
• [C-SR-2] É ALTAMENTE RECOMENDÁVEL que o erro de calibração seja menor que 0,01 rad/s quando o dispositivo estiver parado à temperatura ambiente.
• [C-SR-3] É ALTAMENTE RECOMENDADO ter uma resolução de 16 bits ou mais.
• DEVE informar eventos de até 200 Hz.

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

• [C-2-1] É PRECISO implementar o sensor TYPE_GYROSCOPE.
• [C-SR-4] É altamente recomendável implementar o sensor TYPE_GYROSCOPE_UNCALIBRATED.

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

• [C-3-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] É STRONGLY_RECOMMENDED implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Se as implementações do dispositivo incluem um giroscópio de três eixos, um sensor de acelerômetro e um sensor de magnetômetro, elas:

• [C-4-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

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

• [C-5-1] É PRECISO implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR-6] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

Implementações de dispositivos:

• [C-SR-1] É ALTAMENTE RECOMENDADO incluir um barômetro (sensor de pressão do ar ambiente).

Se as implementações do dispositivo incluírem um barômetro, elas:

• [C-1-1] É PRECISO implementar e informar o sensor TYPE_PRESSURE.
• [C-1-2] É PRECISO enviar eventos a 5 Hz ou mais.
• [C-1-3] É PRECISO compensar a temperatura.
• [C-SR-2] É ALTAMENTE RECOMENDADO que seja possível informar medições de pressão no intervalo de 300 a 1.100 hPa.
• Deve ter uma precisão absoluta de 1hPa.
• DEVE ter uma precisão relativa de 0,12hPa em um intervalo de 20hPa (equivalente a uma precisão de aproximadamente 1 m em uma mudança de aproximadamente 200 m no nível do mar).

7.3.6. Termômetro

Se as implementações do dispositivo incluírem um termômetro ambiente (sensor de temperatura), elas:

• [C-1-1] É PRECISO definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura ambiente, e o sensor PRECISA medir a temperatura ambiente (cabine do veículo/sala) de onde o usuário está interagindo com o dispositivo em graus Celsius.

Se as implementações do dispositivo incluírem um sensor de termômetro que mede uma temperatura diferente da ambiente, como a da CPU, elas:

• [C-2-1] DEFINIR SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura.

Se as implementações do dispositivo incluírem um sensor para monitorar a temperatura da pele, elas:

• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à API PowerManager.getThermalHeadroom.

7.3.7. Fotômetro

• As implementações de dispositivos PODEM incluir um fotômetro (sensor de luz ambiente).

7.3.8. Sensor de proximidade

• As implementações de dispositivos PODEM incluir um sensor de proximidade.

Se as implementações do dispositivo incluírem um sensor de proximidade e informarem apenas uma leitura binária "perto" ou "longe", elas:

• [C-1-1] É NECESSÁRIO medir a proximidade de um objeto na mesma direção da tela. Ou seja, o sensor de proximidade PRECISA ser orientado para detectar objetos próximos à tela, já que a intenção principal desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se as implementações do dispositivo incluírem um sensor de proximidade com qualquer outra orientação, ele NÃO PODE ser acessível por essa API.
• [C-1-2] PRECISA ter precisão de 1 bit ou mais.
• [C-1-3] É OBRIGATÓRIO usar 0 centímetros como a leitura próxima e 5 centímetros como a leitura distante.
• [C-1-4] É OBRIGATÓRIO informar um intervalo máximo e uma resolução de 5.

7.3.9. Sensores de alta fidelidade

Se as implementações de dispositivos incluírem um conjunto de sensores de maior qualidade, conforme definido nesta seção, e os disponibilizarem para apps de terceiros, elas:

• [C-1-1] É OBRIGATÓRIO identificar o capability usando a flag de recurso android.hardware.sensor.hifi_sensors.

Se as implementações do dispositivo declararem android.hardware.sensor.hifi_sensors, elas:

• [C-2-1] É PRECISO ter um sensor TYPE_ACCELEROMETER que:

  • PRECISA ter um intervalo de medição entre pelo menos -8g e +8g, e é ALTAMENTE RECOMENDADO ter um intervalo de medição entre pelo menos -16g e +16g.
  • PRECISA ter uma resolução de medição de pelo menos 2048 LSB/g.
  • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou inferior.
  • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais; DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
  • O ruído de medição não pode exceder 400 μg/√Hz.
  • É necessário implementar um formulário de não ativação desse sensor com uma capacidade de buffer de pelo menos 3.000 eventos do sensor.
  • O consumo de energia em lote precisa ser de no máximo 3 mW.
  • [C-SR-1] É ALTAMENTE RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
  • DEVE ter uma caminhada aleatória de aceleração menor que 30 μg √Hz testada à temperatura ambiente.
  • DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 1 mg/°C.
  • DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,5% e uma mudança de sensibilidade em relação à temperatura de ≤ 0,03%/C°.
  • DEVE ter uma sensibilidade no eixo transversal de < 2,5 % e uma variação de sensibilidade no eixo transversal de < 0,2% na faixa de temperatura de operação do dispositivo.

• [C-2-2] É PRECISO ter um TYPE_ACCELEROMETER_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_ACCELEROMETER.

• [C-2-3] É PRECISO ter um sensor TYPE_GYROSCOPE que:

  • PRECISA ter um intervalo de medição entre pelo menos -1000 e +1000 dps.
  • PRECISA ter uma resolução de medição de pelo menos 16 LSB/dps.
  • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou inferior.
  • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais; DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
  • O ruído de medição não pode ser superior a 0,014°/s/√Hz.
  • [C-SR-2] É ALTAMENTE RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
  • DEVE ter uma taxa de caminhada aleatória menor que 0,001 °/s √Hz testada à temperatura ambiente.
  • DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 0,05 °/ s / °C.
  • DEVE ter uma mudança de sensibilidade em relação à temperatura de ≤ 0,02% / °C.
  • DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,2%.
  • DEVE ter uma densidade de ruído de ≤ 0,007 °/s/√Hz.
  • DEVE ter um erro de calibração menor que 0,002 rad/s no intervalo de temperatura de 10 a 40 ℃ quando o dispositivo estiver parado.
  • DEVE ter uma sensibilidade de gravidade menor que 0,1°/s/g.
  • DEVE ter uma sensibilidade no eixo transversal de < 4,0 % e uma variação de sensibilidade no eixo transversal de < 0,3% no intervalo de temperatura de operação do dispositivo.

• [C-2-4] É PRECISO ter um TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade que TYPE_GYROSCOPE.

• [C-2-5] É PRECISO ter um sensor TYPE_GEOMAGNETIC_FIELD que:

  • PRECISA ter um intervalo de medição entre pelo menos -900 e +900 μT.
  • É PRECISO ter uma resolução de medição de pelo menos 5 LSB/uT.
  • PRECISA ter uma frequência de medição mínima de 5 Hz ou menor.
  • PRECISA ter uma frequência de medição máxima de 50 Hz ou mais.
  • Deve ter um ruído de medição não superior a 0,5 uT.

• [C-2-6] É PRECISO ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_GEOMAGNETIC_FIELD e, além disso:

  • É necessário implementar um formulário de não ativação desse sensor com uma capacidade de buffer de pelo menos 600 eventos do sensor.
  • [C-SR-3] É ALTAMENTE RECOMENDADO ter um espectro de ruído branco de 1 Hz a pelo menos 10 Hz quando a taxa de relatório for de 50 Hz ou mais.

• [C-2-7] É OBRIGATÓRIO ter um sensor TYPE_PRESSURE que:

  • PRECISA ter um intervalo de medição entre pelo menos 300 e 1.100 hPa.
  • PRECISA ter uma resolução de medição de pelo menos 80 LSB/hPa.
  • Deve ter uma frequência de medição mínima de 1 Hz ou inferior.
  • PRECISA ter uma frequência máxima de medição de 10 Hz ou mais.
  • O ruído de medição não pode exceder 2 Pa/√Hz.
  • É PRECISO implementar um formulário de não ativação desse sensor com uma capacidade de buffer de pelo menos 300 eventos de sensor.
  • O consumo de energia em lote precisa ser de no máximo 2 mW.

• [C-2-8] É PRECISO ter um sensor TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] É OBRIGATÓRIO ter um sensor TYPE_SIGNIFICANT_MOTION que:

  • O consumo de energia precisa ser de no máximo 0,5 mW quando o dispositivo está estático e de 1,5 mW quando ele está em movimento.

• [C-2-10] É PRECISO ter um sensor TYPE_STEP_DETECTOR que:

  • É necessário implementar um formulário de não ativação desse sensor com uma capacidade de buffer de pelo menos 100 eventos do sensor.
  • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo está estático e de 1,5 mW quando o dispositivo está em movimento.
  • O consumo de energia em lote precisa ser de no máximo 4 mW.

• [C-2-11] É PRECISO ter um sensor TYPE_STEP_COUNTER que:

  • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo está estático e de 1,5 mW quando o dispositivo está em movimento.

• [C-2-12] É PRECISO ter um sensor TILT_DETECTOR que:

  • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo está estático e de 1,5 mW quando o dispositivo está em movimento.

• [C-2-13] O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro, pelo giroscópio e pelo magnetômetro PRECISA estar a até 2, 5 milissegundos um do outro. O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro e pelo giroscópio DEVE estar dentro de 0,25 milissegundos um do outro.

• [C-2-14] É OBRIGATÓRIO ter carimbos de data/hora de eventos do sensor de giroscópio na mesma base de tempo que o subsistema da câmera e com um erro de até 1 milissegundo.

• [C-2-15] É NECESSÁRIO enviar amostras para os aplicativos em até 5 milissegundos a partir do momento em que os dados estão disponíveis em qualquer um dos sensores físicos acima para o aplicativo.

• [C-2-16] NÃO PODE ter um consumo de energia maior que 0,5 mW quando o dispositivo está estático e 2,0 mW quando o dispositivo está em movimento quando qualquer combinação dos seguintes sensores está ativada:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] PODE ter um sensor TYPE_PROXIMITY, mas, se estiver presente, PRECISA ter uma capacidade de buffer mínima de 100 eventos do sensor.

Todos os requisitos de consumo de energia nesta seção não incluem o consumo de energia do processador de aplicativos. Ele inclui a energia gerada por toda a cadeia de sensores, o sensor, qualquer circuito de suporte, qualquer sistema de processamento de sensores dedicado etc.

Se as implementações de dispositivos incluem suporte a sensores diretos, elas:

• [C-3-1] É OBRIGATÓRIO declarar corretamente o suporte a tipos de canal direto e ao nível de taxas de relatórios diretos usando a API isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
• [C-3-2] É PRECISO oferecer suporte a pelo menos um dos dois tipos de canal direto do sensor para todos os sensores que declaram suporte ao canal direto do sensor.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DEVE oferecer suporte à geração de relatórios de eventos pelo canal direto do sensor para o sensor principal (variante sem ativação) dos seguintes tipos:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensores biométricos

Para mais informações sobre como medir a segurança do desbloqueio biométrico, consulte Documentação sobre como medir a segurança biométrica.

Se as implementações do dispositivo incluem uma tela de bloqueio segura, elas:

• DEVE incluir um sensor biométrico

Os sensores biométricos podem ser classificados como Classe 3 (antes Forte), Classe 2 (antes Fraco) ou Classe 1 (antes Conveniente) com base nas taxas de falsificação e aceitação de impostores e na segurança do pipeline biométrico. Essa classificação determina os recursos que o sensor biométrico tem para interagir com a plataforma e com aplicativos de terceiros. Os sensores precisam atender a outros requisitos, conforme detalhado abaixo, se quiserem ser classificados como Classe 1, Classe 2 ou Classe 3. A biometria de Classe 2 e Classe 3 recebe recursos adicionais, conforme detalhado abaixo.

Se as implementações do dispositivo disponibilizarem um sensor biométrico para apps de terceiros por meio de android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, eles:

• [C-4-1] É OBRIGATÓRIO atender aos requisitos de biometria de Classe 3 ou Classe 2, conforme definido neste documento.
• [C-4-2] DEVE reconhecer e honrar cada nome de parâmetro definido como uma constante na classe Authenticators e qualquer combinação dela. Por outro lado, NÃO É PERMITIDO reconhecer ou honrar constantes de número inteiro transmitidas para os métodos canAuthenticate(int) e setAllowedAuthenticators(int) diferentes daqueles documentados como constantes públicas em Authenticators e qualquer combinação deles.
• [C-4-3] É PRECISO implementar a ação ACTION_BIOMETRIC_ENROLL em dispositivos que tenham biometria de Classe 3 ou Classe 2. Essa ação PRECISA apresentar apenas os pontos de entrada de inscrição para biometria de Classe 3 ou Classe 2.

Se as implementações de dispositivos forem compatíveis com a biometria passiva, elas:

• [C-5-1] POR PADRÃO, É NECESSÁRIO exigir uma etapa de confirmação extra (por exemplo, pressionar um botão).
• [C-SR-1] É ALTAMENTE RECOMENDADO ter uma configuração que permita aos usuários substituir a preferência do aplicativo e sempre exigir uma etapa de confirmação.
• [C-SR-2] É ALTAMENTE RECOMENDADO que a ação de confirmação seja protegida para que um comprometimento do sistema operacional ou do kernel não possa ser falsificado. Por exemplo, isso significa que a ação de confirmação baseada em um botão físico é roteada por um pino de entrada/saída (GPIO) de uso geral de um elemento seguro (SE) que não pode ser controlado por nenhum outro meio além de uma pressão de botão físico.
• [C-5-2] É necessário implementar um fluxo de autenticação implícita (sem etapa de confirmação) correspondente a setConfirmationRequired(boolean), que os aplicativos podem definir para usar nos fluxos de login.

Se as implementações de dispositivos tiverem vários sensores biométricos, elas:

• [C-SR-3] É ALTAMENTE RECOMENDADO exigir que apenas uma biometria seja confirmada por autenticação. Por exemplo, se os sensores de impressão digital e facial estiverem disponíveis no dispositivo, onAuthenticationSucceeded será enviado depois que qualquer um deles for confirmado.

Para que as implementações de dispositivos permitam o acesso a chaves do keystore a aplicativos de terceiros, elas:

• [C-6-1] PRECISA atender aos requisitos da Classe 3, conforme definido nesta seção abaixo.
• [C-6-2] É PRECISO apresentar apenas biometria de Classe 3 quando a autenticação requer BIOMETRIC_STRONG ou a autenticação é invocada com um CryptoObject.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 1 (anteriormente Convenience), elas:

• [C-1-1] É PRECISO ter uma taxa de aceitação falsa menor que 0,002%.
• [C-1-2] É OBRIGATÓRIO divulgar que esse modo pode ser menos seguro que um PIN, padrão ou senha fortes e listar claramente os riscos de ativá-lo, se as taxas de aceitação de falsificação e de impostor forem maiores que 7%, conforme medido pelos protocolos de teste de biometria do Android.
• [C-1-9] É OBRIGATÓRIO solicitar ao usuário a autenticação principal recomendada (por exemplo, PIN, padrão, senha) após no máximo 20 tentativas falsas e no mínimo 90 segundos de tempo de espera para a verificação biométrica, em que uma tentativa falsa é uma com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
• [C-SR-4] É ALTAMENTE RECOMENDADO reduzir o número total de tentativas falsas de verificação biométrica especificadas em [C-1-9] se as taxas de spoofing e de imitação forem maiores que 7%, conforme medido pelos protocolos de teste de biometria do Android.
• [C-1-3] É OBRIGATÓRIO limitar a taxa de tentativas de verificação biométrica, em que uma tentativa falsa é aquela com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
• [C-SR-5] É ALTAMENTE RECOMENDADO limitar a taxa de tentativas por pelo menos 30 segundos após cinco tentativas falsas de verificação biométrica para o número máximo de tentativas falsas por [C-1-9], em que uma tentativa falsa é uma com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
• [C-SR-6] É ALTAMENTE RECOMENDADO ter toda a lógica de limitação de taxa no TEE.
• [C-1-10] É PRECISO desativar a biometria quando o backoff da autenticação principal for acionado pela primeira vez, conforme descrito em [C-0-2] da seção 9.11.
• [C-1-11] É PRECISO ter uma taxa de aceitação de falsificação e impostor não superior a 30%, com (1) uma taxa de aceitação de falsificação e impostor para o nível A do instrumento de ataque de apresentação (PAI, na sigla em inglês) não superior a 30% e (2) uma taxa de aceitação de falsificação e impostor de espécies de PAI de nível B não superior a 40%, conforme medido pelos protocolos de teste de biometria do Android.
• [C-1-4] É PRECISO impedir a adição de novas biometrias sem primeiro estabelecer uma cadeia de confiança, fazendo com que o usuário confirme ou adicione uma nova credencial de dispositivo (PIN/padrão/senha) protegida pelo TEE. A implementação do Projeto de código aberto do Android fornece o mecanismo no framework para fazer isso.
• [C-1-5] É OBRIGATÓRIO remover completamente todos os dados biométricos identificáveis de um usuário quando a conta dele for removida (inclusive por redefinição para a configuração original).
• [C-1-6] É PRECISO honrar a flag individual para essa biometria (ou seja, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] É OBRIGATÓRIO solicitar ao usuário a autenticação primária recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 24 horas ou menos. Observação: o upgrade de dispositivos lançados no Android versão 9 ou anterior PRECISA exigir a autenticação primária recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos.
• [C-1-8] É OBRIGATÓRIO solicitar ao usuário a autenticação principal recomendada (por exemplo, PIN, padrão, senha) ou a biometria de Classe 3 (FORTE) após uma das seguintes ações:
  • um período de inatividade de 4 horas OU
  • Três tentativas de autenticação biométrica com falha.
  • O período de tempo limite de inatividade e a contagem de falhas de autenticação são redefinidos após qualquer confirmação bem-sucedida das credenciais do dispositivo. Observação: o upgrade de dispositivos lançados no Android versão 9 ou anterior pode ser dispensado da C-1-8.
• [C-SR-7] É ALTAMENTE RECOMENDADO usar a lógica no framework fornecido pelo Projeto Android Open Source para aplicar restrições especificadas em [C-1-7] e [C-1-8] para novos dispositivos.
• [C-SR-8] É ALTAMENTE RECOMENDADO ter uma taxa de rejeição falsa inferior a 10%, conforme medido no dispositivo.
• [C-SR-9] É ALTAMENTE RECOMENDADO ter uma latência abaixo de 1 segundo, medida desde a detecção da biometria até o desbloqueio da tela, para cada biometria registrada.

Se as implementações de dispositivo quiserem tratar um sensor biométrico como Classe 2 (anteriormente Fraco), elas:

• [C-2-1] É PRECISO atender a todos os requisitos da Classe 1 acima.

• [C-2-2] É PRECISO ter uma taxa de aceitação de falsificação e impostor não superior a 20%, com (1) uma taxa de aceitação de falsificação e impostor para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) de nível A não superior a 20% e (2) uma taxa de aceitação de falsificação e impostor de espécies de PAI de nível B não superior a 30%, conforme medido pelos protocolos de teste de biometria do Android.

• [C-2-3] É OBRIGATÓRIO realizar a correspondência biométrica em um ambiente de execução isolado fora do espaço do usuário ou do kernel do Android, como o ambiente de execução confiável (TEE) ou em um chip com um canal seguro para o ambiente de execução isolado.

• [C-2-4] É PRECISO que todos os dados identificáveis sejam criptografados e autenticados criptograficamente, de modo que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação no site do Projeto Android Open Source.

• [C-2-5] Para biometria baseada em câmera, enquanto a autenticação ou o registro biométrico está acontecendo:

  • PRECISA operar a câmera em um modo que impeça que os frames da câmera sejam lidos ou alterados fora do ambiente de execução isolado ou um chip com um canal seguro para o ambiente de execução isolado.
  • Para soluções de câmera RGB única, os frames da câmera PODEM ser legíveis fora do ambiente de execução isolado para oferecer suporte a operações como a visualização para registro, mas ELES NÃO PODEM ser alterados.

• [C-2-6] NÃO é permitido permitir que aplicativos de terceiros distingam entre cada registro biométrico individual.

• [C-2-7] NÃO É PERMITIDO permitir acesso não criptografado a dados biométricos identificáveis ou a qualquer dado derivado deles (como incorporações) ao processador de aplicativos fora do contexto do TEE. A atualização de dispositivos lançados no Android versão 9 ou anterior não está isenta da C-2-7.

• [C-2-8] É OBRIGATÓRIO ter um pipeline de processamento seguro para que um comprometimento do sistema operacional ou do kernel não permita que dados sejam injetados diretamente para autenticação falsa como o usuário. Observação: se as implementações do dispositivo já foram lançadas no Android versão 9 ou anterior e não puderem atender ao requisito C-2-8 com uma atualização do software do sistema, elas PODEM ser isentas do requisito.

• [C-SR-10] É ALTAMENTE RECOMENDADO incluir a detecção de vida para todas as modalidades biométricas e a detecção de atenção para biometria facial.

• [C-2-9] É OBRIGATÓRIO disponibilizar o sensor biométrico para apps de terceiros.

Se as implementações de dispositivo quiserem tratar um sensor biométrico como Classe 3 (antes Forte), elas:

• [C-3-1] É OBRIGATÓRIO atender a todos os requisitos da classe 2 acima, exceto [C-1-7] e [C-1-8].
• [C-3-2] É OBRIGATÓRIO ter uma implementação de keystore protegida por hardware.
• [C-3-3] É PRECISO ter uma taxa de aceitação de falsificação e impostor não superior a 7%, com (1) uma taxa de aceitação de falsificação e impostor para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) de nível A não superior a 7% e (2) uma taxa de aceitação de falsificação e impostor de espécies de PAI de nível B não superior a 20%, conforme medido pelos protocolos de teste de biometria do Android.
• [C-3-4] É OBRIGATÓRIO solicitar ao usuário a autenticação primária recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos.
• [C-3-5] É PRECISO gerar novamente o ID do autenticador para todos os métodos biométricos de classe 3 compatíveis com o dispositivo se algum deles for reinserido.
• [C-3-6] É necessário ativar chaves de keystore com suporte biométrico para aplicativos de terceiros.

Se as implementações do dispositivo contiverem um sensor de impressão digital sob a tela (UDFPS), elas:

• [C-SR-11] É ALTAMENTE RECOMENDADO impedir que a área sensível ao toque do UDFPS interfira na navegação de três botões, que alguns usuários podem exigir para fins de acessibilidade.

7.3.11. Sensor de pose

Implementações de dispositivos:

• PODE oferecer suporte ao sensor de pose com 6 graus de liberdade.

Se as implementações de dispositivos oferecerem suporte ao sensor de pose com seis graus de liberdade, elas:

• [C-1-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_POSE_6DOF.
• [C-1-2] PRECISA ser mais preciso do que o vetor de rotação sozinho.

7.3.12. Sensor de ângulo de dobradiça

Se as implementações de dispositivo oferecerem suporte a um sensor de ângulo de articulação, elas:

• [C-1-1] É OBRIGATÓRIO implementar e informar TYPE_HINGLE_ANGLE.
• [C-1-2] PRECISA oferecer suporte a pelo menos duas leituras entre 0 e 360 graus (incluindo 0 e 360 graus).
• [C-1-3] É PRECISO retornar um sensor de ativação para getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 [Mudou para 7.4.9]

7.4. Conectividade de dados

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android e neste documento, se refere especificamente a hardware relacionado a fazer chamadas de voz e enviar mensagens SMS por uma rede GSM ou CDMA. Embora essas ligações de voz possam ou não ser comutadas por pacotes, elas são consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade e as APIs de "telefonia" do Android se referem especificamente a chamadas de voz e SMS. Por exemplo, implementações de dispositivos que não podem fazer ligações ou enviar/receber mensagens SMS não são consideradas dispositivos de telefonia, mesmo que usem uma rede celular para conectividade de dados.

• O Android PODE ser usado em dispositivos que não incluem hardware de telefonia. Ou seja, o Android é compatível com dispositivos que não são smartphones.

Se as implementações de dispositivos incluírem telefonia GSM ou CDMA, elas:

• [C-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.telephony e outras flags de subrecurso de acordo com a tecnologia.
• [C-1-2] É PRECISO implementar suporte total à API para essa tecnologia.
• DEVEM permitir todos os tipos de serviço celular disponíveis (2G, 3G, 4G, 5G etc.) durante chamadas de emergência (independentemente dos tipos de rede definidos por SetAllowedNetworkTypeBitmap()).

Se as implementações de dispositivos não incluírem hardware de telefonia, elas:

• [C-2-1] É OBRIGATÓRIO implementar as APIs completas como no-ops.

Se as implementações de dispositivos oferecerem suporte a eUICCs ou eSIMs/chips integrados e incluírem um mecanismo reservado para disponibilizar a funcionalidade de eSIM para desenvolvedores de terceiros, eles:

• [C-3-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.telephony.euicc.

Se as implementações do dispositivo não definirem a propriedade do sistema ro.telephony.iwlan\_operation\_mode como "legado", elas:

• [C-4-1] NÃO DEVE informar NETWORK_TYPE_IWLAN usando NetworkRegistrationInfo#getAccessNetworkTechnology() quando NetworkRegistrationInfo#getTransportType() for informado como TRANSPORT_TYPE_WWAN para a mesma instância de NetworkRegistrationInfo.

Se as implementações de dispositivos oferecerem suporte a um único registro de subsistema multimídia IP (IMS, na sigla em inglês) para os recursos de serviço de telefonia multimídia (MMTEL) e serviço de comunicação avançado (RCS) e forem compatíveis com os requisitos da operadora de celular em relação ao uso de um único registro de IMS para todo o tráfego de sinalização de IMS, elas:

• [C-5-1] É PRECISO declarar a flag de recurso android.hardware.telephony.ims e fornecer uma implementação completa da API ImsService para MMTEL e RCS API User Capability Exchange.
• [C-5-2] É PRECISO declarar a flag de recurso android.hardware.telephony.ims.singlereg e fornecer uma implementação completa da API SipTransport, da API GbaService, indicações de portador dedicadas usando o HAL IRadio 1.6 e provisionamento por um servidor de configuração automática (ACS) ou outro mecanismo de provisionamento proprietário usando a API IMS Configuration.

Se as implementações de dispositivos informarem o recurso android.hardware.telephony, faça o seguinte:

• [C-6-1] O SmsManager#sendTextMessage e o SmsManager#sendMultipartTextMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer a funcionalidade de mensagens de texto. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer a funcionalidade de mensagens multimídia.
• [C-6-2] O aplicativo designado por android.provider.Telephony.Sms#getDefaultSmsPackage PRECISA usar as APIs SmsManager ao enviar e receber mensagens SMS e MMS. A implementação de referência do AOSP em packages/apps/Messaging atende a esse requisito.
• [C-6-3] O aplicativo que responde a Intent#ACTION_DIAL PRECISA oferecer suporte à entrada de códigos de discagem arbitrários formatados como *#*#CODE#*#* e acionar uma transmissão TelephonyManager#ACTION_SECRET_CODE correspondente.
• [C-6-4] O aplicativo que responde a Intent#ACTION_DIAL PRECISA usar VoicemailContract.Voicemails#TRANSCRIPTION para mostrar a transcrição visual do correio de voz aos usuários, se ele oferece suporte a transcrições visuais do correio de voz.
• [C-6-5] PRECISA representar todos os SubscriptionInfo com UUIDs de grupo equivalentes como uma única assinatura em todos os affordances visíveis para o usuário que mostram e controlam as informações do chip SIM. Exemplos de affordances incluem interfaces de configurações que correspondem a Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
• [C-6-6] NÃO PRECISA mostrar ou permitir o controle de nenhuma SubscriptionInfo com um UUID de grupo não nulo e um bit oportunista em nenhuma característica visível para o usuário que permite a configuração ou o controle das configurações do cartão SIM.

Se as implementações do dispositivo informarem o recurso android.hardware.telephony e fornecerem uma barra de status do sistema, faça o seguinte:

• [C-7-1] É OBRIGATÓRIO selecionar uma assinatura ativa representativa para um determinado UUID de grupo para mostrar ao usuário em qualquer recurso que forneça informações de status do SIM. Exemplos de affordances incluem o ícone de sinal de celular da barra de status ou o bloco de Configurações rápidas.
• [C-SR-1] É ALTAMENTE RECOMENDADO que a assinatura representativa seja escolhida para ser a assinatura de dados ativa, a menos que o dispositivo esteja em uma chamada de voz, durante a qual é ALTAMENTE RECOMENDADO que a assinatura representativa seja a assinatura de voz ativa.

Se as implementações de dispositivos informarem o recurso android.hardware.telephony, faça o seguinte:

• [C-6-7] É PRECISO ser capaz de abrir e usar simultaneamente o número máximo de canais lógicos (20 no total) para cada UICC de acordo com o ETSI TS 102 221.
• [C-6-8] NENHUM dos comportamentos a seguir pode ser aplicado a apps de operadora ativos (designados por TelephonyManager#getCarrierServicePackageName) automaticamente ou sem a confirmação explícita do usuário:
  • Revogar ou limitar o acesso à rede
  • Revogar permissões
  • Restringir a execução de apps em segundo plano ou em primeiro plano além dos recursos de gerenciamento de energia incluídos no AOSP
  • Desativar ou desinstalar o app

Se as implementações do dispositivo informarem o recurso android.hardware.telephony e todas as assinaturas não oportunísticas ativas que compartilham um UUID de grupo forem desativadas, removidas fisicamente do dispositivo ou marcadas como oportunísticas, o dispositivo:

• [C-8-1] É OBRIGATÓRIO desativar automaticamente todas as assinaturas oportunistas ativas restantes no mesmo grupo.

Se as implementações de dispositivos incluem telefonia GSM, mas não telefonia CDMA, elas:

• [C-9-1] NÃO DEVE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] É PRECISO gerar uma IllegalArgumentException ao tentar definir qualquer tipo de rede 3GPP2 em máscaras de bits de tipo de rede preferido ou permitido.
• [C-9-3] PRECISA retornar uma string vazia de TelephonyManager#getMeid.

Se as implementações do dispositivo oferecerem suporte a eUICCs com várias portas e perfis, elas:

• [C-10-1] É PRECISO declarar a flag de recurso android.hardware.telephony.euicc.mep.

7.4.1.1. Compatibilidade com o bloqueio de números

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

• [C-1-1] É PRECISO incluir suporte a bloqueio de números
• [C-1-2] É PRECISO implementar totalmente BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.

• [C-1-3] É PRECISO bloquear todas as ligações e mensagens de um número de telefone em 'BlockedNumberProvider' sem nenhuma interação com apps. A única exceção é quando o bloqueio de número é temporariamente suspenso, conforme descrito na documentação do SDK.

• [C-1-4] É PRECISO gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada e FILTRAR chamadas com BLOCKED_TYPE da visualização de registro de chamadas padrão no app discador pré-instalado.

• [C-1-5] NÃO É PERMITIDO gravar no provedor de telefonia para uma mensagem bloqueada.

• [C-1-6] É PRECISO implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada pelo método TelecomManager.createManageBlockedNumbersIntent().

• [C-1-7] NÃO É PERMITIDO que usuários secundários acessem ou editem os números bloqueados no dispositivo, porque a plataforma Android assume que o usuário principal tem controle total dos serviços de telefonia, uma única instância, no dispositivo. Toda a interface relacionada ao bloqueio PRECISA ser oculta para usuários secundários, e a lista de bloqueio PRECISA ser respeitada.

• DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.

• DEVE fornecer uma capacidade do usuário para mostrar chamadas bloqueadas no app de discagem pré-instalado.

7.4.1.2. API Telecom

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

• [C-1-1] É PRECISO oferecer suporte às APIs ConnectionService descritas no SDK.
• [C-1-2] É OBRIGATÓRIO mostrar uma nova chamada recebida e oferecer ao usuário a possibilidade de aceitar ou rejeitar a chamada recebida quando o usuário estiver em uma chamada feita por um app de terceiros que não oferece suporte ao recurso de retenção especificado por CAPABILITY_SUPPORT_HOLD.
• [C-1-3] É PRECISO ter um aplicativo que implemente InCallService.

• [C-SR-1] É ALTAMENTE RECOMENDADO notificar o usuário de que atender uma chamada recebida encerrará uma chamada em andamento.

  A implementação do AOSP atende a esses requisitos com uma notificação de alerta que indica ao usuário que atender uma chamada recebida fará com que a outra chamada seja encerrada.

• [C-SR-2] É ALTAMENTE RECOMENDADO pré-carregar o app de discagem padrão que mostra uma entrada de registro de chamadas e o nome de um app de terceiros no registro de chamadas quando o app de terceiros define a chave EXTRA_LOG_SELF_MANAGED_CALLS extras no PhoneAccount para true.

• [C-SR-3] É ALTAMENTE RECOMENDADO processar os eventos KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK dos fones de ouvido de áudio para as APIs android.telecom conforme abaixo:

  • Chame Connection.onDisconnect() quando um toque curto do evento de tecla for detectado durante uma chamada em andamento.
  • Chame Connection.onAnswer() quando um toque curto do evento de tecla for detectado durante uma chamada recebida.
  • Chame Connection.onReject() quando um pressionamento longo do evento de tecla for detectado durante uma chamada recebida.
  • Alternar o status de silêncio do CallAudioState.

7.4.1.3. Descarregar o Keepalive NAT-T da rede celular

Implementações de dispositivos:

• DEVE incluir suporte para o offload de keepalive de rede celular.

Se as implementações de dispositivos incluírem suporte ao offload de keepalive de rede celular e exibirem a funcionalidade para apps de terceiros, elas:

• [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
• [C-1-2] É NECESSÁRIO oferecer suporte a pelo menos um slot de manutenção de conexão simultâneo por rede celular.
• [C-1-3] É PRECISO oferecer suporte a tantos slots de keepalive celular simultâneos quantos forem compatíveis com o HAL do rádio celular.
• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte a pelo menos três slots de keepalive celular por instância de rádio.

Se as implementações de dispositivos não incluírem suporte ao offload de keepalive de rede celular, elas:

• [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementações de dispositivos:

• DEVE incluir suporte a uma ou mais formas de 802.11.

Se as implementações de dispositivos incluírem suporte a 802.11 e exporem a funcionalidade a um aplicativo de terceiros, elas:

• [C-1-1] É OBRIGATÓRIO implementar a API correspondente do Android.
• [C-1-2] É OBRIGATÓRIO informar a flag de recurso de hardware android.hardware.wifi.
• [C-1-3] É OBRIGATÓRIO implementar a API multicast conforme descrito na documentação do SDK.
• [C-1-4] É PRECISO oferecer suporte a DNS multicast (mDNS) e NÃO filtrar pacotes mDNS (224.0.0.251) em qualquer momento da operação, incluindo:
  • Mesmo quando a tela não está ativa.
  • Para implementações de dispositivos Android TV, mesmo em estados de energia em espera.
• [C-1-5] NÃO DEVE tratar a chamada do método da API WifiManager.enableNetwork() como uma indicação suficiente para alternar o Network ativo atualmente, que é usado por padrão para o tráfego do aplicativo e é retornado por métodos da API ConnectivityManager como getActiveNetwork e registerDefaultNetworkCallback. Em outras palavras, eles só poderão desativar o acesso à Internet fornecido por qualquer outro provedor de rede (por exemplo, dados móveis) se validarem que a rede Wi-Fi está fornecendo acesso à Internet.
• [C-1-6] É ALTAMENTE RECOMENDADO que, quando o método da API ConnectivityManager.reportNetworkConnectivity() for chamado, reavalie o acesso à Internet no Network e, assim que a avaliação determinar que o Network atual não fornece mais acesso à Internet, mude para qualquer outra rede disponível (por exemplo, dados móveis) que ofereça acesso à Internet.
• [C-1-7] É PRECISO randomizar o endereço MAC de origem e o número de sequência dos frames de solicitação de sondagem, uma vez no início de cada verificação, enquanto a STA está desconectada.
• [C-1-8] É PRECISO usar um endereço MAC consistente (NÃO É PERMITIDO randomizar o endereço MAC no meio de uma verificação).
• [C-1-9] É PRECISO iterar o número de sequência da solicitação de sondagem normalmente (sequencialmente) entre as solicitações de sondagem em uma verificação.
• [C-1-10] É PRECISO randomizar o número de sequência da solicitação de sondagem entre a última solicitação de sondagem de uma verificação e a primeira solicitação de sondagem da próxima verificação.
• [C-SR-1] É ALTAMENTE RECOMENDADO randomizar o endereço MAC de origem usado para toda a comunicação STA com um ponto de acesso (AP) durante a associação e associação.
  • O dispositivo PRECISA usar um endereço MAC aleatório diferente para cada SSID (FQDN para Passpoint) com que se comunica.
  • O dispositivo PRECISA oferecer ao usuário uma opção para controlar a randomização por SSID (FQDN para Passpoint) com opções não aleatórias e aleatórias e PRECISA definir o modo padrão para que novas configurações do Wi-Fi sejam aleatórias.
• [C-SR-2] É ALTAMENTE RECOMENDADO usar um BSSID aleatório para qualquer AP criado.
  • O endereço MAC PRECISA ser randomizado e persistido por SSID usado pelo AP.
  • O DISPOSITIVO PODE oferecer ao usuário uma opção para desativar esse recurso. Se essa opção for fornecida, a randomização PRECISA ser ativada por padrão.

Se as implementações de dispositivos incluírem suporte ao modo de economia de energia do Wi-Fi, conforme definido no padrão IEEE 802.11, elas:

• PRECISA desativar o modo de economia de energia do Wi-Fi sempre que um app adquirir bloqueio WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY pelas APIs WifiManager.createWifiLock() e WifiManager.WifiLock.acquire() e o bloqueio estiver ativo.
• [C-3-2] A latência média de ida e volta entre o dispositivo e um ponto de acesso enquanto o dispositivo está no modo de bloqueio de latência baixa do Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) PRECISA ser menor do que a latência durante um modo de bloqueio de alto desempenho do Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] É ALTAMENTE RECOMENDADO minimizar a latência de ida e volta do Wi-Fi sempre que uma trava de baixa latência (WIFI_MODE_FULL_LOW_LATENCY) é adquirida e entra em vigor.

Se as implementações do dispositivo oferecem suporte ao Wi-Fi e usam essa tecnologia para a verificação de local, elas:

• [C-2-1] É OBRIGATÓRIO fornecer uma capacidade do usuário para ativar/desativar a leitura de valor pelo método da API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementações de dispositivos:

• DEVE incluir suporte para Wi-Fi Direct (Wi-Fi ponto a ponto).

Se as implementações de dispositivos incluem suporte para Wi-Fi Direct, elas:

• [C-1-1] É PRECISO implementar a API correspondente do Android conforme descrito na documentação do SDK.
• [C-1-2] É OBRIGATÓRIO informar o recurso de hardware android.hardware.wifi.direct.
• [C-1-3] PRECISA ter suporte à operação regular de Wi-Fi.
• [C-1-4] É PRECISO oferecer suporte a operações Wi-Fi e Wi-Fi Direct simultaneamente.
• [C-SR-1] É ALTAMENTE RECOMENDADO randomizar o endereço MAC de origem para todas as conexões Wi-Fi Direct recém-formadas.

7.4.2.2. Configuração de link direto com Wi-Fi em túnel

Implementações de dispositivos:

• DEVE incluir suporte para Wi-Fi Tunneled Direct Link Setup (TDLS) conforme descrito na documentação do SDK do Android.

Se as implementações do dispositivo incluem suporte para TDLS e o TDLS é ativado pela API WiFiManager, elas:

• [C-1-1] É PRECISO declarar suporte a TDLS por meio de WifiManager.isTdlsSupported.
• Use TDLS apenas quando for possível E benéfico.
• DEVE ter alguma heurística e NÃO usar TDLS quando o desempenho for pior do que passar pelo ponto de acesso Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementações de dispositivos:

• DEVEM incluir suporte para Wi-Fi Aware.

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

• [C-1-1] É OBRIGATÓRIO implementar as APIs WifiAwareManager conforme descrito na documentação do SDK.
• [C-1-2] É OBRIGATÓRIO declarar a flag de recurso android.hardware.wifi.aware.
• [C-1-3] É PRECISO oferecer suporte a operações Wi-Fi e Wi-Fi Aware simultaneamente.
• [C-1-4] É NECESSÁRIO randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de até 30 minutos e sempre que o Wi-Fi Aware estiver ativado, a menos que uma operação de varredura Aware esteja em andamento ou que um caminho de dados Aware esteja ativo. A randomização não é esperada enquanto o caminho de dados estiver ativo.

Se as implementações do dispositivo incluem suporte para Wi-Fi Aware e localização de Wi-Fi, conforme descrito na Seção 7.4.2.5, e expõem essas funcionalidades a apps de terceiros, então:

• [C-2-1] É PRECISO implementar as APIs de descoberta com localização: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint do Wi-Fi

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

• [C-1-1] É PRECISO incluir suporte para Wi-Fi Passpoint.
• [C-1-2] É PRECISO implementar as APIs WifiManager relacionadas à Passpoint conforme descrito na documentação do SDK.
• [C-1-3] É necessário oferecer suporte ao padrão IEEE 802.11u, especificamente relacionado à descoberta e seleção de rede, como o serviço de publicidade genérica (GAS, na sigla em inglês) e o protocolo de consulta de rede de acesso (ANQP, na sigla em inglês).
• [C-1-4] É PRECISO declarar a flag de recurso android.hardware.wifi.passpoint.
• [C-1-5] É PRECISO seguir a implementação do AOSP para descobrir, corresponder e associar a redes do Passpoint.
• [C-1-6] PRECISA oferecer suporte a pelo menos o seguinte subconjunto de protocolos de provisionamento de dispositivos, conforme definido na Wi-Fi Alliance Passpoint R2: autenticação EAP-TTLS e SOAP-XML.
• [C-1-7] É OBRIGATÓRIO processar o certificado do servidor AAA, conforme descrito na especificação do Hotspot 2.0 R3.
• [C-1-8] É PRECISO oferecer suporte ao controle de provisionamento do usuário pelo seletor de Wi-Fi.
• [C-1-9] É PRECISO manter as configurações do Passpoint persistentes após reinicializações.
• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao recurso de aceitação de termos e condições.
• [C-SR-2] É ALTAMENTE RECOMENDADO oferecer suporte ao recurso de informações do local.

Se um botão de desativação do controle do usuário global do Passpoint for fornecido, as implementações:

• [C-3-1] É OBRIGATÓRIO ativar o Passpoint por padrão.

7.4.2.5. Local do Wi-Fi (tempo de retorno do Wi-Fi - RTT)

Implementações de dispositivos:

• DEVE incluir suporte para Local do Wi-Fi.

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

• [C-1-1] É OBRIGATÓRIO implementar as APIs WifiRttManager conforme descrito na documentação do SDK.
• [C-1-2] É OBRIGATÓRIO declarar a flag de recurso android.hardware.wifi.rtt.
• [C-1-3] É PRECISO randomizar o endereço MAC de origem de cada burst de RTT que é executado enquanto a interface Wi-Fi em que o RTT está sendo executado não está associada a um ponto de acesso.
• [C-1-4] TEM QUE ser preciso com uma margem de 2 metros a 80 MHz de largura de banda no percentil 68 (calculado com a função de distribuição cumulativa).
• [C-SR-1] É ALTAMENTE RECOMENDADO informar com precisão até 1,5 metro com largura de banda de 80 MHz no percentil 68 (calculado com a função de distribuição cumulativa).

7.4.2.6. Descarregar o keepalive do Wi-Fi

Implementações de dispositivos:

• DEVE incluir suporte para transferência de dados de keepalive do Wi-Fi.

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

• [C-1-1] É PRECISO oferecer suporte à API SocketKeepAlive.
• [C-1-2] É PRECISO ter suporte a pelo menos três slots de keepalive simultâneos por Wi-Fi.

Se as implementações de dispositivos não incluírem suporte ao offload de keepalive do Wi-Fi, elas:

• [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocolo de provisionamento de dispositivo)

Implementações de dispositivos:

• DEVE incluir suporte para Wi-Fi Easy Connect (DPP).

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

• [C-1-1] O método WifiManager#isEasyConnectSupported() PRECISA retornar true.

7.4.2.8. Validação do certificado do servidor de Wi-Fi empresarial

Se o certificado do servidor Wi-Fi não for validado ou se o nome de domínio do servidor Wi-Fi não estiver definido, as implementações do dispositivo:

• [C-SR-1] É ALTAMENTE RECOMENDADO não oferecer ao usuário a opção de adicionar manualmente a rede Wi-Fi corporativa no app Configurações.

7.4.2.9. Trust on First Use (TOFU)

Se as implementações de dispositivos oferecerem suporte ao Trust on First Use (TOFU) e permitirem que o usuário defina configurações WPA/WPA2/WPA3-Enterprise, elas:

• [C-4-1] É PRECISO fornecer ao usuário uma opção para selecionar o uso de TOFU.

7.4.3. Bluetooth

Se as implementações do dispositivo oferecem suporte ao perfil de áudio Bluetooth, elas:

• DEVE oferecer suporte a codecs de áudio avançados e Bluetooth (por exemplo, LDAC) com A2DP.

Se as implementações do dispositivo oferecerem suporte a HFP, A2DP e AVRCP, elas:

• DEVE oferecer suporte a pelo menos cinco dispositivos conectados.

Se as implementações do dispositivo declararem o recurso android.hardware.vr.high_performance, elas:

• [C-1-1] É PRECISO ter suporte a Bluetooth 4.2 e à extensão de comprimento de dados do Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.

Se as implementações do dispositivo incluem suporte para Bluetooth e Bluetooth de baixa energia, elas:

• [C-2-1] É OBRIGATÓRIO declarar os recursos relevantes da plataforma (android.hardware.bluetooth e android.hardware.bluetooth_le, respectivamente) e implementar as APIs da plataforma.
• DEVE implementar perfis relevantes do Bluetooth, como A2DP, AVRCP, OBEX, HFP etc., conforme apropriado para o dispositivo.

Se as implementações de dispositivos incluem suporte para Bluetooth de baixa energia (BLE), elas:

• [C-3-1] É OBRIGATÓRIO declarar o recurso de hardware android.hardware.bluetooth_le.
• [C-3-2] É OBRIGATÓRIO ativar as APIs de Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e android.bluetooth.
• [C-3-3] É PRECISO informar o valor correto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar se a lógica de filtragem das classes da API ScanFilter está implementada.
• [C-3-4] É OBRIGATÓRIO informar o valor correto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar se a publicidade de baixa energia é compatível.
• [C-3-5] É NECESSÁRIO implementar um tempo limite de endereço privado solucionável (RPA) de no máximo 15 minutos e rotacionar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo estiver usando BLE ativamente para digitalização ou publicidade. Para evitar ataques de tempo, os intervalos de tempo limite também precisam ser aleatórios entre 5 e 15 minutos.
• DEVE oferecer suporte ao descarregamento da lógica de filtragem para o chipset Bluetooth ao implementar a API ScanFilter.
• DEVE oferecer suporte ao descarregamento da verificação em lote para o chipset Bluetooth.
• DEVE oferecer suporte a vários anúncios com pelo menos quatro slots.

Se as implementações do dispositivo oferecem suporte ao Bluetooth LE e usam esse tipo de Bluetooth para a verificação de local, elas:

• [C-4-1] É OBRIGATÓRIO fornecer uma característica de uso do usuário para ativar/desativar a leitura de valor pela BluetoothAdapter.isBleScanAlwaysAvailable() da API do sistema.

Se as implementações do dispositivo incluírem suporte para o perfil de Bluetooth LE e de aparelhos auditivos, conforme descrito em Suporte a áudio de aparelho auditivo usando Bluetooth LE, elas:

• [C-5-1] É PRECISO retornar true para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Se as implementações de dispositivos incluem suporte para Bluetooth ou Bluetooth Low Energy, elas:

• [C-6-1] É PRECISO restringir o acesso a qualquer metadado do Bluetooth (como resultados de pesquisa) que possa ser usado para derivar a localização do dispositivo, a menos que o app solicitante transmita com sucesso uma verificação de permissão android.permission.ACCESS_FINE_LOCATION com base no estado atual em primeiro/segundo plano.

Se as implementações do dispositivo incluírem suporte a Bluetooth ou Bluetooth de baixa energia e o manifesto do app não incluir uma declaração do desenvolvedor informando que ele não está extraindo a localização do Bluetooth, ele:

• [C-6-2] É OBRIGATÓRIO restringir o acesso ao Bluetooth atrás do android.permission.ACCESS_FINE_LOCATION.

Se as implementações do dispositivo retornarem true para a API BluetoothAdapter.isLeAudioSupported(), elas:

• [C-7-1] É PRECISO oferecer suporte a clientes unicast.
• [C-7-2] É PRECISO oferecer suporte a 2M PHY.
• [C-7-3] É PRECISO oferecer suporte à publicidade estendida do LE.
• [C-7-4] É PRECISO oferecer suporte a pelo menos duas conexões de CIS em um CIG.
• [C-7-5] É PRECISO ativar o cliente unicast do BAP, o coordenador do conjunto CSIP, o servidor MCP, o controlador do VCP e o servidor CCP simultaneamente.
• [C-SR-1] É ALTAMENTE RECOMENDADO ativar o cliente unicast HAP.

Se as implementações do dispositivo retornarem true para a API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), elas:

• [C-8-1] É PRECISO ter suporte a pelo menos 2 links BIS em um BIG.
• [C-8-2] É PRECISO ativar a fonte de transmissão do BAP e o assistente de transmissão do BAP simultaneamente.
• [C-8-3] É PRECISO oferecer suporte à publicidade periódica de LE.

Se as implementações do dispositivo retornarem true para a API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), elas:

• [C-9-1] É PRECISO oferecer suporte a PAST (transferência periódica de sincronização de publicidade).
• [C-9-2] É PRECISO oferecer suporte à publicidade periódica de LE.

Se as implementações do dispositivo declararem FEATURE_BLUETOOTH_LE, elas:

• [C-10-1] É OBRIGATÓRIO que as medições de RSSI estejam dentro de +/-9 dB para 95% das medições a 1 m de distância de um dispositivo de referência transmitindo em ADVERTISE_TX_POWER_HIGH em um ambiente de linha de visão.
• [C-10-2] É PRECISO incluir correções de Rx/Tx para reduzir as variações por canal de modo que as medições em cada um dos três canais, em cada uma das antenas (se várias forem usadas), estejam dentro de +/-3 dB uma da outra para 95% das medições.
• [C-SR-2] É ALTAMENTE RECOMENDADO medir e compensar o deslocamento de Rx para garantir que a RSSI média do BLE seja -60 dBm +/-10 dB a 1 m de distância de um dispositivo de referência que transmite em ADVERTISE_TX_POWER_HIGH, em que os dispositivos são orientados de modo que estejam em "planos paralelos" com telas voltadas para a mesma direção.
• [C-SR-3] É ALTAMENTE RECOMENDADO medir e compensar o deslocamento de transmissão para garantir que a RSSI média do BLE seja -60 dBm +/-10 dB ao fazer a varredura de um dispositivo de referência posicionado a 1 m de distância e transmitindo em ADVERTISE_TX_POWER_HIGH, em que os dispositivos estão orientados de modo que estejam em "planos paralelos" com telas voltadas para a mesma direção.

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

Se as implementações do dispositivo forem compatíveis com a versão 5.0 do Bluetooth, elas:

• [C-SR-4] É ALTAMENTE RECOMENDADO oferecer suporte a:
  • LE 2M PHY
  • PHY do codec LE
  • Extensão de publicidade LE
  • Publicidade periódica
  • Pelo menos 10 conjuntos de anúncios
  • Pelo menos 8 conexões simultâneas de LE. Cada conexão pode estar em uma das funções de topologia de conexão.
  • Privacidade da camada de enlace LE
  • Uma "lista de resolução" com pelo menos 8 entradas

7.4.4. Comunicação a curta distância (NFC)

Implementações de dispositivos:

• DEVE incluir um transceptor e hardware relacionado para comunicações a curta distância (NFC).
• [C-0-1] É PRECISO implementar as APIs android.nfc.NdefMessage e android.nfc.NdefRecord, mesmo que elas não incluam suporte a NFC ou declarem o recurso android.hardware.nfc, porque as classes representam um formato de representação de dados independente de protocolo.

Se as implementações de dispositivos incluírem hardware NFC e planejam disponibilizá-lo para apps de terceiros, elas:

• [C-1-1] É OBRIGATÓRIO informar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature().
• PRECISA ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões NFC:
• [C-1-2] PRECISA ser capaz de atuar como leitor/gravador do Fórum de NFC (conforme definido pela especificação técnica do Fórum de NFC NFCForum-TS-DigitalProtocol-1.0) pelos seguintes padrões de NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Tipos de tag do NFC Forum 1, 2, 3, 4 e 5 (definidos pelo NFC Forum)

• [C-SR-1] ALTAMENTE RECOMENDADO para ser capaz de ler e gravar mensagens NDEF e dados brutos usando os seguintes padrões de NFC. Embora os padrões de NFC sejam indicados como ALTAMENTE RECOMENDADOS, a definição de compatibilidade para uma versão futura está planejada para mudar isso para OBRIGATÓRIO. Esses padrões são opcionais nesta versão, mas serão obrigatórios em versões futuras. Os dispositivos atuais e novos que executam essa versão do Android precisam atender a esses requisitos para fazer upgrade para as versões futuras da plataforma.

• [C-1-13] É PRECISO pesquisar todas as tecnologias com suporte no modo de descoberta de NFC.

• DEVE estar no modo de descoberta de NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.

• DEVE ser capaz de ler o código de barras e o URL (se codificado) dos produtos de código de barras NFC Thinfilm.

Os links disponíveis publicamente não estão disponíveis para as especificações do JIS, ISO e NFC do fórum citadas acima.

O Android inclui suporte para o modo de emulação de cartão host (HCE) de NFC.

Se as implementações do dispositivo incluírem um chipset de controlador NFC compatível com HCE (para NfcA e/ou NfcB) e oferecerem suporte ao roteamento de ID do aplicativo (AID), elas:

• [C-2-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.nfc.hce.
• [C-2-2] É PRECISO oferecer suporte a APIs NFC HCE, conforme definido no SDK do Android.

Se as implementações do dispositivo incluírem um chipset de controlador NFC compatível com HCE para NfcF e implementarem o recurso para aplicativos de terceiros, elas:

• [C-3-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.nfc.hcef.
• [C-3-2] É OBRIGATÓRIO implementar as APIs de emulação de cartão NfcF conforme definido no SDK do Android.

Se as implementações do dispositivo incluírem suporte geral a NFC, conforme descrito nesta seção, e oferecerem suporte a tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) no papel de leitor/gravador, elas:

• [C-4-1] É OBRIGATÓRIO implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
• [C-4-2] É OBRIGATÓRIO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). Esse não é um recurso padrão do Android e, como tal, não aparece como uma constante na classe android.content.pm.PackageManager.

7.4.5. Protocolos de rede e APIs

7.4.5.1. Capacidade mínima de rede

Implementações de dispositivos:

• [C-0-1] PRECISA incluir suporte a uma ou mais formas de rede de dados. Especificamente, as implementações de dispositivos precisam incluir suporte a pelo menos um padrão de dados com capacidade de 200 Kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
• DEVE incluir suporte a pelo menos um padrão de dados sem fio comum, como 802.11 (Wi-Fi), quando um padrão de rede física (como Ethernet) é a conexão de dados principal.
• PODE implementar mais de uma forma de conectividade de dados.

7.4.5.2. IPv6

Implementações de dispositivos:

• [C-0-2] É PRECISO incluir uma pilha de rede IPv6 e oferecer suporte à comunicação IPv6 usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, bem como as APIs nativas, como os sockets AF_INET6.
• [C-0-3] É OBRIGATÓRIO ativar o IPv6 por padrão.
  • É PRECISO garantir que a comunicação IPv6 seja tão confiável quanto o IPv4, por exemplo:
    • [C-0-4] É NECESSÁRIO manter a conectividade IPv6 no modo de suspensão.
    • [C-0-5] A limitação de taxa NÃO PODE fazer com que o dispositivo perca a conectividade IPv6 em qualquer rede compatível com IPv6 que use tempos de vida de RA de pelo menos 180 segundos.
• [C-0-6] É OBRIGATÓRIO fornecer a aplicativos de terceiros conectividade IPv6 direta à rede quando conectado a uma rede IPv6, sem qualquer forma de tradução de endereço ou de porta que ocorra localmente no dispositivo. As APIs gerenciadas, como Socket#getLocalAddress ou Socket#getLocalPort, e as APIs NDK, como getsockname() ou IPV6_PKTINFO, precisam retornar o endereço IP e a porta que são realmente usados para enviar e receber pacotes na rede e que são visíveis como o IP de origem e a porta para servidores da Internet (Web).

O nível necessário de suporte ao IPv6 depende do tipo de rede, conforme mostrado nos requisitos a seguir.

Se as implementações de dispositivos forem compatíveis com Wi-Fi, elas:

• [C-1-1] É PRECISO oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.

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

• [C-2-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 em Ethernet.

Se as implementações de dispositivos oferecerem suporte a dados móveis, elas:

• [C-3-1] É PRECISO oferecer suporte à operação IPv6 (somente IPv6 e possivelmente pilha dupla) em redes celulares.

Se as implementações de dispositivos forem compatíveis com mais de um tipo de rede (por exemplo, Wi-Fi e dados móveis), eles:

• [C-4-1] É necessário atender simultaneamente aos requisitos acima em cada rede quando o dispositivo estiver conectado simultaneamente a mais de um tipo de rede.

7.4.5.3. Portais passivos

Um portal cativo se refere a uma rede que exige login para ter acesso à Internet.

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

• [C-1-1] É PRECISO fornecer um aplicativo de portal captive para processar a intent ACTION_CAPTIVE_PORTAL_SIGN_IN e mostrar a página de login do portal captive, enviando essa intent, em chamada para a API do sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] É OBRIGATÓRIO realizar a detecção de portais cativos e oferecer suporte ao login pelo aplicativo de portal cativo quando o dispositivo estiver conectado a qualquer tipo de rede, incluindo rede celular/móvel, Wi-Fi, Ethernet ou Bluetooth.
• [C-1-3] É PRECISO oferecer suporte ao login em portais cativos usando DNS de texto sem criptografia quando o dispositivo estiver configurado para usar o modo estrito de DNS particular.
• [C-1-4] É OBRIGATÓRIO usar o DNS criptografado de acordo com a documentação do SDK para android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive para todo o tráfego de rede que não se comunica explicitamente com o portal de acesso.
• [C-1-5] É PRECISO garantir que, enquanto o usuário faz login em um portal capturado, a rede padrão usada pelos aplicativos (retornada por ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback e usada por padrão pelas APIs de rede Java, como java.net.Socket e APIs nativas, como connect()) seja qualquer outra rede disponível que ofereça acesso à Internet, se disponível.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

• [C-0-1] A configuração mestre de sincronização automática PRECISA estar ativada por padrão para que o método getMasterSyncAutomatically() retorne "true".

7.4.7. Economia de dados

Se as implementações de dispositivos incluírem uma conexão limitada, elas serão:

• [C-SR-1] É ALTAMENTE RECOMENDADO fornecer o modo de economia de dados.

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

• [C-1-1] É PRECISO oferecer suporte a todas as APIs na classe ConnectivityManager conforme descrito na documentação do SDK.

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

• [C-2-1] PRECISA retornar o valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().
• [C-2-2] NÃO DEVE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Elementos de segurança

Se as implementações de dispositivos oferecerem suporte a elementos seguros com suporte à API Open Mobile e os disponibilizarem para apps de terceiros, elas:

• [C-1-1] É OBRIGATÓRIO enumerar os leitores de elementos seguros disponíveis usando a API android.se.omapi.SEService.getReaders().

• [C-1-2] É NECESSÁRIO declarar os flags de recursos corretos usando android.hardware.se.omapi.uicc para o dispositivo com elementos seguros baseados em UICC, android.hardware.se.omapi.ese para o dispositivo com elementos seguros baseados em eSE e android.hardware.se.omapi.sd para o dispositivo com elementos seguros baseados em SD.

7.4.9. UWB

Se as implementações do dispositivo incluírem suporte ao 802.1.15.4 e exporem a funcionalidade a um aplicativo de terceiros, elas:

• [C-1-1] É OBRIGATÓRIO implementar a API Android correspondente no android.uwb.
• [C-1-2] É PRECISO informar a flag de recurso de hardware android.hardware.uwb.
• [C-1-3] PRECISA oferecer suporte a todos os perfis UWB relevantes definidos na implementação do Android.
• [C-1-4] É PRECISO fornecer uma característica para o usuário ativar/desativar o rádio UWB.
• [C-1-5] É PRECISO aplicar que os apps que usam rádio UWB tenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICES).

• [C-SR-1] É ALTAMENTE RECOMENDADO passar nos testes de conformidade e certificação relevantes definidos por organizações de padrão, incluindo FIRA, CCC e CSA.

  • [C-1-6] É PRECISO garantir que as medições de distância estejam dentro de +/-15 cm para 95% das medições no ambiente de linha de visão a 1 m de distância em uma câmara não reflexiva.
  • [C-1-7] É OBRIGATÓRIO garantir que a mediana das medições de distância a 1 m do dispositivo de referência esteja entre [0,75 m, 1,25 m], em que a distância de informações empíricas é medida a partir da borda superior do DUT, segurada com a face para cima e inclinada 45 graus.
  • [C-SR-2] É ALTAMENTE RECOMENDADO seguir as etapas de configuração de medição especificadas em Calibração de presença.

7,5. Cameras

Se as implementações do dispositivo incluírem pelo menos uma câmera, elas:

• [C-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.camera.any.
• [C-1-2] É PRECISO que um aplicativo possa alocar simultaneamente três bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo sensor de câmera de maior resolução no dispositivo, enquanto a câmera está aberta para a finalidade de visualização básica e captura de fotos.
• [C-1-3] É necessário garantir que o app de câmera padrão pré-instalado que processa intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE seja responsável por remover a localização do usuário nos metadados da imagem antes de enviar para o app de recebimento quando ele não tiver ACCESS_FINE_LOCATION.

Se as implementações do dispositivo oferecem suporte ao recurso de saída HDR de 10 bits, elas:

• [C-2-1] É PRECISO oferecer suporte a pelo menos o perfil HDR HLG para todos os dispositivos de câmera com saída de 10 bits.
• [C-2-2] É NECESSÁRIO oferecer suporte à saída de 10 bits para a câmera traseira principal ou frontal principal.
• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à saída de 10 bits para as duas câmeras principais.
• [C-2-3] PRECISA oferecer suporte aos mesmos perfis HDR para todas as subcâmeras físicas com compatibilidade com BACKWARD_COMPATIBLE de uma câmera lógica e a própria câmera lógica.

Para dispositivos de câmera lógica com suporte a HDR de 10 bits que implementam a API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, eles:

• [C-3-1] PRECISA oferecer suporte à alternância entre todas as câmeras físicas com compatibilidade com versões anteriores pelo controle CONTROL_ZOOM_RATIO na câmera lógica.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera localizada na lateral do dispositivo, oposta à tela. Ou seja, ela captura imagens do lado oposto do dispositivo, como uma câmera tradicional.

Implementações de dispositivos:

• DEVE incluir uma câmera traseira.

Se as implementações do dispositivo incluírem pelo menos uma câmera traseira, elas:

• [C-1-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera e android.hardware.camera.any.
• [C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
• DEVE ter o autofoco de hardware ou de software implementado no driver da câmera (transparente para o software do aplicativo).
• PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
• PODE incluir um flash.

Se a câmera tiver um flash:

• [C-2-1] A lâmpada do flash PRECISA DE ESTAR acesa enquanto uma instância de android.hardware.Camera.PreviewCallback foi registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha ativado explicitamente o flash ativando os atributos FLASH_MODE_AUTO ou FLASH_MODE_ON de um objeto Camera.Parameters. Essa restrição não se aplica ao aplicativo de câmera do sistema integrado do dispositivo, mas apenas a apps de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela, ou seja, uma câmera normalmente usada para capturar imagens do usuário, como em videoconferências e aplicativos semelhantes.

Implementações de dispositivos:

• PODE incluir uma câmera frontal.

Se as implementações do dispositivo incluírem pelo menos uma câmera frontal, elas:

• [C-1-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
• [C-1-3] NÃO use uma câmera frontal como padrão para a API Camera e NÃO configure a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera do dispositivo.
• [C-1-4] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo quando o aplicativo atual requer explicitamente que a tela da câmera seja girada por uma chamada ao método android.hardware.Camera.setDisplayOrientation(). Por outro lado, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo quando o aplicativo atual não solicita explicitamente que a tela da câmera seja girada por uma chamada para o método android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NÃO é permitido espelhar os streams de imagem estática ou vídeo capturados retornados aos callbacks do aplicativo ou comprometidos com o armazenamento de mídia.
• [C-1-6] É PRECISO espelhar a imagem exibida pela visualização pós-reprodução da mesma forma que o fluxo de imagem de visualização da câmera.
• PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

Se as implementações de dispositivo puderem ser giradas pelo usuário (por exemplo, automaticamente por um acelerômetro ou manualmente pela entrada do usuário):

• [C-2-1] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação atual do dispositivo.

7.5.3. Câmera externa

Implementações de dispositivos:

• PODE incluir suporte para uma câmera externa que não está necessariamente sempre conectada.

Se as implementações do dispositivo incluem suporte para uma câmera externa, elas:

• [C-1-1] É OBRIGATÓRIO declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
• [C-1-2] É PRECISO oferecer suporte à classe de vídeo USB (UVC 1.0 ou mais recente) se a câmera externa se conectar pela porta host USB.
• [C-1-3] É PRECISO passar nos testes do CTS da câmera com um dispositivo de câmera externa conectado. Os detalhes dos testes do CTS da câmera estão disponíveis em source.android.com.
• DEVE oferecer suporte a compressões de vídeo, como MJPEG, para permitir a transferência de streams não codificados de alta qualidade (ou seja, streams de imagens brutos ou comprimidos de forma independente).
• PODE oferecer suporte a várias câmeras.
• PODE oferecer suporte à codificação de vídeo baseada na câmera.

Se a codificação de vídeo baseada na câmera for compatível:

• [C-2-1] Um fluxo não codificado / MJPEG simultâneo (resolução QVGA ou maior) PRECISA estar acessível para a implementação do dispositivo.

7.5.4. Comportamento da API Camera

O Android inclui dois pacotes de API para acessar a câmera. A API android.hardware.camera2 mais recente expõe o controle de câmera de nível mais baixo para o app, incluindo fluxos de streaming/fotos em sequência eficientes sem cópia e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, redução de ruído, nitidez e muito mais.

O pacote de API mais antigo, android.hardware.Camera, está marcado como descontinuado no Android 5.0, mas ainda está disponível para uso em apps. As implementações de dispositivos Android precisam garantir o suporte contínuo da API, conforme descrito nesta seção e no SDK do Android.

Todos os recursos comuns entre a classe android.hardware.Camera descontinuada e o pacote mais recente android.hardware.camera2 PRECISAM ter desempenho e qualidade equivalentes nas duas APIs. Por exemplo, com configurações equivalentes, a velocidade e a precisão do autofoco precisam ser idênticas, e a qualidade das imagens capturadas precisa ser a mesma. Os recursos que dependem das diferentes semânticas das duas APIs não precisam ter velocidade ou qualidade correspondentes, mas precisam ser o mais próximos possível.

As implementações de dispositivos precisam implementar os seguintes comportamentos para as APIs relacionadas à câmera, para todas as câmeras disponíveis. Implementações de dispositivos:

• [C-0-1] É OBRIGATÓRIO usar android.hardware.PixelFormat.YCbCr_420_SP para dados de pré-visualização fornecidos a callbacks de aplicativos quando um aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] PRECISA estar no formato de codificação NV21 quando um aplicativo registra uma instância android.hardware.Camera.PreviewCallback e o sistema chama o método onPreviewFrame() e o formato de visualização é YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame(). Ou seja, o NV21 PRECISA ser o padrão.
• [C-0-3] PRECISA oferecer suporte ao formato YV12 (conforme indicado pela constante android.graphics.ImageFormat.YV12) para visualizações de câmera para câmeras frontais e traseiras para android.hardware.Camera. O codificador de vídeo e a câmera de hardware podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA oferecer suporte à conversão para YV12.
• [C-0-4] É PRECISO oferecer suporte aos formatos android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG como saídas pela API android.media.ImageReader para dispositivos android.hardware.camera2 que anunciam o recurso REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE em android.request.availableCapabilities.
• [C-0-5] A API Camera precisa ser implementada na documentação do SDK do Android, mesmo que o dispositivo tenha foco automático de hardware ou outros recursos. Por exemplo, câmeras que não têm foco automático ainda precisam chamar todas as instâncias android.hardware.Camera.AutoFocusCallback registradas, mesmo que isso não tenha relevância para uma câmera sem foco automático. Isso se aplica a câmeras frontais. Por exemplo, embora a maioria das câmeras frontais não ofereça suporte ao foco automático, os callbacks da API ainda precisam ser "falsos", conforme descrito.
• [C-0-6] É PRECISO reconhecer e honrar cada nome de parâmetro definido como uma constante na classe android.hardware.Camera.Parameters e na classe android.hardware.camera2.CaptureRequest. Por outro lado, as implementações de dispositivos NÃO precisam reconhecer ou reconhecer constantes de string transmitidas ao método android.hardware.Camera.setParameters(), exceto aquelas documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos precisam oferecer suporte a todos os parâmetros padrão da câmera, se o hardware permitir, e NÃO podem oferecer suporte a tipos personalizados de parâmetros da câmera. Por exemplo, implementações de dispositivos que oferecem suporte à captura de imagens usando técnicas de High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera Camera.SCENE_MODE_HDR.
• [C-0-7] É OBRIGATÓRIO informar o nível adequado de suporte com a propriedade android.info.supportedHardwareLevel conforme descrito no SDK do Android e informar as flags de recursos do framework adequadas.
• [C-0-8] PRECISA declarar também os recursos de câmera individuais de android.hardware.camera2 usando a propriedade android.request.availableCapabilities e declarar as flags de recursos adequadas. PRECISA definir a flag de recurso se algum dos dispositivos de câmera conectados oferecer suporte ao recurso.
• [C-0-9] É OBRIGATÓRIO transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada da imagem for adicionada à loja de mídia.
• [C-0-10] É OBRIGATÓRIO transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da imagem for adicionada à loja de mídia.
• [C-0-11] É OBRIGATÓRIO que todas as câmeras sejam acessíveis pela API android.hardware.Camera descontinuada, que também precisa ser acessível pela API android.hardware.camera2.
• [C-0-12] É OBRIGATÓRIO garantir que a aparência facial NÃO seja alterada, incluindo, mas não se limitando a, alterar a geometria facial, o tom de pele facial ou o suavização da pele facial para qualquer API android.hardware.camera2 ou android.hardware.Camera.
• [C-SR-1] Para dispositivos com várias câmeras RGB voltadas para a mesma direção, é ALTAMENTE RECOMENDADO oferecer suporte a um dispositivo de câmera lógica que liste o recurso CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, consistindo de todas as câmeras RGB voltadas para essa direção como subdispositivos físicos.

Se as implementações do dispositivo fornecerem uma API de câmera reservada a apps de terceiros, elas:

• [C-1-1] É OBRIGATÓRIO implementar essa API de câmera usando a API android.hardware.camera2.
• PODE fornecer tags e/ou extensões do fornecedor à API android.hardware.camera2.

7.5.5. Orientação da câmera

Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, elas:

• [C-1-1] PRECISA estar orientado de forma que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é segurado na orientação paisagem, as câmeras precisam capturar imagens nessa orientação. Isso se aplica independentemente da orientação natural do dispositivo, ou seja, se aplica a dispositivos com orientação principal de paisagem e retrato.

Os dispositivos que atendem a todos os critérios abaixo estão isentos do requisito acima:

• O dispositivo implementa telas de geometria variável, como telas dobráveis ou articuladas.
• Quando o estado de dobra ou articulação do dispositivo muda, ele alterna entre orientações retrato-principal e paisagem-principal (ou vice-versa).

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos

Implementações de dispositivos:

• [C-0-1] PRECISA incluir um gerenciador de downloads que os aplicativos PODEM usar para fazer o download de arquivos de dados e PRECISA ser capaz de fazer o download de arquivos individuais de pelo menos 100 MB de tamanho para o local "cache" padrão.

7.6.2. Armazenamento compartilhado do aplicativo

Implementações de dispositivos:

• [C-0-1] É PRECISO oferecer armazenamento para ser compartilhado por aplicativos, também conhecido como "armazenamento externo compartilhado", "armazenamento compartilhado do aplicativo" ou pelo caminho Linux "/sdcard" em que ele é montado.
• [C-0-2] DEVE ser configurado com o armazenamento compartilhado montado por padrão, ou seja, "pronto para uso", independentemente de o armazenamento ser implementado em um componente de armazenamento interno ou em um meio de armazenamento removível (por exemplo, slot de cartão digital seguro).
• [C-0-3] É PRECISO montar o armazenamento compartilhado do aplicativo diretamente no caminho sdcard do Linux ou incluir um link simbólico do Linux de sdcard para o ponto de montagem real.
• [C-0-4] É OBRIGATÓRIO ativar o armazenamento de escopo por padrão para todos os apps com nível de API 29 ou mais recente, exceto na seguinte situação:
  • Quando o app solicitou android:requestLegacyExternalStorage="true" no manifesto.
• [C-0-5] É NECESSÁRIO editar os metadados de localização, como tags EXIF do GPS, armazenados em arquivos de mídia quando esses arquivos são acessados por MediaStore, exceto quando o app de chamada tem a permissão ACCESS_MEDIA_LOCATION.

As implementações de dispositivos PODEM atender aos requisitos acima usando uma das seguintes opções:

• Armazenamento removível acessível ao usuário, como um slot para cartão Secure Digital (SD).
• Parte do armazenamento interno (não removível) conforme implementado no Android Open Source Project (AOSP).

Se as implementações do dispositivo usarem armazenamento removível para atender aos requisitos acima, elas:

• [C-1-1] É PRECISO implementar uma interface do usuário pop-up ou aviso ao usuário quando não há um meio de armazenamento inserido no slot.
• [C-1-2] É PRECISO incluir um meio de armazenamento formatado em FAT (por exemplo, um cartão SD) ou mostrar na caixa e em outros materiais disponíveis no momento da compra que o meio de armazenamento precisa ser comprado separadamente.

Se as implementações do dispositivo usarem uma parte do armazenamento não removível para atender aos requisitos acima, elas:

• DEVE usar a implementação do AOSP do armazenamento compartilhado do aplicativo interno.
• PODE compartilhar o espaço de armazenamento com os dados privados do aplicativo.

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

• [C-3-1] É PRECISO fornecer um mecanismo para acessar os dados no armazenamento compartilhado do aplicativo em um computador host.
• EXPORÃO o conteúdo das duas rotas de armazenamento de forma transparente pelo serviço de verificação de mídia do Android e pelo android.provider.MediaStore.
• PODE usar armazenamento em massa USB, mas DEVE usar o protocolo de transferência de mídia para atender a esse requisito.

Se as implementações do dispositivo tiverem uma porta USB com o modo periférico USB e oferecerem suporte ao protocolo de transferência de mídia, elas:

• PRECISA ser compatível com o host de MTP do Android de referência, Transferência de arquivos do Android.
• DEVE informar uma classe de dispositivo USB de 0x00.
• DEVE informar um nome de interface USB de "MTP".

7.6.3. Armazenamento adotável

Se o dispositivo for móvel, ao contrário da televisão, as implementações do dispositivo serão:

• [C-SR-1] É ALTAMENTE RECOMENDADO implementar o armazenamento adaptável em um local estável de longo prazo, já que a desconexão acidental pode causar perda/corrupção de dados.

Se a porta do dispositivo de armazenamento removível estiver em um local estável de longo prazo, como no compartimento da bateria ou em outra capa protetora, as implementações do dispositivo serão:

• [C-SR-2] É ALTAMENTE RECOMENDADO implementar o armazenamento adotável.

7.7. USB

Se as implementações do dispositivo tiverem uma porta USB, elas:

• DEVE oferecer suporte ao modo de periférico USB e ao modo de host USB.
• DEVE oferecer suporte à desativação da sinalização de dados por USB.

7.7.1. Modo de periférico USB

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

• [C-1-1] A porta PRECISA ser conectável a um host USB com uma porta USB tipo A ou tipo C padrão.
• [C-1-2] É OBRIGATÓRIO informar o valor correto de iSerialNumber no descritor de dispositivo padrão USB por android.os.Build.SERIAL.
• [C-1-3] É PRECISO detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão de resistor do USB tipo C e PRECISA detectar mudanças na propaganda, se eles oferecem suporte ao USB tipo C.
• [C-SR-1] A porta DEVE usar o formato USB micro-B, micro-AB ou tipo C. É ALTAMENTE RECOMENDADO que os dispositivos Android atuais e novos cumpram esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
• [C-SR-2] A porta DEVE estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação de tela de software para todos os apps (incluindo a tela inicial), para que a tela seja renderizada corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É ALTAMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
• [C-SR-3] DEVE implementar suporte para consumir 1,5 A de corrente durante o chirp de HS e o tráfego, conforme especificado na especificação de carregamento de bateria USB, revisão 1.2. É ALTAMENTE RECOMENDADO que os dispositivos Android atuais e novos cumpram esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
• [C-SR-4] É ALTAMENTE RECOMENDADO não oferecer suporte a métodos de carregamento proprietários que modifiquem a tensão do Vbus além dos níveis padrão ou alterem os papéis de destino/fonte, já que isso pode resultar em problemas de interoperabilidade com os carregadores ou dispositivos que oferecem suporte aos métodos padrão de fornecimento de energia USB. Embora isso seja "FORTEMENTE RECOMENDADO", em versões futuras do Android, poderemos EXIGIR que todos os dispositivos tipo C ofereçam suporte à interoperabilidade completa com carregadores tipo C padrão.
• [C-SR-5] É ALTAMENTE RECOMENDADO oferecer suporte à entrega de energia para dados e trocar de função de energia quando houver suporte para USB Type-C e modo de host USB.
• DEVE oferecer suporte ao fornecimento de energia para carregamento de alta tensão e suporte a Modos alternativos, como saída de tela.
• PRECISA implementar a API e a especificação do Android Open Accessory (AOA, na sigla em inglês) conforme documentado na documentação do SDK do Android.

Se as implementações do dispositivo incluem uma porta USB e implementam a especificação AOA, elas:

• [C-2-1] É PRECISO declarar suporte ao recurso de hardware android.hardware.usb.accessory.
• [C-2-2] A classe de armazenamento em massa USB PRECISA incluir a string "android" no final da string iInterface da descrição da interface do armazenamento em massa USB.

7.7.2. Modo de host USB

Se as implementações do dispositivo incluem uma porta USB com suporte ao modo host, elas:

• [C-1-1] É OBRIGATÓRIO implementar a API host USB do Android conforme documentado no SDK do Android e DECLARAR suporte ao recurso de hardware android.hardware.usb.host.
• [C-1-2] É PRECISO implementar suporte para conectar periféricos USB padrão. Em outras palavras, é PRECISO:
  • Ter uma porta tipo C no dispositivo ou ser enviado com cabos que adaptam uma porta proprietary no dispositivo a uma porta USB-C padrão (dispositivo USB Type-C).
  • Ter uma porta tipo A no dispositivo ou ser enviado com cabos que adaptam uma porta proprietary no dispositivo a uma porta USB tipo A padrão.
  • Ter uma porta micro-AB no dispositivo, que DEVE ser enviada com um cabo que se adapta a uma porta tipo A padrão.
• [C-1-3] NÃO PODE ser enviado com um adaptador que converte portas USB tipo A ou micro-AB em uma porta tipo C (soquete).
• [C-SR-1] É ALTAMENTE RECOMENDÁVEL implementar a classe de áudio USB conforme documentado na documentação do SDK do Android.
• DEVE oferecer suporte ao carregamento do dispositivo periférico USB conectado no modo host; anunciando uma corrente de origem de pelo menos 1,5 A, conforme especificado na seção "Terminais" da Especificação de cabo e conector USB Type-C, revisão 1.2 para conectores USB Type-C ou usando a faixa de corrente de saída da porta de carregamento downstream(CDP, na sigla em inglês) conforme especificado nas Especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
• DEVEM implementar e oferecer suporte aos padrões USB Type-C.

Se as implementações do dispositivo incluem uma porta USB com suporte ao modo de host e à classe de áudio USB, elas:

• [C-2-1] É PRECISO oferecer suporte à classe HID do USB.
• [C-2-2] É PRECISO oferecer suporte à detecção e ao mapeamento dos seguintes campos de dados HID especificados nas tabelas de uso do USB HID e na solicitação de uso do comando de voz para as constantes KeyEvent conforme abaixo:
  • Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
  • Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
  • Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Se as implementações do dispositivo incluírem uma porta USB com suporte ao modo host e ao Framework de acesso ao armazenamento (SAF, na sigla em inglês), elas:

• [C-3-1] É OBRIGATÓRIO reconhecer todos os dispositivos MTP (protocolo de transferência de mídia) conectados remotamente e tornar o conteúdo deles acessível pelas intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se as implementações do dispositivo incluírem uma porta USB com suporte ao modo de host e ao USB Type-C, elas:

• [C-4-1] É PRECISO implementar a funcionalidade de porta de função dupla, conforme definido pela especificação USB Type-C (seção 4.5.1.3.3). Para portas de função dupla, em dispositivos que incluem uma entrada de áudio de 3,5 mm, a detecção de sink USB (modo host) PODE estar desativada por padrão, mas PRECISA ser possível para o usuário ativá-la.
• [C-SR-2] É ALTAMENTE RECOMENDADO que ofereça suporte a DisplayPort, DEVE oferecer suporte a taxas de dados USB SuperSpeed e ALTAMENTE RECOMENDADO que ofereça suporte ao fornecimento de energia para troca de dados e de funções.
• [C-SR-3] É ALTAMENTE RECOMENDÁVEL que o modo de acessório do adaptador de áudio não seja compatível, conforme descrito no Apêndice A da Revisão 1.2 da especificação de cabo e conector USB Type-C.
• PRECISA implementar o modelo Try.* mais adequado para o formato do dispositivo. Por exemplo, um dispositivo portátil DEVE implementar o modelo Try.SNK.

7.8. Áudio

7.8.1. Microfone

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

• [C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.microphone.
• [C-1-2] É OBRIGATÓRIO atender aos requisitos de gravação de áudio na seção 5.4.
• [C-1-3] É NECESSÁRIO atender aos requisitos de latência de áudio na seção 5.6.
• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à gravação de ultrassom, conforme descrito na seção 7.8.3.

Se as implementações do dispositivo omitirem um microfone, elas:

• [C-2-1] NÃO DEVE informar a constante de recurso android.hardware.microphone.
• [C-2-2] É PRECISO implementar a API de gravação de áudio pelo menos como no-ops, de acordo com a seção 7.

7.8.2. Saída de áudio

Se as implementações do dispositivo incluírem um alto-falante ou uma porta de saída de áudio/multimídia para um periférico de saída de áudio, como uma entrada de áudio de 3,5 mm com quatro condutores ou uma porta no modo host USB usando a classe de áudio USB, elas:

• [C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.audio.output.
• [C-1-2] É NECESSÁRIO atender aos requisitos de reprodução de áudio na seção 5.5.
• [C-1-3] É NECESSÁRIO atender aos requisitos de latência de áudio na seção 5.6.
• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à reprodução próxima de ultrassom, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos não incluírem um alto-falante ou uma porta de saída de áudio, elas:

• [C-2-1] NÃO DEVE informar o recurso android.hardware.audio.output.
• [C-2-2] É PRECISO implementar as APIs relacionadas à saída de áudio como no-ops, no mínimo.

Para os fins desta seção, uma "porta de saída" é uma interface física, como uma entrada de áudio de 3,5 mm, HDMI ou porta de modo host USB com classe de áudio USB. O suporte à saída de áudio por protocolos baseados em rádio, como Bluetooth, Wi-Fi ou rede celular, não se qualifica como inclusão de uma "porta de saída".

7.8.2.1. Portas de áudio analógicas

Para ser compatível com os fones de ouvido e outros acessórios de áudio que usam o plugue de áudio de 3,5 mm em todo o ecossistema do Android, se as implementações do dispositivo incluírem uma ou mais portas de áudio analógico, elas:

• [C-SR-1] É ALTAMENTE RECOMENDADO incluir pelo menos uma das portas de áudio como um conector de áudio de 3,5 mm com 4 condutores.

Se as implementações do dispositivo tiverem um conector de áudio de 3,5 mm com quatro condutores, elas:

• [C-1-1] É PRECISO oferecer suporte à reprodução de áudio em fones de ouvido estéreo e fones de ouvido estéreo com microfone.
• [C-1-2] É PRECISO oferecer suporte a conectores de áudio TRRS com a ordem de pinagem CTIA.
• [C-1-3] É PRECISO oferecer suporte à detecção e ao mapeamento para os códigos de tecla dos seguintes três intervalos de impedância equivalente entre o microfone e os condutores de terra no plugue de áudio:
  • 70 ohms ou menos: KEYCODE_HEADSETHOOK
  • 210-290 ohms: KEYCODE_VOLUME_UP
  • 360-680 ohms: KEYCODE_VOLUME_DOWN
• [C-1-4] PRECISA acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que todos os contatos no plugue estiverem tocando os segmentos relevantes na tomada.
• [C-1-5] É PRECISO ser capaz de controlar pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohms.
• [C-1-6] É PRECISO ter uma tensão de polarização do microfone entre 1,8 V e 2,9 V.
• [C-1-7] É OBRIGATÓRIO detectar e mapear para o código de tecla o seguinte intervalo de impedância equivalente entre o microfone e os condutores de aterramento na tomada de áudio:
  • 110-180 ohms:KEYCODE_VOICE_ASSIST
• [C-SR-2] É ALTAMENTE RECOMENDADO oferecer suporte a plugues de áudio com a ordem de pinagem OMTP.
• [C-SR-3] É ALTAMENTE RECOMENDADO oferecer suporte à gravação de áudio de fones de ouvido estéreo com microfone.

Se as implementações do dispositivo tiverem um conector de áudio de 3,5 mm com quatro condutores e oferecerem suporte a um microfone, e transmitirem o android.intent.action.HEADSET_PLUG com o microfone de valor extra definido como 1, elas:

• [C-2-1] É PRECISO oferecer suporte à detecção de microfone no acessório de áudio conectado.

7.8.2.2. Portas de áudio digital

Consulte a seção 2.2.1 para ver os requisitos específicos do dispositivo.

7.8.3. Near-Ultrasound

O áudio próximo ao ultrassom é a faixa de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

• É PRECISO informar corretamente o suporte ao recurso de áudio de quase ultrassom usando a API AudioManager.getProperty da seguinte maneira:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND for "true", os seguintes requisitos PRECISAM ser atendidos pelas fontes de áudio VOICE_RECOGNITION e UNPROCESSED:

• [C-1-1] A resposta de potência média do microfone na faixa de 18,5 kHz a 20 kHz PRECISA ser de no máximo 15 dB abaixo da resposta em 2 kHz.
• [C-1-2] A relação sinal-ruído não ponderada do microfone em 18,5 kHz a 20 kHz para um tom de 19 kHz em -26 dBFS PRECISA ser maior que 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND for "true":

• [C-2-1] A resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser pelo menos 40 dB abaixo da resposta em 2 kHz.

7.8.4. Integridade do sinal

Implementações de dispositivos:

• DEVEM fornecer um caminho de sinal de áudio sem falhas para fluxos de entrada e saída em dispositivos portáteis, conforme definido por zero falhas medidas durante um teste de um minuto por caminho. Teste usando o OboeTester "Teste de falhas automatizado".

O teste requer um dongle de loopback de áudio, usado diretamente em uma entrada de 3,5 mm e/ou em combinação com um adaptador USB-C para 3,5 mm. Todas as portas de saída de áudio precisam ser testadas.

No momento, o OboeTester oferece suporte a caminhos da AAudio. Portanto, as combinações a seguir DEVEM ser testadas para verificar falhas usando a AAudio:

Modo de desempenho	Compartilhamento	Taxa de amostragem	Em Chans	Out Chans
LOW_LATENCY	EXCLUSIVO	NÃO ESPECIFICADO	1	2
LOW_LATENCY	EXCLUSIVO	NÃO ESPECIFICADO	2	1
LOW_LATENCY	COMPARTILHADO	NÃO ESPECIFICADO	1	2
LOW_LATENCY	COMPARTILHADO	NÃO ESPECIFICADO	2	1
NENHUMA	COMPARTILHADO	48000	1	2
NENHUMA	COMPARTILHADO	48000	2	1
NENHUMA	COMPARTILHADO	44100	1	2
NENHUMA	COMPARTILHADO	44100	2	1
NENHUMA	COMPARTILHADO	16000	1	2
NENHUMA	COMPARTILHADO	16000	2	1

Um stream confiável DEVE atender aos seguintes critérios de razão sinal-ruído (SNR, na sigla em inglês) e distorção harmônica total (THD, na sigla em inglês) para seno de 2000 Hz.

Transdutor	THD	SNR
alto-falante principal integrado, medido usando um microfone de referência externo	< 3,0%	>= 50 dB
microfone principal integrado, medido usando um alto-falante de referência externo	< 3,0%	>= 50 dB
entradas analógicas integradas de 3,5 mm, testadas usando o adaptador de loopback	Menos de 1%	>= 60 dB
Adaptadores USB fornecidos com o smartphone, testados com adaptador de loopback	< 1,0%	>= 60 dB

7.9. Realidade virtual

O Android inclui APIs e recursos para criar apps de "realidade virtual" (RV), incluindo experiências de RV de alta qualidade em dispositivos móveis. As implementações de dispositivos precisam implementar essas APIs e comportamentos corretamente, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android inclui suporte ao modo de RV, um recurso que processa a renderização estereoscópica de notificações e desativa componentes da interface do sistema monocular enquanto um aplicativo de RV tem o foco do usuário.

7.9.2. Modo de realidade virtual: alto desempenho

Se as implementações do dispositivo oferecem suporte ao modo de RV, elas:

• [C-1-1] É PRECISO ter pelo menos dois núcleos físicos.
• [C-1-2] É PRECISO declarar o recurso android.hardware.vr.high_performance.
• [C-1-3] É PRECISO oferecer suporte ao modo performance sustentada.
• [C-1-4] É PRECISO oferecer suporte ao OpenGL ES 3.2.
• [C-1-5] É PRECISO oferecer suporte a android.hardware.vulkan.level 0.
• DEVE ter suporte para android.hardware.vulkan.level 1 ou mais recente.
• [C-1-6] É NECESSÁRIO implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace e expor as extensões na lista de extensões EGL disponíveis.
• [C-1-8] É PRECISO implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures e expor as extensões na lista de extensões GL disponíveis.
• [C-SR-1] É ALTAMENTE RECOMENDADO implementar GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture e expor as extensões na lista de extensões GL disponíveis.
• [C-SR-2] É ALTAMENTE RECOMENDADO oferecer suporte ao Vulkan 1.1.
• [C-SR-3] É ALTAMENTE RECOMENDADO implementar VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image e expor na lista de extensões Vulkan disponíveis.
• [C-SR-4] É ALTAMENTE RECOMENDADO expor pelo menos uma família de filas do Vulkan em que flags contenha VK_QUEUE_GRAPHICS_BIT e VK_QUEUE_COMPUTE_BIT, e queueCount seja pelo menos 2.
• [C-1-7] A GPU e a tela PRECISAM ser capazes de sincronizar o acesso ao buffer frontal compartilhado para que a renderização alternada do olho do conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de rasgo visíveis.
• [C-1-9] É PRECISO implementar suporte para as flags AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT conforme descrito no NDK.
• [C-1-10] É PRECISO implementar suporte para AHardwareBuffers com qualquer combinação dos flags de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para pelo menos os seguintes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] É ALTAMENTE RECOMENDADO oferecer suporte à alocação de AHardwareBuffers com mais de uma camada e sinalizações e formatos especificados em C-1-10.
• [C-1-11] É PRECISO ter suporte à decodificação H.264 de pelo menos 3840 x 2160 a 30 fps, com compactação de uma média de 40 Mbps (equivalente a 4 instâncias de 1920 x 1080 a 30 fps-10 Mbps ou 2 instâncias de 1920 x 1080 a 60 fps-20 Mbps).
• [C-1-12] É PRECISO ter suporte a HEVC e VP9, ser capaz de decodificar pelo menos 1920 x 1080 a 30 fps compactado para uma média de 10 Mbps e SER CAPAZ de decodificar 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 instâncias de 1920 x 1080 a 30 fps-5 Mbps).
• [C-1-13] É NECESSÁRIO oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
• [C-1-14] É PRECISO ter uma tela integrada, e a resolução PRECISA ser de pelo menos 1920 x 1080.
• [C-SR-6] É ALTAMENTE RECOMENDADO ter uma resolução de tela de pelo menos 2.560 x 1.440.
• [C-1-15] A tela PRECISA ser atualizada a pelo menos 60 Hz no modo de RV.
• [C-1-17] A tela PRECISA oferecer suporte a um modo de baixa persistência com persistência de ≤ 5 milissegundos, sendo que a persistência é definida como a quantidade de tempo em que um pixel está emitindo luz.
• [C-1-18] É PRECISO ter suporte para Bluetooth 4.2 e extensão de comprimento de dados do Bluetooth LE seção 7.4.3.
• [C-1-19] É PRECISO 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 oferecer suporte ao tipo de canal direto TYPE_HARDWARE_BUFFER para todos os tipos de canal direto listados acima.
• [C-1-21] É PRECISO atender aos requisitos relacionados ao giroscópio, ao acelerômetro e ao magnetômetro para android.hardware.hifi_sensors, conforme especificado na seção 7.3.9.
• [C-SR-8] É ALTAMENTE RECOMENDADO oferecer suporte ao recurso android.hardware.sensor.hifi_sensors.
• [C-1-22] É PRECISO ter uma latência de movimento para fóton de ponta a ponta não superior a 28 milissegundos.
• [C-SR-9] É ALTAMENTE RECOMENDADO ter uma latência de movimento para fóton de ponta a ponta não superior a 20 milissegundos.
• [C-1-23] É OBRIGATÓRIO ter a proporção do primeiro frame, que é a proporção entre o brilho dos pixels no primeiro frame após uma transição de preto para branco e o brilho dos pixels brancos em estado estável, 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 para o aplicativo em primeiro plano superior.

Se o núcleo exclusivo tiver suporte, ele:

• [C-2-1] PRECISA não permitir que nenhum outro processo do espaço do usuário seja executado nele (exceto drivers de dispositivo usados pelo aplicativo), mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

7.10. Retorno tátil

Consulte a seção 2.2.1 para ver os requisitos específicos do dispositivo.

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 indica que o dispositivo não é de uma classe de performance de mídia.

Se as implementações do dispositivo 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] É PRECISO 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 é definida apenas para dispositivos portáteis na versão 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 potência são essenciais para a experiência do usuário e afetam as suposições de referência que os desenvolvedores teriam ao desenvolver um app.

8.1. Consistência na 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 dispositivo, dependendo do tipo, podem ter requisitos mensuráveis para a latência da interface do usuário e a alternância de tarefas, conforme descrito na seção 2.

8.2. Desempenho de acesso à E/S de arquivos

Fornecer uma referência comum para um desempenho consistente de acesso a arquivos no armazenamento de dados particular do aplicativo (partição /data) permite que os desenvolvedores definam uma expectativa adequada que ajudaria no design do software. As implementações do dispositivo, 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.
• Performance 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 lendo um arquivo de 256 MB usando um buffer de gravação de 10 MB.
• Desempenho de leitura aleatória. Medido lendo 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 do dispositivo incluírem recursos para melhorar o gerenciamento de energia do dispositivo que estão incluídos no AOSP (por exemplo, bucket de apps em espera, soneca) ou estender os recursos para aplicar restrições mais rígidas do que o bucket restrito para apps em espera, elas:

• [C-1-1] PRECISAM NÃO se 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 espera e economia de energia do app.
• [C-1-2] NÃO se desvie da implementação do AOSP para o uso de configurações globais ou do DeviceConfig para gerenciar o limite de jobs, alarmes e rede para apps em cada bucket de modo de espera do app.
• [C-1-3] NÃO se desviar da implementação do AOSP para o número de buckets de app em espera usados para o app em espera.
• [C-1-4] É OBRIGATÓRIO implementar Buckets de app em espera e Soneca, conforme descrito em Gerenciamento de energia.
• [C-1-5] É PRECISO retornar true para PowerManager.isPowerSaveMode() quando o dispositivo estiver no modo de economia de energia.
• [C-1-6] É necessário fornecer ao usuário a capacidade de mostrar todos os apps que estão isentos dos modos de economia de bateria do modo de espera e do modo soneca do app ou de qualquer otimização de bateria e IMPLEMENTAR a intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS para pedir ao usuário que permita que um app ignore as otimizações de bateria.
• [C-SR-1] É ALTAMENTE RECOMENDADO fornecer ao usuário a capacidade de ativar e desativar o recurso de economia de bateria.
• [C-SR-2] É ALTAMENTE RECOMENDADO fornecer ao usuário a capacidade de exibir todos os apps que estão isentos dos modos de economia de energia "Em espera do app" e "Doze".

Se as implementações do dispositivo estenderem os recursos de gerenciamento de energia incluídos no AOSP e essa extensão aplicar restrições mais rigorosas do que o bucket "Raro" do App em espera, 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 suspensão, conforme definido pela Interface avançada de energia e configuração (ACPI).

Se as implementações de dispositivos implementarem os estados de energia S4, conforme definido pelo ACPI, elas:

• [C-1-1] APENAS entre neste 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).

Se as implementações de dispositivos implementarem os estados de energia S3 conforme definido pelo ACPI, elas:

• [C-2-1] PRECISA atender a C-1-1 acima ou PRECISA entrar no estado S3 somente quando os aplicativos de terceiros não precisarem dos recursos do sistema (por exemplo, tela, CPU).

  Por outro lado, é PRECISO sair do estado S3 quando aplicativos de terceiros precisam dos recursos do sistema, conforme descrito neste SDK.

  Por exemplo, enquanto os aplicativos de terceiros solicitam que a tela continue ligada com FLAG_KEEP_SCREEN_ON ou que a CPU continue em execução com PARTIAL_WAKE_LOCK, o dispositivo NÃO PODE entrar no estado S3, a menos que, conforme descrito em C-1-1, o usuário tenha realizado uma ação explícita para colocar o dispositivo em um estado inativo. Por outro lado, quando uma tarefa implementada por apps de terceiros é acionada pelo JobScheduler ou quando o Firebase Cloud Messaging é enviado para 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 completo, e o AOSP implementa vários sinais de ativação que acionam uma ativação a partir desse estado.

8.4. Contabilidade de consumo de energia

Um registro e relatórios mais precisos do consumo de energia oferecem ao desenvolvedor do app os incentivos e as 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 aproximado de bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.
• [C-SR-2] É ALTAMENTE RECOMENDADO informar todos os valores de consumo de energia em miliamperes por 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 pelo comando adb shell dumpsys batterystats do shell para o desenvolvedor do app.
• 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 flutuar drasticamente em apps de alto desempenho de longa duração, seja por causa de outros apps em execução em segundo plano ou do estrangulamento 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 possa solicitar que o sistema otimize a alocação dos recursos para lidar com essas flutuações.

Implementações de dispositivos:

• [C-0-1] É OBRIGATÓRIO informar o suporte ao modo performance sustentada com precisão pelo método da API PowerManager.isSustainedPerformanceModeSupported().

• DEVE oferecer suporte ao modo performance sustentada.

Se as implementações de dispositivos informarem suporte ao modo performance sustentado, elas:

• [C-1-1] É PRECISO fornecer ao aplicativo em primeiro plano um nível consistente de desempenho por pelo menos 30 minutos, quando o app solicitar.
• [C-1-2] É PRECISO honrar a 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 principal em primeiro plano.

Se as implementações de dispositivos oferecerem suporte à reserva de um núcleo exclusivo para o aplicativo em primeiro plano, elas:

• [C-2-1] É OBRIGATÓRIO informar os números de ID das cores exclusivas que podem ser reservadas pelo aplicativo em primeiro plano principal pelo método da API Process.getExclusiveCores().
• [C-2-2] NÃO DEVE permitir que nenhum processo do espaço do usuário, exceto os drivers de dispositivo usados pelo aplicativo, seja executado nas CPUs exclusivas, mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

Se as implementações do dispositivo não oferecerem suporte a um núcleo exclusivo, elas:

• [C-3-1] PRECISA retornar uma lista vazia pelo método Process.getExclusiveCores() da API.

9. Compatibilidade do modelo de segurança

Implementações de dispositivos:

• [C-0-1] É PRECISO 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 do Android.

• [C-0-2] É PRECISO oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades.

Se as implementações do dispositivo 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] É PRECISO oferecer suporte ao modelo de permissões do Android e ao modelo de papéis do Android, conforme definido na documentação para desenvolvedores do Android. Especificamente, eles PRECISAM aplicar cada permissão e função definida conforme descrito na documentação do SDK. Nenhuma permissão nem 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] Permissões com um protectionLevel de PROTECTION_FLAG_PRIVILEGED SOMENTE podem ser concedidas a apps pré-instalados nos caminhos privilegiados da imagem do sistema (assim como arquivos APEX) e estar no subconjunto das permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito lendo e respeitando as permissões permitidas de cada app dos arquivos no caminho etc/permissions/ e usando o caminho system/priv-app como o caminho privilegiado.

As permissões com nível de proteção perigoso são de execução. Os aplicativos com targetSdkVersion > 22 os solicitam no momento da execução.

Implementações de dispositivos:

• [C-0-3] É OBRIGATÓRIO mostrar uma interface dedicada para que o usuário decida se concede as permissões de execução solicitadas e também forneça uma interface para que o usuário gerencie as permissões de execução.
• [C-0-4] É PRECISO ter uma e apenas uma implementação das duas interfaces do usuário. Se a implementação do dispositivo oferecer suporte a um dispositivo complementar, ele PODE fornecer uma interface extra.

• [C-0-5] NÃO é permitido conceder permissões de tempo 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 padrão de concessão de permissões ou por ter um papel da plataforma.

• [C-0-6] É PRECISO conceder a permissão android.permission.RECOVER_KEYSTORE apenas a apps do sistema que registram um agente de recuperação devidamente protegido. Um agente de recuperação protegido adequadamente é 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 de chaves do Google Cloud para evitar ataques de força bruta no fator de conhecimento da tela de bloqueio.

Implementações de dispositivos:

• [C-0-7] É obrigatório obedecer às propriedades da permissão de localização do Android quando um app solicita os dados de localização ou de atividade física usando a API padrão do Android ou um mecanismo reservado. 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 à qual o dispositivo está conectado).
  • Atividade física do usuário ou classificação da atividade física.

Mais especificamente, as implementações de dispositivos:

• [C-0-8] É OBRIGATÓRIO obter o consentimento do usuário para permitir que um app acesse os dados de local ou atividade física.
• [C-0-9] É PRECISO conceder uma permissão de execução SOMENTE ao app que tem permissão suficiente, conforme descrito no SDK. Por exemplo, TelephonyManager#getServiceState requer android.permission.ACCESS_FINE_LOCATION).

As únicas exceções às propriedades de permissão de local do Android acima são para apps que não acessam a localização para derivar ou identificar o local do usuário. Mais especificamente:

• Quando os apps têm a permissão RADIO_SCAN_WITHOUT_LOCATION.
• Para fins de configuração e configuração do dispositivo, 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 um papel associado às permissões hardRestricted a um app.
  • O instalador concede o hardRestricted a um app.
  • Um app recebe a hardRestricted em uma versão anterior do Android.

• [C-0-11] Os apps que têm uma permissão softRestricted PRECISAM ter apenas acesso limitado e PRECISAM NÃO ter acesso total até que sejam incluídos na lista de permissões permitidas, 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 FORNEÇA funções ou APIs personalizadas para contornar as restrições de permissão definidas nas APIs setPermissionPolicy e setPermissionGrantState.

• [C-0-13] É OBRIGATÓRIO usar as APIs AppOpsManager para registrar e acompanhar cada acesso programático de dados protegidos por permissões perigosas de atividades e serviços do Android.

• [C-0-14] SOMENTE DEVE atribuir papéis a aplicativos com funcionalidades que atendem aos requisitos de função.

• [C-0-15] NÃO é permitido definir funções que sejam duplicadas ou que tenham uma funcionalidade de superconjunto de funções definidas pela plataforma.

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 do dispositivo oferecerem uma capacidade para o usuário escolher quais apps podem ser renderizados sobre outros com uma atividade que processa a intent ACTION_MANAGE_OVERLAY_PERMISSION, elas:

• [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 IU, independentemente do app inicial ou de qualquer informação fornecida.

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

• [C-3-1] É OBRIGATÓRIO mostrar uma exoneração de responsabilidade durante a configuração de dispositivos totalmente gerenciados (configuração do proprietário do dispositivo) informando que o administrador de TI poderá permitir que os apps controlem as configurações no 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 do dispositivo pré-instalarem pacotes que contêm qualquer uma das 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ção do sistema, Inteligência de texto do sistema ou Inteligência visual do sistema, os pacotes:

• [C-4-1] É PRECISO atender a todos os requisitos descritos para implementações de dispositivos na seção "9.8.6 Captura de conteúdo".
• [C-4-2] NÃO pode ter a permissão android.permission.INTERNET. Isso é mais rigoroso do que a recomendação INTENSAMENTE RECOMENDADO listada na seção 9.8.6.
• [C-4-3] NÃO É PERMITIDO vincular a outros apps, exceto os seguintes apps do sistema: Bluetooth, Contatos, Mídia, Telefonia, SystemUI e componentes que fornecem APIs da Internet.Isso é mais rigoroso do que o ALTAMENTE RECOMENDADO listado na seção 9.8.6.

9.2. Isolamento de UID e processo

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao modelo de sandbox de aplicativos Android, em que cada aplicativo é executado como um UID no estilo Unix e em um processo separado.
• [C-0-2] É PRECISO oferecer suporte à execução de vários aplicativos como o mesmo ID de usuário do Linux, desde que os aplicativos sejam assinados e criados corretamente, 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] É necessário 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 algum outro software ou tecnologia que não seja o formato executável Dalvik ou o código nativo. Resumindo:

• [C-0-1] Os ambientes de execução alternativos PRECISAM ser aplicativos Android e obedecer ao modelo de segurança padrão do Android, conforme descrito em outro lugar na seção 9.

• [C-0-2] Não é permitido que ambientes de execução alternativos tenham acesso a recursos protegidos por permissões não solicitadas no arquivo AndroidManifest.xml do ambiente de execução pelo mecanismo <uses-permission>.

• [C-0-3] Os ambientes de execução alternativos NÃO PODEM permitir que os aplicativos usem recursos protegidos por permissões do Android restritas a aplicativos do sistema.

• [C-0-4] Os ambientes de execução alternativos PRECISAM obedecer ao modelo de sandbox do Android e os aplicativos instalados que usam um ambiente de execução 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] As runtimes alternativas NÃO PODEM ser iniciadas com, conceder ou receber acesso aos sandboxes correspondentes a outros apps Android.

• [C-0-6] As runtimes alternativas NÃO PODEM ser iniciadas com, receber ou conceder a outros aplicativos qualquer privilégio do superusuário (raiz) ou de qualquer outro ID de usuário.

• [C-0-7] Quando os arquivos .apk de ambientes de execução alternativos são incluídos na imagem do sistema das implementações do dispositivo, eles PRECISAM ser assinados com uma chave diferente da usada para assinar outros aplicativos incluídos nas implementações do dispositivo.

• [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 precisa usar um recurso do dispositivo para o qual há uma permissão correspondente do Android (como câmera, GPS etc.), o ambiente 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 detidos pelo próprio ambiente de execução ao instalar qualquer aplicativo que use esse ambiente.

• Ambientes de execução alternativos PRECISAM instalar apps pelo PackageManager em sandboxes do Android separados (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 a vários usuários e oferece suporte a isolamento total de usuários e clonagem de perfis de usuários 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 modo multiusuário se usarem mídia removível para armazenamento externo principal.

Se as implementações de dispositivos incluem suporte para vários usuários, elas:

• [C-1-2] PRECISA implementar, para cada usuário, 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] É PRECISO ter diretórios de armazenamento de aplicativos compartilhados separados e isolados (também conhecidos como /sdcard) para cada instância de usuário.
• [C-1-4] É OBRIGATÓRIO garantir que os aplicativos de um determinado usuário não possam listar, ler ou gravar nos arquivos de outro usuário, mesmo que os dados dos dois usuários estejam armazenados no mesmo volume ou sistema de arquivos.
• [C-1-5] PRECISA criptografar o conteúdo do cartão SD quando o modo multiusuário estiver ativado usando uma chave armazenada apenas em mídia não removível acessível apenas ao sistema, se as implementações do dispositivo usarem mídia removível para as APIs de armazenamento externo. Como isso torna a mídia ilegível para um PC host, as implementações de dispositivos precisam mudar para MTP ou um sistema semelhante para fornecer aos PCs host acesso aos dados do usuário atual.

Se as implementações do dispositivo incluem suporte para vários usuários, todos os usuários, exceto aqueles criados especificamente para executar instâncias duplas do mesmo app, podem:

• [C-2-1] É PRECISO ter diretórios de armazenamento de apps compartilhados separados e isolados (também conhecidos como /sdcard) para cada instância de usuário.
• [C-2-2] É PRECISO garantir que os aplicativos de propriedade e executados em nome de um determinado usuário 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 contra o usuário principal (e somente contra o usuário principal) para executar duas instâncias do mesmo app. Essas duas instâncias compartilham o armazenamento parcialmente isolado, são apresentadas ao usuário final no iniciador ao mesmo tempo e aparecem na mesma visualização de itens recentes. Por exemplo, isso pode ser usado para oferecer suporte ao usuário que instala duas instâncias separadas de um único app em um dispositivo dual-SIM.

Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, elas:

• [C-3-1] APENAS pode fornecer acesso a armazenamento ou dados que já estão acessíveis ao perfil de usuário pai ou são de propriedade direta desse perfil de usuário adicional.
• [C-3-2] NÃO deve ter isso como um perfil de trabalho.
• [C-3-3] É PRECISO ter diretórios de dados de apps particulares isolados da conta de usuário principal.
• [C-3-4] NÃO PERMITIR que o perfil de usuário extra seja criado se houver um proprietário do dispositivo provisionado (consulte a seção 3.9.1) ou permitir que um proprietário do dispositivo seja provisionado sem remover primeiro o perfil de usuário extra.

9.6. Aviso de SMS premium

O Android inclui suporte para avisar os usuários sobre qualquer mensagem SMS premium enviada. SMS premium são mensagens de texto enviadas para um serviço registrado com uma operadora que pode gerar uma cobrança para o usuário.

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

• [C-1-1] É OBRIGATÓRIO avisar 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 no dispositivo. O Android Open Source Project upstream fornece 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 do seccomp e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:

• [C-0-1] É PRECISO manter a compatibilidade com aplicativos existentes, mesmo quando o SELinux ou outros recursos de segurança forem implementados abaixo do framework do Android.
• [C-0-2] NÃO PODE ter uma interface do usuário visível quando uma violação de segurança é detectada e bloqueada pelo recurso de segurança implementado abaixo do framework do Android, mas PODE ter uma interface do usuário visível quando ocorre uma violação de segurança não bloqueada, resultando em uma exploração bem-sucedida.
• [C-0-3] NÃO É PERMITIDO tornar o SELinux ou qualquer outro recurso de segurança implementado abaixo do framework do Android configurável para o usuário ou desenvolvedor do app.
• [C-0-4] NÃO é permitido que um app que possa afetar outro por meio de uma API (como a API Device Administration) configure uma política que quebre a compatibilidade.
• [C-0-5] É PRECISO dividir o framework de mídia em vários processos para que seja possível conceder acesso mais restrito a cada processo, conforme descrito no site do Projeto Android Open Source.
• [C-0-6] É OBRIGATÓRIO implementar um mecanismo de sandbox de aplicativo de kernel que permita a filtragem de chamadas do sistema usando uma política configurável de programas multithread. O upstream do Android Open Source Project atende a esse requisito ativando o seccomp-BPF com sincronização de threadgroup (TSYNC), conforme descrito na seção "Configuração do kernel" do source.android.com.

Os recursos de integridade do kernel e de autoproteção são essenciais para a segurança do Android. Implementações de dispositivos:

• [C-0-7] É PRECISO 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] É PRECISO implementar proteções rígidas de memória do kernel em que o código executável é somente leitura, os dados somente leitura não são executáveis nem graváveis e os dados graváveis não são executáveis (por exemplo, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] É PRECISO implementar a verificação de limites de tamanho de objeto estático e dinâmico 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 o nível 28 da API ou mais recente.
• [C-0-10] NÃO EXECUTAR a memória do espaço do usuário ao executar no modo do kernel (por exemplo, PXN de hardware ou emulado por CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente enviados com o nível 28 da API ou mais recente.
• [C-0-11] NÃO É PERMITIDO ler ou gravar a memória do espaço do usuário no kernel fora das APIs de acesso de cópia de usuário normais (por exemplo, PAN de hardware ou emulado por CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente enviados com o nível 28 da API ou mais recente.
• [C-0-12] É PRECISO implementar o isolamento da tabela de páginas do kernel se o hardware for vulnerável ao CVE-2017-5754 em todos os dispositivos enviados originalmente com o nível 28 da API ou mais recente (por exemplo, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] É PRECISO implementar o aumento da proteção da previsão de ramificação se o hardware for vulnerável ao CVE-2017-5715 em todos os dispositivos enviados originalmente com o nível 28 da API ou mais recente (por exemplo, CONFIG_HARDEN_BRANCH_PREDICTOR).
• [C-SR-1] É ALTAMENTE RECOMENDADO manter os dados do kernel que são gravados apenas durante a inicialização marcados como somente leitura após a inicialização (por exemplo, __ro_after_init).

• [C-SR-2] É ALTAMENTE RECOMENDADO que o layout do código do kernel e da memória seja aleatório e que se evite exposições que comprometam a randomização (por exemplo, CONFIG_RANDOMIZE_BASE com entropia do carregador de inicialização pelo /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

• [C-SR-3] É ALTAMENTE RECOMENDADO ativar a integridade do fluxo de controle (CFI, na sigla em inglês) no kernel para fornecer 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, na sigla em inglês), a pilha de chamadas de sombra (SCS, na sigla em inglês) ou a limpeza de estouro de inteiros (IntSan, na sigla em inglês) nos componentes que estão ativados.

• [C-SR-5] É ALTAMENTE RECOMENDADO ativar a CFI, a SCS e a IntSan para qualquer componente de espaço do usuário sensível à segurança, conforme explicado em CFI e IntSan.

• [C-SR-6] É ALTAMENTE RECOMENDADO ativar a inicialização da 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 assumir o valor usado pelo compilador para inicializar os locais.

• [C-SR-7] É ALTAMENTE RECOMENDADO 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 ELAS NÃO PODEM assumir o valor usado pelo kernel para inicializar essas alocações.

Se as implementações do dispositivo usarem um kernel do Linux capaz de oferecer suporte ao SELinux, elas:

• [C-1-1] É PRECISO implementar o SELinux.
• [C-1-2] É PRECISO definir o SELinux para o modo de aplicação global.
• [C-1-3] É PRECISO configurar todos os domínios no modo de aplicação. Não são permitidos domínios em modo permissivo, incluindo domínios específicos de um dispositivo/fabricante.
• [C-1-4] NÃO É PERMITIDO modificar, omitir ou substituir as regras neverallow presentes na pasta system/sepolicy fornecida no upstream do Android Open Source Project (AOSP), e a política PRECISA ser compilada com todas as regras neverallow presentes, tanto para domínios AOSP SELinux quanto para domínios específicos de dispositivo/fabricante.
• [C-1-5] É OBRIGATÓRIO executar aplicativos de terceiros com o nível 28 da API ou mais recente em sandboxes SELinux por aplicativo com restrições de SELinux por aplicativo no diretório de dados particular de cada aplicativo.
• DEVE manter a política SELinux padrão fornecida na pasta system/sepolicy do Projeto Android Open Source upstream e adicionar apenas a essa política para a própria configuração específica do dispositivo.

Se as implementações do dispositivo usarem um kernel diferente do Linux ou do Linux sem o SELinux, elas:

• [C-2-1] É PRECISO usar um sistema de controle de acesso obrigatório equivalente ao SELinux.

Se as implementações de dispositivos usarem dispositivos de E/S com suporte a DMA, elas:

• [C-SR-9] É ALTAMENTE RECOMENDADO isolar cada dispositivo de E/S capaz de DMA, usando um IOMMU (por exemplo, o 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 dispositivo.
• [C-SR-11] É ALTAMENTE RECOMENDADO que sejam testados usando ferramentas de detecção de erros de memória do kernel, como o 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 dispositivo).
• [C-SR-12] É ALTAMENTE RECOMENDADO usar ferramentas de detecção de erros de memória na produção, como MTE, GWP-ASan e KFENCE.

Se as implementações do dispositivo usarem um TEE baseado na 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 que eles acessem apenas a memória que foi explicitamente compartilhada com eles pelo protocolo acima. Se o dispositivo tiver suporte ao nível de exceção Arm S-EL2, isso será aplicado pelo gerenciador de partição segura. Caso contrário, isso precisa ser forçado pelo SO do TEE.

9,8. Privacidade

9.8.1. Histórico de uso

O Android armazena o histórico das escolhas do usuário e o gerencia usando o UsageStatsManager.

Implementações de dispositivos:

• [C-0-1] É OBRIGATÓRIO manter um período de retenção razoável desse histórico de usuário.
• [C-SR-1] É ALTAMENTE RECOMENDADO manter o período de retenção 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 usando o StatsManager e a API System IncidentManager.

Implementações de dispositivos:

• [C-0-2] SOMENTE os campos marcados com DEST_AUTOMATIC precisam ser incluídos no relatório de incidentes criado pela classe IncidentManager da API System.
• [C-0-3] É PROIBIDO 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. Gravações

Implementações de dispositivos:

• [C-0-1] NÃO É PERMITIDO pré-carregar ou distribuir componentes de software prontos para uso que enviem as informações particulares do usuário (por exemplo, teclas pressionadas, texto exibido na tela, bugreport) do dispositivo sem o consentimento do usuário ou limpar notificações em andamento.
• [C-0-2] É OBRIGATÓRIO mostrar e receber o consentimento explícito do usuário, permitindo que qualquer informação sensível exibida na tela do usuário seja capturada sempre que a transmissão ou gravação de tela estiver ativada por MediaProjection ou APIs proprietárias. NÃO PODE permitir que os usuários desativem a exibição futura do consentimento do usuário.
• [C-0-3] É NECESSÁRIO ter uma notificação contínua para o usuário enquanto a transmissão ou gravação de tela estiver ativada. O AOSP atende a esse requisito mostrando um ícone de notificação em andamento na barra de status.

Se as implementações do dispositivo incluírem uma funcionalidade no sistema que captura o conteúdo exibido na tela e/ou grava o stream de áudio reproduzido no dispositivo, que não seja pela API do sistema ContentCaptureService ou outros meios proprietários descritos na Seção 9.8.6 Captura de conteúdo, elas:

• [C-1-1] É PRECISO ter uma notificação em andamento para o usuário sempre que esse recurso estiver ativado e capturando/gravando ativamente.

Se as implementações de dispositivo incluírem um componente ativado nativamente, capaz de gravar o á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 ARMAZENE de forma persistente no armazenamento do dispositivo nem transmita fora do dispositivo o áudio bruto gravado ou qualquer formato que possa ser convertido de volta no áudio original ou em um fac-símile próximo, exceto com consentimento explícito do usuário.

Um "indicador de microfone" se refere a uma visualização na tela, que é constantemente visível para o usuário e não pode ser obscurecida, que os usuários entendem como um microfone em uso(por texto, cor, ícone ou alguma combinação exclusiva).

Um "indicador de câmera" se refere a uma visualização na tela, que é constantemente visível para o usuário e não pode ser obscurecida, que os usuários entendem como uma câmera em uso (por texto, cor, ícone ou alguma combinação exclusiva).

Depois que o primeiro segundo é exibido, um indicador pode mudar visualmente, por exemplo, ficando menor, e não é necessário mostrar como foi originalmente apresentado e entendido.

O indicador de microfone pode ser mesclado com um indicador de câmera exibido ativamente, desde que texto, ícones ou cores indiquem ao usuário que o uso do microfone foi iniciado.

O indicador da câmera pode ser mesclado com um indicador de microfone exibido ativamente, desde que texto, ícones ou cores indiquem ao usuário que o uso da câmera começou.

Se as implementações do dispositivo declararem android.hardware.microphone, elas:

• [C-SR-1] É ALTAMENTE RECOMENDADO mostrar o indicador do microfone quando um app está acessando dados de áudio do microfone, mas não quando o microfone é 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 CDD [C-3-X]. .
• [C-SR-2] É ALTAMENTE RECOMENDADO mostrar a lista de apps recentes e ativos usando o microfone conforme retornado por PermissionManager.getIndicatorAppOpUsageData(), junto com as mensagens de atribuição associadas a eles.
• [C-SR-3] É ALTAMENTE RECOMENDADO não ocultar o indicador do microfone para apps do sistema que têm interfaces do usuário visíveis ou interação direta do usuário.

Se as implementações do dispositivo declararem android.hardware.camera.any, elas:

• [C-SR-4] É ALTAMENTE RECOMENDADO mostrar o indicador da câmera quando um app está acessando dados da câmera ao vivo, mas não quando a câmera está 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].
• [C-SR-5] É ALTAMENTE RECOMENDADO mostrar apps recentes e ativos usando a câmera retornada de PermissionManager.getIndicatorAppOpUsageData(), junto com as mensagens de atribuição associadas a eles.
• [C-SR-6] É ALTAMENTE RECOMENDADO não ocultar o indicador da câmera para apps do sistema que têm interfaces do usuário visíveis ou interação direta do usuário.

9.8.3. Conectividade

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

• [C-1-1] É PRECISO apresentar uma interface que solicite 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] É PRECISO pré-instalar os mesmos certificados raiz para a loja de autoridade de certificação confiável do sistema (AC) fornecidos no projeto upstream do Android Open Source.
• [C-0-2] É OBRIGATÓRIO enviar com uma loja de AC raiz do usuário vazia.
• [C-0-3] É OBRIGATÓRIO mostrar um aviso ao usuário indicando que o tráfego de rede pode ser monitorado quando uma AC raiz do usuário é adicionada.

Se o tráfego do dispositivo for roteado por uma VPN, as implementações do dispositivo:

• [C-1-1] É OBRIGATÓRIO mostrar um aviso ao usuário indicando:
  • Esse tráfego de rede pode ser monitorado.
  • Esse tráfego de rede está sendo roteado pelo aplicativo VPN 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 VPN (por exemplo, carregando um serviço de VPN com android.permission.CONTROL_VPN concedido), elas:

• [C-2-1] É PRECISO pedir o consentimento do usuário antes de ativar esse mecanismo, a menos que essa VPN seja ativada pelo Device Policy Controller pelo DevicePolicyManager.setAlwaysOnVpnPackage(), nesse caso, o usuário não precisa fornecer um consentimento separado, mas PRECISA ser notificado.

Se as implementações de dispositivo implementarem uma capacidade do usuário para ativar a função "VPN sempre ativa" de um app de VPN de terceiros, elas:

• [C-3-1] É PRECISO desativar essa capacidade do usuário para apps que não oferecem suporte ao serviço de VPN sempre ativa 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] É OBRIGATÓRIO impedir o acesso ao número de série do dispositivo e, quando aplicável, ao IMEI/MEID, ao número de série do SIM e à Identidade Internacional de Assinante de Celular (IMSI) de um app, a menos que ele atenda a um dos seguintes requisitos:
  • é um app de operadora assinado que é 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 do dispositivo ou do perfil que recebeu a permissão READ_PHONE_STATE.
  • (Somente para número de série do SIM/ICCID) tem a exigência de regulamentação local de que o app detecte mudanças na identidade do assinante.

9.8.6. Captura de conteúdo e pesquisa de apps

O Android, pela API System ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query ou por outros meios proprietários, oferece suporte a um mecanismo para implementações de dispositivos capturarem as seguintes interações de dados de aplicativos entre os aplicativos e o usuário:

• Textos e gráficos renderizados na tela, incluindo, entre outros, notificações e dados de assistência pela API AssistStructure.
• 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 outro evento que um aplicativo forneça ao sistema pela API Content Capture ou pela API AppSearchManager, uma API proprietária e do Android com capacidade semelhante.
• Qualquer texto ou outros dados enviados pelo TextClassifier API para o Classificador de texto do sistema, ou seja, para o serviço do sistema para entender o significado do texto, além de gerar próximas ações previstas com base no texto.
• Dados indexados pela implementação da AppSearch na plataforma, incluindo, entre outros, texto, gráficos, dados de mídia ou outros dados semelhantes.

Se as implementações do dispositivo capturarem os dados acima, elas:

• [C-1-1] PRECISA criptografar todos esses dados quando armazenados no dispositivo. Essa criptografia PODE ser realizada usando a criptografia baseada em arquivos do Android ou qualquer das cifras listadas como versão 26 ou mais recente da API, descritas no SDK Cipher.
• [C-1-2] NÃO É PERMITIDO fazer backup de dados brutos ou criptografados usando métodos de backup do Android ou qualquer outro método de backup.
• [C-1-3] SOMENTE é permitido enviar todos esses dados e o registro do dispositivo usando um mecanismo de preservação de privacidade. O mecanismo de preservação de 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 introspeccionáveis (por exemplo, implementados usando uma tecnologia de privacidade diferencial, como RAPPOR).
• [C-1-4] NÃO É PERMITIDO associar esses dados a qualquer identidade de usuário (como Account) no dispositivo, exceto com o consentimento explícito do usuário sempre que os dados forem associados.
• [C-1-5] NADA IMPEDE o compartilhamento desses dados com outros componentes do SO que não seguem os requisitos descritos na seção atual (9.8.6 Captura de conteúdo), exceto com o consentimento explícito do usuário sempre que for compartilhado.
• [C-1-6] É OBRIGATÓRIO fornecer ao usuário a possibilidade de apagar os dados que a ContentCaptureService ou os meios proprietários coletam se os dados forem armazenados de qualquer forma no dispositivo.
• [C-1-7] É OBRIGATÓRIO fornecer uma capacidade do usuário para desativar a exibição dos dados coletados pela AppSearch ou por meios proprietários na plataforma Android, por exemplo, no iniciador.
• [C-SR-1] É ALTAMENTE RECOMENDADO não solicitar a permissão 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.

Se as implementações de dispositivo incluírem um serviço que implementa a API System ContentCaptureService, AppSearchManager.index ou qualquer serviço proprietário que capture os dados conforme descrito acima, elas:

• [C-2-1] NÃO DEVE permitir que os usuários substituam os serviços por um aplicativo ou serviço instalável pelo usuário e DEVE permitir que apenas os serviços pré-instalados capturem esses dados.
• [C-2-2] NÃO é permitido que nenhum app, exceto o mecanismo de serviços pré-instalado, capture esses dados.
• [C-2-3] É PRECISO fornecer ao usuário a capacidade de desativar os serviços.
• [C-2-4] NÃO É PERMITIDO omitir a capacidade do usuário de gerenciar permissões do Android que são mantidas pelos serviços e seguem 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 vincular o serviço ou compartilhar IDs de processo), exceto o seguinte:

  • Telefonia, contatos, interface do sistema e mídia

O Android, por meio de SpeechRecognizer#onDeviceSpeechRecognizer(), oferece a capacidade de realizar o reconhecimento de fala no dispositivo, sem envolver a rede. Qualquer implementação do SpeechRecognizer no dispositivo PRECISA seguir as políticas descritas nesta seção.

9.8.7. Acesso à área de transferência

Implementações de dispositivos:

• [C-0-1] NÃO DEVE retornar dados recortados da área de transferência (por exemplo, pela API ClipboardManager), a menos que o app de terceiros seja o IME padrão ou o app que está 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 inserção ou leitura.

9.8.8. Local

A localização inclui informações na classe Location 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 grosseira quanto locais no nível do país (como o local do código do país: MCC - Mobile Country Code).

Confira a seguir uma lista de tipos de local que derivam diretamente a localização de um usuário ou podem ser convertidos em uma localização do usuário. Esta não é uma lista completa, mas deve ser usada como um exemplo de como a localização pode ser derivada de forma direta ou indireta:

• GPS/GNSS/DGPS/PPP
  • Solução de posicionamento global ou sistema global de navegação por satélite ou solução diferencial de posicionamento global
  • 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… incluindo todas as tecnologias de modem celular futuras 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 ative/desative a configuração de localização do dispositivo e as configurações de verificação de Wi-Fi/Bluetooth sem o consentimento ou a iniciação explícita do usuário.
• [C-0-2] É OBRIGATÓRIO fornecer ao usuário a capacidade de acessar informações relacionadas à localização, incluindo solicitações de localização recentes, permissões no nível do app e uso de verificação de Wi-Fi/Bluetooth para determinar a localização.
• [C-0-3] É OBRIGATÓRIO 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, discar 911 ou enviar mensagem para 911). No entanto, para o setor automotivo, um veículo PODE iniciar uma sessão de emergência sem interação ativa do usuário no caso de um acidente ser detectado (por exemplo, para atender aos requisitos de chamada de emergência).
• [C-0-4] É PRECISO preservar a capacidade da API Emergency Location Bypass de ignorar as configurações de localização do dispositivo sem mudar as configurações.
• [C-0-5] É necessário programar uma notificação que lembre o usuário depois que um app em segundo plano tiver acessado a localização dele usando a permissão [ACCESS_BACKGROUND_LOCATION].

9.8.9. Apps instalados

Por padrão, os apps Android destinados ao nível 30 da API ou mais recente não podem acessar detalhes sobre outros apps instalados. Consulte Visibilidade do pacote na documentação do SDK do Android.

Implementações de dispositivos:

• [C-0-1] NÃO EXPOR detalhes de nenhum outro app instalado a qualquer app que tenha como alvo o nível 30 da API ou mais recente, a menos que o app já consiga ver detalhes sobre o outro app instalado pelas APIs gerenciadas. Isso inclui, mas não se limita a, 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 em qualquer outro diretório dedicado e específico do app no armazenamento externo. As únicas exceções são as seguintes:
  • A autoridade do provedor de armazenamento externo (por exemplo, apps como o DocumentsUI).
  • Provedor de downloads que usa a autoridade do provedor de "downloads" para fazer o download de arquivos para o armazenamento do app.
  • Apps de protocolo de transferência de mídia (MTP, na sigla em inglês) assinados pela plataforma que usam a permissão privilegiada ACCESS_MTP para permitir a transferência de arquivos para outro dispositivo.
  • Apps que instalam outros apps e têm a permissão INSTALL_PACKAGES só podem acessar diretórios "obb" para gerenciar arquivos de expansão do APK.

9.8.10. Relatório de bug de conectividade

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

• [C-1-1] É PRECISO oferecer suporte à geração de relatórios de bugs de conectividade pelo BUGREPORT_MODE_TELEPHONY com o BugreportManager.
• [C-1-2] É OBRIGATÓRIO receber o consentimento do usuário sempre que BUGREPORT_MODE_TELEPHONY for usado para gerar um relatório e NÃO é permitido solicitar o consentimento do usuário para todas as solicitações futuras do aplicativo.
• [C-1-3] NÃO DEVE 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 vinculado)
  • Buffer de registro de rádio
• [C-1-5] NÃO inclua o seguinte nos relatórios gerados:
  • Qualquer tipo de informação que não esteja diretamente relacionada ao 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 (os UIDs são aceitáveis, mas os nomes de pacotes não são).
• PODE incluir informações adicionais que não estão associadas a nenhuma identidade do usuário. (por exemplo, registros de fornecedores).

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 afetarem a privacidade/segurança/bateria/armazenamento/memória, elas:

• [C-SR-1] É ALTAMENTE RECOMENDADO que a configuração do desenvolvedor seja desativada por padrão. A implementação de referência do AOSP atende a isso fornecendo a opção Enable verbose vendor logging nas configurações do desenvolvedor para incluir mais registros de fornecedores específicos do dispositivo nos relatórios de bugs.

9.8.11. Compartilhamento de blobs de dados

O Android, por meio do BlobStoreManager, permite que os apps contribuam com blobs de dados para que o sistema seja compartilhado com um conjunto selecionado de apps.

Se as implementações do dispositivo oferecerem suporte a blobs de dados 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(). A implementação de referência do AOSP atende a esses requisitos.
• [C-1-2] NÃO É PERMITIDO enviar do dispositivo ou compartilhar com outros apps os hashes seguros de blobs de dados (que são usados para controlar o acesso).

9.8.12. Identificação de música

O Android, por meio da API System MusicRecognitionManager, oferece suporte a um mecanismo para implementações de dispositivos solicitarem o reconhecimento de música, considerando um registro de áudio, e delegar o reconhecimento de música a um app privilegiado que implementa a API MusicRecognitionService.

Se as implementações do dispositivo incluírem um serviço que implementa a API MusicRecognitionManager do sistema ou qualquer serviço proprietário que transmita dados de áudio conforme descrito acima, elas:

• [C-1-1] É PRECISO que o autor da chamada de MusicRecognitionManager tenha a permissão MANAGE_MUSIC_RECOGNITION.
• [C-1-2] É PRECISO que um único aplicativo de reconhecimento de música pré-instalado implemente o MusicRecognitionService.
• [C-1-3] NÃO é permitido aos usuários substituir o MusicRecognitionManagerService ou o MusicRecognitionService por um aplicativo ou serviço instalável pelo usuário.
• [C-1-4] É necessário garantir que, quando o MusicRecognitionManagerService acessar o registro de áudio e o encaminhar ao aplicativo que implementa o MusicRecognitionService, o acesso ao áudio seja rastreado por invocações de AppOpsManager.noteOp / startOp.

Se as implementações do dispositivo de MusicRecognitionManagerService ou MusicRecognitionService armazenarem dados de áudio capturados, elas:

• [C-2-1] NÃO ARMAZENE áudio bruto ou impressões digitais de áudio no disco, nem na memória por mais de 14 dias.
• [C-2-2] NÃO COMPARTILHE esses dados fora do MusicRecognitionService, exceto com o consentimento explícito do usuário sempre que forem compartilhados.

9.8.13. SensorPrivacyManager

Se as implementações de dispositivo oferecerem ao usuário uma característica de software para desativar a entrada da câmera e/ou do microfone para a implementação do dispositivo, elas:

• [C-1-1] PRECISA retornar "true" com precisão para o método da API supportsSensorToggle() relevante.
• [C-1-2] Quando um app tentar acessar um microfone ou uma câmera bloqueados, ele PRECISA apresentar ao usuário uma característica que não possa ser dispensada, que indique claramente que o sensor está bloqueado e exija uma escolha para continuar bloqueando ou desbloqueando, conforme a implementação do AOSP que atende a esse requisito.
• [C-1-3] DEVE transmitir apenas dados de câmera e áudio em branco (ou falsos) para apps e não informar um código de erro devido ao usuário não ligar a câmera nem o microfone usando a affordance do usuário apresentada em [C-1-2] acima.

9,9. Criptografia de armazenamento de dados

Todos os dispositivos precisam atender aos requisitos da seção 9.9.1. Os 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] É PRECISO implementar as APIs do modo de inicialização direta, mesmo que elas não ofereçam suporte à 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 do dispositivo (DE) e criptografados por credencial (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 compartilhada 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 pronta para uso.

• [C-0-3] É PRECISO atender ao requisito de criptografia de armazenamento de dados acima implementando um dos dois métodos de criptografia abaixo:

  • 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.

Observação: implementações de dispositivos que foram enviados com um nível 28 da API ou anterior e que não atendem aos requisitos da 9.9.2 por uma atualização de software do sistema 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 enviado.

9.9.3. Métodos de criptografia

Se as implementações do dispositivo forem criptografadas, elas:

• [C-1-1] É PRECISO inicializar sem pedir credenciais ao usuário e permitir que apps que reconhecem a inicialização direta acessem o armazenamento criptografado do dispositivo (DE, na sigla em inglês) depois que a mensagem ACTION_LOCKED_BOOT_COMPLETED for transmitida.
• [C-1-2] SOMENTE PERMITIR O ACESSO AO ARMAZENAMENTO CRIPTOGRÁFICO DE CREDENCIAIS (CE, NA SIGLA EM INGLÊS) DEPOIS QUE O USUÁRIO DESBLOQUEAR O DISPOSITIVO FORNECENDO AS CREDENCIAIS (POR EXEMPLO, SENHA, PIN, PADRÃO OU IMPRESSÃO DIGITAL) E A MENSAGEM ACTION_USER_UNLOCKED FOR TRANSMITIDA.
• [C-1-13] NÃO ofereça nenhum método para desbloquear o armazenamento protegido por CE sem as credenciais fornecidas pelo usuário, uma chave de depósito fiduciário registrada ou uma retomada na implementação de reinicialização que atenda aos requisitos da seção 9.9.4.
• [C-1-4] É OBRIGATÓRIO usar a inicialização verificada.

9.9.3.1. Criptografia baseada em arquivos com criptografia de metadados

Se as implementações de dispositivos usarem a criptografia baseada em arquivos com a criptografia de metadados, elas:

• [C-1-5] É NECESSÁ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 de arquivos, propriedade, modos e atributos estendidos (xattrs).
• [C-1-6] É NECESSÁRIO criptografar os nomes de arquivo usando AES-256-CBC-CTS ou Adiantum.
• [C-1-12] Se o dispositivo tiver instruções do padrão de criptografia avançada (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 PRECISAM ser usadas, não o Adiantum.
• [C-1-13] É OBRIGATÓRIO usar uma função de derivação de chave criptograficamente forte e não reversível (por exemplo, HKDF-SHA512) para derivar as subchaves necessárias (por exemplo, chaves por arquivo) das chaves CE e DE. "Forte criptograficamente e não reversí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 pseudoaleatórias sobre as entradas.
• [C-1-14] NÃO use as mesmas chaves ou subchaves de criptografia baseada em arquivo (FBE) para finalidades criptográficas diferentes (por exemplo, para criptografia e derivação de chave ou para dois algoritmos de criptografia diferentes).
• [C-1-15] É PRECISO garantir que todos os blocos não excluídos do conteúdo do arquivo criptografado no armazenamento persistente tenham sido 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 oferece suporte apenas a um IV de 32 bits.
• [C-1-16] É OBRIGATÓRIO garantir que todos os nomes de arquivos criptografados não excluídos no armazenamento persistente em diretórios distintos foram criptografados usando combinações distintas de chave de criptografia e vetor de inicialização (IV).

• [C-1-17] É OBRIGATÓRIO garantir que todos os blocos de metadados do sistema de arquivos criptografados no armazenamento persistente tenham sido criptografados usando combinações distintas de chave de criptografia e vetor de inicialização (IV).

• Chaves que protegem as áreas de armazenamento de CE e DE e os metadados do sistema de arquivos:

  • [C-1-7] PRECISA ser criptograficamente vinculado a um keystore protegido por hardware. Esse keystore PRECISA estar vinculado à inicialização verificada e à raiz de confiança do hardware do dispositivo.
  • [C-1-8] As chaves de CE precisam estar vinculadas às credenciais da tela de bloqueio de um usuário.
  • [C-1-9] As chaves de CE precisam estar 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, nenhuma chave de CE ou DE de um usuário concorda com as chaves de CE ou DE de outro usuário.
  • [C-1-11] É OBRIGATÓRIO usar as criptografias, os comprimentos de chave e os modos com suporte obrigatório.
  • [C-1-12] PRECISA ser apagado com segurança durante o desbloqueio e o bloqueio do carregador de inicialização, conforme descrito aqui.

• DEVE tornar os apps essenciais pré-instalados (por exemplo, Alarm, Phone, Messenger) compatíveis com o Direct Boot.

O projeto upstream do 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.

Observação: implementações de dispositivos que foram enviados no nível 28 da API ou versões anteriores e que não atendem aos requisitos da 9.9.3 por uma atualização de software do sistema 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 enviado.

9.9.3.2. Criptografia no nível de bloco por usuário

Se as implementações de dispositivo usarem a criptografia no nível do bloco por usuário, elas:

• [C-1-1] É OBRIGATÓRIO ativar o suporte a vários usuários, conforme descrito na seção 9.5.
• [C-1-2] É PRECISO fornecer partições por usuário, usando partições brutas ou volumes lógicos.
• [C-1-3] É OBRIGATÓRIO usar chaves de criptografia exclusivas e distintas por usuário para criptografar os dispositivos de bloco subjacentes.

• [C-1-4] É OBRIGATÓRIO usar AES-256-XTS para criptografia em 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 keystore 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 em nível de 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 de 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. Esse recurso permite que os usuários recebam notificações de apps instalados após a reinicialização.

Uma implementação de retomada na reinicialização precisa continuar garantindo que, quando um dispositivo cair nas mãos de um invasor, será 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 a 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 os seguintes recursos 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 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 adulterações (por exemplo, Titan M).
  • Não é possível ler a RAM do dispositivo em tempo real.
  • Não é possível acessar 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 será compatível com [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] É PRECISO informar corretamente pelo método da API do sistema PersistentDataBlockManager.getFlashLockState() se o estado do carregador de inicialização permite a atualização da imagem do sistema.

• [C-0-2] É PRECISO oferecer suporte à inicialização verificada para a integridade do dispositivo.

Se as implementações do dispositivo já foram lançadas sem suporte à inicialização verificada em uma versão anterior do Android e não puderem adicionar suporte a esse recurso com uma atualização do software do sistema, elas PODEM ser isentas do requisito.

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

• [C-1-1] É PRECISO declarar a flag de recurso da plataforma android.software.verified_boot.
• [C-1-2] É PRECISO realizar a verificação em cada sequência de inicialização.
• [C-1-3] É PRECISO iniciar a verificação em uma chave de hardware imutável que seja a raiz de confiança e ir até a partição do sistema.
• [C-1-4] É PRECISO implementar cada fase de verificação para verificar a integridade e a autenticidade de todos os bytes na próxima fase antes de executar o código nesta fase.
• [C-1-5] É OBRIGATÓRIO 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 é permitido que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário consinta tentar a inicialização. Nesse caso, os dados de qualquer bloco de armazenamento não verificado NÃO PODEM ser usados.
• [C-1-7] NÃO É PERMITIDO que partições verificadas no dispositivo sejam modificadas, a menos que o usuário tenha desbloqueado explicitamente o carregador de inicialização.
• [C-SR-1] Se houver vários chips discretos no dispositivo (por exemplo, rádio, processador de imagens especializado), é ALTAMENTE RECOMENDÁVEL verificar cada etapa durante a inicialização do processo de inicialização de cada um desses chips.
• [C-1-8] É OBRIGATÓRIO usar armazenamento inviolável: para armazenar se o bootloader está desbloqueado. O armazenamento com evidências de adulteração significa que o carregador de inicialização pode detectar se o armazenamento foi adulterado no Android.
• [C-1-9] É OBRIGATÓRIO solicitar que o usuário, ao usar o dispositivo, exija a confirmação física antes de permitir a transição do modo bloqueado para o modo desbloqueado do carregador de inicialização.
• [C-1-10] É OBRIGATÓRIO implementar a proteção de reversão para partições usadas pelo Android (por exemplo, inicialização, partições do sistema) e usar armazenamento inviolável para armazenar os metadados usados para determinar a versão mínima do SO permitida.
• [C-1-11] É PRECISO apagar com segurança todos os dados do usuário durante o desbloqueio e o 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-SR-2] É ALTAMENTE RECOMENDADO verificar todos os arquivos APK de apps privilegiados com uma cadeia de confiança com base 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 jeito nenhum.
• DEVE implementar a proteção contra reversão para qualquer componente com firmware persistente (por exemplo, modem, câmera) e DEVE usar armazenamento inviolável para armazenar os metadados usados para determinar a versão mínima permitida.

Se as implementações de dispositivos já foram lançadas sem suporte a C-1-8 a C-1-11 em uma versão anterior do Android e não puderem adicionar suporte a esses requisitos com uma atualização de software do sistema, elas PODEM ser isentas dos requisitos.

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.

Implementações de dispositivos:

• [C-0-3] É PRECISO oferecer suporte à verificação criptográfica do conteúdo do arquivo em relação a uma chave confiável sem ler o arquivo inteiro.
• [C-0-4] NÃO É PERMITIDO que as solicitações de leitura em um arquivo protegido sejam bem-sucedidas quando o conteúdo lido não for verificado em uma chave confiável.

Se as implementações de dispositivos já foram 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 puderem adicionar suporte a esse recurso com uma atualização de software do sistema, elas PODEM ser isentas do requisito. O projeto upstream do Android Open Source oferece uma implementação preferencial desse recurso com base no recurso fs-verity do kernel do Linux.

Implementações de dispositivos:

• [C-SR-4] É ALTAMENTE RECOMENDADO oferecer suporte à API Android Protected Confirmation.

Se as implementações do dispositivo oferecerem suporte à API Android Protected Confirmation, elas:

• [C-3-1] É OBRIGATÓRIO informar true para a API ConfirmationPrompt.isSupported().

• [C-3-2] É NECESSÁRIO garantir que o código em execução no SO Android, incluindo o kernel, malicioso ou não, não possa gerar uma resposta positiva sem interação do usuário.

• [C-3-3] É OBRIGATÓRIO garantir que o usuário tenha podido analisar e aprovar a mensagem solicitada, mesmo que o SO Android, incluindo o kernel, esteja comprometido.

9.11. Chaves e credenciais

O sistema Android Keystore 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 que pelo menos 8.192 chaves sejam importadas ou geradas.
• [C-0-2] A autenticação da tela de bloqueio PRECISA implementar um intervalo de tempo entre as 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 de 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] É NECESSÁRIO fazer backup da implementação do keystore com um ambiente de execução isolado.
• [C-1-2] É PRECISO ter implementações de algoritmos criptográficos RSA, AES, ECDSA, ECDH (se o IKeyMintDevice for aceito), 3DES e HMAC, além de funções de hash da família MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos aceitos pelo sistema Keystore do Android em uma área isolada com segurança do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais em que o kernel ou o código do espaço do usuário pode acessar o estado interno do ambiente isolado, incluindo o DMA. O upstream do Android Open Source Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
• [C-1-3] É PRECISO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e, somente quando bem-sucedido, permitir que as chaves vinculadas à autenticação sejam usadas. 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 upstream do Android Open Source Project fornece a camada de abstração de hardware (HAL, na sigla em inglês) do gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
• [C-1-4] É PRECISO 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 precisam ser compartilhadas em um número suficiente de dispositivos para evitar que sejam usadas como identificadores. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de um SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

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

• [C-1-5] É PRECISO permitir que o usuário escolha o tempo limite de suspensão para a transição do estado desbloqueado para o bloqueado, com um tempo limite mínimo permitido de até 15 segundos. Dispositivos automotivos, que bloqueiam a tela sempre que a unidade principal é desligada ou o usuário é trocado, PODEM NÃO ter a configuração de tempo limite de suspensão.
• [C-1-6] É PRECISO oferecer suporte a uma das seguintes opções:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1,
  • IKeyMintDevice versão 1 ou
  • IKeyMintDevice versão 2.
• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte à versão 1 do IKeyMintDevice.

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 primária baseada em fábrica de conhecimento pode ser apoiada 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 deslizar em uma grade de exatamente 3 x 3 pontos

Os métodos de autenticação acima são referidos como os métodos principais recomendados neste documento.

Se as implementações de dispositivo 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 a autenticação do usuário para o uso de chaves.

Se as implementações de dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio se forem baseados em um segredo conhecido e usarem um novo método de autenticação para ser tratado como uma maneira segura de bloquear a tela:

• [C-3-1] A entropia do comprimento mínimo 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 (por exemplo, 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 controlador da política do dispositivo (DPC) tiver definido a política de requisitos de senha usando o DevicePolicyManager.setRequiredPasswordComplexity() com uma constante de complexidade mais restritiva do que PASSWORD_COMPLEXITY_NONE ou pelo 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 retornar aos métodos principais recomendados (por exemplo, PIN, padrão, senha) uma vez 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 deles.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação primários recomendados para desbloquear a tela de bloqueio e usarem um novo método de autenticação com base em biometria para ser tratado como uma maneira segura de bloquear a tela, o novo método:

• [C-4-1] É PRECISO atender a todos os requisitos descritos na seção 7.3.10 para a Classe 1 (anteriormente conveniência).
• [C-4-2] É OBRIGATÓRIO ter um mecanismo de fallback para usar um dos métodos de autenticação primários recomendados, que é baseado em um secret conhecido.
• [C-4-3] PRECISA ser desativado e permitir apenas a autenticação primária recomendada para desbloquear a tela quando o aplicativo de controle de políticas de dispositivo (DPC) tiver definido a política de recurso de proteção de tela 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 (anteriormente 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íticas de dispositivo (DPC, na sigla em inglês) tiver definido a política de qualidade dos requisitos de senha usando 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 principal recomendada (por exemplo, PIN, padrão, 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 PODEM ser tratados como uma tela de bloqueio segura e DEVEM atender aos requisitos que começam com C-8 nesta seção abaixo.

Se as implementações do dispositivo 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 fallback para usar um dos métodos de autenticação principais 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 principal recomendados para desbloquear a tela quando o aplicativo de controle de políticas do 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 para um dos métodos de autenticação primários recomendados (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 4 horas ou menos. Quando um token físico atende aos requisitos de implementações do TrustAgent no 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 PODE ser tratado como uma tela de bloqueio segura e DEVE seguir as restrições listadas em C-8 abaixo.

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

• [C-7-1] É PRECISO ter uma indicação clara no menu de configurações e na tela de bloqueio quando o bloqueio do dispositivo for adiado ou puder ser desbloqueado por agentes de confiança. Por exemplo, o AOSP atende a esse requisito mostrando uma descrição de texto para as configurações "Bloquear automaticamente" e "O botão liga/desliga bloqueia instantaneamente" no menu de configurações e um ícone distinto na tela de bloqueio.
• [C-7-2] É NECESSÁRIO 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 IMPLEMENTE totalmente a função TrustAgentService.addEscrowToken() em um dispositivo usado como dispositivo pessoal principal (por exemplo, dispositivo portátil), mas IMPLEMENTE totalmente a função em implementações de dispositivo que são normalmente compartilhadas (por exemplo, Android TV ou dispositivo automotivo).
• [C-7-4] É OBRIGATÓRIO criptografar todos os tokens armazenados adicionados por TrustAgentService.addEscrowToken().
• [C-7-5] A chave de criptografia ou o token de depósito em garantia NÃO PODEM ser armazenados no mesmo dispositivo em que a chave é usada. Por exemplo, é permitido que uma chave armazenada em um smartphone desbloqueie uma conta de usuário em uma TV. Para 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 o 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] É OBRIGATÓRIO ter um mecanismo de fallback para usar um dos métodos de autenticação primários recomendados.
• [C-7-8] O usuário PRECISA ser desafiado para um dos métodos de autenticação primária recomendados (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 72 horas ou menos, a menos que a segurança do usuário (por exemplo, distração do motorista) seja uma preocupação.
• [C-7-9] O usuário PRECISA ser desafiado para um dos métodos de autenticação principal recomendados (por exemplo, PIN, padrão, 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 pode ser tratado como uma tela de bloqueio segura e DEVE seguir as restrições listadas em C-8 abaixo.
• [C-7-11] NENHUM TrustAgent em dispositivos pessoais principais (por exemplo, portáteis) pode desbloquear o dispositivo.Eles só podem ser usados para manter um dispositivo já desbloqueado nesse estado por até 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 com segurança criptográfica (por exemplo, UKEY2) para transmitir o token de depósito em garantia do dispositivo de armazenamento para o dispositivo de destino.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio que não é uma tela de bloqueio segura, conforme descrito acima, e usarem um novo método de autenticação para desbloquear o teclado bloqueador:

• [C-8-1] O novo método PRECISA ser desativado quando o aplicativo do controlador de políticas do dispositivo (DPC) tiver definido a política de qualidade da senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_NONE ou pelo DevicePolicyManager.setRequiredPasswordComplexity() com uma constante de complexidade mais restritiva do que 'PASSWORD_COMPLEXITY_NONE'.
• [C-8-2] Não é permitido redefinir os timers de expiração da senha definidos por DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Elas NÃO PODEM expor uma API para uso por apps de terceiros para mudar o estado de bloqueio.

Se as implementações de dispositivo permitirem que os aplicativos criem telas virtuais secundárias e não oferecerem suporte a eventos de entrada associados, como por meio de VirtualDeviceManager, eles:

• [C-9-1] É OBRIGATÓRIO bloquear essas telas virtuais secundárias quando a tela padrão do dispositivo estiver bloqueada e desbloqueá-las quando a tela padrão do dispositivo estiver desbloqueada.

Se as implementações de dispositivo 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] É PRECISO oferecer suporte a estados de bloqueio separados por dispositivo virtual
• [C-10-2] É OBRIGATÓRIO desconectar todos os dispositivos virtuais após o tempo limite de inatividade
• [C-10-3] É OBRIGATÓRIO ter um tempo limite de inatividade
• [C-10-4] É OBRIGATÓRIO bloquear todas as telas quando o usuário iniciar um bloqueio, incluindo através da capacidade de uso do bloqueio do usuário necessária para dispositivos portáteis (consulte a Seção 2.2.5[9.11/H-1-2]).
• [C-10-5] É OBRIGATÓRIO ter instâncias de dispositivos virtuais separadas por usuário
• [C-10-6] É OBRIGATÓRIO desativar a criação de eventos de entrada associados por VirtualDeviceManager quando indicado por DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] É OBRIGATÓRIO usar uma área de transferência separada apenas para cada dispositivo virtual (ou desativar a área de transferência para dispositivos virtuais)
• [C-10-11] É PRECISO desativar a interface de usuário de autenticação em dispositivos virtuais, incluindo a entrada de fator de conhecimento e a solicitação biométrica
• [C-10-12] É PRECISO restringir intents iniciadas de um dispositivo virtual para serem mostradas apenas no mesmo dispositivo virtual.
• [C-10-13] Não é permitido 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*.

Quando as implementações de dispositivo permitem que o usuário transfira o fator de conhecimento de autenticação principal de um dispositivo de origem para um 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 documento de políticas de segurança do serviço Google Cloud Key Vault ao transferir o fator de conhecimento do dispositivo de origem para o dispositivo de destino, de modo que o fator de conhecimento não possa ser descriptografado remotamente ou usado para desbloquear remotamente nenhum dos dispositivos.
• [C-11-2] É OBRIGATÓRIO, 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] Em um dispositivo de destino que não tem um fator de conhecimento de autenticação principal definido, é OBRIGATÓRIO pedir que o usuário confirme um fator de conhecimento transferido no dispositivo de destino antes de definir esse fator de conhecimento como o fator de conhecimento de autenticação principal para o dispositivo de destino e antes de disponibilizar os dados transferidos de um dispositivo de origem.

Se as implementações do dispositivo 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, eles:

• [C-12-1] SOMENTE 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 tiver autenticado a identidade nessa tela de bloqueio. Os dispositivos próximos podem usar mecanismos de detecção no pulso ou no corpo após um desbloqueio único do usuário para satisfazer o requisito de autenticação do usuário.
• [C-12-2] É PRECISO colocar a implementação do dispositivo no estado TrustState.TRUSTABLE quando a tela é desligada (por exemplo, por meio de um botão ou de um tempo limite de exibição) e o TrustAgent não tiver revogado a confiança. O AOSP atende a esse requisito.
• [C-12-3] SOMENTE mude o dispositivo de TrustState.TRUSTABLE para o estado TrustState.TRUSTED se o TrustAgent ainda estiver concedendo confiança com base nos requisitos em C-12-1.
• [C-12-4] É OBRIGATÓRIO chamar TrustManagerService.revokeTrust()
  • Após um máximo de 24 horas após a concessão de confiança, ou
  • Após uma janela de inatividade de 8 horas ou
  • Se as implementações não estiverem usando o alcance criptograficamente seguro e preciso, conforme definido em [C-12-5], quando a conexão subjacente ao dispositivo físico próximo for perdida.
• [C-12-5] As implementações que dependem de um alcance seguro e preciso para atender aos requisitos de [C-12-4] PRECISAM usar uma das seguintes soluções:
  • Implementações que usam UWB:
    • PRECISA atender aos requisitos de conformidade, certificação, precisão e calibração 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 Neighbor Awareness Networking (NAN):
    • É PRECISO atender aos requisitos de precisão 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 Calibração de presença.
    • É PRECISO usar o LTF seguro, conforme definido em IEEE 802.11az.

Se as implementações de dispositivo permitirem que os aplicativos criem telas virtuais secundárias e oferecerem suporte a eventos de entrada associados, como por meio do VirtualDeviceManager, e as telas não forem marcadas com VIRTUAL_DISPLAY_FLAG_SECURE, elas:

• [C-13-8] É PRECISO bloquear atividades com o atributo android:canDisplayOnRemoteDevices ou os metadados android.activity.can_display_on_remote_devices definidos como false para serem iniciados no dispositivo virtual.
• [C-13-9] É OBRIGATÓRIO impedir que atividades que não ativam explicitamente o streaming e que indicam que mostram conteúdo sensível, incluindo por SurfaceView#setSecure, FLAG_SECURE ou SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, sejam iniciada no dispositivo virtual.

Se as implementações de dispositivos oferecerem suporte a estados de energia de exibição separados por DeviceStateManager E oferecerem suporte a estados de bloqueio de exibição separados por KeyguardDisplayManager, eles:

• [C-SR-2] É ALTAMENTE RECOMENDADO usar uma credencial que atenda aos requisitos definidos na seção 9.11.1 ou uma métrica biométrica 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 de telas separadas por um tempo limite de exibição definido.
• [C-SR-4] É ALTAMENTE RECOMENDADO permitir que o usuário bloqueie globalmente todas as telas com o bloqueio do dispositivo portátil principal.

9.11.2. StrongBox

O sistema de armazenamento de chaves do Android permite que os desenvolvedores de apps armazenem chaves criptográficas em um processador seguro dedicado, bem como o 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 ser qualificado como StrongBox.

Implementações de dispositivos que têm um processador seguro dedicado:

• [C-SR-1] É ALTAMENTE RECOMENDADO oferecer suporte ao StrongBox. O StrongBox provavelmente vai se tornar um requisito em uma versão futura.

Se as implementações do dispositivo oferecem suporte ao StrongBox, elas:

• [C-1-1] É OBRIGATÓRIO declarar FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] É NECESSÁRIO 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] É PRECISO ter uma CPU discreta que não compartilhe cache, DRAM, coprocessadores ou outros recursos principais com o processador do aplicativo (AP).

• [C-1-4] É OBRIGATÓRIO garantir que os periféricos compartilhados com o AP não possam alterar o processamento do StrongBox de nenhuma forma ou extrair informações dele. O AP PODE desativar ou bloquear o acesso ao StrongBox.

• [C-1-5] É PRECISO ter um relógio interno com precisão razoável (+-10%) que seja imune à manipulação pelo AP.

• [C-1-6] É PRECISO ter um gerador de números aleatórios real que produza uma saída distribuída uniformemente e imprevisível.

• [C-1-7] É PRECISO ter resistência a adulteração, incluindo resistência a penetração física e falhas.

• [C-1-8] É PRECISO ter resistência a canais laterais, incluindo resistência a vazamento de informações por meio de energia, temporização, radiação eletromagnética e canais laterais de radiação térmica.

• [C-1-9] É PRECISO ter armazenamento seguro que garanta a confidencialidade, integridade, autenticidade, consistência e atualidade 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 do dispositivo:

  • [C-1-10] É PRECISO incluir o hardware certificado de acordo com o perfil de proteção de IC seguro BSI-CC-PP-0084-2014 ou avaliado por um laboratório de testes credenciado nacionalmente que incorpore a avaliação de vulnerabilidade de alto potencial de ataque de acordo com o Common Criteria Application of Attack Potential to Smartcards.
  • [C-1-11] É OBRIGATÓRIO incluir o firmware que é avaliado por um laboratório de testes credenciado nacionalmente que incorpora a avaliação de vulnerabilidade de alto potencial de ataque de acordo com a Aplicação de critérios comuns de potencial de ataque a smartcards.
  • [C-SR-2] É ALTAMENTE RECOMENDÁVEL incluir o hardware que é avaliado usando um alvo de segurança, 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 interna com acesso a chaves de assinatura de firmware não pode produzir firmware que cause vazamento de segredos do StrongBox, para contornar requisitos de segurança funcional ou permitir 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 pelo HAL IAuthSecret.

9.11.3. Credencial de identidade

O sistema de credencial de identidade é definido e alcançado pela implementação de todas as APIs no pacote android.security.identity.*. Essas APIs permitem que os desenvolvedores de apps armazenem e extraiam documentos de identidade do usuário. Implementações de dispositivos:

• [C-SR-1] são FORTEMENTE RECOMENDADAS 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] É PRECISO implementar o sistema de credencial de identidade (por exemplo, as APIs android.security.identity.*) com código que se comunique com um aplicativo confiável em uma área isolada com segurança do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais em que o kernel ou o código do espaço do usuário pode acessar o estado interno do ambiente isolado, incluindo o DMA.

• [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 não sejam afetadas (por exemplo, os dados de credenciais não são liberados 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 incorreto ou comprometido.

O projeto upstream do Android Open Source oferece 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] É PRECISO fornecer aos usuários um mecanismo para realizar uma "Redefinição de dados de fábrica".
• [C-0-2] É OBRIGATÓRIO excluir todos os dados do sistema de arquivos userdata ao realizar uma "Redefinição de dados de fábrica".
• [C-0-3] É OBRIGATÓRIO excluir os dados de maneira que atenda aos padrões relevantes do setor, como o NIST SP800-88, ao realizar uma "Restauração de dados de fábrica".
• [C-0-4] É PRECISO acionar o processo "Redefinição de dados de fábrica" acima quando a API DevicePolicyManager.wipeData() for chamada pelo app Device Policy do usuário principal.
• PODE fornecer uma opção de eliminação 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 que os usuários inicializem em um modo em que apenas os 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] PRECISA oferecer ao usuário a opção de entrar no modo de inicialização segura de uma maneira ininterruptível de apps de terceiros instalados no dispositivo, exceto quando o app de terceiros é um Device Policy Controller e definiu a flag UserManager.DISALLOW_SAFE_BOOT como verdadeira.

• [C-1-2] É OBRIGATÓRIO oferecer ao usuário a capacidade de desinstalar apps de terceiros no modo de segurança.

• DEVEM fornecer ao usuário a opção de entrar no modo de inicialização segura no menu de inicialização usando um fluxo de trabalho diferente do 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 o HAL do veículo 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 do framework 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 pelo SubscriptionManager.setSubscriptionPlans().

Todas as implementações de dispositivos:

• [C-0-1] PRECISA retornar planos de assinatura apenas para o app da operadora móvel que os forneceu originalmente.
• [C-0-2] NÃO É PERMITIDO fazer backup ou fazer upload de planos de assinatura remotamente.
• [C-0-3] SOMENTE é permitido 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 dispositivo incluírem um recurso para migrar dados de um dispositivo para outro e não limitarem os dados do aplicativo que são copiados para o que é configurado pelo desenvolvedor do aplicativo no manifesto pelo 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 primária, conforme descrito em 9.11.1 Tela de bloqueio segura e autenticação.
• [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 de transferir quaisquer dados.
• [C-1-3] É PRECISO usar a confirmação 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] SOMENTE 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] É OBRIGATÓRIO mostrar uma indicação de que o dispositivo de origem teve dados migrados por uma migração de dados de dispositivo para dispositivo no menu de configurações. Um usuário NÃO PODE remover essa indicação.

9.17. Framework de virtualização do Android

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), o host do Android:

• [C-1-1] PRECISA oferecer suporte a todas as APIs definidas pelo pacote android.system.virtualmachine.*.
• [C-1-2] NÃO é permitido modificar o SELinux do Android e o modelo de permissão para o gerenciamento de máquinas virtuais protegidas.
• [C-1-3] NÃO é permitido modificar, omitir ou substituir as regras de neverallow presentes no system/sepolicy fornecido no upstream do Android Open Source Project (AOSP), e a política PRECISA ser compilada com todas as regras de neverallow presentes.
• [C-1-4] NÃO É PERMITIDO que códigos não confiáveis (por exemplo, apps de terceiros) criem e executem uma máquina virtual protegida. Observação: isso pode mudar em versões futuras do Android.
• [C-1-5] NÃO é permitido que uma máquina virtual protegida execute código que não faça parte da imagem de fábrica ou das atualizações dela. Qualquer coisa que não seja coberta pela Inicialização verificada do Android (por exemplo, arquivos transferidos por sideload ou baixados da Internet) NÃO PODE ser executada em uma máquina virtual protegida.

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), qualquer instância de máquina virtual protegida:

• [C-2-1] É PRECISO executar todos os sistemas operacionais disponíveis no APEX de virtualização em uma máquina virtual protegida.
• [C-2-2] NÃO é permitido que uma máquina virtual protegida execute um sistema operacional que não seja assinado pelo implementador do dispositivo ou pelo fornecedor do SO.
• [C-2-3] NÃO é permitido que uma máquina virtual protegida execute dados como código (por exemplo, SELinux neverallow execmem).
• [C-2-4] NÃO É PERMITIDO modificar, omitir ou substituir as regras de neverallow presentes no system/sepolicy/microdroid fornecido no upstream do Android Open Source Project (AOSP).
• [C-2-5] É PRECISO implementar mecanismos de defesa em profundidade de máquinas virtuais protegidas (por exemplo, SELinux para pVMs), mesmo para sistemas operacionais que não sejam o Microdroid.
• [C-2-6] É PRECISO garantir que o firmware da pVM se recuse a inicializar se não for possível verificar a imagem inicial.
• [C-2-7] É OBRIGATÓRIO garantir que o firmware da pVM se recuse a inicializar se a integridade do instance.img for comprometida.

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), o hipervisor:

• [C-3-1] NÃO É PERMITIDO que nenhuma pVM tenha acesso a uma página pertencente a outra entidade (ou seja, outra pVM ou hipervisor), a menos que seja explicitamente compartilhada pelo proprietário da página. Isso inclui a VM do host. Isso se aplica aos acessos de CPU e DMA.
• [C-3-2] É PRECISO limpar uma página depois que ela é usada por uma VM e antes de ser devolvida ao host (por exemplo, a pVM é destruída).
• [C-3-3] É PRECISO garantir que o firmware da pVM seja carregado e executado antes de qualquer código em uma pVM.
• [C-3-4] É PRECISO garantir que as BCCs e as CDIs fornecidas a uma instância de pVM só possam ser derivadas por essa instância específica.

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android, em todas as áreas:

• [C-4-1] NÃO é permitido fornecer funcionalidade a uma pVM que permita contornar o modelo de segurança do Android.

Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, faça o seguinte:

• [C-5-1] É PRECISO oferecer suporte à compilação isolada de uma atualização do ambiente de execução do ART.

Se o dispositivo implementar suporte às APIs do Framework de virtualização do Android e ao gerenciamento de chaves:

• [C-6-1] É PRECISO enraizar a cadeia do DICE em um ponto que o usuário não possa modificar, mesmo em dispositivos desbloqueados. (Para garantir que não possa ser falsificado).
• [C-6-2] É OBRIGATÓRIO fazer o teste de diagnóstico de desempenho de e-commerce (DICE) corretamente, ou seja, fornecer os valores corretos.

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 esse motivo, É ALTAMENTE RECOMENDADO que os implementadores de dispositivos façam o menor número possível de mudanças na implementação de referência e preferencial do Android disponível no Android Open Source Project. Isso vai minimizar o risco de introduzir bugs que criam incompatibilidades que exigem retrabalho e possíveis atualizações do dispositivo.

10.1. Conjunto de teste de compatibilidade

Implementações de dispositivos:

• [C-0-1] É PRECISO passar no Conjunto de teste de compatibilidade do Android (CTS, na sigla em inglês) disponível no Projeto Android Open Source, usando o software de envio final no dispositivo.

• [C-0-2] É PRECISO 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. A versão do CTS será independente dessa definição de compatibilidade, e várias revisões do CTS poderão ser lançadas para o Android 13.

Implementações de dispositivos:

• [C-0-3] É PRECISO passar na versão mais recente do CTS disponível no momento em que o software do dispositivo é concluído.

• PRECISA usar a implementação de referência na árvore do Android Open Source o máximo possível.

10.2. Verificador do CTS

O Verificador do CTS está incluído no Compatibility Test Suite e é destinado a 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] É PRECISO executar corretamente todos os casos aplicáveis no verificador do CTS.

O Verificador do CTS tem testes para muitos tipos de hardware, incluindo alguns opcionais.

Implementações de dispositivos:

• [C-0-2] É PRECISO passar em todos os testes de hardware que eles têm. Por exemplo, se um dispositivo tiver um acelerômetro, ele PRECISA executar corretamente o caso de teste do acelerômetro no Verificador CTS.

Casos de teste para recursos indicados como opcionais por este documento de definição de compatibilidade podem ser pulados ou omitidos.

• [C-0-2] Todos os dispositivos e builds precisam executar corretamente o verificador CTS, conforme observado acima. No entanto, como muitos builds são muito semelhantes, não é esperado que os implementadores do dispositivo executem explicitamente o Verificador do CTS em builds que diferem apenas de maneiras triviais. Especificamente, implementações de dispositivos que diferem de uma implementação que passou no Verificador do CTS apenas pelo conjunto de localidades, 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, pode ser necessário reiniciar o dispositivo. Qualquer método pode ser usado, desde que ele possa substituir todo o software pré-instalado no dispositivo. Por exemplo, qualquer uma das seguintes abordagens vai atender a esse requisito:

  • Faça o download "over-the-air (OTA)" com a atualização off-line por reinicialização.
  • Atualizações "conectadas" por USB de um PC host.
  • Atualizações "off-line" com uma reinicialização e atualização de um arquivo no armazenamento removível.

• [C-0-2] O mecanismo de atualização usado PRECISA oferecer suporte a atualizações sem apagar os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados privados e compartilhados do aplicativo. O software upstream do Android inclui um mecanismo de atualização que atende a esse requisito.

• [C-0-3] A atualização inteira 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] O mecanismo de assinatura é ALTAMENTE RECOMENDADO para gerar hash da atualização com SHA-256 e validar o hash em relação à chave pública usando ECDSA NIST P-256.

Se as implementações do dispositivo incluírem suporte a uma conexão de dados não medida, como o perfil 802.11 ou Bluetooth PAN (rede de área pessoal), elas:

• [C-1-1] É PRECISO oferecer suporte a downloads OTA com atualização off-line por reinicialização.

As implementações de dispositivos precisam verificar se a imagem do sistema é binariamente idêntica ao resultado esperado após uma OTA. A implementação 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 precisam oferecer suporte a atualizações A/B do sistema. O AOSP implementa esse recurso usando o HAL de controle de inicialização.

Se um erro for encontrado em uma implementação de dispositivo após o lançamento, mas dentro de um período razoável de vida útil do produto determinado em consulta com a equipe de compatibilidade do Android para afetar a compatibilidade de apps de terceiros, faça o seguinte:

• [C-2-1] O implementador do dispositivo PRECISA corrigir o erro com uma atualização de software disponível que possa ser aplicada de acordo com o mecanismo descrito.

O Android inclui recursos que permitem que o app proprietário do dispositivo (se presente) controle 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] PRECISA implementar o comportamento descrito na classe SystemUpdatePolicy.

12. Registro de alterações do documento

Confira abaixo um resumo das mudanças na definição de compatibilidade desta versão:

4 de outubro de 2023

2. Tipos de dispositivo

• 2.2.5. Modelo de segurança:

  Conferir revisão

  • [9.8/H-1-14] É PRECISO mostrar o indicador de microfone, conforme descrito na seção 9.8.2 [9.8/C-3-1], quando um resultado de palavra de ativação é transmitido para a voz.

• 2.2.7.1 Mídia:

  Conferir revisão

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

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

  • [5.1/H-1-13] É OBRIGATÓRIO ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de decodificação de áudio de 128 kbps ou menos para todos os decodificadores de áudio durante o carregamento. O carregamento aqui é definido como uma sessão de transcodificação de vídeo concorrente de 1080p para 720p usando codecs de vídeo de hardware com a inicialização de reprodução de áudio-vídeo de 1080p.

7.4. Conectividade de dados

• 7.4.1.1. Compatibilidade com o bloqueio de números:

  Conferir revisão

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

• 7.4.1.2. API de operadora de telefonia:

  Conferir revisão

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

9.11. Chaves e credenciais

• 9.11.2. StrongBox:

  Conferir revisão

  é fornecido pelo HAL IAuthSecret.

  O IAR removido vai se tornar um requisito obrigatório no Android 14.

26 de junho de 2023

2. Tipos de dispositivo

• 2.2.1. Hardware

  • Os requisitos 7.2.3/H-0-5, 7.2.3/H-0-6 e 7.2.3/H-0-7 foram removidos.

  • Outra atualização:

    Conferir revisão

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

• 2.5.1. Hardware

  Conferir revisão

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

  • [7.6.1/A-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 512 MB se qualquer uma das densidades a seguir for usada:

    • 280 dpi ou menos em telas pequenas/normais
    • ldpi ou menor em telas extragrandes
    • mdpi ou menor em telas grandes

  • [7.6.1/A-1-2] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 608 MB se qualquer uma das densidades a seguir for usada:

    • xhdpi ou superior em telas pequenas/normais
    • hdpi ou superior em telas grandes
    • mdpi ou superior em telas extragrandes

  • [7.6.1/A-1-3] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se qualquer uma das densidades a seguir for usada:

    • 400 dpi ou mais em telas pequenas/normais
    • xhdpi ou superior em telas grandes
    • tvdpi ou superior em telas extragrandes

  • [7.6.1/A-1-4] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1344 MB se qualquer uma das densidades a seguir for usada:

    • 560 dpi ou mais em telas pequenas/normais
    • 400 dpi ou mais em telas grandes
    • xhdpi ou superior em telas extragrandes

3. Software

• 3.2.3.5. Intenções de aplicativo condicionais

  Conferir revisão

  Se as implementações do dispositivo informarem android.hardware.telephony.calling android.hardware.telephony, elas:

7. Compatibilidade de hardware

• 7.4. Conectividade de dados

  Conferir revisão

  Requisitos para a calibragem de presença.

9. Compatibilidade com o modelo de segurança

• 9.1 Permissões

  Conferir revisão

  Implementações de dispositivos:

  • [C-0-5] NÃO É PERMITIDO conceder permissões de execução a apps pré-instalados, 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 ele a permissão.

    OU

    • As permissões de execução são concedidas pela política padrão de concessão de permissões ou para manter um papel da plataforma. Associado a um padrão de intent em que o aplicativo pré-instalado é definido como o gerenciador padrão.

• 9.11. Chaves e credenciais

  • Os requisitos [C-13-10] e 9.11.4 foram removidos.

20 de março de 2023

2. Tipos de dispositivo

• 2.2.3. Software

  Conferir revisão

  Se a implementação de configurações do dispositivo portátil implementar uma funcionalidade dividida usando a incorporação de atividades, ela:

  • [C-17-13.2.3.1/ H-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.

  Finalizar novos requisitos

• 2.3.2. Multimídia

  Conferir revisão

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

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

• 2.5.1. Hardware

  Conferir revisão

  Implementações de dispositivos automotivos:

  • [7.3/A-0-1SR1] PODE estimar a localização por dead reckoning, mesclando GPS/GNSS com outros sensores. Se o local for calculado, é ALTAMENTE RECOMENDADO implementar e informar os tipos de sensor correspondentes e/ou os IDs de propriedade do veículo usados.

  • [7.3/A-0-20-4] A Localização solicitada por LocationManager#requestLocationUpdates() NÃO PODE ser correspondida ao mapa.

3. Software

• 3.18. Contatos

  Conferir revisão

  Conta padrão para novos contatos:o Provedor de contatos oferece APIs para gerenciar a configuração da conta padrão ao criar um novo contato.

  Se as implementações do dispositivo pré-carregarem um app de contatos, o app de contatos pré-carregado:

  • [C-2-1] PRECISA processar a intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT para iniciar uma interface de seleção de conta e salvar a configuração no provedor de contatos quando uma conta é selecionada.

  • [C-2-2] É OBRIGATÓRIO respeitar a configuração de conta padrão ao processar Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT para ContactsContracts.Contacts.CONTENT_TYPE e ContactsContract.RawContacts.CONTENT_TYPE selecionando inicialmente a conta.

  Finalizar novos requisitos

• 3.2.3.5. Intenções de aplicativo condicionais

  Conferir revisão

  [Moved to 2.2.3]

  Se a implementação do app Configurações do dispositivo implementar uma funcionalidade dividida, usando a incorporação de atividades, então:

  • [C-17-1] É PRECISO 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 em Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

  Finalizar novos requisitos

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

• 6.1. Ferramentas para desenvolvedores

  Conferir revisão

  • Monkey
    • [C-0-8] É PRECISO incluir o framework Monkey e disponibilizá-lo para uso em aplicativos.

7. Compatibilidade de hardware

• 7.3.13. IEEE 802.1.15.4 (UWB)

  Conferir revisão

  [Moved to 7.4.9]

  Se as implementações do dispositivo incluírem suporte ao 802.1.15.4 e exporem a funcionalidade a um aplicativo de terceiros, elas:

  • [C-1-1] É OBRIGATÓRIO implementar a API Android correspondente no android.uwb.
  • [C-1-2] É PRECISO informar a flag de recurso de hardware android.hardware.uwb.
  • [C-1-3] PRECISA oferecer suporte a todos os perfis UWB relevantes definidos na implementação do Android.
  • [C-1-4] É PRECISO fornecer uma característica para o usuário ativar/desativar o rádio UWB.
  • [C-1-5] É PRECISO aplicar que os apps que usam rádio UWB tenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICES).
  • [C-1-6] É ALTAMENTE RECOMENDADO passar nos testes de conformidade e certificação relevantes definidos por organizações de padronização, incluindo FIRA, CCC e CSA.

  Finalizar novos requisitos

• 7.4.1. Telefonia

  Conferir revisão

  Se as implementações do dispositivo incluem telefonia GSM ou CDMAinformam o recurso android.hardware.telephony, então:

  • [C-6-1] O SmsManager#sendTextMessage e o SmsManager#sendMultipartTextMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer a funcionalidade de mensagens de texto. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer a funcionalidade de mensagens multimídia.
  • [C-6-2] O aplicativo designado por android.provider.Telephony.Sms#getDefaultSmsPackage PRECISA usar as APIs SmsManager ao enviar e receber mensagens SMS e MMS. A implementação de referência do AOSP em packages/apps/Messaging atende a esse requisito.
  • [C-6-3] O aplicativo que responde a Intent#ACTION_DIAL PRECISA oferecer suporte à entrada de códigos de discagem arbitrários formatados como *#*#CODE#*#* e acionar uma transmissão TelephonyManager#ACTION_SECRET_CODE correspondente.
  • [C-6-4] O aplicativo que responde a Intent#ACTION_DIAL PRECISA usar VoicemailContract.Voicemails#TRANSCRIPTION para mostrar a transcrição visual do correio de voz aos usuários, se ele oferece suporte a transcrições visuais do correio de voz.
  • [C-6-5] PRECISA representar todos os SubscriptionInfo com UUIDs de grupo equivalentes como uma única assinatura em todos os affordances visíveis para o usuário que mostram e controlam as informações do chip SIM. Exemplos de affordances incluem interfaces de configurações que correspondem a Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
  • [C-6-6] NÃO PRECISA mostrar ou permitir o controle de nenhuma SubscriptionInfo com um UUID de grupo não nulo e um bit oportunista em nenhuma característica visível para o usuário que permite a configuração ou o controle das configurações do cartão SIM.

  Se as implementações do dispositivo incluem telefonia GSM ou CDMAinformam o recurso android.hardware.telephony e fornecem uma barra de status do sistema, faça o seguinte:

  • [C-6-7-1] É PRECISO selecionar uma assinatura ativa representativa para um determinado UUID de grupo para mostrar ao usuário em qualquer recurso que forneça informações de status do SIM. Exemplos de affordances incluem o ícone de sinal de celular da barra de status ou o bloco de Configurações rápidas.
  • [C-SR-1] É ALTAMENTE RECOMENDADO que a assinatura representativa seja escolhida para ser a assinatura de dados ativa, a menos que o dispositivo esteja em uma chamada de voz, durante a qual é ALTAMENTE RECOMENDADO que a assinatura representativa seja a assinatura de voz ativa.

  Se as implementações do dispositivo incluírem telefonia GSM ou CDMAinformarem o recurso android.hardware.telephony, então:

  • [C-6-87] 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 o ETSI TS 102 221.
  • [C-6-108] NÃO É PERMITIDO aplicar nenhum dos seguintes comportamentos a apps de operadora ativos (designados por TelephonyManager#getCarrierServicePackageName) automaticamente ou sem a confirmação explícita do usuário:
    • Revogar ou limitar o acesso à rede
    • Revogar permissões
    • Restringir a execução de apps em segundo plano ou em primeiro plano além dos recursos de gerenciamento de energia incluídos no AOSP
    • Desativar ou desinstalar o app

  Se as implementações de dispositivo incluírem telefonia GSM ou CDMAinformarem o recurso android.hardware.telephony e todas as assinaturas não oportunísticas ativas que compartilham um UUID de grupo forem desativadas, removidas fisicamente do dispositivo ou marcadas como oportunísticas, o dispositivo:

  • [C-78-1] É PRECISO desativar automaticamente todas as assinaturas oportunistas ativas restantes no mesmo grupo.

  Se as implementações de dispositivos incluem telefonia GSM, mas não telefonia CDMA, elas:

  • [C-89-1] NÃO PRECISA declarar PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-89-2] É PRECISO gerar uma IllegalArgumentException ao tentar definir qualquer tipo de rede 3GPP2 em máscaras de bits de tipo de rede preferido ou permitido.
  • [C-89-3] PRECISA retornar uma string vazia de TelephonyManager#getMeid.

  Se as implementações do dispositivo oferecerem suporte a eUICCs com várias portas e perfis, elas:

  • [C-1110-1] É PRECISO declarar a flag de recurso android.hardware.telephony.euicc.mep.

• 7.4.9. UWB

  Conferir revisão

  Se as implementações de dispositivos informarem suporte ao recurso android.hardware.uwb pela classe android.content.pm.PackageManager, se as implementações de dispositivos incluírem suporte ao 802.1.15.4 e exporem a funcionalidade a um aplicativo de terceiros, elas:

  • [C-1-1] É OBRIGATÓRIO implementar a API Android correspondente no android.uwb.
  • [C-1-2] É PRECISO informar a flag de recurso de hardware android.hardware.uwb.
  • [C-1-3] PRECISA oferecer suporte a todos os perfis UWB relevantes definidos na implementação do Android.
  • [C-1-4] É PRECISO fornecer uma característica para o usuário ativar/desativar o rádio UWB.
  • [C-1-5] É PRECISO aplicar que os apps que usam rádio UWB tenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICES).
  • [C-SR-1] É ALTAMENTE RECOMENDADO passar nos testes de conformidade e certificação relevantes definidos por organizações de padrão, incluindo FIRA, CCC e CSA.
  • [C-1-16] É NECESSÁRIO 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-27] É PRECISO garantir que a mediana das medições de distância a 1 m do dispositivo de referência esteja entre [0,75 m, 1,25 m], em que a distância real é medida a partir da borda superior do DUT, segurada com a face para cima e inclinada 45 graus.
  • [C-SR-2] É ALTAMENTE RECOMENDADO seguir as etapas de configuração de medição especificadas em Requisitos de calibração de presença.

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

  Finalizar novos requisitos

• 7.8.2.2. Portas de áudio digital

  Conferir revisão

  Para ser compatível com fones de ouvido e outros acessórios de áudio que usam conectores USB-C e implementam (classe de áudio USB) em todo o ecossistema Android, conforme definido na especificação de fones de ouvido USB do Android.

19 de outubro de 2022

2. Tipos de dispositivo

• 2.2.3 Software

  Conferir revisão

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

  • [3.8.17/H-1-1] É PRECISO apresentar 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.

3. Software

• 3.2.3.5. Intenções de aplicativo condicionais

  Conferir revisão

  Se a implementação do dispositivo implementar uma funcionalidade dividida, usando a incorporação de atividades, ele:

  • [C-17-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 em Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

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

  • [C-18-1] PRECISA honrar 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 assistente.

• 3.4.1 Compatibilidade com o Webview

  Conferir revisão

  • [C-1-4]PRECISA renderizar o conteúdo fornecido ou o URL remoto em um processo distinto do aplicativo que instancia a WebView. Especificamente, o processo de renderizador separado PRECISA ter privilégios mais baixos, ser executado como um ID de usuário separado, não ter acesso ao diretório de dados do app, não ter acesso direto à rede e ter acesso apenas aos serviços de sistema mínimos necessários pelo Binder. A implementação do AOSP da WebView atende a esse requisito.

7. Compatibilidade de hardware

• 7.4.2 IEEE 802.11 (Wi-Fi)

  Conferir revisã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:

  • [C-3-1] É OBRIGATÓRIO RECOMENDA-SE desligar o modo de economia de energia do Wi-Fi sempre que um app adquire o bloqueio WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY por meio de WifiManager.createWifiLock() e WifiManager.WifiLock.acquire().

• 7.4.3 Bluetooth

  Conferir revisão

  Se as implementações de dispositivos incluem suporte para Bluetooth de baixa energia (BLE), elas:

  • [C-3-5] É PRECISO implementar um tempo limite de endereço privado solucionável (RPA) de no máximo 15 minutos e girar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo estiver usando ativamente o BLE para digitalização ou publicidade. Para evitar ataques de tempo, os intervalos de tempo limite também precisam ser aleatórios entre 5 e 15 minutos.

• 7.5.5 Orientação da câmera

  Conferir revisão

  Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, elas:

  • [C-1-1] PRECISA estar orientado de forma que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é segurado na orientação paisagem, as câmeras precisam capturar imagens nessa orientação. Isso se aplica independentemente da orientação natural do dispositivo, ou seja, se aplica a dispositivos com orientação principal de paisagem e retrato.

  Os dispositivos que atendem a todos os critérios abaixo estão isentos do requisito acima:

  • O dispositivo implementa telas de geometria variável, como telas dobráveis ou articuladas.
  • Quando o estado de dobra ou articulação do dispositivo muda, ele alterna entre orientações retrato-principal e paisagem-principal (ou vice-versa).

  Finalizar novos requisitos

9. Compatibilidade com o modelo de segurança

• 9.11 Chaves e credenciais

  Conferir revisão

  Quando a implementação do dispositivo oferece suporte a uma tela de bloqueio segura, ela:

  • [C-1-6] É PRECISO ter suporte a IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice versão 1 ou IKeyMintDevice versão 2.

• 9.17 Framework de virtualização do Android

  Conferir revisão

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), o host do Android:

  • [C-1-3] NÃO é permitido modificar, omitir ou substituir as regras de neverallow presentes no system/sepolicy fornecido no upstream do Android Open Source Project (AOSP), e a política PRECISA ser compilada com todas as regras de neverallow presentes.

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), qualquer instância de máquina virtual protegida:

  • [C-2-4] NÃO É PERMITIDO modificar, omitir ou substituir as regras neverallow presentes no system/sepolicy/microdroid fornecido no upstream do Android Open Source Project (AOSP).

  Se o dispositivo implementar suporte às APIs do Framework de virtualização do Android e ao gerenciamento de chaves:

  • [C-6-2] É OBRIGATÓRIO fazer o teste de diagnóstico de desempenho de e-commerce (DICE) corretamente, ou seja, fornecer os valores corretos. Mas talvez não seja necessário chegar a esse nível de detalhe.

15 de agosto de 2022

2. Tipos de dispositivo

• 2.2.1 Hardware: mudanças nos requisitos de hardware, conforme segue.

  • Dispositivos de entrada:

    Conferir revisão

    Implementações de dispositivos portáteis:

    • [7.2.3/H-0-5] É PRECISO chamar OnBackInvokedCallback.onBackStarted() na janela focada atual quando o gesto de volta for iniciado ou o botão Voltar (KEYCODE_BACK) for pressionado.
    • [7.2.3/H-0-6] É PRECISO chamar OnBackInvokedCallback.onBackInvoked() quando o gesto de volta é confirmado ou o botão "Voltar" é liberado (UP).
    • [7.2.3/H-0-7] É PRECISO chamar OnBackInvokedCallback.onBackCancelled() quando o gesto de voltar não for confirmado ou o evento KEYCODE_BACK for cancelado.

    Finalizar novos requisitos

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

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

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

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

    Finalizar novos requisitos

  • Latência de áudio:

    Conferir revisão

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

    • [5.6/H-1-1] É PRECISO ter uma latência média contínua de ida e volta de 500 800 milissegundos ou menos em 5 medições, com uma Média de desvio absoluto menor que 50 100 ms, sobre os seguintes caminhos de dados: "alto-falante para microfone", adaptador de loopback de 3,5 mm (se houver suporte), loopback USB (se houver suporte). pelo menos um caminho com suporte.

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

    Finalizar novos requisitos

  • Entradas táteis:

    Conferir revisão

    Se as implementações de dispositivos portáteis incluírem pelo menos um atuador háptico, elas:

    • [7.10/H]* NÃO use um atuador háptico (vibrador) de massa excêntrica rotativa (ERM, na sigla em inglês).
    • [7.10/H]* DEVE posicionar o atuador perto do local em que o dispositivo normalmente é segurado ou tocado pelas mãos.
    • [7.10/H]* DEVE implementar todas as constantes públicas para haptics claros 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.
    • [7.10/H]* DEVE implementar todas as constantes públicas para haptics claras em android.os.VibrationEffect, ou seja, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e todas as constantes públicas viáveis PRIMITIVE_* para haptics avançados em android.os.VibrationEffect.Composition, ou seja, (PRIMITIVE_CLICK e PRIMITIVE_TICK) (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Algumas dessas primitivas, como LOW_TICK e SPIN, só podem ser viáveis se o vibrador puder oferecer suporte a frequências relativamente baixas.

    • [7.10/H]* DEVE seguir as orientações para mapeamento de constantes públicas em android.view.HapticFeedbackConstants para as constantes recomendadas de android.os.VibrationEffect, com as relações de amplitude correspondentes.

    Finalizar novos requisitos

    • [7.10/H]* DEVE usar estes mapeamentos de constantes de retorno tátil vinculados.

    • [7.10/H]* DEVE verificar se o resultado da API pública android.os.Vibrator.hasAmplitudeControl() reflete corretamente os recursos do vibrador.

    Finalizar novos requisitos

    • [7.10/H]* É necessário verificar os recursos de escalonamento de amplitude executando android.os.Vibrator.hasAmplitudeControl().

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

    • [7.10/H]* PRECISA mover o atuador háptico no eixo X (esquerda-direita) da orientação retrato.

    • [7.10/H]* É NECESSÁRIO verificar e atualizar, se necessário, a configuração padrão para primitivas sem suporte, conforme descrito nas orientações de implementação para constantes.

    • [7.10/H]* DEVE oferecer suporte de fallback para reduzir o risco de falha, conforme descrito aqui.

• 2.2.3 Software:

  • Controles de dispositivo simples de autenticação:

    Conferir revisão

    • [3.8.16/H-1-5] É obrigatório fornecer ao usuário uma affordance para desativar os controles de dispositivo simples de autenticação designados pelo app dos controles registrados pelos aplicativos de terceiros usando ControlsProviderService e a API Control Control.isAuthRequired.

  • Notificações do MediaStyle:

    Conferir revisão

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

    • [3.8.3.1/H-1-SR] É ALTAMENTE RECOMENDÁVEL fornecer uma característica do usuário(por exemplo, "comutador de saída") acessada pela interface do sistema, que permite que os usuários mudem entre as rotas de mídia disponíveis(por exemplo, dispositivos e rotas Bluetooth fornecidos ao MediaRouter2Manager) quando um app publica uma notificação de MediaStyle com um token de MediaSession.

• 2.2.4 Desempenho e energia: novo requisito para apps que executam serviços em primeiro plano.

  Conferir revisão

  Implementações de dispositivos portáteis:

  • [8.5/H-0-1] É OBRIGATÓRIO fornecer uma capacidade de uso do usuário no menu "Configurações" com a capacidade de interromper um app que está executando um serviço em primeiro plano e mostrar todos os apps que têm serviços em primeiro plano ativos e a duração de cada um desses serviços desde que ele foi iniciado, conforme descrito no documento do SDK.
    • Alguns apps podem ser dispensados da interrupção ou da listagem em uma affordance do usuário, conforme descrito no documento do SDK.

  Finalizar novos requisitos

• 2.2.7.1 Mídia: atualizações na seção "Requisitos de mídia para dispositivos portáteis", conforme segue:

  Conferir revisão

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

  • [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 codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-2] É PRECISO oferecer suporte a 6 instâncias de sessões de decodificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 1080p a 30 fps.
  • [5.1/H-1-3] É OBRIGATÓRIO anunciar o número máximo de sessões de codificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-4] É PRECISO oferecer suporte a 6 instâncias de sessões de codificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 1080p a 30 fps.
  • [5.1/H-1-5] É OBRIGATÓRIO anunciar o número máximo de sessões de codificador e decodificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-6] É PRECISO oferecer suporte a 6 instâncias de decodificador de vídeo de hardware e sessões de codificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente na resolução 1080p a 30 fps.
  • [5.1/H-1-7] É PRECISO ter uma latência de inicialização de codec de 40 ms ou menos para uma sessão de codificação de vídeo de 1080p ou menor para todos os codificadores de vídeo de hardware quando sob carga. O carregamento aqui é definido como uma sessão de transcodificação de vídeo simultânea de 1080p para 720p usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo de 1080p.
  • [5.1/H-1-8] É PRECISO ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de codificação de áudio de 128 kbps ou menos para todos os codificadores de áudio durante a carga. O carregamento aqui é definido como uma sessão de transcodificação de vídeo de 1080p para 720p simultânea usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo de 1080p.
  • [5.1/H-1-9] É PRECISO oferecer suporte a duas instâncias de sessões de decodificador de vídeo de hardware seguras (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 1080p a 30 fps.
  • [5.1/H-1-10] É PRECISO oferecer suporte a três instâncias de sessões de decodificador de vídeo de hardware não seguras com uma instância de sessão de decodificador de vídeo de hardware segura (4 instâncias no total) (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codec executada simultaneamente em resolução 1080p a 30 fps.
  • [5.1/ H-1-11] É PRECISO oferecer suporte a um decodificador seguro para cada decodificador AVC, HEVC, VP9 ou AV1 de hardware no dispositivo.
  • [5.1/H-1-12] É PRECISO ter uma latência de inicialização do decodificador de vídeo de 40 ms ou menos.
  • [5.1/H-1-13] É PRECISO ter uma latência de inicialização do decodificador de áudio de 30 ms ou menos.
  • [5.1/H-1-14] É PRECISO oferecer suporte ao decodificador de hardware AV1 Main 10, nível 4.1.
  • [5.1/H-SR] É altamente recomendável oferecer suporte a granulação de filme para decodificador de hardware AV1.
  • [5.1/H-1-15] É PRECISO ter pelo menos 1 decodificador de vídeo de hardware compatível com 4K60.
  • [5.1/H-1-16] É PRECISO ter pelo menos 1 codificador de vídeo de hardware compatível com 4K60.
  • [5.3/H-1-1] NÃO PODE haver mais de 1 frame em 10 segundos (ou seja, menos de 0,167% de queda de frames) para uma sessão de vídeo de 1080p 60 fps sob carga. A carga é definida como uma sessão de transcodificação simultânea de 1080p para 720p somente em vídeo usando codecs de vídeo de hardware, além de uma reprodução de áudio AAC de 128 kbps.
  • [5.3/H-1-2] NÃO É PERMITIDO perder mais de 1 frame em 10 segundos durante uma mudança de resolução de vídeo em uma sessão de vídeo de 60 fps sob carga. A carga é definida como uma sessão de transcodificação de vídeo simultânea de 1080p para 720p usando codecs de vídeo de hardware, além de uma reprodução de áudio AAC de 128 kbps.
  • [5.6/H-1-1] É PRECISO ter uma latência de toque para tom de 80 milissegundos ou menos usando o teste de toque para tom do OboeTester ou o teste de toque para tom do CTS Verifier.
  • [5.6/H-1-2] É PRECISO ter uma latência de áudio de ida e volta de 80 milissegundos ou menos em pelo menos um caminho de dados compatível.
  • [5.6/H-1-3] É PRECISO oferecer suporte a áudio de 24 bits ou mais para saída estéreo por meio de conectores de áudio de 3,5 mm, se presentes, e por áudio USB, se houver suporte em todo o caminho de dados para configurações de baixa latência e streaming. Para a configuração de baixa latência, a AAudio precisa ser usada pelo app no modo de callback de baixa latência. Para a configuração de streaming, o app precisa usar um Java AudioTrack. Nas configurações de baixa latência e streaming, o sink de saída do HAL precisa aceitar AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT ou AUDIO_FORMAT_PCM_FLOAT como formato de saída de destino.
  • [5.6/H-1-4] É PRECISO ter suporte a dispositivos de áudio USB de 4 canais ou mais (usado por controladores de DJ para visualizar músicas).
  • [5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar a flag de recurso MIDI.
  • [5.7/H-1-2] É PRECISO oferecer suporte a MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL com os recursos de descriptografia de conteúdo abaixo.

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

  Finalizar novos requisitos

• 2.2.7.2 Câmera: atualizações nos requisitos da câmera da classe de desempenho de mídia.

  Conferir revisão

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

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

  Finalizar novos requisitos

• 2.2.7.3 Hardware: atualizações nos requisitos da classe de performance de mídia para hardware.

  Conferir revisão

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

  • [7.1.1.1/H-2-1] É PRECISO ter uma resolução de tela de pelo menos 1080p.
  • [7.1.1.3/H-2-1] É NECESSÁRIO ter uma densidade de tela de pelo menos 400 dpi.
  • [7.6.1/H-2-1] É PRECISO ter pelo menos 8 GB de memória física.

  Finalizar novos requisitos

• 2.2.7.4 Desempenho: atualizações na classe de desempenho de mídia para desempenho.

  Conferir revisão

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

  • [8.2/H-1-1] É PRECISO garantir um desempenho de gravação sequencial de pelo menos 125 MB/s.
  • [8.2/H-1-2] É PRECISO garantir um desempenho de gravação aleatória de pelo menos 10 MB/s.
  • [8.2/H-1-3] É PRECISO garantir um desempenho de leitura sequencial de pelo menos 250 MB/s.
  • [8.2/H-1-4] É PRECISO garantir uma performance de leitura aleatória de pelo menos 40 MB/s.

  Finalizar novos requisitos

• 2.5.1 Hardware: atualizações nos requisitos de acelerômetro e giroscópio de três eixos, bem como os requisitos da câmera de visão externa.

  Conferir revisão

  Implementações de dispositivos automotivos:

  • [7.3.1/A-0-4] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor do carro do Android.
  • [7.3/A-SR] É _RECOMENDADO_FORTEMENTE incluir um acelerômetro de três eixos e um giroscópio de três eixos.
  • [7.3/A-SR] É STRONGLY_RECOMMENDED implementar e informar o sensor TYPE_HEADING.

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

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

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

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

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

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

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

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

  Finalizar novos requisitos

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

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

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

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

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

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

  Finalizar novos requisitos

  Uma câmera de visão externa é uma câmera que captura imagens de cenas fora da implementação do dispositivo, como a câmera retrovisor uma câmera de painel .

  Se as implementações de dispositivos automotivos incluírem uma câmera de visão externa, para essa câmera, elas:

  • [7.5.5/A-SR] É ALTAMENTE RECOMENDADO que a orientação seja feita de modo que a dimensão longa da câmera se alinhe ao horizonte.

  • PRECISA oferecer suporte ao framework de sincronização do Android.

  • PODE ter o foco automático de hardware ou de software implementado no driver da câmera.

  Se as implementações de dispositivos automotivos incluírem uma ou mais câmeras de visão externa e carregarem o serviço do sistema de visualização externa (EVS, na sigla em inglês), para essa câmera, elas:

  • [7.5/A-2-1] A visualização da câmera NÃO PODE ser girada ou espelhada horizontalmente.

  Implementações de dispositivos automotivos:

  • PODE incluir uma ou mais câmeras disponíveis para aplicativos de terceiros.

  Se as implementações de dispositivos automotivos incluírem pelo menos uma câmera e a disponibilizarem para aplicativos de terceiros, elas:

  • [7.5/A-3-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera.any.
  • [7.5/A-3-2] NÃO DECLARAR a câmera como uma câmera do sistema.
  • PODE aceitar câmeras externas descritas na seção 7.5.3.
  • PODE incluir recursos (como foco automático etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

  Finalizar novos requisitos

• Modelo de segurança 2.5.5: novos requisitos para permissões de câmera em dispositivos automotivos.

  Conferir revisão

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

  • [9.8.2/A-2-1] É PRECISO mostrar o indicador da câmera quando um app estiver acessando dados da câmera em tempo real, mas não quando a câmera estiver sendo acessada apenas por apps que tenham as funções mencionadas na seção 9.1 Permissões com identificador CDD [C-3-X].

  • [9.8.2/A-2-2] Não é permitido ocultar o indicador da câmera para apps do sistema que têm interfaces do usuário visíveis ou interação direta do usuário.

  Finalizar novos requisitos

• 2.6.1 Requisitos do tablet: hardware: atualização dos requisitos de tamanho da tela do tablet.

  Conferir revisão

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

  • Tem um tamanho de tela maior que 7" e menor que 18", medido na diagonal.

  Tamanho da tela

  • [7.1.1.1/Tab-0-1] PRECISA ter uma tela de 7 a 18 polegadas.

3. Software

• 3.2.2 Parâmetros do build: foram atualizados os caracteres ASCII em getSerial().

  Conferir revisão

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

  Parâmetro	Detalhes
  getSerial()	DEVE (ser ou retornar) um número de série de hardware, que DEVE estar disponível e ser exclusivo em dispositivos com o mesmo MODELO e FABRICANTE. O valor desse campo precisa ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9]+$”.

• 3.2.3.5 Intenções de aplicativo condicionais: atualização dos requisitos para intenções de aplicativo condicionais.

  Conferir revisão

  Se as implementações do dispositivo incluem uma tela grande (geralmente com largura e altura de 600 dp ou mais) e oferecem suporte à funcionalidade de divisão, elas:

  • [C-17-1] É PRECISO 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.

  Finalizar novos requisitos

• 3.5.1 Restrição de aplicativo: atualizações nas restrições de aplicativo.

  Conferir revisão

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

  • [C-1-1] É PRECISO permitir que o usuário veja a lista de apps restritos.
  • [C-1-2] É PRECISO oferecer ao usuário a capacidade de ativar / desativar todas essas restrições exclusivas em cada app.
  • [C-1-3] É PROIBIDO aplicar automaticamente essas restrições reservadas sem evidências de comportamento de integridade do sistema ruim, mas é PERMITIDO aplicar as restrições em apps após a detecção de comportamento de integridade do sistema ruim, como wakelocks presos, serviços de execução longa e outros critérios. Os critérios podem ser determinados pelos implementadores do dispositivo, mas precisam estar relacionados ao impacto do app na integridade do sistema. Outros critérios que não estejam relacionados apenas à integridade do sistema, como a falta de popularidade do app no mercado, NÃO devem ser usados como critérios.
  • [C-1-4] NÃO é permitido aplicar automaticamente essas restrições reservadas a apps quando um usuário desativou as restrições de apps manualmente e PODE sugerir ao usuário que aplique essas restrições reservadas.

  • [C-1-5] É OBRIGATÓRIO informar aos usuários se essas restrições de propriedade intelectual são aplicadas a um app automaticamente. Essas informações precisam ser fornecidas no período de 24 horas anterior à aplicação dessas restrições reservadas.

  • [C-1-6] PRECISA retornar verdadeiro para o método ActivityManager.isBackgroundRestricted() em todas as chamadas de API de um app.

  • [C-1-7] NÃO DEVE restringir o app em primeiro plano que é usado explicitamente pelo usuário.

  • [C-1-8] É OBRIGATÓRIO suspender essas restrições proprietárias em um app sempre que um usuário começar a usá-lo explicitamente, tornando-o o aplicativo em primeiro plano principal.

  • [C-1-9] É OBRIGATÓRIO informar todos esses eventos de restrições reservadas pelo UsageStats.

  • [C-1-10] É OBRIGATÓRIO fornecer um documento ou site público e claro que descreva como as restrições de propriedade são aplicadas. Esse documento ou site PRECISA ser vinculado nos documentos do SDK do Android e PRECISA incluir:

    • Acionar condições para restrições de propriedade.
    • O que e como um app pode ser restrito.
    • Como um app pode ser isento dessas restrições.
    • Como um app pode solicitar uma isenção de restrições de propriedade, se elas oferecerem essa isenção para apps que o usuário pode instalar.

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

  Finalizar novos requisitos

• 3.8.1 Launcher (tela inicial): atualizações para oferecer suporte a monochrome/adaptive-icon.

  Conferir revisão

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

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

  Finalizar novos requisitos

• 3.8.2 Widgets: atualização para a presença de widgets de apps de terceiros no Acesso rápido.

  Conferir revisão

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

  • [C-1-2] É PRECISO incluir suporte integrado a AppWidgets e expor as características da interface do usuário para adicionar, configurar, visualizar e remover AppWidgets diretamente no Launcher.

• 3.8.3.1 Apresentação de notificações: esclarecer a definição de notificações de alerta.

  Conferir revisão

  As notificações de alerta são apresentadas ao usuário conforme chegam, independentemente da plataforma em que ele está.

• 3.8.3.3 Modo de prioridade / NP (não perturbe): atualização para incluir o modo de prioridade nos requisitos de NP (não perturbe).

  Conferir revisão

  3.8.3.3. Não perturbe / Modo de prioridade

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

• 3.8.6 Temas: novos requisitos para paletas de cores tonais dinâmicas.

  Conferir revisão

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

  • [C-1-4] É OBRIGATÓRIO gerar paletas de tons de cores dinâmicas, conforme especificado na documentação do AOSP de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.system_palette e android.theme.customization.theme_style).

  • [C-1-5] É NECESSÁRIO gerar paletas de tons de cores dinâmicas usando estilos de tema de cores enumerados na documentação Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.theme_styles), ou seja, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD.

    "Cor de origem" usada para gerar paletas de tons de cores dinâmicas quando enviada com android.theme.customization.system_palette (como documentado em Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

  • [C-1-6] É PRECISO ter um valor de croma CAM16 de 5 ou maior.

    • DEVE ser derivado do plano de fundo por meio de com.android.systemui.monet.ColorScheme#getSeedColors, que fornece várias cores de origem válidas para escolher uma.

    • DEVE usar o valor 0xFF1B6EF3 se nenhuma das cores fornecidas atender ao requisito de cor de origem acima.

  Finalizar novos requisitos

• Área de transferência 3.8.17: adicionado uma nova seção de requisitos para conteúdo na área de transferência.

  Conferir revisão

  3.8.17. Área de transferência

  Implementações de dispositivos:

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

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

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

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

  Finalizar novos requisitos

• 3.9.1.1 Provisionamento do proprietário do dispositivo: atualizações nos requisitos de provisionamento do proprietário do dispositivo.

  Conferir revisão

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

  • [C-1-1] É PRECISO oferecer suporte à inscrição de um cliente de política de dispositivo (DPC, na sigla em inglês) como um app de proprietário do dispositivo conforme descrito abaixo:
    • Quando a implementação do dispositivo não tem nem dados do usuário configurados, ela:
      • [C-1-5] É PRECISO registrar o aplicativo DPC como o app proprietário do dispositivo ou permitir que o app DPC escolha se quer se tornar um proprietário do dispositivo ou do perfil,se o dispositivo declarar suporte à comunicação de campo próximo (NFC) pela flag de recursos android.hardware.nfc e receber uma mensagem NFC que contenha um registro com o tipo MIME MIME_TYPE_PROVISIONING_NFC.
      • [C-1-8] É PRECISO enviar a intent ACTION_GET_PROVISIONING_MODE depois que o provisionamento do proprietário do dispositivo for acionado para que o app DPC possa escolher se quer 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. Por exemplo, no provisionamento baseado em NFC, em que o provisionamento do proprietário do perfil não é aceito.
      • [C-1-9] É OBRIGATÓRIO enviar a intent ACTION_ADMIN_POLICY_COMPLIANCE para o app proprietário do dispositivo se um proprietário do dispositivo for estabelecido durante o provisionamento, independentemente do método de provisionamento usado. O usuário não pode continuar no assistente de configuração até que o app de proprietário do dispositivo seja concluído.
    • Quando a implementação do dispositivo tem usuários ou dados do usuário, ela:
      • [C-1-7] Não é mais permitido registrar nenhum aplicativo DPC como o app proprietário do dispositivo.
  • [C-1-2] É PRECISO mostrar um aviso de divulgação adequado (conforme referenciado no AOSP) e receber o consentimento afirmativo do usuário final antes que um app seja definido como proprietário do dispositivo, a menos que o dispositivo seja configurado programaticamente para o modo de demonstração de varejo antes da interação do usuário final na tela. Exige alguma ação afirmativa antes ou durante o processo de provisionamento para consentir que um app seja definido como proprietário do dispositivo. O consentimento pode ser feito por ação do usuário ou por meios programáticos, mas o aviso de divulgação adequado (conforme mencionado no AOSP) PRECISA ser mostrado antes do provisionamento do proprietário do dispositivo ser iniciado. Além disso, o mecanismo de consentimento do proprietário do dispositivo programático usado (por empresas) para provisionamento de proprietário do dispositivo NÃO PODE interferir na experiência pronta para uso para uso não empresarial.
  • [C-1-3] NÃO É PERMITIDO codificar o consentimento ou impedir o uso de outros apps de proprietário do dispositivo.

  Se as implementações do dispositivo declararem android.software.device_admin, mas também incluírem uma solução de gerenciamento de dispositivo proprietária e fornecerem um mecanismo para promover um aplicativo configurado na solução como um "equivalente ao proprietário do dispositivo" ao "proprietário do dispositivo" padrão, conforme reconhecido pelas APIs DevicePolicyManager padrão do Android, elas:

  • [C-2-1] É PRECISO ter um processo em vigor para verificar se o app específico que está sendo promovido pertence a uma solução legítima de gerenciamento de dispositivos corporativos e foi configurado na solução proprietária para ter direitos equivalentes como "proprietário do dispositivo".
  • [C-2-2] É PRECISO mostrar a mesma declaração de consentimento do proprietário do dispositivo do AOSP que o fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o aplicativo DPC como "Proprietário do dispositivo".
  • [C-2-3] O consentimento não pode ser codificado rigidamente nem impedir o uso de outros apps de proprietário do dispositivo.
  • Pode ter dados do usuário no dispositivo antes de registrar o aplicativo DPC como "proprietário do dispositivo".

• 3.9.4 Requisitos de função de gerenciamento de dispositivos: adicionamos uma seção para os requisitos de função de gerenciamento de dispositivos.

  Conferir revisão

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

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

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

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

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

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

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

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

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

  Finalizar novos requisitos

• 3.18 Contatos: como adicionar informações para novos contatos.

  Conferir revisão

  Conta padrão para novos contatos:o Provedor de contatos oferece APIs para gerenciar a configuração da conta padrão ao criar um novo contato.

  Se as implementações do dispositivo pré-carregarem um app de contatos, o app de contatos pré-carregado:

  • [C-2-1] PRECISA processar a intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT para iniciar uma interface de seleção de conta e salvar a configuração no provedor de contatos quando uma conta é selecionada.

  • [C-2-2] É OBRIGATÓRIO respeitar a configuração de conta padrão ao processar Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT para ContactsContracts.Contacts.CONTENT_TYPE e ContactsContract.RawContacts.CONTENT_TYPE selecionando inicialmente a conta.

  Finalizar novos requisitos

4. Compatibilidade de empacotamento de aplicativos

• 4. Compatibilidade de empacotamento de aplicativos: atualizações na versão do Esquema de assinatura do APK.

  Conferir revisão

  Implementações de dispositivos:

  • [C-0-2] É obrigatório oferecer suporte à verificação de arquivos ".apk" usando o Esquema de assinatura de APK v3.1 , Esquema de assinatura de APK v3, Esquema de assinatura de APK v2 e assinatura JAR.

  • [C-0-9] PRECISA oferecer suporte à verificação de arquivos .apk usando o Esquema de assinatura de APK v4 e o Esquema de assinatura de APK v4.1 .

5. Compatibilidade com multimídia

• 5.1.2 Decodificação de áudio: foram adicionados novos requisitos para decodificadores capazes de gerar áudio multicanal.

  Conferir revisão

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

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

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

  • [C-SR] É 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 é reduzido para estéreo (quando se usa um valor de 2) ou é enviado usando o número nativo de canais (quando se usa um valor igual ou maior que esse número). Por exemplo, um valor de 6 ou mais configuraria um decodificador para gerar 6 canais ao receber conteúdo 5.1.
  • [C-SR] Ao decodificar, o decodificador é ALTAMENTE RECOMENDADO a anunciar a máscara de canal usada no formato de saída com a chave KEY_CHANNEL_MASK, usando as constantes android.media.AudioFormat (por exemplo, CHANNEL_OUT_5POINT1).

  Finalizar novos requisitos

• 5.4.1 Captura de áudio bruto e informações do microfone: atualizações nas fontes de áudio com suporte para streams de entrada de áudio.

  Conferir revisão

  Se as implementações do dispositivo declararem android.hardware.microphone, elas:

  • [C-1-1] PRECISA permitir a captura de conteúdo de áudio bruto com as seguintes características para qualquer fluxo de ENTRADA AudioRecord ou AAudio que seja aberto. No mínimo, as seguintes características precisam ter suporte:

    • 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.
    • [C-1-4] É PRECISO honrar a API MicrophoneInfo e preencher corretamente as informações dos microfones disponíveis no dispositivo acessíveis aos aplicativos de terceiros pela API AudioManager.getMicrophones(), para AudioRecord ativo usando MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. e os microfones ativos no momento, que são acessíveis aos aplicativos de terceiros pelas APIs AudioRecord.getActiveMicrophones() e MediaRecorder.getActiveMicrophones().

• 5.4.2 Captura para reconhecimento de voz: os requisitos para fluxo de áudio de reconhecimento de voz foram atualizados e foram adicionados requisitos para níveis de ganho do microfone.

  Conferir revisão

  Se as implementações do dispositivo declararem android.hardware.microphone, elas:

  • DEVE gravar o fluxo de áudio de reconhecimento de voz com amplitude aproximadamente plana em relação às características de frequência: especificamente, ±3 dB, de 100 Hz a 4.000 Hz.
  • DEVE gravar o stream de áudio de reconhecimento de voz com a sensibilidade de entrada definida de modo que uma fonte de nível de potência sonora (SPL) de 90 dB a 1.000 Hz produza RMS de 2.500 para amostras de 16 bits.

  • DEVEM apresentar características aproximadamente planas de amplitude versus frequência na faixa de frequência média: especificamente ±3dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • [C-SR] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de baixa frequência: especificamente de ±20 dB de 30 Hz a 100 Hz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • [C-SR] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de alta frequência: especificamente de ±30 dB de 4.000 Hz a 22 KHz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • DEVERÁ definir a sensibilidade de entrada de áudio de modo que uma fonte de tom senoidal de 1000 Hz tocada a 90 dB de nível de pressão sonora (SPL, na sigla em inglês) (medido ao lado do microfone) produza uma resposta ideal de RMS 2500 em um intervalo de 1770 e 3530 para 16 amostras de bits (ou -22,35 dB ±3dB de escala completa para ponto flutuante/amostras de precisão dupla) para cada microfone usado para gravar a fonte de áudio do reconhecimento de voz.

  Finalizar novos requisitos

• 5.4.6 Níveis de ganho do microfone: os requisitos para os níveis de ganho do microfone foram movidos para a seção 5.4.2.

  Conferir revisão

  5.4.6. Níveis de ganho do microfone [Movimentado para 5.4.2]

  Se as implementações do dispositivo declararem android.hardware.microphone, elas:

  • DEVEM apresentar características aproximadamente planas de amplitude versus frequência na faixa de frequência média: especificamente ±3dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • [C-SR] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de frequência baixa: especificamente de ±20 dB de 5 Hz a 100 Hz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • [C-SR] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de alta frequência: especificamente de ±30 dB de 4.000 Hz a 22 KHz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • DEVE definir a sensibilidade de entrada de áudio de modo que uma fonte de tom senoidal de 1.000 Hz tocada a 90 dB de nível de pressão sonora (SPL) produza uma resposta com RMS de 2.500 para amostras de 16 bits (ou -22,35 dB de escala completa para amostras de ponto flutuante/dupla precisão) para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.

• 5.5.4 Transferência de áudio: atualizações nos requisitos de reprodução de transferência de áudio.

  Conferir revisão

  Se as implementações do dispositivo oferecerem suporte à reprodução de transferência de áudio, elas:

  • [C-SR] É ALTAMENTE RECOMENDADO cortar o conteúdo de áudio sem lacunas entre dois clipes com o mesmo formato quando especificado pela API AudioTrack sem lacunas e pelo contêiner de mídia do MediaPlayer.

• 5.6 Latência de áudio: atualizações nos requisitos de latência de áudio.

  Conferir revisão

  Para os fins desta seção, use as seguintes definições:

  • Jitter de saída fria. A variabilidade entre medições separadas de valores de latência de saída fria.
  • Jitter de entrada fria. A variabilidade entre medições separadas de valores de latência de entrada fria.

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

  • [C-1-2] Latência de saída fria de 500 milissegundos ou menos.
  • [C-1-3] Abrir um stream de saída usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

  Se as implementações do dispositivo declararem android.hardware.audio.output, é ALTAMENTE RECOMENDÁVEL que elas atendam ou excedam os seguintes requisitos:

  • [C-SR] Latência de saída fria de 100 milissegundos ou menos no caminho de dados do alto-falante. É ALTAMENTE RECOMENDÁVEL que os dispositivos atuais e novos que executam essa versão do Android atendam a esses requisitos. Em uma versão futura da plataforma, vamos exigir uma latência de saída a frio de 200 ms ou menos como obrigatória.
  • [C-SR] Minimizar o jitter de saída a frio.

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

  • [C-3-2] Latência de entrada fria de 500 milissegundos ou menos.
  • [C-3-3] Abrir um fluxo de entrada usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

  Se as implementações do dispositivo incluírem android.hardware.microphone, é ALTAMENTE RECOMENDÁVEL que elas atendam a estes requisitos de áudio de entrada:

  • [C-SR] Latência de entrada fria de 100 milissegundos ou menos no caminho de dados do microfone. É MUITO RECOMENDÁVEL que os dispositivos atuais e novos que executam esta versão do Android atendam a esses requisitos. Em uma versão futura da plataforma, vamos exigir uma latência de entrada fria de 200 ms ou menos.

  • [C-SR] Latência de entrada contínua de 30 milissegundos ou menos.
  • [C-SR] Minimizar o jitter de entrada a frio.

• 5.10 Áudio profissional: atualizações nos requisitos de latência de áudio para suporte a áudio profissional.

  Conferir revisão

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

  • [C-1-2] PRECISA ter a latência de áudio de ida e volta contínua, conforme definido na seção 5.6 Latência de áudio de 25 milissegundos ou menos e DEVE ser de 10 milissegundos ou menos em pelo menos um caminho com suporte.
  • [C-1-5] É NECESSÁRIO atender às latências e aos requisitos de áudio USB usando a API AAudio native audio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
  • [C-1-8] É OBRIGATÓRIO ter uma latência média de Tap-to-Tone de 80 milissegundos ou menos em pelo menos cinco medições no caminho de dados do alto-falante para o microfone.
  • [C-SR] É ALTAMENTE RECOMENDADO fornecer um nível consistente de desempenho da CPU enquanto o áudio está ativo e a carga da CPU está variando. Isso precisa ser testado usando o app Android SynthMark. O SynthMark usa um sintetizador de software executado em um framework de áudio simulado que mede o desempenho do sistema. Consulte a documentação do SynthMark para uma explicação dos comparativos. O app SynthMark precisa ser executado usando a opção "Teste automatizado" e alcançar os seguintes resultados: * voicemark.90 >= 32 vozes * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
  • DEVE ter uma latência da entrada de toque para a saída de áudio menor ou igual a 40 ms.

  Se as implementações do dispositivo incluírem um conector de áudio de 3,5 mm com quatro condutores, elas:

  • [C-2-1] É PRECISO ter uma latência média de áudio de ida e volta contínua, conforme definido na seção 5.6 Latência de áudio, de 20 milissegundos ou menos, em 5 medições com uma Desvio absoluto médio de menos de 5 milissegundos no caminho da entrada de áudio usando um dongle de retorno de áudio.

• 5.12 Vídeo HDR: adicionamos uma nova seção para os requisitos de vídeo HDR.

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

• 6.1 Ferramentas para desenvolvedores: atualizações de conectividade e requisitos do kernel da GPU.

  Conferir revisão

  Se as implementações do dispositivo oferecerem suporte a conexões adb para uma máquina host via Wi-Fi ou Ethernet, elas:

  • [C-4-1] O método AdbManager#isAdbWifiSupported() PRECISA retornar true.

  Se as implementações do dispositivo oferecerem suporte a conexões adb para uma máquina host via Wi-Fi ou Ethernet e incluírem pelo menos uma câmera, elas:

  • [C-5-1] O método AdbManager#isAdbWifiQrSupported() precisa retornar true.

  • Informações de trabalho da GPU

    Implementações de dispositivos:

    • [C-6-1] É PRECISO implementar o comando de shell dumpsys gpu --gpuwork para mostrar os dados de trabalho da GPU agregados retornados pelo ponto de rastreamento do kernel power/gpu_work_period ou não mostrar dados se o ponto de rastreamento não tiver suporte. A implementação do AOSP é frameworks/native/services/gpuservice/gpuwork/.

  Finalizar novos requisitos

7. Compatibilidade de hardware

• 7.1.4.1 OpenGL ES: atualização para extensões recomendadas.

  Conferir revisão

  Se as implementações do dispositivo forem compatíveis com qualquer uma das versões do OpenGL ES, elas:

  • DEVEM oferecer suporte às extensões EGL_IMG_context_priority e EGL_EXT_protected_content.

  Finalizar novos requisitos

• 7.1.4.2 Vulkan: atualizações para a versão com suporte para Vulkan.

  Conferir revisão

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

  • [SR] É ALTAMENTE RECOMENDADO incluir suporte para Vulkan 1.3. Vulkan 1.1
  • NÃO pode oferecer suporte a uma versão da variante do Vulkan (ou seja, a parte da variante da versão do núcleo do Vulkan PRECISA ser zero).

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

  • [SR] É ALTAMENTE RECOMENDADO incluir suporte para Vulkan 1.3. Vulkan 1.1

  Se as implementações do dispositivo incluem suporte ao Vulkan 1.0 ou mais recente, elas:

  • DEVE ser compatível com VkPhysicalDeviceProtectedMemoryFeatures e VK_EXT_global_priority.
  • [C-1-12] NÃO É PERMITIDO enumerar o suporte à extensão VK_KHR_performance_query.
  • [C-SR] É FORTEMENTE RECOMENDADO atender aos requisitos especificados pelo perfil de referência do Android 2021.

• 7.2.3 Teclas de navegação:

  Conferir revisão

  Implementações de dispositivos:

  • [C-SR] É ALTAMENTE RECOMENDADO fornecer todas as funções de navegação como canceláveis. "Cancelável" é definido como a capacidade do usuário de impedir a execução da função de navegação (por exemplo, voltar à tela inicial, voltar, etc.) se o deslize não for liberado após um determinado limite.

  Finalizar novos requisitos

  Se a função de navegação de volta for fornecida e o usuário cancelar o gesto "Voltar", então:

  • [C-8-1] OnBackInvokedCallback.onBackCancelled() PRECISA ser chamado.
  • [C-8-2] OnBackInvokedCallback.onBackInvoked() NÃO PODE ser chamado.
  • [C-8-3] O evento KEYCODE_BACK NÃO deve ser enviado.

  Se a função de navegação de retorno for fornecida, mas o aplicativo em primeiro plano NÃO tiver um OnBackInvokedCallback registrado, faça o seguinte:

  • O sistema DEVE fornecer uma animação para o aplicativo em primeiro plano que sugere que o usuário está voltando, conforme fornecido no AOSP.

  Se as implementações do dispositivo oferecerem suporte à API setNavBarMode do sistema para permitir que qualquer app do sistema com permissão android.permission.STATUS_BAR defina o modo da barra de navegação, elas:

  • [C-9-1] É NECESSÁRIO oferecer suporte a ícones adequados para crianças ou navegação baseada em botões, conforme fornecido no código do AOSP.

  Finalizar novos requisitos

• 7.3.1 Acelerômetro: atualizações nos requisitos de sensores para acelerômetros.

  Conferir revisão

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

  • [C-1-2] É PRECISO implementar e informar o sensor TYPE_ACCELEROMETER.
  • [SR] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
  • [SR] É ALTAMENTE RECOMENDADO implementar e relatar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. É FORTEMENTE RECOMENDADO que os dispositivos Android atendam a esse requisito para que possam fazer upgrade para a versão futura da plataforma, quando isso se tornar OBRIGATÓRIO.
  • DEVE implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER conforme descrito no documento do SDK do Android.

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

  • [C-2-1] É PRECISO implementar e informar o sensor TYPE_ACCELEROMETER.
  • [C-SR] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
  • [C-SR] É ALTAMENTE RECOMENDADO implementar e informar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. É FORTEMENTE RECOMENDADO que os dispositivos Android atendam a esse requisito para que possam fazer upgrade para a versão futura da plataforma, quando isso se tornar OBRIGATÓRIO.
  • DEVE implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER conforme descrito no documento do SDK do Android.

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

  • [C-3-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
  • [C-SR] É STRONGLY_RECOMMENDED implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

  Finalizar novos requisitos

  Se as implementações do dispositivo incluírem um acelerômetro de três eixos e qualquer um dos sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER forem implementados:

  • [C-4-1] A soma do consumo de energia PRECISA ser sempre menor que 4 mW.

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

  • [C-5-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.

  Se as implementações do dispositivo incluírem um acelerômetro de três eixos, um sensor de giroscópio de três eixos e um sensor de magnetômetro, elas:

  • [C-6-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

• 7.3.4 Giroscópios: atualizações nos requisitos de sensores para giroscópios.

  Conferir revisão

  Se as implementações do dispositivo incluírem um giroscópio, elas:

  • [C-1-1] É PRECISO que o sistema consiga informar eventos com frequência de pelo menos 50 Hz.
  • [C-1-4] PRECISA ter uma resolução de 12 bits ou mais.
  • [C-1-5] É PRECISO compensar a temperatura.
  • [C-1-6] DEVE ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • [C-1-7] PRECISA ter uma variação não maior que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar com a taxa de amostragem, mas PRECISA ser limitada por esse valor. Em outras palavras, se você medir a variação do giroscópio com uma taxa de amostragem de 1 Hz, ela NÃO PODE ser maior do que 1e-7 rad^2/s^2.
  • [C-SR] É ALTAMENTE RECOMENDÁVEL que o erro de calibração seja menor que 0,01 rad/s quando o dispositivo estiver parado à temperatura ambiente.
  • [C-SR] É ALTAMENTE RECOMENDADO ter uma resolução de 16 bits ou mais.
  • DEVE informar eventos de até 200 Hz.

  Finalizar novos requisitos

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

  • [C-2-1] PRECISA implementar o sensor TYPE_GYROSCOPE.

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

  • [C-3-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES.
  • [C-SR] É STRONGLY_RECOMMENDED implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

  Finalizar novos requisitos

  Se as implementações do dispositivo incluem um giroscópio de três eixos, um sensor de acelerômetro e um sensor de magnetômetro, elas:

  • [C-4-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

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

  • [C-5-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.

• 7.3.10 Sensores biométricos: atualizações nos requisitos de sensores biométricos.

  Conferir revisão

  Os sensores biométricos podem ser classificados como Classe 3 (antes Forte), Classe 2 (antes Fraco) ou Classe 1 (antes Conveniente) com base nas taxas de falsificação e aceitação de impostores e na segurança do pipeline biométrico. Essa classificação determina os recursos que o sensor biométrico tem para interagir com a plataforma e com aplicativos de terceiros. Os sensores precisam atender a outros requisitos, conforme detalhado abaixo, se quiserem ser classificados como Classe 1, Classe 2 ou Classe 3. Os sensores são classificados como Classe 1 por padrão e precisam atender a outros requisitos, conforme detalhado abaixo, se quiserem ser classificados como Classe 2 ou Classe 3. A biometria de Classe 2 e de Classe 3 recebe outros recursos, conforme detalhado abaixo.

  Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 1 (anteriormente Convenience), elas:

  • [C-1-11] É PRECISO ter uma taxa de aceitação de falsificação e impostor não superior a 30%, com (1) uma taxa de aceitação de falsificação e impostor para o nível A do instrumento de ataque de apresentação (PAI, na sigla em inglês) não superior a 30% e (2) uma taxa de aceitação de falsificação e impostor de espécies de PAI de nível B não superior a 40%, conforme medido pelos protocolos de teste de biometria do Android.

  Finalizar novos requisitos

  Se as implementações de dispositivo quiserem tratar um sensor biométrico como Classe 2 (anteriormente Fraco), elas:

  • [C-2-2] É PRECISO ter uma taxa de aceitação de falsificação e impostor não superior a 20%, com (1) uma taxa de aceitação de falsificação e impostor para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) de nível A não superior a 20% e (2) uma taxa de aceitação de falsificação e impostor de espécies de PAI de nível B não superior a 30%, conforme medido pelos protocolos de teste de biometria do Android.

  Se as implementações de dispositivo quiserem tratar um sensor biométrico como Classe 3 (antes Forte), elas:

  • [C-3-3] É PRECISO ter uma taxa de aceitação de falsificação e impostor não superior a 7%, com (1) uma taxa de aceitação de falsificação e impostor para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) de nível A não superior a 7% e (2) uma taxa de aceitação de falsificação e impostor de espécies de PAI de nível B não superior a 20%, conforme medido pelos protocolos de teste de biometria do Android.

• 7.3.13 IEEE 802.1.15.4 (UWB): foi adicionada uma nova seção de requisitos para UWB.

  Conferir revisão

  7.3.13. IEEE 802.1.15.4 (UWB)

  Se as implementações do dispositivo incluírem suporte ao 802.1.15.4 e exporem a funcionalidade a um aplicativo de terceiros, elas:

  • [C-1-1] É OBRIGATÓRIO implementar a API Android correspondente no android.uwb.
  • [C-1-2] É PRECISO informar a flag de recurso de hardware android.hardware.uwb.
  • [C-1-3] PRECISA oferecer suporte a todos os perfis UWB relevantes definidos na implementação do Android.
  • [C-1-4] É PRECISO fornecer uma característica para o usuário ativar/desativar o rádio UWB.
  • [C-1-5] É PRECISO aplicar que os apps que usam rádio UWB tenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICES).
  • [C-1-6] É ALTAMENTE RECOMENDADO passar nos testes de conformidade e certificação relevantes definidos por organizações de padronização, incluindo FIRA, CCC e CSA.

  Finalizar novos requisitos

• 7.4.1 Telefonia: atualizações nos requisitos de telefonia para telefonia GSM e CDMA e configurações de uso de celular.

  Conferir revisão

  Se as implementações de dispositivos oferecerem suporte a eUICCs ou eSIMs/chips integrados e incluírem um mecanismo reservado para disponibilizar a funcionalidade de eSIM para desenvolvedores de terceiros, eles:

  • [C-3-1] É PRECISO declarar a flag de recurso android.hardware.telephony.euicc. Forneça uma implementação completa do EuiccManager API.

  Se as implementações de dispositivos incluem telefonia GSM ou CDMA, então:

  • [C-6-1] O SmsManager#sendTextMessage e o SmsManager#sendMultipartTextMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer a funcionalidade de mensagens de texto. SmsManager#sendMultimediaMessage e SmsManager#downloadMultimediaMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer a funcionalidade de mensagens multimídia.
  • [C-6-2] O aplicativo designado por android.provider.Telephony.Sms#getDefaultSmsPackage PRECISA usar as APIs SmsManager ao enviar e receber mensagens SMS e MMS. A implementação de referência do AOSP em packages/apps/Messaging atende a esse requisito.
  • [C-6-3] O aplicativo que responde a Intent#ACTION_DIAL PRECISA oferecer suporte à entrada de códigos de discagem arbitrários formatados como *#*#CODE#*#* e acionar uma transmissão TelephonyManager#ACTION_SECRET_CODE correspondente.
  • [C-6-4] O aplicativo que responde a Intent#ACTION_DIAL PRECISA usar VoicemailContract.Voicemails#TRANSCRIPTION para mostrar a transcrição visual do correio de voz aos usuários, se ele oferece suporte a transcrições visuais do correio de voz.
  • [C-6-5] PRECISA representar todos os SubscriptionInfo com UUIDs de grupo equivalentes como uma única assinatura em todos os affordances visíveis para o usuário que mostram e controlam as informações do chip SIM. Exemplos de affordances incluem interfaces de configurações que correspondem a Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
  • [C-6-6] NÃO PRECISA mostrar ou permitir o controle de nenhuma SubscriptionInfo com um UUID de grupo não nulo e um bit oportunista em nenhuma característica visível para o usuário que permite a configuração ou o controle das configurações do cartão SIM.

  Se as implementações do dispositivo incluírem telefonia GSM ou CDMA e fornecerem uma barra de status do sistema, faça o seguinte:

  • [C-6-7] É OBRIGATÓRIO selecionar uma assinatura ativa representativa para um determinado UUID de grupo para mostrar ao usuário em qualquer recurso que forneça informações de status do SIM. Exemplos de affordances incluem o ícone de sinal de celular da barra de status ou o bloco de Configurações rápidas.
  • [C-SR] É ALTAMENTE RECOMENDADO que a assinatura representativa seja escolhida para ser a assinatura de dados ativa, a menos que o dispositivo esteja em uma chamada de voz, durante a qual é ALTAMENTE RECOMENDADO que a assinatura representativa seja a assinatura de voz ativa.

  Se as implementações de dispositivos incluem telefonia GSM ou CDMA, então:

  • [C-6-8] É PRECISO ser capaz de abrir e usar simultaneamente o número máximo de canais lógicos (20 no total) para cada UICC de acordo com o ETSI TS 102 221.
  • [C-6-10] NÃO É PERMITIDO aplicar nenhum dos seguintes comportamentos a apps de operadora ativos (designados por TelephonyManager#getCarrierServicePackageName) automaticamente ou sem a confirmação explícita do usuário:
    • Revogar ou limitar o acesso à rede
    • Revogar permissões
    • Restringir a execução de apps em segundo plano ou em primeiro plano além dos recursos de gerenciamento de energia incluídos no AOSP
    • Desativar ou desinstalar o app

  Se as implementações de dispositivo incluírem telefonia GSM ou CDMA e todas as assinaturas não oportunísticas ativas que compartilham um UUID de grupo forem desativadas, removidas fisicamente do dispositivo ou marcadas como oportunísticas, o dispositivo:

  • [C-7-1] É OBRIGATÓRIO desativar automaticamente todas as assinaturas oportunistas ativas restantes no mesmo grupo.

  Se as implementações de dispositivos incluem telefonia GSM, mas não telefonia CDMA, elas:

  • [C-8-1] NÃO PRECISA declarar PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-8-2] É OBRIGATÓRIO gerar uma IllegalArgumentException ao tentar definir qualquer tipo de rede 3GPP2 em máscaras de bits de tipo de rede preferido ou permitido.
  • [C-8-3] PRECISA retornar uma string vazia de TelephonyManager#getMeid.

  Se as implementações do dispositivo oferecerem suporte a eUICCs com várias portas e perfis, elas:

  • [C-11-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.telephony.euicc.mep.

  Finalizar novos requisitos

• 7.4.1.1 Compatibilidade com o bloqueio de números: atualizações nos requisitos de bloqueio de números.

  Conferir revisão

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

  • [C-1-4] NÃO É PERMITIDO gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada.

  • [C-1-4] É PRECISO gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada e FILTRAR chamadas com BLOCKED_TYPE da visualização de registro de chamadas padrão no app discador pré-instalado.
  • DEVE fornecer uma capacidade do usuário para mostrar chamadas bloqueadas no app de discagem pré-instalado.

  Finalizar novos requisitos

• 7.4.1.3 Desativação de keepalive NAT-T de celular: nova seção para a desativação de keepalive NAT-T de celular.

  Conferir revisão

  7.4.1.3. Descarregar o Keepalive NAT-T da rede celular

  Implementações de dispositivos:

  • DEVE incluir suporte para o offload de keepalive de rede celular.

  Se as implementações de dispositivos incluírem suporte ao offload de keepalive de rede celular e exibirem a funcionalidade para apps de terceiros, elas:

  • [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
  • [C-1-2] É NECESSÁRIO oferecer suporte a pelo menos um slot de manutenção de conexão simultâneo por rede celular.
  • [C-1-3] É PRECISO oferecer suporte a tantos slots de keepalive celular simultâneos quantos forem compatíveis com o HAL do rádio celular.
  • [C-SR] É ALTAMENTE RECOMENDADO oferecer suporte a pelo menos três slots de keepalive celular por instância de rádio.

  Se as implementações de dispositivos não incluírem suporte ao offload de keepalive de rede celular, elas:

  • [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

  Finalizar novos requisitos

• 7.4.2.5 Local do Wi-Fi (tempo de retorno do Wi-Fi - RTT): atualizações na precisão do local do Wi-Fi.

  Conferir revisão

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

  • [C-1-4] TEM QUE ser preciso com uma margem de 2 metros a 80 MHz de largura de banda no percentil 68 (calculado com a função de distribuição cumulativa).
  • [C-SR] É ALTAMENTE RECOMENDADO informar com precisão até 1,5 metro com largura de banda de 80 MHz no percentil 68 (calculado com a função de distribuição cumulativa).

  Finalizar novos requisitos

• 7.4.2.6 Offload de keepalive do Wi-Fi: foi atualizado para adicionar requisitos de offload de keepalive da rede celular.

  Conferir revisão

  Implementações de dispositivos:

  • DEVE incluir suporte para transferência de dados de keepalive do Wi-Fi.

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

  • [C-1-1] É PRECISO oferecer suporte à API SocketKeepAlive.
  • [C-1-2] É PRECISO ter suporte a pelo menos três slots de keepalive simultâneos por Wi-Fi
    e pelo menos um slot de manutenção de conexão por rede celular.

  Se as implementações de dispositivos não incluírem suporte ao offload de keepalive do Wi-Fi, elas:

  • [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

• 7.4.2.9 Trust On First Use (TOFU): adicionamos a seção de requisitos do Trust on First Use.

  Conferir revisão

  7.4.2.9 Confiança no primeiro uso (TOFU)

  Se as implementações de dispositivos oferecerem suporte ao Trust on First Use (TOFU) e permitirem que o usuário defina configurações WPA/WPA2/WPA3-Enterprise, elas:

  • [C-4-1] É PRECISO fornecer ao usuário uma opção para selecionar o uso de TOFU.

  Finalizar novos requisitos

• 7.4.3 Bluetooth: atualização dos requisitos de Bluetooth.

  Conferir revisão

  Se as implementações do dispositivo oferecem suporte ao perfil de áudio Bluetooth, elas:

  • DEVE oferecer suporte a codecs de áudio avançados e Bluetooth (por exemplo, LDAC) com A2DP.

  Se as implementações do dispositivo retornarem true para a API BluetoothAdapter.isLeAudioSupported(), elas:

  • [C-7-1] É PRECISO oferecer suporte a clientes unicast.
  • [C-7-2] É PRECISO oferecer suporte a 2M PHY.
  • [C-7-3] É PRECISO oferecer suporte à publicidade estendida do LE.
  • [C-7-4] É PRECISO oferecer suporte a pelo menos duas conexões de CIS em um CIG.
  • [C-7-5] É PRECISO ativar o cliente unicast BAP, o coordenador de conjunto CSIP, o servidor MCP, o controlador VCP e o servidor CCP simultaneamente.
  • [C-SR] É ALTAMENTE RECOMENDADO ativar o cliente unicast HAP.

  Se as implementações do dispositivo retornarem true para a API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), elas:

  • [C-8-1] É PRECISO ter suporte a pelo menos 2 links BIS em um BIG.
  • [C-8-2] É PRECISO ativar a fonte de transmissão do BAP e o assistente de transmissão do BAP simultaneamente.
  • [C-8-3] É PRECISO oferecer suporte à publicidade periódica de LE.

  Se as implementações do dispositivo retornarem true para a API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), elas:

  • [C-9-1] É PRECISO oferecer suporte a PAST (transferência periódica de sincronização de publicidade).
  • [C-9-2] É PRECISO oferecer suporte à publicidade periódica de LE.

  Se as implementações do dispositivo declararem FEATURE_BLUETOOTH_LE, elas:

  • [C-10-1] É OBRIGATÓRIO que as medições de RSSI estejam dentro de +/-9 dB para 95% das medições a 1 m de distância de um dispositivo de referência transmitindo em ADVERTISE_TX_POWER_HIGH em um ambiente de linha de visão.
  • [C-10-2] É PRECISO incluir correções de Rx/Tx para reduzir as variações por canal de modo que as medições em cada um dos três canais, em cada uma das antenas (se várias forem usadas), estejam dentro de +/-3 dB uma da outra para 95% das medições.
  • [C-SR] É ALTAMENTE RECOMENDADO medir e compensar o deslocamento de Rx para garantir que a RSSI média do BLE seja -60 dBm +/-10 dB a 1 m de distância de um dispositivo de referência transmitindo em ADVERTISE_TX_POWER_HIGH, em que os dispositivos são orientados de modo que estejam em "planos paralelos" com telas voltadas para a mesma direção.
  • [C-SR] É ALTAMENTE RECOMENDADO medir e compensar o deslocamento de transmissão para garantir que a RSSI média do BLE seja -60 dBm +/-10 dB ao fazer a varredura de um dispositivo de referência posicionado a 1 m de distância e transmitindo em ADVERTISE_TX_POWER_HIGH, em que os dispositivos são orientados de modo que estejam em "planos paralelos" com 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.

  Se as implementações do dispositivo forem compatíveis com a versão 5.0 do Bluetooth, elas:

  • [C-SR] É ALTAMENTE RECOMENDADO oferecer suporte para:
    • LE 2M PHY
    • PHY do codec LE
    • Extensão de publicidade LE
    • Publicidade periódica
    • Pelo menos 10 conjuntos de anúncios
    • Pelo menos 8 conexões simultâneas de LE. Cada conexão pode estar em uma das funções de topologia de conexão.
    • Privacidade da camada de enlace LE
    • Uma "lista de resolução" com pelo menos 8 entradas

  Finalizar novos requisitos

• 7.4.9 UWB: adição de uma seção de requisitos para hardware UWB.

  Conferir revisão

  7.4.9. UWB

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

  • [C-1-1] É OBRIGATÓRIO 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-2] É OBRIGATÓRIO garantir que a mediana das medições de distância a 1 m do dispositivo de referência esteja entre [0,75 m, 1,25 m], em que a distância real é medida a partir da borda superior do DUT, segurada com a face para cima e inclinada 45 graus.

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

  Finalizar novos requisitos

• 7.5 Câmeras: atualizações nos requisitos para o recurso de saída HDR de 10 bits.

  Conferir revisão

  Se as implementações do dispositivo oferecem suporte ao recurso de saída HDR de 10 bits, elas:

  • [C-2-1] É PRECISO oferecer suporte a pelo menos o perfil HDR HLG para todos os dispositivos de câmera com saída de 10 bits.
  • [C-2-2] É NECESSÁRIO oferecer suporte à saída de 10 bits para a câmera traseira principal ou frontal principal.
  • [C-SR] É ALTAMENTE RECOMENDADO oferecer suporte à saída de 10 bits para as duas câmeras principais.
  • [C-2-3] PRECISA oferecer suporte aos mesmos perfis HDR para todas as subcâmeras físicas com compatibilidade com BACKWARD_COMPATIBLE de uma câmera lógica e a própria câmera lógica.

  Para dispositivos de câmera lógica com suporte a HDR de 10 bits que implementam a API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, eles:

  • [C-3-1] PRECISA oferecer suporte à alternância entre todas as câmeras físicas com compatibilidade com versões anteriores pelo controle CONTROL_ZOOM_RATIO na câmera lógica.

  Finalizar novos requisitos

• 7.7.2 Modo de host USB: revisões para portas de função dupla.

  Conferir revisão

  Se as implementações do dispositivo incluírem uma porta USB com suporte ao modo de host e ao USB Type-C, elas:

  • [C-4-1] É PRECISO implementar a funcionalidade de porta de função dupla, conforme definido pela especificação USB Type-C (seção 4.5.1.3.3). Para portas de função dupla, em dispositivos que incluem uma entrada de áudio de 3,5 mm, a detecção de USB (modo host) PODE estar desativada por padrão, mas PRECISA ser possível para o usuário ativá-la.

• Classe de desempenho de mídia 7.11: atualizada para incluir o Android T.

  Conferir revisão

  Se as implementações do dispositivo retornarem um valor diferente de zero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

  • [C-1-3] É PRECISO 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 é definida apenas para dispositivos portáteis na versão T, S ou R.

  Finalizar novos requisitos

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

9. Compatibilidade com o modelo de segurança

• 9.1 Permissões: estender caminhos aceitos para listas de permissões de apps pré-instalados para arquivos APEX.

  Conferir revisão

  • [C-0-2] Permissões com um protectionLevel de PROTECTION_FLAG_PRIVILEGED SOMENTE podem ser concedidas a apps pré-instalados nos caminhos privilegiados da imagem do sistema (bem como arquivos APEX) e estar dentro do subconjunto das permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito lendo e respeitando as permissões permitidas de cada app dos arquivos no caminho etc/permissions/ e usando o caminho system/priv-app como o caminho privilegiado.

• 9.7 Recursos de segurança: atualizações nos requisitos de inicialização para manter a integridade do kernel.

  Conferir revisão

  Os recursos de integridade do kernel e de autoproteção são essenciais para a segurança do Android. Implementações de dispositivos:

  • [C-SR] É ALTAMENTE RECOMENDADO ativar a inicialização da pilha no kernel para impedir 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 assumir o valor usado pelo compilador para inicializar os locais.

  Finalizar novos requisitos

• 9.8.7 Privacidade: acesso à área de transferência: limpe automaticamente os dados da área de transferência após 60 minutos após uma atividade de corte/cópia/colagem para proteger a privacidade do usuário.

  Conferir revisão

  Implementações de dispositivos:

  • [C-0-1] NÃO DEVE retornar dados recortados da área de transferência (por exemplo, pela API ClipboardManager), a menos que o app de terceiros seja o IME padrão ou o app em foco no momento.
  • [C-0-2] PRECISA limpar os dados da área de transferência no máximo 60 minutos após a última vez que foram colocados ou lidos de uma área de transferência.

• 9.11 Chaves e credenciais: atualizações nos requisitos da tela de bloqueio segura, incluindo a adição de ECDH e 3DES aos algoritmos criptográficos.

  Conferir revisão

  Quando a implementação do dispositivo oferece suporte a uma tela de bloqueio segura, ela:

  • [C-1-2] É PRECISO ter implementações de RSA, AES, ECDSA, ECDH (se o IKeyMintDevice for aceito), 3DES e algoritmos criptográficos HMAC e funções de hash da família MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos aceitos pelo sistema do Android Keystore em uma área isolada com segurança do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais em que o kernel ou o código do espaço do usuário pode acessar o estado interno do ambiente isolado, incluindo o DMA. O upstream do Android Open Source Project (AOSP) atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.

• 9.11.1 Tela de bloqueio, autenticação e dispositivos virtuais seguros: adição de uma seção de requisitos para dispositivos virtuais e transferências de autenticação.

  Conferir revisão

  Se as implementações do dispositivo 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-3] O usuário PRECISA ser desafiado para um dos métodos de autenticação primários recomendados (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 4 horas ou menos. Quando um token físico atende aos requisitos para implementações do TrustAgent no C-X, as restrições de tempo limite definidas em C-9-5 são aplicadas.

  Se as implementações de dispositivo permitirem que os aplicativos criem telas virtuais secundárias e não oferecerem suporte a eventos de entrada associados, como por meio de VirtualDeviceManager, eles:

  • [C-9-1] É OBRIGATÓRIO bloquear essas telas virtuais secundárias quando a tela padrão do dispositivo estiver bloqueada e desbloqueá-las quando a tela padrão do dispositivo estiver desbloqueada.

  Se as implementações de dispositivo 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] É PRECISO oferecer suporte a estados de bloqueio separados por dispositivo virtual
  • [C-10-2] É OBRIGATÓRIO desconectar todos os dispositivos virtuais após o tempo limite de inatividade
  • [C-10-3] É OBRIGATÓRIO ter um tempo limite de inatividade
  • [C-10-4] É OBRIGATÓRIO bloquear todas as telas quando o usuário iniciar um bloqueio, incluindo através da capacidade de uso do bloqueio do usuário necessária para dispositivos portáteis (consulte a Seção 2.2.5[9.11/H-1-2]).
  • [C-10-5] É OBRIGATÓRIO ter instâncias de dispositivos virtuais separadas por usuário
  • [C-10-6] É OBRIGATÓRIO desativar a criação de eventos de entrada associados por VirtualDeviceManager quando indicado por DevicePolicyManager.setNearbyAppStreamingPolicy
  • [C-10-7] É OBRIGATÓRIO usar uma área de transferência separada apenas para cada dispositivo virtual (ou desativar a área de transferência para dispositivos virtuais)
  • [C-10-11] É PRECISO desativar a interface de usuário de autenticação em dispositivos virtuais, incluindo a entrada de fator de conhecimento e a solicitação biométrica
  • [C-10-12] É PRECISO restringir intents iniciadas de um dispositivo virtual para serem mostradas apenas no mesmo dispositivo virtual.
  • [C-10-13] Não é permitido 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*.

  Quando as implementações de dispositivo permitem que o usuário transfira o fator de conhecimento de autenticação principal de um dispositivo de origem para um 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 documento de políticas de segurança do serviço Google Cloud Key Vault ao transferir o fator de conhecimento do dispositivo de origem para o dispositivo de destino, de modo que o fator de conhecimento não possa ser descriptografado remotamente ou usado para desbloquear remotamente nenhum dos dispositivos.
  • [C-11-2] É OBRIGATÓRIO, 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] Em um dispositivo de destino que não tem um fator de conhecimento de autenticação principal definido, é OBRIGATÓRIO pedir que o usuário confirme um fator de conhecimento transferido no dispositivo de destino antes de definir esse fator de conhecimento como o fator de conhecimento de autenticação principal para o dispositivo de destino e antes de disponibilizar os dados transferidos de um dispositivo de origem.

  Se as implementações do dispositivo 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, eles:

  • [C-12-1] SOMENTE 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 tiver autenticado a identidade nessa tela de bloqueio. Os dispositivos próximos podem usar mecanismos de detecção no pulso ou no corpo após um desbloqueio único do usuário para satisfazer o requisito de autenticação do usuário.
  • [C-12-2] É PRECISO colocar a implementação do dispositivo no estado TrustState.TRUSTABLE quando a tela é desligada (por exemplo, por meio de um botão ou de um tempo limite de exibição) e o TrustAgent não tiver revogado a confiança. O AOSP atende a esse requisito.
  • [C-12-3] SOMENTE mude o dispositivo de TrustState.TRUSTABLE para o estado TrustState.TRUSTED se o TrustAgent ainda estiver concedendo confiança com base nos requisitos em C-12-1.
  • [C-12-4] É OBRIGATÓRIO chamar TrustManagerService.revokeTrust() após, no máximo, 24 horas de concessão de confiança, uma janela de inatividade de 8 horas ou quando a conexão com o dispositivo físico próximo for perdida.

  Se as implementações de dispositivo permitirem que os aplicativos criem telas virtuais secundárias e oferecerem suporte a eventos de entrada associados, como por meio do VirtualDeviceManager, e as telas não forem marcadas com VIRTUAL_DISPLAY_FLAG_SECURE, elas:

  • [C-13-8] É PRECISO bloquear atividades com o atributo android:canDisplayOnRemoteDevices ou os metadados android.activity.can_display_on_remote_devices definidos como falsos de serem iniciados no dispositivo virtual.
  • [C-13-9] É OBRIGATÓRIO impedir que atividades que não ativam explicitamente o streaming e que indicam que mostram conteúdo sensível, incluindo por SurfaceView#setSecure, FLAG_SECURE ou SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, sejam iniciada no dispositivo virtual.
  • [C-13-10] É PRECISO desativar a instalação de apps iniciada em dispositivos virtuais.

  Finalizar novos requisitos

• 9.11.2 Strongbox: a resistência a ataques internos (IAR, na sigla em inglês) é um requisito necessário.

  Conferir revisão

  Para validar a conformidade com [C-1-3] a [C-1-9], as implementações de dispositivos:

  • [C-SR] são ALTAMENTE RECOMENDADOS para oferecer resistência a ataques internos (IAR, na sigla em inglês), o que significa que um insider com acesso às chaves de assinatura do firmware não pode produzir firmware que cause vazamentos de segredos do StrongBox, contorne os requisitos de segurança funcional 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 pelo HAL do IAuthSecret. O IAR se tornará um requisito obrigatório no Android 14.

• 9.11.3 Credencial de identidade: informações adicionadas sobre a implementação de referência do sistema de credenciais de identidade.

  Conferir revisão

  O sistema de credencial de identidade é definido e alcançado pela implementação de todas as APIs no pacote android.security.identity.*. Essas APIs permitem que os desenvolvedores de apps armazenem e extraiam documentos de identidade do usuário. Implementações de dispositivos:

  O projeto upstream do Android Open Source oferece uma implementação de referência de um aplicativo confiável (libeic) que pode ser usado para implementar o sistema de credenciais de identidade.

  Finalizar novos requisitos

• 9.11.4 Atestado de identidade: adicionamos uma seção para o requisito de atestado de identidade.

  Conferir revisão

  9.11.4. Atestado de identidade

  As implementações de dispositivos precisam oferecer suporte ao atestado de código do dispositivo.

  Finalizar novos requisitos

• Framework de virtualização do Android 9.17: adicionamos uma seção de requisitos para o Framework de virtualização do Android.

  Conferir revisão

  9.17. Framework de virtualização do Android

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), o host do Android:

  • [C-1-1] PRECISA oferecer suporte a todas as APIs definidas pelo pacote android.system.virtualmachine.*.
  • [C-1-2] NÃO é permitido modificar o SELinux do Android e o modelo de permissão para o gerenciamento de máquinas virtuais protegidas.
  • [C-1-3] NÃO é permitido modificar, omitir ou substituir as regras de neverallow presentes no system/sepolicy fornecido no upstream do Android Open Source Project (AOSP), e a política PRECISA ser compilada com todas as regras de neverallow presentes.
  • [C-1-4] NÃO É PERMITIDO que códigos não confiáveis (por exemplo, apps de terceiros) criem e executem uma máquina virtual protegida. Observação: isso pode mudar em versões futuras do Android.
  • [C-1-5] NÃO é permitido que uma máquina virtual protegida execute código que não faça parte da imagem de fábrica ou das atualizações dela. Qualquer coisa que não seja coberta pela Inicialização verificada do Android (por exemplo, arquivos transferidos por sideload ou baixados da Internet) NÃO PODE ser executada em uma máquina virtual protegida.

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), qualquer instância de máquina virtual protegida:

  • [C-2-1] É PRECISO executar todos os sistemas operacionais disponíveis no APEX de virtualização em uma máquina virtual protegida.
  • [C-2-2] NÃO é permitido que uma máquina virtual protegida execute um sistema operacional que não seja assinado pelo implementador do dispositivo ou pelo fornecedor do SO.
  • [C-2-3] NÃO é permitido que uma máquina virtual protegida execute dados como código (por exemplo, SELinux neverallow execmem).
  • [C-2-4] NÃO É PERMITIDO modificar, omitir ou substituir as regras de neverallow presentes no system/sepolicy/microdroid fornecido no upstream do Android Open Source Project (AOSP).
  • [C-2-5] É PRECISO implementar mecanismos de defesa em profundidade de máquinas virtuais protegidas (por exemplo, SELinux para pVMs), mesmo para sistemas operacionais que não sejam o Microdroid.
  • [C-2-6] É PRECISO garantir que o firmware da pVM se recuse a inicializar se não for possível verificar a imagem inicial.
  • [C-2-7] É OBRIGATÓRIO garantir que o firmware da pVM se recuse a inicializar se a integridade do instance.img for comprometida.

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android (android.system.virtualmachine.*), o hipervisor:

  • [C-3-1] NÃO É PERMITIDO que nenhuma pVM tenha acesso a uma página pertencente a outra entidade (ou seja, outra pVM ou hipervisor), a menos que seja explicitamente compartilhada pelo proprietário da página. Isso inclui a VM do host. Isso se aplica aos acessos de CPU e DMA.
  • [C-3-2] É PRECISO limpar uma página depois que ela é usada por uma VM e antes de ser devolvida ao host (por exemplo, a pVM é destruída).
  • [C-3-3] É PRECISO garantir que o firmware da pVM seja carregado e executado antes de qualquer código em uma pVM.
  • [C-3-4] É PRECISO garantir que as BCCs e as CDIs fornecidas a uma instância de pVM só possam ser derivadas por essa instância específica.

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android, em todas as áreas:

  • [C-4-1] NÃO é permitido fornecer funcionalidade a uma pVM que permita contornar o modelo de segurança do Android.

  Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, faça o seguinte:

  • [C-5-1] É PRECISO oferecer suporte à compilação isolada de uma atualização do ambiente de execução do ART.

  Se o dispositivo implementar suporte às APIs do Framework de virtualização do Android e ao gerenciamento de chaves:

  • [C-6-1] É PRECISO enraizar a cadeia do DICE em um ponto que o usuário não possa modificar, mesmo em dispositivos desbloqueados. (Para garantir que não possa ser falsificado).
  • [C-6-2] É OBRIGATÓRIO fazer o teste de diagnóstico de desempenho de e-commerce (DICE) corretamente, ou seja, fornecer os valores corretos. Mas talvez não seja necessário chegar a esse nível de detalhes.

  Finalizar novos requisitos

13. Entre em contato

Você pode participar do fórum de compatibilidade com o Android e pedir esclarecimentos ou mencionar problemas que você acha que o documento não aborda.