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 "PRECISA", "NÃO PODE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVE", "DEVE", "NÃO DEVE", "RECOMENDADO", "PODE" e "OPCIONAL" está de acordo com o padrão IETF definido em 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 assim 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 são silenciosos, ambíguos ou incompletos, é responsabilidade do implementador do dispositivo garantir a compatibilidade com as implementações atuais.

Por esse motivo, o Android Open Source Project é a referência e a implementação preferida do Android. É RECOMENDADO OS implementadores de dispositivos para basear as implementações na maior extensão possível no código-fonte "upstream" disponível no Android Open Source Project. Embora alguns componentes possam ser substituídos por implementações alternativas, é FORTEMENTE RECOMENDADO não seguir essa prática, já que a aprovação nos testes de software se tornará muito mais difícil. É responsabilidade do implementador garantir compatibilidade comportamental total com a implementação padrão do Android, incluindo e além do Teste de Compatibilidade do Android. Por fim, observe que certas 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 serão funcionalmente idênticos às informações na documentação desse SDK. Nos casos em que essa Definição de Compatibilidade ou o Conjunto de Teste de Compatibilidade discordar da documentação do SDK, a documentação do SDK será considerada autoritativa. Todos os detalhes técnicos fornecidos nos recursos vinculados ao longo deste documento são considerados para inclusão como parte da 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 mencionados como "Requisitos principais" neste documento.

1.1.2. ID do requisito

O ID do requisito é atribuído para os requisitos OBRIGATÓRIOS.

• O ID é atribuído apenas para os requisitos OBRIGATÓRIOS.
• Os requisitos FORTEMENTE RECOMENDADOS são marcados como [SR], mas o ID não foi 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 conforme abaixo:

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

1.1.3 ID do requisito na seção 2

Os IDs de requisitos 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 formato e o requisito específico dele.

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

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

2. Tipos de dispositivo

O Android Open Source Project fornece uma pilha de software que pode ser usada para vários tipos de dispositivos e formatos. Para oferecer suporte à segurança nos dispositivos, a pilha de software, incluindo qualquer SO substituto ou uma implementação alternativa de kernel, precisa ser executada em um ambiente seguro, conforme descrito na seção 9 e em outras partes deste CDD. Existem 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 tipo de dispositivo.

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 ver as principais diferenças na configuração de hardware por tipo de dispositivo, consulte os requisitos específicos do dispositivo a seguir nesta seção.

2.2. Requisitos para dispositivos portáteis

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

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

• usar uma fonte de energia que ofereça mobilidade, como uma bateria;
• Ter uma tela diagonal física no intervalo de 3,3 polegadas (ou 2,5 polegadas para implementações de dispositivos enviadas no nível de API 29 ou anterior) a 8 polegadas.

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

Observação:os requisitos que não se aplicam a Tablets Android são marcados com um *.

2.2.1. Hardware

Implementações de dispositivos portáteis:

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

• [7.1.1.3/H-SR-1] são RECOMENDADOS PARA oferecer aos usuários uma affordance para mudar o tamanho de exibição (densidade da tela).

• A [7.1.1.1/H-0-2] PRECISA oferecer suporte à composição de GPU de buffers gráficos com capacidade de, no mínimo, a resolução mais alta de qualquer tela integrada.

Se as implementações de dispositivos portáteis permitirem a rotação da tela de software, elas:

• [7.1.1.1/H-1-1]* PRECISA disponibilizar a tela lógica para aplicativos de terceiros com pelo menos 2 polegadas nas bordas curtas e 2,7 polegadas nas bordas maiores. Os dispositivos que foram enviados com uma API do Android de nível 29 ou anterior podem ser isentos desse requisito.

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

• [7.1.1.1/H-2-1]* PRECISA fazer com que a tela lógica disponibilizada para aplicativos de terceiros tenha pelo menos 2,7 polegadas nas bordas curtas. Os dispositivos que foram enviados com uma API do Android de nível 29 ou anterior 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] PRECISA anunciar o 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] PRECISA informar se o dispositivo oferece suporte ao recurso de criação de perfil da GPU usando uma propriedade do sistema graphics.gpu.profiler.support.

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

• [7.1.4.6/H-1-1] PRECISA relatar como saída um rastro protobuf que esteja em conformidade com o esquema de contadores de GPU e de estágios de renderização de GPU definidos na documentação do Perfetto (links em inglês).
• [7.1.4.6/H-1-2] PRECISA informar valores em conformidade para os contadores de GPU do dispositivo seguindo o proto do pacote de rastreamento de GPU.
• [7.1.4.6/H-1-3] PRECISA informar valores em conformidade para os RenderStages da GPU do dispositivo após o proto do pacote de rastreamento do estágio de renderização.
• [7.1.4.6/H-1-4] PRECISA informar um tracepoint de frequência de GPU, conforme especificado pelo formato: power/gpu_frequency.

Implementações de dispositivos portáteis:

• [7.1.5/H-0-1] PRECISA incluir suporte ao modo de compatibilidade de aplicativo legado, conforme implementado pelo código-fonte aberto do Android. Ou seja, as implementações de dispositivos NÃO PODEM mudar os gatilhos ou limites em que o modo de compatibilidade é ativado nem o comportamento do próprio modo de compatibilidade.
• [7.2.1/H-0-1] PRECISA incluir suporte a aplicativos editor de método de entrada (IME, na sigla em inglês) de terceiros.
• [7.2.3/H-0-2] PRECISA enviar os eventos 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, teclado de hardware externo conectado ao dispositivo Android).
• [7.2.3/H-0-3] PRECISA fornecer a função "Home" em todas as telas compatíveis com Android que fornecem a tela inicial.
• [7.2.3/H-0-4] PRECISA 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.
• [7.2.4/H-0-1] PRECISA oferecer suporte à entrada touchscreen.
• [7.2.4/H-SR-1] É RECOMENDADO PARA iniciar o app assistivo selecionado pelo usuário, em outras palavras, o app que implementa VoiceInteractionService ou uma atividade que processa o ACTION_ASSIST ao tocar e manter pressionado KEYCODE_MEDIA_PLAY_PAUSE ou KEYCODE_HEADSETHOOK se a atividade em primeiro plano não processar esses eventos de tocar e manter pressionado.
• [7.3.1/H-SR-1] É MUITO RECOMENDADO a inclusão de um acelerômetro de três eixos.

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

• [7.3.1/H-1-1] PRECISA relatar eventos com até uma frequência de pelo menos 100 Hz.

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

• [7.3.3/H-2-1] PRECISA informar as medições de GNSS assim que elas forem encontradas, mesmo que uma localização calculada com o GPS/GNSS ainda não tenha sido informada.
• [7.3.3/H-2-2] PRECISA informar as pseudodistâncias e taxas de GNSS, que, em condições de céu aberto após determinar a localização, enquanto a posição fixa ou em movimento com menos de 0,2 metro por segundo ao quadrado de aceleração, são suficientes para calcular uma posição dentro de 20 metros e velocidade dentro de 0,2 metros por segundo, no mínimo 0,2 metros por segundo.

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

• [7.3.4/H-3-1] PRECISA relatar eventos com até uma frequência de pelo menos 100 Hz.
• [7.3.4/H-3-2] PRECISA ser capaz de medir mudanças de orientação 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] DEVEM incluir um sensor de proximidade.

Implementações de dispositivos portáteis:

• [7.3.11/H-SR-1] É RECOMENDADO para 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 Wi-Fi Neighbor Awareness Networking (NAN) declarando PackageManager.FEATURE_WIFI_AWARE e Local Wi-Fi (Tempo de retorno do Wi-Fi — RTT) ao declarar PackageManager.FEATURE_WIFI_RTT:

• O valor de

• [7.4.2.5/H-SR-1] São RECOMENDADOS muito para informar com precisão o intervalo a +/-1 metro a +/-1 metro a 160 MHz de largura de banda de 160 MHz no 90o percentil (calculado com a Função de distribuição cumulativa), +/-2 metros a 80 MHz#de largura de banda no 90o percentil/-4 metros na largura de banda do 90o percentil/0, +/-4 metros na largura de banda de +/-9 a 90%, +/-9 a 90% a 90%.

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

Se as implementações de dispositivos portáteis incluírem um dispositivo de câmera lógico que liste 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, na sigla em inglês) normal por padrão e PRECISA estar entre 50 e 95 graus.

Implementações de dispositivos portáteis:

• [7.6.1/H-0-1] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados particulares do aplicativo, também 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 compatibilidade somente com ABI de 32 bits:

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

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

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

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

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

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

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

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

• [7.6.1/H-8-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.824 MB se a tela padrão usar resoluções de framebuffer 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 incluírem 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] PRECISA declarar a flag de recurso android.hardware.ram.low.
• [7.6.1/H-9-2] PRECISA ter pelo menos 1,1 GB de armazenamento não volátil para dados privados do aplicativo (também conhecido 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] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados particulares do aplicativo (também conhecido 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 ou menos 2 GB e menos de 4 GB de memória disponíveis para o kernel e o espaço do usuário, elas:

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

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

Implementações de dispositivos portáteis:

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

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

• [7.9.1/H-1-1] PRECISA declarar a flag de recurso android.hardware.vr.high_performance.
• [7.9.1/H-1-2] PRECISA incluir um aplicativo que implemente android.service.vr.VrListenerService, que pode ser ativado por aplicativos de RV via android.app.Activity#setVrModeEnabled.

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

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

Função	Mapeamentos	O contexto	Comportamento
R	Página de uso do HID: 0x0C Uso do HID: 0x0CD Chave do kernel: KEY_PLAYPAUSE Chave do Android: KEYCODE_MEDIA_PLAY_PAUSE	Reprodução de mídia	Entrada: pressione rapidamente Saída: toque ou pause
			Entrada: toque e mantenha pressionado Saída: inicia um comando de voz Envia: android.speech.action.VOICE_SEARCH_HANDS_FREE se o dispositivo estiver bloqueado ou a tela estiver desligada. Caso contrário, envia android.speech.RecognizerIntent.ACTION_WEB_SEARCH
		Alguém está ligando	Entrada: pressionamento curto Saída: aceitar chamada
			Entrada: tocar e manter pressionado Saída: rejeitar a chamada
		Chamada em andamento	Entrada: pressione rapidamente Saída: encerrar a chamada
			Entrada: tocar e manter pressionado Saída: ativar ou desativar o som do microfone
B	Página de uso do HID: 0x0C Uso do HID: 0x0E9 Chave do kernel: KEY_VOLUMEUP Chave do Android: VOLUME_UP	Reprodução de mídia, ligação em andamento	Entrada: toque curto ou longo. Saída: aumenta o volume do sistema ou do fone de ouvido
C	Página de uso do HID: 0x0C Uso de HID: 0x0EA Chave do kernel: KEY_VOLUMEDOWN Chave do Android: VOLUME_DOWN	Reprodução de mídia, ligação em andamento	Entrada: toque curto ou longo. Saída: diminui o volume do sistema ou do fone de ouvido
D	Página de uso do HID: 0x0C Uso do HID: 0x0CF Chave do kernel: KEY_VOICECOMMAND Chave do Android: KEYCODE_VOICE_ASSIST	Todas. Pode ser acionado em qualquer instância.	Entrada: toque curto ou longo. Saída: inicia o comando de voz.

• [7.8.2.2/H-1-2] PRECISA acionar ACTION_HEADSET_PLUG em uma inserção de plugue, mas somente depois que as interfaces de áudio USB e os endpoints forem enumerados corretamente para identificar o tipo de terminal conectado.

Quando o terminal de áudio USB do tipo 0x0302 é detectado, ele:

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

Quando o terminal de áudio USB do tipo 0x0402 é detectado, ele:

• [7.8.2.2/H-3-1] PRECISA 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, eles:

• [7.8.2.2/H-4-1] PRECISA 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] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_HEADSET e role isSink() se o campo de tipo do terminal de áudio USB for 0x0402.

• [7.8.2.2/H-4-3] PRECISA 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] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e a função isSink() se o campo de tipo de terminal de áudio USB for 0x603.

• [7.8.2.2/H-4-5] PRECISA 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] PRECISA 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] PRECISA 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] São RECOMENDADOS FORTEMENTE após a conexão de um periférico de áudio USB-C para 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] PRECISA ter uma latência média contínua de ida e volta de 500 milissegundos ou menos acima de cinco medições, com desvio absoluto médio menor que 50 ms, nos seguintes caminhos de dados: "alto-falante para microfone", adaptador de loopback de 3,5 mm (se compatível) e loopback USB (se compatível).

• [5.6/H-1-2] PRECISA ter uma latência média do Toque a tom de 500 milissegundos ou menos em pelo menos cinco medições do alto-falante para o caminho de dados do microfone.

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

• [7,10/H]* NÃO DEVE usar um atuador tátil (vibrador) de massa giratória excêntrica (ERM).
• [7,10/H]* DEVE posicionar o posicionamento do 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 retorno tátil claro em android.view.HapticFeedbackConstants, ou seja, (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_START, KEY_PRESS, TEXT_HAND_VILEASE_MOV, KEY_PRESS, TEXT_HAND_VILE
• PRIMITIVE_* Algumas dessas primitivas, como LOW_TICK e SPIN, só serão viáveis se a vibração for compatível com frequências relativamente baixas.

• [7.10/H]* DEVE seguir as orientações de mapeamento de constantes públicas em android.view.HapticFeedbackConstants para as constantes android.os.VibrationEffect recomendadas, 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 da vibração.

Um atuador ressonante linear (LRA, na sigla em inglês) é um sistema de mola de massa única que tem uma frequência ressonante 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 ressonante linear, elas:

• [7,10/H]* DEVE mover o atuador tátil no eixo X (esquerda-direita) na orientação retrato.

Se as implementações de dispositivos portáteis tiverem um atuador tátil, que é o atuador ressonante linear (LRA, na sigla em inglês) do eixo X, elas:

• [7,10/H]* DEVE ter a frequência ressonante da LRA do eixo X abaixo de 200 Hz.

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

• [7.10/H]* DEVE verificar o status da implementação executando as APIs android.os.Vibrator.areAllEffectssupported() e android.os.Vibrator.arePrimitivessupported().

• [7,10/H]* DEVE fazer uma avaliação de qualidade para constantes de retorno tátil.

• [7.10/H]* DEVE verificar e atualizar, se necessário, a configuração substituta para primitivos não compatíveis, conforme descrito na orientação de implementação para constantes.

2.2.2. Multimídia

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

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

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] PRECISA 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 funcionalidade para acessar os dados do provedor de documentos usando a API DocumentsProvider.
• [3.2.3.1/H-0-2]* PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intent pública definidos pelos intents de aplicativo listados aqui.
• [3.2.3.1/H-SR-1] São FORTEMENTE RECOMENDADOS para pré-carregar um aplicativo de e-mail que pode processar as intents ACTION_SENDTO, ACTION_SEND ou ACTION_SEND_MULTIPLE para enviar um e-mail.
• [3.4.1/H-0-1] PRECISA fornecer uma implementação completa da API android.webkit.Webview.
• [3.4.2/H-0-1] PRECISA incluir um aplicativo de navegador autônomo para a navegação na Web de usuários gerais.
• [3.8.1/H-SR-1] São RECOMENDADOS muito para implementar uma tela de início padrão com suporte à fixação de atalhos, widgets e widgetFeatures no app.
• [3.8.1/H-SR-2] É RECOMENDADO muito a implementação de uma tela de início padrão que oferece acesso rápido a outros atalhos fornecidos por apps de terceiros pela API AtalhoManager.
• [3.8.1/H-SR-3] É FORTEMENTE RECOMENDADO incluir um app de tela de início padrão que mostre selos para os ícones do app.
• [3.8.2/H-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte a widgets de apps de terceiros.
• [3.8.3/H-0-1] PRECISA permitir que apps de terceiros notifiquem os usuários sobre eventos importantes usando as classes de API Notification e NotificationManager.
• [3.8.3/H-0-2] PRECISA oferecer suporte a notificações avançadas.
• [3.8.3/H-0-3] PRECISA oferecer suporte a notificações de alerta.
• [3.8.3/H-0-4] PRECISA incluir uma aba de notificações, oferecendo ao usuário a capacidade de controlar diretamente (por exemplo, responder, adiar, dispensar, bloquear) as notificações usando recursos do usuário, como botões de ação ou o painel de controle, conforme implementado no AOSP.
• [3.8.3/H-0-5] PRECISA mostrar as opções fornecidas por RemoteInput.Builder setChoices() na aba de notificações.
• [3.8.3/H-SR-1] É FORTEMENTE RECOMENDADO para mostrar a primeira opção fornecida usando RemoteInput.Builder setChoices() na aba de notificações sem precisar de outras interações do usuário.
• [3.8.3/H-SR-2] É RECOMENDADO PARA mostrar todas as opções fornecidas pelo RemoteInput.Builder setChoices() na aba de notificações quando o usuário abre todas as notificações na aba.
• [3.8.3.1/H-SR-1] É RECOMENDADO PARA mostrar ações em que Notification.Action.Builder.setContextual está definido como true alinhado às respostas exibidas por Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] É FORTEMENTE RECOMENDADO para implementar um assistente no dispositivo para processar a Ação de assistência.

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

• [3.8.3.1/H-SR-2] São RECOMENDADOS ALTAMENTE para fornecer uma funcionalidade do usuário (por exemplo, seletor de saída) acessada pela interface do sistema que permite alternar entre rotas de mídia adequadas disponíveis (por exemplo, dispositivos Bluetooth e rotas fornecidas para MediaRouter2Manager) quando um app posta uma notificação MediaStyle com um token MediaSession.

Se as implementações de dispositivos portáteis forem compatíveis com a ação de assistência, elas:

• [3.8.4/H-SR-2] É RECOMENDADO que você use a tecla HOME e a mantenha pressionada como a interação designada para iniciar o app assistivo, conforme descrito na seção 7.2.3. PRECISA iniciar o app assistivo selecionado pelo usuário. Em outras palavras, 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 das notificações de alerta e silenciosas sem conversa, elas:

• [3.8.4/H-1-1]* PRECISA mostrar notificações de conversa antes das notificações que não são de conversa, com exceção das notificações de serviço em primeiro plano em andamento e 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] PRECISA mostrar as notificações da tela de bloqueio, incluindo o modelo de notificação de mídia.

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

• [3.9/H-1-1] PRECISA 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 às APIs ControlsProviderService e Control e permitirem que apps de terceiros publiquem controles de dispositivos, elas:

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

• [3.8.16/H-1-4] PRECISA renderizar com precisão nessa funcionalidade de usuário o nome e o ícone de cada app de terceiros que fornece controles por meio da API ControlsProviderService, bem como todos os campos especificados fornecidos pelas APIs Control.

• [3.8.16/H-1-5] PRECISA oferecer uma opção de usuário para desativar os controles de dispositivo autenticados 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 implementam esses controles, elas:

• [3.8.16/H-2-1] PRECISA informar null para as APIs ControlsProviderService e Control.
• [3.8.16/H-2-2] PRECISA 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] PRECISA apresentar uma confirmação ao usuário de que os dados foram copiados para a área de transferência (por exemplo, uma miniatura ou 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 os dispositivos.

Implementações de dispositivos portáteis:

• [3.10/H-0-1] PRECISA oferecer suporte a serviços de acessibilidade de terceiros.
• [3.10/H-SR-1] É FORTEMENTE RECOMENDADO para pré-carregar serviços de acessibilidade no dispositivo comparável ou exceder a funcionalidade do acesso com interruptor e do TalkBack (para idiomas compatíveis com o mecanismo de conversão de texto em voz pré-instalado), conforme fornecido no projeto de código aberto de TalkBack.
• [3.11/H-0-1] PRECISA oferecer suporte à instalação de mecanismos TTS de terceiros.
• [3.11/H-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um mecanismo TTS com suporte aos idiomas disponíveis no dispositivo.
• [3.13/H-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um componente de interface para Configurações rápidas.

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

• [3.16/H-1-1] PRECISA oferecer suporte ao recurso de pareamento do dispositivo complementar.

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

• [7.2.3/H] A zona de reconhecimento de gestos para a função inicial não pode ter mais de 32 dp de altura em relação à parte de baixo da tela.

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

• [7.2.3/H-0-1] A área de gestos 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 forem compatíveis com 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] PRECISA declarar o suporte de perfis gerenciados usando a flag de recurso android.software.managed_users.

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

• [7.5.4/H-1-1] PRECISA respeitar as intents 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] PRECISA respeitar a intent android.media.action.VIDEO_CAMERA para iniciar a câmera no modo de vídeo, conforme descrito no SDK.

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

• [3.2.3.1/ H-1-1] PRECISA ter uma atividade que processe a intent Settings#ACTION_CONFIG_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 iniciar a atividade da intent analisada em Settings#EXTRA_CONFIG_EMBEDDED_DEEP_LINK_INTENT_URI.

2.2.4 Desempenho e potência

• [8.1/H-0-1] Latência de frame consistente. A latência de frame inconsistente ou um atraso na renderização de frames NÃO PODEM ocorrer com mais frequência do que cinco quadros por segundo e DEVEM estar abaixo de 1 quadros por segundo.
• [8.1/H-0-2] Latência da interface do usuário. As implementações de dispositivos PRECISAM garantir uma experiência do usuário de baixa latência rolando uma lista de 10 mil entradas na lista, conforme definido pelo Conjunto de Teste de Compatibilidade do Android (CTS) em menos de 36 segundos.
• [8.1/H-0-3] Troca de tarefas. Quando vários aplicativos já foram iniciados, a reinicialização de um aplicativo já 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] PRECISA garantir um desempenho de gravação sequencial de pelo menos 5 MB/s.
• [8.2/H-0-2] PRECISA garantir um desempenho de gravação aleatória de pelo menos 0,5 MB/s.
• [8.2/H-0-3] PRECISA garantir um desempenho de leitura sequencial de pelo menos 15 MB/s.
• [8.2/H-0-4] PRECISA 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 incluídos no AOSP ou ampliar os recursos incluídos no AOSP, elas:

• [8.3/H-1-1] PRECISA fornecer funcionalidade do usuário para ativar e desativar o recurso de economia de bateria.
• [8.3/H-1-2] PRECISA oferecer recursos ao usuário para mostrar todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".

Implementações de dispositivos portáteis:

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

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

• [8.4/H-1-1] PRECISA respeitar a intent android.intent.action.POWER_USAGE_SUMMARY e exibir um menu de configurações que mostre esse uso da energia.

Implementações de dispositivos portáteis:

• [8.5/H-0-1] PRECISA fornecer funcionalidade de usuário no menu "Configurações" com a capacidade de interromper um app que esteja executando um serviço em primeiro plano e mostrar todos os apps que têm serviços ativos em primeiro plano e a duração de cada um desses serviços desde o início, conforme descrito no documento do SDK.
  • Alguns apps podem estar isentos de serem interrompidos ou listados em uma funcionalidade 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] PRECISA permitir que apps de terceiros acessem as estatísticas de uso pela permissão android.permission.PACKAGE_USAGE_STATS e fornecer um mecanismo acessível ao usuário para conceder ou revogar o acesso a esses apps em resposta à intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implementações de dispositivos portáteis:

• [9.11/H-0-2] PRECISA fazer backup da implementação de keystore com um ambiente de execução isolado.
• [9.11/H-0-3] PRECISA ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash das famílias MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos com suporte do sistema Android Keystore em uma área isolada com segurança do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o código do kernel ou do espaço do usuário possa acessar o estado interno do ambiente isolado, incluindo a DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura analisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
• [9.11/H-0-4] PRECISA executar 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 maneira a permitir que apenas o ambiente de execução isolado execute a autenticação na tela de bloqueio. O Android Open Source Project fornece a Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
• [9.11/H-0-5] PRECISA oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executada em um hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas entre um número grande de dispositivos para evitar que elas sejam usadas como identificadores de dispositivos. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidas. Se mais de 100 mil unidades de uma SKU forem produzidas, uma chave diferente poderá ser usada para cada 100 mil unidades.
• [9/H-0-1] PRECISA declarar o recurso "android.hardware.security.model.compatível".

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior do Android, esse dispositivo estará isento da exigência de ter um keystore apoiado por um ambiente de execução isolado e oferecer suporte ao atestado de chaves, 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 são compatíveis com uma tela de bloqueio segura, elas:

• [9.11/H-1-1] PRECISA permitir que o usuário escolha o menor tempo limite de suspensão, ou seja, um tempo de transição do estado desbloqueado para o bloqueado, de 15 segundos ou menos.
• [9.11/H-1-2] PRECISA fornecer funcionalidade ao usuário para ocultar notificações e desativar todas as formas de autenticação, exceto a autenticação principal descrita em 9.11.1 Tela de bloqueio segura. O AOSP atende ao requisito de modo de bloqueio total.

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

• [9.5/H-2-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem 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 É PRECISO oferecer suporte a perfis restritos, mas PRECISA estar alinhado à implementação de controles do AOSP para permitir /desativar o acesso de outros usuários a chamadas de voz e SMS.

O Android, com a API do sistema VoiceInteractionService, oferece suporte a um mecanismo para detecção de hotword segura sempre ativada sem indicação de acesso ao microfone

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

• [9.8/H-1-1] PRECISA garantir que o serviço de detecção de hotword só possa transmitir dados para o System ou o ContentCaptureService
• [9.8/H-1-2] PRECISA garantir que o serviço de detecção de hotword só possa transmitir dados de áudio do microfone ou derivados para o servidor do sistema pela API HotwordDetectionService ou para ContentCaptureService pela API ContentCaptureManager.
• [9.8/H-1-3] NÃO PODE fornecer áudio de microfone com mais de 30 segundos para uma solicitação individual acionada por hardware ao serviço de detecção de hotword.
• [9.8/H-1-4] NÃO PODE fornecer áudio de microfone em buffer com mais de oito segundos para uma solicitação individual ao serviço de detecção de hotword.
• [9.8/H-1-5] NÃO PODE fornecer áudio de microfone em buffer com mais de 30 segundos ao serviço de interação por voz ou entidade semelhante.
• [9.8/H-1-6] NÃO PODE permitir que mais de 100 bytes de dados que não sejam de áudio sejam transmitidos do serviço de detecção de hotword em cada resultado de hotword bem-sucedido.
• [9.8/H-1-7] NÃO PODE permitir que mais de 5 bits de dados sejam transmitidos do serviço de detecção de hotword em cada resultado negativo de hotword.
• [9.8/H-1-8] PRECISA permitir apenas a transmissão de dados do serviço de detecção de hotword em uma solicitação de validação de hotword do servidor do sistema.
• [9.8/H-1-9] NÃO PODE permitir que um aplicativo instalável pelo usuário forneça o serviço de detecção de hotword.
• [9.8/H-1-10] NÃO PODE aparecer na interface do usuário dados quantitativos sobre o uso do microfone pelo serviço de detecção de hotword.
• [9.8/H-1-11] PRECISA registrar o número de bytes incluídos em cada transmissão do serviço de detecção de hotword para permitir a inspeção para pesquisadores de segurança.
• [9.8/H-1-12] PRECISA 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 hotword para permitir a inspeção para pesquisadores de segurança.
• [9.8/H-1-14] PRECISA exibir o indicador de microfone, conforme descrito na seção 9.8.2, quando um resultado de hotword bem-sucedido é transmitido para o serviço de interação por voz ou entidade semelhante.
• [9.8/H-SR-1] É FORTEMENTE RECOMENDADO que você notifique os usuários antes de definir um aplicativo como o provedor do serviço de detecção de hotwords.
• [9.8/H-SR-2] É FORTEMENTE RECOMENDADO para proibir a transmissão de dados não estruturados para fora do serviço de detecção de hotwords.
• [9.8/H-SR-3] É RECOMENDADO ALTAMENTE para reiniciar o processo que hospeda o serviço de detecção de hotwords pelo menos uma vez a cada hora ou a cada 30 eventos de acionamento de hardware, o que ocorrer primeiro.

Se as implementações do dispositivo incluem um aplicativo que usa a API System HotwordDetectionService ou um mecanismo semelhante para detecção de hotword sem indicação de uso do microfone, o aplicativo:

• [9.8/H-2-1] PRECISA fornecer aviso explícito ao usuário para cada frase de hotword compatível.
• [9.8/H-2-2] NÃO PODE preservar dados brutos de áudio ou dados derivados deles por meio do serviço de detecção de hotword.
• [9.8/H-2-3] NÃO PODE transmitir do serviço de detecção de hotword, dados de áudio, dados que podem ser usados para reconstruir (total ou parcialmente) o áudio ou conteúdos de áudio não relacionados à própria hotword, exceto para ContentCaptureService.

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

• [9.8.2/H-4-1] PRECISA exibir o indicador de microfone quando um app estiver acessando dados de áudio pelo microfone, mas não quando o microfone é acessado somente por HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService ou por apps com as funções mencionadas na seção 9.1 com o identificador CDD [C-4-X].
• [9.8.2/H-4-2] PRECISA mostrar a lista de apps recentes e ativos usando o microfone como retornado de PermissionManager.getIndicatorAppOpUsageData(), além de todas 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] PRECISA exibir o indicador da câmera quando um app estiver acessando dados da câmera em tempo real, mas não quando a câmera só estiver sendo acessada por apps que detêm os papéis mencionados na seção 9.1 com o identificador CDD [C-4-X].
• [9.8.2/H-5-2] PRECISA mostrar apps recentes e ativos usando a câmera como retornada de PermissionManager.getIndicatorAppOpUsageData(), com todas as mensagens de atribuição associadas a eles.

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

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

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

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

• Perfetto (link em inglês)
  • [6.1/H-0-2]* PRECISA expor um binário /system/bin/perfetto ao usuário do shell, que o cmdline está em conformidade com a documentação do perfetto (link em inglês).
  • [6.1/H-0-3]* O binário do perfetto PRECISA aceitar como entrada uma configuração protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (links em inglês).
  • [6.1/H-0-4]* O binário do perfetto PRECISA gravar como saída um trace protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (links em inglês).
  • [6.1/H-0-5]* PRECISA fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto (links em inglês).
  • [6.1/H-0-6]* O daemon rastreado do perfetto PRECISA estar 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:

• PRECISA 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] PRECISA 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] PRECISA oferecer suporte a seis instâncias de sessões de decodificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recentes) em qualquer combinação de codecs executada simultaneamente com resolução de 1080p a 30 fps.
• [5.1/H-1-3] PRECISA anunciar o número máximo de sessões do 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] PRECISA oferecer suporte a seis instâncias de sessões de codificador de vídeo em hardware (AVC, HEVC, VP9, AV1 ou mais recentes) em qualquer combinação de codecs executada simultaneamente com resolução de 1080p a 30 fps.
• [5.1/H-1-5] PRECISA anunciar o número máximo de sessões de codificadores e decodificadores de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codecs por meio dos métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] PRECISA oferecer suporte a seis instâncias de codificadores de vídeo de hardware e sessões de codificadores de vídeo em hardware (AVC, HEVC, VP9, AV1 ou mais recentes) em qualquer combinação de codecs executada simultaneamente a uma resolução de 1080p a 30 fps.
• [5.1/H-1-7] PRECISA 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 simultânea de transcodificação somente vídeo de 1080p a 720p usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo em 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] PRECISA ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de codificação de áudio com taxa de bits de 128 kbps ou menor para todos os codificadores de áudio quando estiver sob carga. O carregamento é definido como uma sessão simultânea de transcodificação de vídeo somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização de gravação de áudio e vídeo em 1080p.
• [5.1/H-1-9] PRECISA oferecer suporte a duas instâncias de sessões de decodificador de vídeo em hardware seguro (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codecs executada simultaneamente com resolução de 1080p a 30 fps.
• [5.1/H-1-10] PRECISA oferecer suporte a três instâncias de sessões de decodificador de vídeo de hardware não 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 codecs executada simultaneamente a uma resolução de 1080p a 30 fps.
• [5.1/ H-1-11] PRECISA oferecer suporte a um decodificador seguro para cada decodificador de hardware AVC, HEVC, VP9 ou AV1 no dispositivo.
• [5.1/H-1-12] PRECISA 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 em hardware quando sob carga. O carregamento é definido como uma sessão simultânea de transcodificação somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware com a inicialização de reprodução de áudio e vídeo em 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] PRECISA ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de decodificação de áudio com taxa de bits de 128 kbps ou menor para todos os decodificadores de áudio quando estiver sob carga. O carregamento é definido como uma sessão simultânea de transcodificação de vídeo somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização de reprodução de áudio e vídeo de 1080p.
• [5.1/H-1-14] PRECISA ser compatível com o decodificador de hardware AV1 Main 10, Level 4.1.
• [5.1/H-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte a FilmGrain para decodificador de hardware AV1.
• [5.1/H-1-15] PRECISA ter pelo menos um decodificador de vídeo por hardware compatível com 4K60.
• [5.1/H-1-16] PRECISA ter pelo menos um codificador de vídeo de hardware compatível com 4K60.
• [5.3/H-1-1] NÃO PODE cair 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 a 60 fps sob carga. O carregamento é definido como uma sessão simultânea de transcodificação de vídeo somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware e uma reprodução de áudio AAC de 128 kbps.
• [5.3/H-1-2] NÃO PODE cair mais de 1 frame em 10 segundos durante uma mudança de resolução do vídeo em uma sessão de vídeo de 60 QPS sob carga. O carregamento é definido como uma sessão simultânea de transcodificação somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware e uma reprodução de áudio AAC de 128 kbps.
• [5.6/H-1-1] PRECISA ter uma latência de toque para tom de 80 milissegundos ou menos usando o teste toque a tom do OboeTester ou o teste de toque do CTS Verifier.
• [5.6/H-1-2] PRECISA ter uma latência de ida e volta de áudio de 80 milissegundos ou menos em pelo menos um caminho de dados compatível.
• [5.6/H-1-3] PRECISA oferecer suporte a áudio de 24 bits ou mais para saída estéreo de mais de 3,5 mm de áudio, se presente, e por áudio USB, se compatível com 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, um AudioTrack Java precisa ser usado pelo app. Nas configurações de baixa latência e streaming, o coletor de saída 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.
• [5.6/H-1-4] PRECISA oferecer suporte a dispositivos de áudio USB com mais de quatro canais. Essa opção é usada pelos controladores de DJ para a prévia de músicas.
• [5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar a sinalização de recurso MIDI.
• [5.7/H-1-2] PRECISA 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 subamostra	1 MiB
Tamanho mínimo do buffer de criptografia genérico	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 QPS

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 da câmera listados no CDD do Android 12 seção 2.2.7.2.

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] PRECISA ter uma câmera traseira principal com resolução de pelo menos 12 megapixels e compatível com captura de vídeo a 4k a 30 fps. A câmera traseira principal é a traseira com o menor ID de câmera.
• [7.5/H-1-2] PRECISA ter uma câmera frontal principal com resolução de pelo menos 5 megapixels e oferecer suporte a captura de vídeo a 1080p a 30 fps. A câmera frontal principal é a frontal com o menor ID de câmera.
• [7.5/H-1-3] PRECISA oferecer suporte à propriedade android.info.supportedHardwareLevel como FULL ou melhor para a câmera principal traseira e LIMITED ou melhor para a câmera principal frontal.
• [7.5/H-1-4] PRECISA oferecer suporte a CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para as duas câmeras principais.
• [7.5/H-1-5] PRECISA ter latência de captura JPEG da câmera2 inferior a 1.000 ms para resolução de 1080p, conforme medido pelo PerformanceTest da câmera CTS em condições de iluminação ITS (3.000K) para as duas câmeras principais.
• [7.5/H-1-6] PRECISA ter a latência de inicialização da câmera2 (abrir a câmera para o primeiro frame de visualização) menor que 500 ms, conforme medido pelo PerformanceTest da câmera CTS em condições de iluminação ITS (3000K) para as duas câmeras principais.
• [7.5/H-1-8] PRECISA 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] PRECISA ter uma câmera principal traseira compatível com 720p ou 1080p a 240 fps.
• [7.5/H-1-10] PRECISA ter ZOOM_RATIO mínimo menor que 1,0 para as câmeras principais se houver uma câmera RGB ultra grande angular voltada para a mesma direção.
• [7.5/H-1-11] PRECISA implementar streaming simultâneo front-back nas câmeras principais.
• [7.5/H-1-12] PRECISA oferecer suporte a CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para a câmera traseira principal.
• [7.5/H-1-13] PRECISA 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] PRECISA oferecer suporte ao recurso STREAM_USE_CASE para a câmera frontal principal e a 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] PRECISA ter uma resolução de tela de pelo menos 1080p.
• [7.1.1.3/H-2-1] PRECISA ter uma densidade de tela de pelo menos 400 dpi.
• [7.6.1/H-2-1] PRECISA 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:

• PRECISA 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] PRECISA garantir um desempenho de gravação sequencial de pelo menos 125 MB/s.
• [8.2/H-1-2] PRECISA garantir um desempenho de gravação aleatória de pelo menos 10 MB/s.
• [8.2/H-1-3] PRECISA garantir um desempenho de leitura sequencial de pelo menos 250 MB/s.
• [8.2/H-1-4] PRECISA garantir um desempenho de leitura aleatória de pelo menos 40 MB/s.

2.3. Requisitos para televisão

Um dispositivo Android Television refere-se 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 do usuário "aproximada" ou "3 metros").

As implementações de dispositivos Android serão classificadas como "Televisão" se atenderem a todos os seguintes critérios:

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

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

2.3.1 Hardware

Implementações de dispositivos de televisão:

• [7.2.2/T-0-1] PRECISA oferecer suporte ao D-pad.
• [7.2.3/T-0-1] PRECISA fornecer as funções Home e Back.
• [7.2.3/T-0-2] PRECISA enviar os eventos normal e longo da função Voltar (KEYCODE_BACK) para o aplicativo em primeiro plano.
• [7.2.6.1/T-0-1] PRECISA incluir suporte a controles de jogos e declarar a flag de recurso android.hardware.gamepad.
• A [7.2.7/T] DEVE fornecer um controle remoto que os usuários possam acessar as entradas de navegação sem toque e teclas de navegação principais.

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

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

Implementações de dispositivos de televisão:

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

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

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

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

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

  • 400 dpi ou mais em telas pequenas/normais
  • xhdpi ou maior em telas grandes
  • tvdpi ou maior em telas muito grandes

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

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

  • 400 dpi ou mais em telas pequenas/normais
  • xhdpi ou maior em telas grandes
  • tvdpi ou maior em telas muito grandes

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 televisão:

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

2.3.2 Multimídia

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

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

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

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

Implementações de dispositivos de televisão:

• [5.2.2/T-SR-1] É RECOMENDADO PARA 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 televisão PRECISAM oferecer suporte aos seguintes formatos de decodificação de vídeo e disponibilizá-los para aplicativos de terceiros:

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

As implementações de dispositivos de televisão PRECISAM oferecer suporte à decodificação MPEG-2, conforme detalhado na Seção 5.3.1, com frame rates e resoluções padrão de até e, inclusive:

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

As implementações de dispositivos de televisão PRECISAM oferecer suporte à decodificação H.264, conforme detalhado na Seção 5.3.4, com frame rates e resoluções padrão de até e, inclusive:

• [5.3.4/T-1-1] HD 1080p a 60 quadros por segundo com o perfil de referência
• [5.3.4/T-1-2] HD 1080p a 60 quadros por segundo com perfil principal
• [5.3.4/T-1-3] HD 1080p a 60 quadros por segundo com High Profile Level 4.2

As implementações de dispositivos de televisão com decodificadores de hardware H.265 PRECISAM oferecer suporte à decodificação H.265, conforme detalhado na Seção 5.3.5, com frame rates e resoluções padrão até e, inclusive:

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

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

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

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

• [5.3.6/T-1-1] HD de 1080p com perfil de decodificação de 60 quadros por segundo

As implementações de dispositivos de televisão com decodificadores de hardware VP9 PRECISAM oferecer suporte à decodificação VP9, conforme detalhado na Seção 5.3.7, com taxas de quadros e resoluções padrão de vídeo, incluindo:

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

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

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

Implementações de dispositivos de televisão:

• [5.5/T-0-1] PRECISA incluir suporte ao volume mestre do sistema e à atenuação do volume da saída de áudio digital em saídas compatíveis, exceto para saída de passagem de áudio compactada, em que nenhuma decodificação de áudio é feita no dispositivo.

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

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

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

• [5.8/T-1-1] PRECISA oferecer suporte a HDCP 2.2.

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

• [5.8/T-2-1] PRECISA oferecer suporte a HDCP 1.4.

2.3.3 Software

Implementações de dispositivos de televisão:

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

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

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

Implementações de dispositivos de televisão:

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

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

• [3.11/T-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um mecanismo TTS com suporte aos idiomas disponíveis no dispositivo.
• [3.11/T-1-1] PRECISA oferecer suporte à instalação de mecanismos TTS de terceiros.

Implementações de dispositivos de televisão:

• [3.12/T-0-1] PRECISA oferecer suporte ao TV Input Framework.

2.3.4 Desempenho e potência

• [8.1/T-0-1] Latência de frame consistente. A latência de frame inconsistente ou um atraso na renderização de frames NÃO PODEM ocorrer com mais frequência do que cinco quadros por segundo e DEVEM estar abaixo de 1 quadros por segundo.
• [8.2/T-0-1] PRECISA garantir um desempenho de gravação sequencial de pelo menos 5 MB/s.
• [8.2/T-0-2] PRECISA garantir um desempenho de gravação aleatória de pelo menos 0,5 MB/s.
• [8.2/T-0-3] PRECISA garantir um desempenho de leitura sequencial de pelo menos 15 MB/s.
• [8.2/T-0-4] PRECISA garantir um desempenho de leitura aleatória de pelo menos 3,5 MB/s.

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

• [8.3/T-1-1] PRECISA fornecer funcionalidade do usuário para ativar e desativar o recurso de economia de bateria.

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

• [8.3/T-1-2] PRECISA registrar o dispositivo como 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] PRECISA oferecer recursos ao usuário para mostrar todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".

Implementações de dispositivos de televisão:

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

2.3.5 Modelo de segurança

Implementações de dispositivos de televisão:

• [9.11/T-0-1] PRECISA fazer backup da implementação de keystore com um ambiente de execução isolado.
• [9.11/T-0-2] É NECESSÁRIO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash das famílias MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos com suporte do sistema Android Keystore em uma área isolada com segurança do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o código do kernel ou do espaço do usuário possa acessar o estado interno do ambiente isolado, incluindo a DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura analisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
• [9.11/T-0-3] PRECISA executar a autenticação da tela de bloqueio no ambiente de execução isolado e, somente quando bem-sucedida, permitir o uso das chaves vinculadas à autenticação. As credenciais da tela de bloqueio PRECISAM ser armazenadas de maneira a permitir que apenas o ambiente de execução isolado execute a autenticação na tela de bloqueio. O Android Open Source Project fornece a Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
• [9.11/T-0-4] PRECISA oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executada em um hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas entre um número grande de dispositivos para evitar que elas sejam usadas como identificadores de dispositivos. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidas. Se mais de 100 mil unidades de uma SKU forem produzidas, uma chave diferente poderá ser usada para cada 100 mil unidades.
• [9/T-0-1] PRECISA declarar o recurso "android.hardware.security.model.compatível".

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior do Android, esse dispositivo estará isento da exigência de ter um keystore apoiado por um ambiente de execução isolado e oferecer suporte ao atestado de chaves, 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 televisão forem compatíveis com uma tela de bloqueio segura, elas:

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

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

• [9.5/T-2-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem 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 televisão incluírem vários usuários e declararem a flag de recurso android.hardware.telephony, elas:

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

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

• [9.8.2/T-4-1] PRECISA exibir o indicador de microfone quando um app estiver acessando dados de áudio pelo microfone, mas não quando o microfone for acessado somente pelo HotwordDetectionService, SOURCE_HOTword, ContentCaptureService ou por apps que tenham os papéis mencionados na Seção 9.1 Permissões com identificador CDD C-3-X.
• [9.8.2/T-4-2] não pode ocultar o indicador de microfone para apps do sistema que têm interfaces do usuário visíveis ou interação direta com o usuário.

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

• [9.8.2/T-5-1] PRECISA exibir o indicador da câmera quando um app estiver acessando dados da câmera em tempo real, mas não quando a câmera só estiver sendo acessada por apps com os papéis mencionados na Seção 9.1 Permissões com identificador CDD [C-3-X].
• [9.8.2/T-5-2] não pode ocultar o indicador de câmera para apps do sistema que têm interfaces do usuário visíveis ou interação direta com o usuário.

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

Implementações de dispositivos de televisão:

• Perfetto (link em inglês)
  • [6.1/T-0-1] PRECISA expor um binário /system/bin/perfetto ao usuário do shell, que o cmdline está em conformidade com a documentação do perfetto (link em inglês).
  • [6.1/T-0-2] O binário do perfetto PRECISA aceitar como entrada uma configuração protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (links em inglês).
  • [6.1/T-0-3] O binário do perfetto PRECISA gravar como saída um trace protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (links em inglês).
  • [6.1/T-0-4] PRECISA fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto (links em inglês).

2.4. Requisitos do relógio

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

As implementações de dispositivos Android serão classificadas como relógios se atenderem a todos os critérios abaixo:

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

Os outros requisitos 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 smartwatches:

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

• [7.2.3/W-0-1] PRECISA ter a função Home disponível para o usuário e a função Back, exceto quando estiver em UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] PRECISA oferecer suporte à entrada touchscreen.

• [7.3.1/W-SR-1] É MUITO RECOMENDADO a inclusão de um acelerômetro de três eixos.

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

• [7.3.3/W-1-1] PRECISA informar as medições do GNSS assim que elas forem encontradas, mesmo que uma localização calculada com o GPS/GNSS ainda não tenha sido informada.
• [7.3.3/W-1-2] PRECISA informar as pseudodistâncias e taxas de GNSS, que, em condições de céu aberto após determinar a localização, enquanto a posição fixa ou em movimento com menos de 0,2 metro por segundo ao quadrado de aceleração, são suficientes para calcular uma posição dentro de 20 metros e uma velocidade dentro de 0,2 metros por segundo, no mínimo 0,2 metros por segundo,

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

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

Implementações de dispositivos de smartwatches:

• O [7.4.3/W-0-1] PRECISA ser compatível com Bluetooth.

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

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

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

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

2.4.2. Multimídia

Nenhum requisito extra.

2.4.3. Software

Implementações de dispositivos de smartwatches:

• [3/W-0-1] PRECISA declarar o recurso android.hardware.type.watch.
• [3/W-0-2] PRECISA oferecer suporte a uiMode = UI_MODE_TYPE_WATCH.
• [3.2.3.1/W-0-1] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intent pública definidos pelos seguintes intents de aplicativo listados aqui.

Implementações de dispositivos de smartwatches:

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

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

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

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

• [3.11/W-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um mecanismo TTS com suporte aos idiomas disponíveis no dispositivo.

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

2.4.4 Desempenho e potência

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

• [8.3/W-SR-1] É RECOMENDADO PARA oferecer funcionalidade ao usuário para mostrar todos os apps isentos dos modos de economia de energia App em espera e Soneca.
• [8.3/W-SR-2] É FORTEMENTE RECOMENDADO para fornecer funcionalidade ao usuário para ativar e desativar o recurso de economia de bateria.

Implementações de dispositivos de smartwatches:

• [8.4/W-0-1] PRECISA fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado de bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
• [8.4/W-0-2] PRECISA informar todos os valores de consumo de energia em miliamperes-hora (mAh).
• [8.4/W-0-3] PRECISA informar o consumo de energia da CPU pelo UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
• [8.4/W-0-4] PRECISA disponibilizar esse uso de energia usando o comando do shell adb shell dumpsys batterystats para o desenvolvedor do app.
• [8.4/W] DEVE ser atribuída 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 smartwatches:

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

Se as implementações de dispositivos de 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 que os proprietários de dispositivos gerenciem 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 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 É POSSÍVEL oferecer suporte a perfis restritos, mas PRECISA estar alinhado à implementação de controles do AOSP para permitir /desativar o acesso de outros usuários a ligações 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 todo ou parte do sistema e/ou da funcionalidade de infoentretenimento.

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

• estejam incorporados como parte de um veículo automotivo ou conectá-lo a ele;
• estão usando uma tela na fila do assento do motorista como tela principal;

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

2.5.1. Hardware

Implementações de dispositivos automotivos:

• [7.1.1.1/A-0-1] PRECISA ter uma tela de pelo menos 6 pol. de tamanho diagonal.

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

• [7.2.3/A-0-1] PRECISA fornecer a função Home e PODE fornecer as funções Back e Recent.

• [7.2.3/A-0-2] PRECISA enviar os eventos normal e longo da função Voltar (KEYCODE_BACK) para o aplicativo em primeiro plano.

• [7.3/A-0-1] PRECISA implementar e informar GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.

• [7.3/A-0-2] O valor da sinalização NIGHT_MODE PRECISA ser consistente com o modo dia/noite do painel e PRECISA ser baseado na entrada do sensor de luz ambiente. O sensor de luz ambiente pode ser o mesmo que o Photometer.

• [7.3/A-0-3] PRECISA fornecer o campo de informações extras do sensor TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor fornecido.

• [7.3/A-SR1] PODE reconhecer a localização ao fundir GPS/GNSS com sensores adicionais. Se o Location for registrado, é MUITO RECOMENDADO implementar e informar os tipos de Sensor correspondentes e/ou IDs de propriedade do veículo usados.

• [7.3/A-0-4] O local solicitado via LocationManager#requestLocationUpdates() NÃO PODE ter correspondência no mapa.

• [7.3.1/A-0-4] PRECISA estar em conformidade com o sistema de coordenadas do sensor de carros do Android.

• [7.3/A-SR-1] São STRONGLY_RECOMMENDED para incluir um acelerômetro de três eixos e um giroscópio de três eixos.

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

Se as implementações de dispositivos automotivos oferecerem suporte ao OpenGL ES 3.1, elas:

• [7.1.4.1/A-0-1] PRECISA declarar o OpenGL ES 3.1 ou uma versão mais recente.
• [7.1.4.1/A-0-2] PRECISA oferecer suporte ao Vulkan 1.1.
• [7.1.4.1/A-0-3] PRECISA 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] PRECISA relatar eventos com até uma frequência de pelo menos 100 Hz.

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

• [7.3.1/A-SR-1] É FORTEMENTE RECOMENDADO para 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] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
• [7.3.1/A-1-4] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

• [7.3.4/A-2-1] PRECISA relatar eventos com até uma frequência de pelo menos 100 Hz.
• [7.3.4/A-2-3] PRECISA ser capaz de medir mudanças de orientação em até 250 graus por segundo.
• [7.3.4/A-SR-1] É FORTEMENTE RECOMENDADO configurar o intervalo de medição do giroscópio como +/-250 dps a fim de 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] É FORTEMENTE RECOMENDADO para 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] PRECISA implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES.
• [7.3.4/A-4-2] PRECISA implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

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

• [7.3.3/A-3-1] PRECISA determinar a localização na primeira vez em que o receptor GPS/GNSS é ativado ou após quatro dias ou mais em um período de 60 segundos.
• [7.3.3/A-3-2] PRECISA atender aos critérios de tempo para 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 local, ou seja, solicitações que não são a primeira vez ou que não são a primeira vez ou que não ocorrem após mais de quatro dias. O requisito 7.3.3/C-1-2 normalmente é 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 detectar por pelo menos 60 segundos com uma precisão de posição satisfeita 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] PRECISA relatar eventos com até uma frequência de pelo menos 1 Hz.
• [7.3.4/A-SR-3] STRONGLY_RECOMMENDED para relatar eventos de até uma frequência de pelo menos 10 Hz.
• DEVE se referir 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] PRECISA oferecer suporte a Bluetooth e DEVE 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, na sigla em inglês).
  • Reprodução de mídia no perfil de distribuição de áudio (A2DP, na sigla em inglês).
  • Controle de reprodução de mídia sobre o perfil de controle remoto (AVRCP, na sigla em inglês).
  • Compartilhamento de contatos usando o perfil de acesso à agenda telefônica (PBAP, na sigla em inglês).

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

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

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

Uma câmera de visualização externa é uma câmera que captura 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 visualização externa.

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

• [7.5/A-1-1] NÃO PODE ter câmeras de visualização externa acessíveis pelas APIs Android Camera, a menos que obedeçam aos requisitos principais da câmera.

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

• [7.5/A-SR-2] É MUITO 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 visualização externa e carregarem o serviço Exterior View System (EVS), para essa câmera, elas:

• [7.5/A-2-1] NÃO PODE girar nem espelhar a visualização da câmera 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] PRECISA informar o flag de recurso android.hardware.camera.any.
• [7.5/A-3-2] não PRECISA declarar a câmera como uma câmera do sistema.
• PODE ser compatível com câmeras externas descritas na seção 7.5.3.
• PODE incluir recursos (como foco automático etc.) disponíveis para as câmeras traseiras, conforme descrito na seção 7.5.1.

Implementações de dispositivos automotivos:

• [7.6.1/A-0-1] PRECISA 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/A] DEVE formatar a partição de dados para oferecer melhor desempenho e longevidade no armazenamento flash, por exemplo, usando o sistema de arquivos f2fs.

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

• [7.6.1/A-SR-1] É RECOMENDADO PARA 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 muito grandes
  • 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 maior em telas pequenas/normais
  • hdpi ou maior em telas grandes
  • mdpi ou maior em telas muito grandes

• [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 maior em telas grandes
  • tvdpi ou maior em telas muito grandes

• [7.6.1/A-2-4] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1.824 MB 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 maior em telas muito grandes

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 compatível com o modo de periféricos.

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

2.5.2 Multimídia

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

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

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

As implementações de dispositivos automotivos são MUITO RECOMENDADAS para oferecer suporte à decodificação de vídeo abaixo:

• [5,3/A-SR-1] H.265 HEVC

2.5.3 Software

Implementações de dispositivos automotivos:

• [3/A-0-1] PRECISA declarar o recurso android.hardware.type.automotive.

• [3/A-0-2] PRECISA oferecer suporte a uiMode = UI_MODE_TYPE_CAR.

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

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

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

Implementações de dispositivos automotivos:

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

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

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

• [3.8.3/A-0-1] PRECISA 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 incluírem um botão "push-to-talk", elas:

• [3.8.4/A-1-1] PRECISA usar um pressionamento breve do botão "push-to-talk" como a interação designada para iniciar o app assistivo selecionado pelo usuário. Ou seja, o app que implementa VoiceInteractionService.

Implementações de dispositivos automotivos:

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

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

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

Implementações de dispositivos automotivos:

• [3.14/A-0-1] PRECISA incluir um framework 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] PRECISA permitir que o usuário interaja de forma segura com aplicativos de mídia enquanto dirige.
• [3.14/A-0-3] PRECISA oferecer suporte à ação da intent implícita CAR_INTENT_ACTION_MEDIA_TEMPLATE com o extra CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] PRECISA fornecer uma affordance para navegar até a atividade de preferência de um app de mídia, mas PRECISA ativá-la apenas quando as Restrições de UX para carros não estiverem em vigor.
• [3.14/A-0-5] PRECISA exibir mensagens de erro definidas por aplicativos de mídia e PRECISA oferecer suporte aos extras opcionais ERROR_RESOLUTION_ACTION_LABEL e ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] PRECISA ser compatível com uma funcionalidade de pesquisa no app.
• [3.14/A-0-7] PRECISA respeitar as definições CONTENT_STYLE_BROWSABLE_HINT e CONTENT_STYLE_PLAYABLE_HINT ao exibir a hierarquia 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] PRECISA incluir serviços de mídia e abri-los com a intent CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implementações de dispositivos automotivos:

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

2.5.4 Desempenho e potência

Implementações de dispositivos automotivos:

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

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 PODE permitir que os usuários interajam com nem com interruptor para o Usuário do sistema headless, exceto para o provisionamento de dispositivos.
• [9.5/A-1-2] PRECISA mudar para um Usuário secundário antes de BOOT_COMPLETED.
• [9.5/A-1-3] PRECISA 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] PRECISA exibir o indicador da câmera quando um app estiver acessando dados da câmera em tempo real, mas não quando a câmera só estiver sendo acessada por apps que detêm as funções mencionadas na Seção 9.1 Permissões com o identificador CDD [C-3-X].
• [9.8.2/A-2-2] não pode ocultar o indicador de câmera para apps do sistema que têm interfaces do usuário visíveis ou interação direta com o usuário.

Implementações de dispositivos automotivos:

• [9.11/A-0-1] PRECISA fazer backup da implementação de keystore com um ambiente de execução isolado.
• [9.11/A-0-2] PRECISA ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash das famílias MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos com suporte do sistema Android Keystore em uma área isolada com segurança do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o código do kernel ou do espaço do usuário possa acessar o estado interno do ambiente isolado, incluindo a DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura analisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
• [9.11/A-0-3] PRECISA executar 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 maneira a permitir que apenas o ambiente de execução isolado execute a autenticação na tela de bloqueio. O Android Open Source Project fornece a Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
• [9.11/A-0-4] PRECISA oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é executada em um hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas entre um número grande de dispositivos para evitar que elas sejam usadas como identificadores de dispositivos. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidas. Se mais de 100 mil unidades de uma SKU forem produzidas, uma chave diferente poderá ser usada para cada 100 mil unidades.
• [9/A-0-1] PRECISA declarar o recurso "android.hardware.security.model.compatível".

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior do Android, esse dispositivo estará isento da exigência de ter um keystore apoiado por um ambiente de execução isolado e oferecer suporte ao atestado de chaves, 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] PRECISA bloquear as mensagens dos subsistemas de veículos do framework do Android, como colocar tipos de mensagens e origens permitidos na lista de permissões.
• [9.14/A-0-2] PRECISA observar o monitoramento contra ataques de negação de serviço do framework do Android ou de apps de terceiros. Isso protege contra o uso de software malicioso que inunde a rede do veículo com tráfego, o que pode levar ao mau funcionamento de subsistemas do veículo.

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

Implementações de dispositivos automotivos:

• Perfetto (link em inglês)
  • [6.1/A-0-1] PRECISA expor um binário /system/bin/perfetto ao usuário do shell, que o cmdline está em conformidade com a documentação do perfetto (link em inglês).
  • [6.1/A-0-2] O binário do perfetto PRECISA aceitar como entrada uma configuração protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (links em inglês).
  • [6.1/A-0-3] O binário do perfetto PRECISA gravar como saída um trace protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (links em inglês).
  • [6.1/A-0-4] PRECISA fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto (links em inglês).

2,6 Requisitos para tablets

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

• Usado por segurar as duas mãos.
• Não tem configuração flip ou conversível.
• As implementações de teclado físico usadas com o dispositivo são conectadas por meio de uma conexão padrão (por exemplo, USB ou Bluetooth).
• tem uma fonte de energia que oferece mobilidade, como uma bateria;
• Tem uma tela com tamanho maior que 7” e menor que 18”, medidas diagonalmente.

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

2.6.1. Hardware

Giroscópio

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

• [7.3.4/Tab-1-1] PRECISA ser capaz de medir mudanças de orientação 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 tablets incluírem uma porta USB compatível com o 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)

Alto desempenho da realidade virtual (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 tablets incluírem vários usuários e não declararem a flag de recurso android.hardware.telephony, elas:

• [9.5/T-1-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem 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 tablets incluírem vários usuários e declararem a flag de recurso android.hardware.telephony, elas:

• [9.5/T-2-1] NÃO É POSSÍVEL oferecer suporte a perfis restritos, mas PRECISA estar alinhado à implementação de controles do AOSP para permitir /desativar o acesso de outros usuários a ligações e SMS.

2.6.2. Software

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

3. Software

3.1. Compatibilidade com APIs gerenciadas

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

Implementações de dispositivos:

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

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

• [C-0-3] NÃO PODE omitir nenhuma API gerenciada, alterar interfaces ou assinaturas da API, se desviar do comportamento documentado ou incluir ambiente autônomo, exceto quando especificamente permitido por esta definição de compatibilidade.

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

• [C-0-5] NÃO PODE permitir que apps de terceiros usem interfaces externas ao 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 @SystemAPI, conforme descrito nos documentos do SDK e membros de classes particulares e privados do pacote.

• [C-0-6] PRECISA ser enviado com todas as interfaces externas ao SDK nas mesmas listas restritas, conforme fornecido pelas sinalizações provisórias e de lista de bloqueio no caminho prebuilts/runtime/appcompat/hiddenapi-flags.csv para a ramificação de nível de API adequada no AOSP.

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

  No entanto, elas:

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

3.1.1. Extensões Android

O Android oferece suporte à extensão da superfície da 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) vai retornar a versão da extensão do apiLevel fornecido, se houver extensões para esse nível da API.

Implementações de dispositivos Android:

• [C-0-1] PRECISA pré-carregar a implementação do AOSP da biblioteca compartilhada ExtShared e dos serviços ExtServices com versões maiores ou iguais às versões mínimas permitidas por cada nível da API. Por exemplo, as implementações de dispositivo Android 7.0 que executam o nível 24 da API PRECISAM incluir pelo menos a versão 1.

• [C-0-2] PRECISA retornar apenas um número de versão de extensão válido que tenha sido definido pelo AOSP.

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

3.1.2. Biblioteca do Android

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

• [C-0-1] NÃO PODE colocar a biblioteca org.apache.http.legacy no bootclasspath.
• [C-0-2] PRECISA adicionar a biblioteca org.apache.http.legacy ao caminho de classe do aplicativo somente quando ele atender a uma destas condições:
  • Segmenta a API de nível 28 ou anterior.
  • 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 leve com APIs

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

3.2.1. Permissões

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

3.2.2. Parâmetros de build

As APIs do Android incluem várias constantes na classe android.os.Build que têm como objetivo descrever 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 sobre os formatos desses valores a que as implementações de dispositivos PRECISAM estar em conformidade.

Parâmetro	Detalhes
VERSÃO.LANÇAMENTO	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 ao código do aplicativo de terceiros. No 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 ao código do aplicativo de terceiros. No Android 13, esse campo PRECISA ter o valor inteiro 13_INT.
VERSÃO.INCREMENTAL	Um valor escolhido pelo implementador do dispositivo que designa o build específico do sistema Android em execução no momento, em formato legível por humanos. Esse valor NÃO PODE ser reutilizado para builds diferentes disponibilizados aos usuários finais. Esse campo costuma ser usado para indicar qual número da versão ou identificador de mudança de controle de origem foi usado para gerar o build. O valor desse campo PRECISA ser codificado como ASCII de 7 bits para impressão e corresponder à expressão regular "^[^ :\/~]+$".
TABULEIRO	Um valor escolhido pelo implementador do dispositivo que identifica o hardware interno específico usado pelo dispositivo, em formato legível por humanos. Um uso possível desse campo é indicar a revisão específica da placa que fornece energia ao dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”.
MARCA	Um valor que reflete o nome da marca associada ao dispositivo, como conhecido pelos usuários finais. PRECISA estar em um formato legível por humanos e DEVE representar o fabricante do dispositivo ou a marca da empresa sob a qual o dispositivo é comercializado. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”.
ABIS_SUPORTE	O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo. Consulte a seção 3.3. Compatibilidade com API nativa.
SUPORTE_32_ABIS_BIT	O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo. Consulte a seção 3.3. Compatibilidade com API nativa.
SUPORTE_64_ABIS_BIT	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 com APIs nativas.
CPU_ABI	O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo. Consulte a seção 3.3. Compatibilidade com 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 com APIs nativas.
DISPOSITIVO	Um valor escolhido pelo implementador do dispositivo, contendo o nome de desenvolvimento ou o codinome que identifica a configuração dos recursos de hardware e o design industrial do dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". O nome do dispositivo NÃO PODE ser alterado durante a vida útil do produto.
IMPRESSORA	Uma string que identifica exclusivamente este build. Ele DEVE ser legível por humanos. Ele PRECISA seguir este modelo: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Por 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 DEVE ser 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_-]+$".
APRESENTADOR	Uma string que identifica exclusivamente o host em que o build foi criado, em formato legível por humanos. Não há requisitos para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
ID	Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão específica, em formato legível por humanos. Esse campo pode ser igual a android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficiente para que os usuários finais diferenciem versões 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 ser alterado durante a vida útil do produto.
FABRICANTE DE SOC	O nome comercial do fabricante do system on chip (SOC) principal usado no produto. Dispositivos com o mesmo fabricante de SOC precisam usar o mesmo valor constante. Peça ao fabricante do SOC a constante correta a ser usada. O valor desse campo PRECISA ser codificável como ASCII de 7 bits, PRECISA corresponder à expressão regular "^([0-9A-Za-z ]+)", NÃO pode começar ou terminar com um espaço nem ser igual a "unknown". Esse campo NÃO PODE ser alterado durante a vida útil do produto.
MODELO_SOC	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. Peça ao fabricante do SOC a constante correta a ser usada. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular "^([0-9A-Za-z ._/+-]+)$", NÃO PODE começar ou terminar com um espaço em branco e NÃO PODE ser igual a "desconhecido". Esse campo NÃO PODE ser alterado durante a vida útil do produto.
MODEL	Um valor escolhido pelo implementador do dispositivo, contendo o nome do dispositivo conhecido pelo usuário final. Esse DEVE ser o mesmo nome usado para comercializar e vender o dispositivo aos usuários finais. 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 ser alterado durante a vida útil do produto.
PRODUTO	Um valor escolhido pelo implementador do dispositivo contendo o nome de desenvolvimento ou o codinome do produto específico (SKU) que PRECISA ser exclusivo na mesma marca. PRECISA ser legível, mas não se destina necessariamente à visualização por usuários finais. O valor deste campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". Esse nome de produto NÃO PODE ser alterado durante a vida útil do produto.
SKU do ODM	Um valor opcional escolhido pelo implementador do dispositivo que contém a SKU (unidade de manutenção de estoque) usada para rastrear configurações específicas do dispositivo, como periféricos incluídos no dispositivo quando vendidos. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular ^([0-9A-Za-z.,_-]+)$.
SÉRIE	PRECISA retornar "UNKNOWN".
TAGS	Uma lista separada por vírgulas de tags 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, dev-keys 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 especificando a configuração de tempo de execução do build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas do 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 para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
PATCH DE SEGURANÇA	Um valor que indica o nível do patch de segurança de uma versão. Ela PRECISA indicar que o build não está vulnerável a nenhum dos problemas descritos no boletim de segurança pública do Android designado. Ele PRECISA estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no Boletim de segurança pública do Android ou no Aviso de segurança do Android, por exemplo, "2015-11-01".
BASE_SO	Um valor que representa o parâmetro FINGERPRINT do build que é idêntico a este 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, informar uma string vazia ("").
BOOTLOADER	Um valor escolhido pelo implementador do dispositivo que identifica a versão interna específica do carregador de inicialização usada no dispositivo, em formato legível. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9._-]+$”.
getRadioVersion() (link em inglês)	PRECISA (ser ou retornar) um valor escolhido pelo implementador do dispositivo, identificando a versão interna específica do rádio/modem usada no dispositivo, em formato legível. Se um dispositivo não tiver nenhum rádio/modem interno, ele PRECISA retornar NULL. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-,]+$".
getSerial() (em inglês)	PRECISA (ser ou retornar) um número de série do hardware, que PRECISA estar disponível e ser exclusivo em dispositivos com o mesmo MODEL e MANUFACTURER. 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 aplicativos

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] É FORTEMENTE RECOMENDADO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtros de intent públicas definidos pelas seguintes intents de app listadas aqui e fornecer fulfillment, ou seja, atender às expectativas do desenvolvedor para essas intents de aplicativo comuns, conforme descrito no SDK.

Consulte a Seção 2 para saber mais sobre intents de aplicativo obrigatórias 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 mencionado na seção 3.2.3.1, exceto as "Configurações", seja substituído por apps de terceiros. A implementação de código aberto upstream do Android permite isso por padrão.

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

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

• No entanto, as implementações de dispositivos podem fornecer atividades padrão para padrões de URI específicos (por exemplo, http://play.google.com) quando a atividade padrão fornece um atributo mais específico para o URI de dados. Por exemplo, um padrão de filtro de intent que especifica o URI de dados "http://www.android.com" é mais específico do que o padrão de intent principal do navegador para "http://".

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

• [C-0-4] PRECISA tentar validar os filtros de intent executando as etapas de validação definidas na especificação Digital Asset Links, implementadas pelo gerenciador de pacotes no Android Open Source Project upstream.
• [C-0-5] PRECISA tentar validar os filtros de intent durante a instalação do aplicativo e definir todos os filtros de intent de URI validados com sucesso como gerenciadores de apps padrão para os URIs.
• PODEM definir filtros de intent de URI específicos como gerenciadores de apps padrão para os URIs se eles forem verificados, mas outros filtros de URI candidatos falharem na verificação. Se uma implementação de dispositivo fizer isso, ela PRECISA fornecer ao usuário as substituições adequadas de padrão por URI no menu de configurações.
• PRECISA fornecer ao usuário controles de links do app por app nas Configurações desta maneira:
  • [C-0-6] O usuário PRECISA conseguir substituir de maneira holística o comportamento de links de apps padrão para que um app seja: sempre aberto, sempre perguntar ou nunca aberto, o que precisa ser aplicado a todos os filtros de intent de URI candidatos igualmente.
  • [C-0-7] O usuário PRECISA ter acesso a uma lista de filtros de intent de URI candidatos.
  • A implementação do dispositivo PODE oferecer ao usuário a capacidade de substituir filtros de intent de URI candidatos específicos que foram verificados com base em filtros por intent.
  • [C-0-8] A implementação do dispositivo PRECISA oferecer aos usuários a capacidade de conferir e substituir filtros de intent de URI candidatos se a implementação do dispositivo permitir que alguns filtros de intent de URI candidatos tenham êxito na verificação, enquanto outros poderão falhar.

3.2.3.3. Namespaces de intents

• [C-0-1] As implementações de dispositivos NÃO PODEM incluir componentes do Android que respeitem qualquer nova intent ou padrões de intent de transmissão usando ACTION, CATEGORY ou outra string de chave no namespace android.* ou com.android.*.
• [C-0-2] Os implementadores de dispositivos NÃO PODEM incluir componentes do Android que respeitem novas intents ou transmitam padrões de intent usando ACTION, CATEGORY ou outra string de chave em um espaço de pacote que pertença a outra organização.
• [C-0-3] Os implementadores de dispositivos NÃO PODEM mudar nem estender nenhum padrão de intent listado na seção 3.2.3.1.
• As implementações de dispositivos podem incluir padrões de intent usando namespaces de maneira clara 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

Aplicativos de terceiros dependem da plataforma para transmitir determinadas intents e notificá-las sobre mudanças no ambiente de hardware ou software.

Implementações de dispositivos:

• [C-0-1] PRECISA transmitir as intents de transmissão públicas listadas aqui em resposta aos eventos apropriados do sistema, conforme descrito na documentação do SDK. Esse requisito não está em conflito com a seção 3.5, uma vez que a limitação para aplicativos em segundo plano também é descrita na documentação do SDK. Além disso, algumas intents de transmissão dependem do suporte a hardware. Se o dispositivo oferecer suporte ao hardware necessário, elas PRECISAM transmitir as intents e fornecer o comportamento inline com a documentação do SDK.

3.2.3.5. Intents de aplicativos condicionais

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

Quando fizer sentido, as implementações de dispositivos PRECISAM fornecer um menu de configurações semelhante e serem compatíveis com o padrão de filtro de intent e os métodos da API descritos na documentação do SDK abaixo.

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

• [C-1-1] PRECISA respeitar a intent android.settings.HOME_SETTINGS para mostrar um menu de configurações padrão do app na tela inicial.

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

• [C-2-1] PRECISA fornecer um menu de configurações que chamará a intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar uma caixa de diálogo e mudar o aplicativo de SMS padrão.

• [C-2-2] PRECISA respeitar a intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar uma caixa de diálogo que permita ao usuário mudar o app Telefone padrão.

  • PRECISA usar a interface do app Telefone padrão selecionada pelo usuário para chamadas recebidas e feitas, exceto chamadas de emergência, que usariam o app Telefone pré-instalado.

• [C-2-3] PRECISA respeitar a intent android.telecom.action.CHANGE_PHONE_ACCOUNTS para oferecer recursos ao usuário para configurar a ConnectionServices associada à PhoneAccounts, assim como uma PhoneAccount padrão que o provedor de serviços de telecomunicações vai usar para fazer chamadas. A implementação do AOSP atende a esse requisito incluindo um menu "Opção de contas telefônicas" no menu de configurações "Chamadas".

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

• [C-2-5] PRECISA fornecer ao usuário affordance para escolher um app que tenha o papel android.app.role.CALL_REDIRECTION.

• [C-2-6] PRECISA respeitar as intents android.intent.action.SENDTO e android.intent.action.VIEW e fornecer uma atividade para enviar/exibir mensagens SMS.

• [C-SR-1] São RECOMENDADOS PARA honrar as intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_Button, android.intent.action.VIEW e android.intent.action.DIAL com um aplicativo discador pré-carregado que pode processar essas intents e fornecer o fulfillment conforme descrito no SDK

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

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

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

• [C-4-1] PRECISA respeitar as intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED e android.nfc.action.TECH_DISCOVERED para mostrar uma atividade que atenda às expectativas do desenvolvedor em relação a essas intents, conforme descrito no SDK.

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

• [C-5-1] PRECISA respeitar 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] PRECISA respeitar 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 forem compatíveis com o recurso "Não perturbe", elas:

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

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

• [C-7-1] PRECISA 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 oferecerem suporte a serviços de acessibilidade de terceiros, elas:

• [C-8-1] PRECISA respeitar a intent android.settings.ACCESSIBILITY_SETTINGS para oferecer um mecanismo acessível ao usuário que ative e desative os serviços de acessibilidade de terceiros e os serviços pré-carregados.

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

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

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

• [C-10-1] PRECISA 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 de dispositivos não oferecerem o modo de economia de dados, elas:

• [C-11-1] PRECISA ter uma atividade que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mas PODE a implementar como um ambiente autônomo.

Se as implementações de dispositivos declararem suporte à câmera usando android.hardware.camera.any, elas:

• [C-12-3] PRECISA processar e permitir que apenas apps Android pré-instalados processem as intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE e MediaStore.ACTION_VIDEO_CAPTURE abaixo, conforme descrito no documento do SDK.

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

• [C-13-1] PRECISA respeitar a intent android.app.action.ADD_DEVICE_ADMIN para invocar uma interface e levar o usuário adicionando o administrador do dispositivo ao sistema (ou permitindo que ele a rejeite).

• [C-13-2] PRECISA respeitar as intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD e android.app.action.START_ENCRYPTION e ter uma atividade para fornecer o fulfillment para essas intents neste link.

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

• [C-14-1] PRECISA 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:

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

Se as implementações de dispositivos tiverem a intenção de impedir que apps, incluindo apps pré-instalados, acessem as estatísticas de uso:

• [C-15-1] ainda PRECISA ter uma atividade que processe o padrão de intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mas PRECISA implementá-la como um ambiente autônomo, que tem um comportamento equivalente a de 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ários por um mecanismo semelhante, elas:

• [C-16-1] PRECISA exibir esses links em todos os serviços de preenchimento automático instalados.

• [C-17-1] [Movido para 2.2.3]

Se as implementações de dispositivos oferecerem suporte à VoiceInteractionService e tiverem mais de um aplicativo instalado ao mesmo tempo usando essa API:

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

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

• [C-SR-3] São fortemente RECOMENDADOS para respeitar as intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA e android.speech.tts.engine.GET_SAMPLE_TEXT têm uma atividade para fornecer fulfillment para essas intents, conforme descrito neste SDK.

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

• DEVE incluir suporte a protetores de tela e fornecer 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/múltiplas

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

• [C-1-1] PRECISA definir a flag de recurso android.software.activities_on_secondary_displays.
• [C-1-2] PRECISA garantir a compatibilidade da API de forma semelhante a uma atividade executada na tela principal.
• [C-1-3] PRECISA colocar a nova atividade na mesma tela que a atividade que a iniciou, quando ela for iniciada sem especificar uma tela de destino com a API ActivityOptions.setLaunchDisplayId().
• [C-1-4] PRECISA destruir todas as atividades quando uma tela com a sinalização Display.FLAG_PRIVATE for removida.
• [C-1-5] PRECISA 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 mostrada, operar 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 PRECISA ser capaz de iniciar. Todos podem abrir uma tela que tenha a flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilidade com API nativa

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

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

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 .so ELF compilado para a arquitetura de hardware do dispositivo adequada. Como o código nativo é altamente dependente da tecnologia do processador subjacente, o Android define várias interfaces binárias de aplicativo (ABIs, na sigla em inglês) no Android NDK.

Implementações de dispositivos:

• [C-0-1] PRECISA ser compatível com uma ou mais ABIs do Android NDK definidas.
• [C-0-2] PRECISA incluir suporte para que o código em execução no ambiente gerenciado chame código nativo, usando a semântica padrão da Interface nativa do Java (JNI).
• [C-0-3] PRECISA ser compatível com a fonte (ou seja, com o cabeçalho) e com o binário (para a ABI) com cada biblioteca necessária na lista abaixo.
• [C-0-5] PRECISA informar com precisão a interface binária do aplicativo (ABI, na sigla em inglês) nativa compatível com o dispositivo, usando os parâmetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, cada um com uma lista separada por vírgulas de ABIs separadas por vírgula.

• [C-0-6] PRECISA informar, usando os parâmetros acima, um subconjunto da lista de ABIs a seguir. Além disso, NÃO É POSSÍVEL informar nenhuma ABI que não esteja na lista.

  • armeabi (não tem mais suporte como destino pelo NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [C-0-7] PRECISA disponibilizar todas as bibliotecas a seguir, fornecendo APIs nativas, para apps que incluem código nativo:

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

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

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

• [C-0-10] NÃO PODE expor outras bibliotecas nativas, implementadas e fornecidas no AOSP como bibliotecas do sistema, a apps de terceiros com nível de API 24 ou mais recente, porque são reservadas.

• [C-0-11] PRECISA 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 PRECISAM estar presentes, a seção 7.1.4.1 descreve em mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.

• [C-0-12] É NECESSÁRIO exportar os símbolos de função para os símbolos de função principais do Vulkan 1.0, assim como as extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2, usando a biblioteca libvulkan.so. Embora todos os símbolos PRECISAM 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 principais disponíveis no Android Open Source Project upstream

Observe que versões futuras do Android podem introduzir a compatibilidade com outras ABIs.

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

Se as implementações de dispositivos informarem compatibilidade com a ABI armeabi, elas:

• [C-3-1] também PRECISA oferecer 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 de dispositivo informarem suporte à ABI armeabi-v7a, para apps que usam essa ABI, elas:

• [C-2-1] PRECISA incluir as linhas abaixo em /proc/cpuinfo. Além disso, NÃO PODE alterar os valores no mesmo dispositivo, mesmo quando eles são lidos por outras ABIs.

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

• [C-2-2] PRECISA sempre manter as seguintes operações disponíveis, mesmo no caso em que a ABI é implementada em uma arquitetura ARMv8, seja por meio da compatibilidade com CPU nativa ou da emulação de software:

  • Instruções do SWP e do SWPB.
  • CP15ISB, CP15DSB e CP15DMB

• [C-2-3] PRECISA incluir suporte à extensão Advanced SIMD (também conhecida como NEON).

3,4 Compatibilidade com a Web

3.4.1. Compatibilidade com WebView

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

• [C-1-1] PRECISA informar android.software.webview.
• [C-1-2] PRECISA usar o build do projeto Chromium do projeto 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 pelo WebView PRECISA estar neste formato:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Versão/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 que android.os.Build.MODEL.
  • "Build/$(BUILD)" PODE ser omitido, mas se estiver presente, a string $(BUILD) PRECISA ser o mesmo que o valor de android.os.Build.ID.
  • O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium no Android Open Source Project upstream.
  • As implementações de dispositivos podem omitir dispositivos móveis na string do user agent.

• O componente WebView DEVE incluir suporte ao maior número possível de recursos HTML5. Se ele for compatível, PRECISA estar em conformidade com a especificação do HTML5.

• [C-1-4] PRECISA renderizar o conteúdo fornecido ou o conteúdo do URL remoto em um processo diferente do aplicativo que instancia a WebView. Especificamente, o processo do renderizador separado PRECISA ter privilégio mínimo, 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 mínimos do sistema pelo binder. A implementação do WebView da WebView no AOSP 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 de C-1-3.

3.4.2. Compatibilidade de navegadores

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

• [C-1-1] PRECISA oferecer suporte a cada uma destas APIs associadas ao HTML5:
  • cache do app/operação off-line
  • Tag<video>
  • geolocalização
• [C-1-2] PRECISA oferecer suporte à API Webstorage (link em inglês) HTML5/W3C e à API IndexedDB (link em inglês) HTML5/W3C. Observe que, como os padrões de desenvolvimento da Web estão fazendo a transição para favorecer o IndexedDB em vez do webstorage, o IndexedDB se tornará um componente obrigatório em uma versão futura do Android.
• PODE enviar uma string do user agent personalizado no aplicativo Navegador autônomo.
• DEVE implementar suporte para o máximo possível de HTML5 no aplicativo Navegador autônomo (seja com base no upstream WebKit Browser ou em um substituto de terceiros).

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

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

3,5 Compatibilidade comportamental de API

Implementações de dispositivos:

• [C-0-9] PRECISA garantir que a compatibilidade comportamental da API seja aplicada a todos os apps instalados, a menos que eles sejam restritos, conforme descrito na Seção 3.5.1.
• [C-0-10] NÃO É POSSÍVEL implementar a abordagem de lista de permissões que garante compatibilidade comportamental da API apenas para apps selecionados por implementadores de dispositivos.

O comportamento de cada um dos tipos de API (gerenciado, flexível, nativo e Web) precisa ser consistente com a implementação preferida 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 mudar a semântica do ciclo de vida ou do ciclo de vida de um tipo específico de componente do sistema (como Service, Activity, ContentProvider etc.).
• [C-0-3] Os dispositivos NÃO PODEM mudar a semântica de uma permissão padrão.
• Os dispositivos NÃO PODEM alterar as limitações aplicadas a 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 de GnssMeasurement e GnssNavigationMessage.
  • [C-0-5] eles PRECISAM limitar a frequência de atualizações fornecidas ao app pela classe de API LocationManager ou pelo método WifiManager.startScan().
  • [C-0-6] Se o app for direcionado ao nível de API 25 ou mais recente, ele NÃO PODERÁ 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ções.
  • [C-0-7] Se o app for direcionado à API de nível 25 ou mais recente, ele PRECISA interromper os serviços em segundo plano do app, como se ele tivesse chamado o método stopSelf(), a menos que o app fosse colocado em uma lista de permissões temporária para processar uma tarefa visível para o usuário.
  • [C-0-8] Se o app for destinado ao nível 25 da API ou mais recente, eles PRECISAM liberar os wake locks mantidos pelo app.
• [C-0-11] Os dispositivos PRECISAM retornar os seguintes provedores de segurança como os sete primeiros valores de matriz do método Security.getProviders(), na ordem indicada e com os nomes e classes fornecidos (como retornado por Provider.getName()), a menos que o app tenha modificado a lista via insertProviderAt() ou removeProvider(). Os dispositivos PODEM retornar provedores adicionais após a lista especificada abaixo.
  1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL: com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider: sun.security.provider.CertPathProvider
  4. Alternativa AndroidKeyStoreBC: 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, na sigla em inglês) 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 pelo Android Open Source Project sempre que possível, em vez de implementar novamente partes significativas do sistema.

3.5.1. Restrição de aplicativo

Se as implementações de dispositivos implementarem um mecanismo reservado para restringir apps (por exemplo, mudar ou restringir comportamentos da API descritos no SDK) e esse mecanismo for mais restritivo que o bucket restrito de apps em espera, elas:

• [C-1-1] PRECISA permitir que o usuário confira a lista de apps restritos.
• [C-1-2] PRECISA fornecer recursos ao usuário para ativar / desativar todas essas restrições reservadas em cada app.

• [C-1-3] NÃO PRECISA aplicar essas restrições de propriedade automaticamente sem evidência de mau comportamento de integridade do sistema, mas PODE: aplicar as restrições a apps após detecção de mau comportamento de integridade do sistema, como wakelocks travados, serviços de longa duração e outros critérios. Os critérios PODEM ser determinados por implementadores de dispositivos, mas PRECISAM estar relacionados ao impacto do app na integridade do sistema. Outros critérios que não são puramente relacionados à integridade do sistema, como a falta de popularidade do app no mercado, NÃO PODEM ser usados como critérios.

• [C-1-4] Não deve aplicar automaticamente essas restrições de propriedade a apps quando um usuário desativou essas restrições manualmente e PODE sugerir que o usuário aplique essas restrições reservadas.

• [C-1-5] PRECISA informar os usuários se essas restrições de propriedade forem aplicadas automaticamente a um app. Essas informações PRECISAM ser fornecidas no período de 24 horas antes da aplicação dessas restrições proprietárias.

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

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

• [C-1-8] PRECISA 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 em primeiro plano.

• [C-1-10] PRECISA fornecer um documento ou site público e claro que descreva como as restrições reservadas são aplicadas. O documento ou site PRECISA estar disponível para links nos documentos do SDK do Android e incluir:

  • Condições de acionamento de restrições reservadas.
  • O que e como um app pode ser restrito.
  • Como um app pode ser isento dessas restrições.
  • Como um app pode solicitar isenção de restrições de propriedade se oferecer suporte a 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] estará isento.

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

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

3.5.2. Hibernação do aplicativo

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

• [C-1-1] PRECISA atender a todos os requisitos da seção 3.5.1, exceto [C-1-6] e [C-1-3].
• [C-1-2] É PRECISO aplicar a restrição para um usuário apenas quando há evidências de que ele não usou o app há algum tempo. É RECOMENDADO que essa duração seja de um mês ou mais. O uso PRECISA ser definido pela interação explícita do usuário com a API UsageStats#getLastTimeVisible() ou por qualquer coisa que faça com que um app saia do estado de fechamento forçado, incluindo vinculações de serviço, vinculações do provedor de conteúdo, transmissões explícitas etc., que serão rastreadas por uma nova API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] PRECISA aplicar restrições que afetem todos os usuários do dispositivo apenas quando houver evidências de que o pacote não foi usado por ALGUM usuário por um período de tempo. É RECOMENDADO que a duração seja de um mês ou mais.
• [C-1-4] NÃO PODE deixar o app incapaz de responder a intents de atividade, vinculações de serviço, solicitações de provedor de conteúdo ou transmissões explícitas.

A hibernação do app no AOSP atende aos requisitos acima.

3,6 Namespaces da 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 nenhuma modificação proibida (confira abaixo) nesses namespaces de pacote:

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

Ou seja, eles:

• [C-0-1] NÃO PODE modificar as APIs expostas publicamente na Plataforma Android mudando qualquer método ou assinatura de classe ou removendo classes ou campos de classe.
• [C-0-2] NÃO PODE adicionar elementos expostos publicamente (como classes, interfaces, 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", conforme 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 PODE afetar o comportamento declarado e a assinatura na linguagem Java de nenhuma API exposta publicamente.
• [C-0-4] NÃO PODE ser anunciado nem exposto a 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 referente a outra organização. Por exemplo, os implementadores de dispositivos NÃO PODEM adicionar APIs ao com.google.* ou namespace semelhante. Somente o Google pode fazer isso. Da mesma forma, o Google NÃO PODE adicionar APIs aos namespaces de outras empresas.
• [C-0-6] PRECISA ser empacotado em uma biblioteca compartilhada do Android para que apenas os apps que as usam explicitamente (por meio do 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 de outra organização, conforme descrito aqui.

Se um implementador de dispositivo propuser melhorar um dos namespaces de pacote acima, como adicionar uma nova funcionalidade útil a uma API existente ou adicionar uma nova API, ele PRECISA acessar source.android.com e iniciar o processo para contribuir com mudanças e código, de acordo com as informações nesse site.

Observe que as restrições acima correspondem às convenções padrão para nomear APIs na linguagem de programação Java. O objetivo desta seção é simplesmente reforçar essas convenções e fazer a vinculação delas com a inclusão nesta Definição de compatibilidade.

3,7 Compatibilidade de ambiente de execução

Implementações de dispositivos:

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

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

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

• Realize 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 valores mínimos, e as implementações de dispositivos podem alocar mais memória por app.

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
pequeno/normal	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)
	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 da interface do usuário

3.8.1. Tela de início (tela inicial)

O Android inclui um aplicativo de tela inicial (tela inicial) e suporte para apps de terceiros para substituir a tela inicial do dispositivo.

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

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

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

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

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

• [C-3-1] PRECISA informar false para ShortcutManager.isRequestPinShortcutSupported().

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

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

Se as implementações do dispositivo incluírem um app de tela de início padrão que mostra selos para os ícones do app, elas:

• [C-5-1] PRECISA respeitar o método da API NotificationChannel.setShowBadge(). Em outras palavras, mostre uma funcionalidade visual associada ao ícone do app se o valor estiver definido como true e não mostre nenhum esquema de selo de ícone do app quando todos os canais de notificação tiverem definido o valor como false.
• Podem substituir os selos de ícone do app pelo esquema reservado de selos quando aplicativos de terceiros indicarem suporte ao esquema de selos reservado com o uso de APIs reservadas, mas DEVE usar os recursos e valores fornecidos pelas APIs de selos de notificação descritas no SDK, como a Notification.Builder.setNumber() e a API Notification.Builder.setBadgeIconType().

Se as implementações de dispositivos oferecerem suporte a ícones monocromáticos, esses ícones:

• [C-6-1] PRECISA ser usada somente quando o usuário as ativar explicitamente (por exemplo, por meio do menu "Configurações" ou do menu de seleção de plano de fundo).

3.8.2. Widgets

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

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

• [C-1-1] PRECISA declarar suporte ao recurso da plataforma android.software.app_widgets.
• [C-1-2] PRECISA incluir suporte integrado para AppWidgets e expor funcionalidades da interface do usuário para adicionar, configurar, visualizar e remover AppWidgets.
• [C-1-3] PRECISA renderizar widgets que tenham 4 x 4 no tamanho de grade padrão. Consulte as Diretrizes de design de widgets de apps na documentação do SDK do Android para mais detalhes.
• PODE oferecer suporte a widgets de aplicativos 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] PRECISA informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] PRECISA ter affordance do usuário antes de adicionar um atalho solicitado pelos apps pelo método AppWidgetManager.requestPinAppWidget() da API.

3.8.3. Notificações

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

3.8.3.1. Apresentação de notificações

Se as implementações de dispositivos permitirem que apps de terceiros notifiquem 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 a implementação de um dispositivo incluir uma vibração, 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 ambiente autônomo. Esse comportamento é detalhado na seção 7.
• [C-1-2] PRECISA renderizar corretamente todos os recursos (ícones, arquivos de animação etc.) fornecidos nas APIs ou no guia de estilo de ícone da barra de status/sistema, embora possam oferecer uma experiência do usuário alternativa para notificações que não seja a fornecida pela implementação de referência do Android Open Source.
• [C-1-3] PRECISA respeitar e implementar corretamente os comportamentos descritos para as APIs para atualizar, remover e agrupar notificações.
• [C-1-4] PRECISA fornecer o comportamento completo da API NotificationChannel documentada no SDK.
• [C-1-5] PRECISA fornecer uma funcionalidade de usuário para bloquear e modificar uma determinada notificação de app de terceiros por cada canal e nível de pacote de app.
• [C-1-6] também PRECISA fornecer uma funcionalidade de usuário para mostrar canais de notificação excluídos.
• [C-1-7] PRECISA renderizar corretamente todos os recursos (imagens, adesivos, ícones etc.) fornecidos por Notification.MessagingStyle ao lado do texto da notificação, sem exigir mais interações com o usuário. Por exemplo, é NECESSÁRIO mostrar todos os recursos, incluindo os ícones fornecidos pelo android.app.Person, em uma conversa em grupo definida pelo setGroupConversation.
• [C-SR-1] É FORTEMENTE RECOMENDADO para fornecer uma funcionalidade para o usuário controlar as notificações expostas a apps que receberam a permissão de listener de notificações. A granularidade PRECISA ser de modo que o usuário possa controlar para cada listener de notificações quais tipos de notificação estão conectados a ele. Os tipos PRECISAM incluir notificações de "conversas", "alertas", "silenciosos" e "em andamento importantes".
• [C-SR-2] são FORTEMENTE RECOMENDADOS fornecem recursos para que os usuários especifiquem apps a serem excluídos da notificação de qualquer listener de notificação específico.
• [C-SR-3] É FORTEMENTE RECOMENDADO para mostrar automaticamente uma funcionalidade de usuário para bloquear a notificação de um determinado app de terceiros por cada canal e nível de pacote de app depois que o usuário dispensar essa notificação várias vezes.
• DEVE ser compatível com notificações avançadas.
• DEVE apresentar algumas notificações de prioridade mais alta como notificações de alerta.
• DEVE ter um recurso do usuário para adiar notificações.
• PODE gerenciar apenas a visibilidade e o momento em que apps de terceiros podem notificar os usuários sobre eventos importantes para reduzir problemas de segurança, como distração do motorista.

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

Implementações de dispositivos:

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

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

• [C-SR-5] É MUITO RECOMENDADO exibir esta conversa como um balão. A implementação do AOSP atende a esses requisitos com a interface, as configurações e a tela de início padrão do sistema.

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

• [C-2-1] PRECISA usar os recursos exatos fornecidos pela classe de API Notification.Style e as subclasses dela para os elementos de recurso apresentados.
• DEVE apresentar todos os elementos de recursos (por exemplo, ícones, títulos e textos de resumo) definidos na classe de API Notification.Style e as subclasses dela.

As notificações de alerta são apresentadas ao usuário à medida que 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] PRECISA usar a visualização e os recursos das notificações de alerta, conforme descrito na classe da API Notification.Builder quando elas são apresentadas.
• [C-3-2] PRECISA mostrar as ações fornecidas pelo Notification.Builder.addAction() com o conteúdo da notificação sem outras interações 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 (após a ativação explícita do usuário) recebam uma cópia de todas as notificações conforme são postadas ou atualizadas.

Implementações de dispositivos:

• [C-0-1] PRECISA atualizar todas as notificações de maneira correta e imediata para todos os serviços de listener instalados e ativados pelo usuário, incluindo todos os metadados anexados ao objeto de notificação.
• [C-0-2] PRECISA respeitar a chamada de API snoozeNotification(), dispensar a notificação e fazer um callback após a duração do adiamento definida na chamada de API.

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

• [C-1-1] PRECISA refletir corretamente o status das notificações adiadas, usando APIs padrão, como NotificationListenerService.getSnoozedNotifications().
• [C-1-2] PRECISA disponibilizar essa funcionalidade de usuário para adiar as notificações de cada app de terceiros instalado, a menos que sejam de serviços persistentes/em primeiro plano.

3.8.3.3. Não perturbe (Não perturbe)/ Modo de prioridade

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

• [C-1-1] PRECISA, quando a implementação do dispositivo fornecer um meio para o usuário conceder ou negar o acesso de apps de terceiros à configuração da política de DND, exibir as regras automáticas de DND criadas pelos aplicativos junto com as regras criadas e predefinidas pelo usuário.
• [C-1-3] PRECISA respeitar os valores de suppressedVisualEffects transmitidos pela NotificationManager.Policy. Se um app tiver definido qualquer uma das flags supPRESSED_EF_SCREEN_OFF ou supPRESSED_EF_SCREEN_ON, DEVE indicar ao usuário que os efeitos visuais foram suprimidos no menu de configurações de NDN.

3.8.4. APIs Assist

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

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

• [C-2-1] PRECISA indicar claramente para o usuário final quando o contexto é compartilhado, de uma das seguintes formas:
  • Sempre que o app assistivo acessa o contexto, mostrando uma luz branca ao redor das bordas da tela que atendem ou excedem a duração e o brilho da implementação do Android Open Source Project.
  • Para o app assistivo pré-instalado, fornecer uma funcionalidade do usuário a menos de duas navegações do menu de configurações padrão da entrada de texto por voz e do app assistente e compartilhar o contexto apenas quando o app assistivo for invocado explicitamente pelo usuário com uma entrada de hotword ou de tecla de navegação assistida.
• [C-2-2] A interação designada para iniciar o app assistivo, conforme descrito na seção 7.2.3, PRECISA iniciar o app de assistência selecionado pelo usuário. Em outras palavras, 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 ao usuário final strings não modais curtas que desaparecem após um breve período e usar a API de tipo de janela TYPE_APPLICATION_OVERLAY para mostrar janelas de alerta como uma sobreposição sobre outros apps.

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

• [C-1-1] PRECISA fornecer uma funcionalidade do usuário para impedir que um app mostre janelas de alerta que usam a TYPE_APPLICATION_OVERLAY . A implementação do AOSP atende a esse requisito porque tem controles na aba de notificações.

• [C-1-2] PRECISA respeitar a API Toast e mostrar avisos dos aplicativos para os usuários finais de maneira altamente visível.

3.8.6. Temas

O Android oferece "temas" como um mecanismo para os aplicativos aplicarem estilos em toda a atividade ou o aplicativo.

O Android inclui uma família de temas "Holo" e "Material" como um conjunto de estilos definidos que os desenvolvedores de apps usam se quiserem combinar com a aparência do tema Holo, conforme definido pelo SDK do Android.

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

• [C-1-1] NÃO PODE mudar nenhum dos atributos de tema Holo expostos a aplicativos.
• [C-1-2] PRECISA oferecer suporte à família de temas "Material" e NÃO PODE mudar nenhum dos atributos de tema do Material ou os recursos expostos a aplicativos.

• [C-1-3] PRECISA definir a família de fontes "sans-serif" como Roboto versão 2.x para os idiomas com suporte da Roboto ou fornecer uma affordance de usuário para mudar a fonte usada na família de fontes "sans-serif" para Roboto versão 2.x para os idiomas compatíveis com a Roboto.

• [C-1-4] PRECISA 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] PRECISA gerar paletas de tons de cores dinâmicas usando estilos de temas de cores enumerados na documentação do Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.theme_styles), ou seja, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW e FRUIT_SALAD.

  A "Cor de origem" é usada para gerar paletas tonais de cores dinâmicas quando enviada com android.theme.customization.system_palette, conforme documentado em Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES.

• [C-1-6] PRECISA ter um valor de chroma CAM16 de 5 ou maior.

  • DEVE ser derivada do plano de fundo via 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 que os desenvolvedores de apps usam se quiserem combinar com 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 a aplicativos.

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

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

• [C-2-1] PRECISA usar a cor branca nos í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 que um app solicite uma barra de status clara usando a flag WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
• [C-2-2] As implementações de dispositivos Android PRECISAM mudar a cor dos ícones de status do sistema para preto (para mais detalhes, consulte R.style) quando um app solicita uma barra de status clara.

3.8.7. Planos fundo interativos

O Android define um tipo de componente e a API e o ciclo de vida correspondentes que permitem que os 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 plano de fundo atrás de outros aplicativos.

O hardware é considerado capaz de executar planos de fundo interativos de forma confiável se pode executar todos os planos de fundo interativos, sem limitações de funcionalidade, com um frame rate razoável e sem efeitos adversos em outros apps. Se as limitações no hardware fizerem com que os planos de fundo e/ou aplicativos falhem, não funcionem, consumam excesso de energia da CPU ou da bateria ou sejam executados em frame rates inaceitavelmente baixos, o hardware será considerado incapaz de executar o plano de fundo interativo. Por exemplo, alguns planos de fundo interativos podem usar um contexto do OpenGL 2.0 ou 3.x para renderizar o conteúdo. O plano de fundo interativo não será executado de maneira confiável em hardwares que não tenham suporte a vários contextos do OpenGL, já que o uso do plano de fundo interativo de um contexto do OpenGL pode entrar em conflito com outros aplicativos que também usam esse contexto.

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

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

• [C-1-1] PRECISA 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 de nível de sistema para alternar tarefas e mostrar atividades e tarefas acessadas recentemente usando uma imagem em miniatura do estado gráfico do app no momento em que o usuário saiu pela última vez.

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

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

• [C-1-1] PRECISA oferecer suporte a pelo menos até sete atividades exibidas.
• DEVE exibir pelo menos o título de quatro atividades por vez.
• [C-1-2] PRECISA implementar o comportamento de fixação da tela e fornecer ao usuário um menu de configurações para ativar ou desativar o recurso.
• DEVE exibir a cor de destaque, o ícone e o título da tela em "Recentes".
• DEVE exibir uma affordance de fechamento ("x"), mas PODE postergar 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 alternância rápida entre os dois apps usados mais recentemente, quando a tecla de função Recentes for tocada duas vezes.
• DEVE acionar o modo de várias janelas de tela dividida, se compatível, quando a tecla de funções recentes for pressionada e manter pressionada.
• PODE exibir recentes afiliadas como um grupo que é movido em conjunto.
• [C-SR-1] É RECOMENDADO usar a interface do usuário upstream do Android (ou uma interface semelhante baseada em miniatura) para a tela de visão geral.

3.8.9. Gerenciamento de entradas

O Android oferece suporte ao gerenciamento de entrada e a editores de métodos de entrada de terceiros.

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

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

3.8.10. Controle de mídia da tela de bloqueio

A API Remote Control Client foi descontinuada no Android 5.0 e substituída pelo Modelo de notificação de mídia, que permite que aplicativos de mídia se integrem aos controles de reprodução mostrados na tela de bloqueio.

3.8.11. Protetores de tela (antigo Dreams)

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

3.8.12. Localização

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] PRECISA exibir o status atual da localização no menu "Localização" em "Configurações".
• [C-1-3] NÃO PODE mostrar os modos de localização no menu "Local" em "Configurações".

3.8.13. Unicode e fonte

O Android inclui suporte para os caracteres de emoji definidos no Unicode 10.0 (link em inglês).

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

• [C-1-1] PRECISA renderizar esses caracteres de emoji em um glifo de cor.
• [C-1-2] PRECISA 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 as linguagens disponíveis no dispositivo.
  • Cobertura completa em Unicode 7.0 de latim, grego e cirílico, incluindo os intervalos latinos estendidos 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 PODE remover nem modificar NotoColorEmoji.tff na imagem do sistema. (É aceitável adicionar uma nova fonte de emoji para substituir o emoji em NotoColorEmoji.tff)
• DEVE oferecer suporte ao tom de pele e aos diversos emojis de família, conforme especificado no Relatório técnico do Unicode no 51 (link em inglês).

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

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

O Android inclui suporte para renderizar fontes de Mianmar. Mianmar tem várias fontes não compatíveis com Unicode, mais conhecidas como "Zawgyi", para renderizar os idiomas birmaneses.

Se as implementações de dispositivos forem compatíveis com o birmanês, elas:

• [C-2-1] PRECISA renderizar texto com uma fonte compatível com Unicode como padrão. Fontes não compatíveis com Unicode NÃO PODEM ser definidas como fonte padrão, a menos que o usuário a escolha no seletor de idioma.
• [C-2-2] PRECISA oferecer suporte a uma fonte Unicode e a uma fonte não compatível com Unicode se uma fonte não compatível com Unicode for compatível com o dispositivo. Uma fonte não compatível com Unicode NÃO PODE remover nem substituir a fonte Unicode.
• [C-2-3] PRECISA renderizar texto com fonte não compatível com Unicode SOMENTE SE um código de idioma com código de script Qaag for especificado (por exemplo, my-Qaag). Nenhum outro código ISO de idioma ou região (atribuído, não atribuído ou reservado) pode ser usado para se referir a fontes não compatíveis com Unicode em Mianmar. 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 dispositivos puderem mostrar várias atividades ao mesmo tempo, elas:

• [C-1-1] PRECISA implementar esses modos de várias janelas de acordo com os comportamentos de aplicativos e APIs descritos na documentação de suporte do modo de várias janelas do SDK do Android e atender a estes requisitos:
• [C-1-2] PRECISA respeitar o android:resizeableActivity, que é definido por um app no arquivo AndroidManifest.xml, conforme descrito neste SDK.
• [C-1-3] NÃO PODE oferecer o modo de tela dividida ou forma livre se a altura da tela for menor que 440 dp e a largura dela for menor que 440 dp.
• [C-1-4] Uma atividade NÃO PODE ser redimensionada para um tamanho menor que 220 dp em modos de várias janelas que não sejam o 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 de dispositivos oferecerem suporte ao modo de várias janelas e ao modo de tela dividida, elas:

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

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

• [C-3-1] PRECISA iniciar atividades no modo picture-in-picture de várias janelas quando o app estiver: * Segmentar o nível 26 da API ou mais recente e declarar android:supportsPictureInPicture * Segmentar o nível 25 da API ou anterior e declarar android:resizeableActivity e android:supportsPictureInPicture.
• [C-3-2] PRECISA expor as ações na SystemUI, conforme especificado pela atividade do PIP atual com a API setActions().
• [C-3-3] PRECISA oferecer suporte a proporções maiores ou iguais a 1:2,39 e menores ou iguais a 2,39:1, conforme especificado pela atividade PIP usando a API setAspectRatio().
• [C-3-4] PRECISA usar KeyEvent.KEYCODE_WINDOW para controlar a janela do PIP. Se esse modo não estiver implementado, a chave PRECISA estar disponível para a atividade em primeiro plano.
• [C-3-5] PRECISA fornecer uma funcionalidade do usuário para bloquear a exibição de um app no modo PIP. A implementação do AOSP atende a esse requisito por ter controles na aba de notificações.

• [C-3-6] PRECISA alocar a largura e a altura mínimas abaixo para a janela do PIP quando um aplicativo não declarar nenhum valor para AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight:

  • Dispositivos com o Configuration.uiMode definido diferente de UI_MODE_TYPE_TELEVISION PRECISAM alocar uma largura e altura mínimas de 108 dp.
  • Os 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. Recorte da 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 funcionar para um aplicativo devido a um corte da tela ou uma tela curvada nas bordas.

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

• [C-1-5] NÃO PODE ter cortes se a proporção do dispositivo for de 1,0 (1:1).
• [C-1-2] NÃO PODE ter mais de um corte por borda.
• [C-1-3] PRECISA respeitar as flags de corte da tela definidas pelo app com a API WindowManager.LayoutParams, conforme descrito no SDK.
• [C-1-4] PRECISA informar os valores corretos de todas as métricas de corte definidas na API DisplayCutout.

3.8.16. Controles do dispositivo

O Android inclui as APIs ControlsProviderService e Control para permitir que aplicativos de terceiros publiquem controles de dispositivos para status e ação rápidos para os usuários.

Consulte a Seção 2_2_3 para ver os requisitos específicos dos dispositivos.

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 qualquer componente, atividade, serviço ou por qualquer conexão de rede, sem 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 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 de qualquer item ClipData em que ClipData.getDescription().getExtras() contenha android.content.extra.IS_SENSITIVE, elas:

• [C-1-1] PRECISA encobrir 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 reconhecimento de segurança executem funções de administração de dispositivos no nível do sistema, como aplicar políticas de senha ou realizar a limpeza remota, usando a API Android Device Administration.

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

• [C-1-1] PRECISA declarar android.software.device_admin.
• [C-1-2] PRECISA oferecer suporte ao provisionamento do proprietário do dispositivo, conforme descrito na seção 3.9.1 e na seção 3.9.1.1.

3.9.1 Provisionamento de dispositivos

3.9.1.1 Provisionamento do proprietário do dispositivo

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

• [C-1-1] PRECISA ser compatível com a inscrição de um cliente Device Policy (DPC) como um app proprietário do dispositivo, conforme descrito abaixo:
  • Quando a implementação do dispositivo não tem usuários nem dados do usuário configurados, ela:
    • [C-1-5] PRECISA registrar o aplicativo DPC como proprietário do dispositivo ou permitir que o app DPC escolha se quer se tornar proprietário do dispositivo ou proprietário do perfil, caso o dispositivo declare suporte a comunicações a curta distância (NFC, na sigla em inglês) usando a flag de recurso android.hardware.nfc e receba uma mensagem NFC contendo um registro com o tipo MIME MIME_TYPE_PROVISIONING_NFC.
    • [C-1-8] PRECISA enviar a intent ACTION_GET_PROVISIONING_MODE após o provisionamento do proprietário do dispositivo ser acionado para que o app DPC possa escolher se vai se tornar 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 com base no contexto que há apenas uma opção válida.
    • [C-1-9] PRECISA enviar a intent ACTION_ADMIN_POLICY_COMPLIANCE ao app Proprietário do dispositivo se esse proprietário for estabelecido durante o provisionamento, independente do método de provisionamento usado. O usuário não pode continuar no assistente de configuração até que o app Proprietário do dispositivo seja concluído.
  • Quando a implementação do dispositivo tem usuários ou dados do usuário, ela:
    • [C-1-7] NÃO PODE mais registrar nenhum aplicativo DPC como o app Proprietário do dispositivo.
• [C-1-2] PRECISA mostrar um aviso de divulgação adequado (conforme mencionado no AOSP) e receber o consentimento afirmativo do usuário final antes de um app ser definido como proprietário do dispositivo, a menos que o dispositivo esteja configurado de maneira programática para o modo de demonstração na loja antes da interação do usuário final na tela.

Se as implementações de dispositivos declararem android.software.device_admin, mas também incluirem uma solução reservada de gerenciamento de dispositivos e fornecerem um mecanismo para promover um aplicativo configurado na solução como "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] PRECISA ter um processo 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 a um "Proprietário do dispositivo".
• [C-2-2] PRECISA mostrar a mesma declaração de consentimento do proprietário do dispositivo AOSP que o fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o app DPC como "Proprietário do dispositivo".
• [C-2-3] NÃO PODE codificar o consentimento nem impedir o uso de outros apps do proprietário do dispositivo.

3.9.1.2 Provisionamento de perfil gerenciado

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

• [C-1-1] PRECISA implementar as APIs para que um aplicativo controlador de política de dispositivo (DPC, na sigla em inglês) se torne 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 à implementação do AOSP.

• [C-1-3] PRECISA fornecer as seguintes affordances do usuário nas Configurações para indicar ao usuário quando uma determinada função do sistema foi desativada pelo Device Policy Controller (DPC):

  • Um ícone consistente ou outra funcionalidade do usuário (por exemplo, o ícone de informações upstream do AOSP) para representar quando uma configuração específica é restrita por um administrador do dispositivo.
  • Uma breve mensagem de explicação, conforme fornecido pelo administrador do dispositivo por meio do setShortSupportMessage.
  • O ícone do aplicativo DPC.

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

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

• [C-1-6] PRECISA enviar a intent ACTION_GET_PROVISIONING_MODE após o provisionamento do proprietário do perfil ser acionado para que o app DPC possa escolher se vai se tornar proprietário do dispositivo ou do perfil, exceto quando o provisionamento é acionado pela intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] PRECISA enviar a intent ACTION_ADMIN_POLICY_COMPLIANCE para o perfil de trabalho quando um proprietário do 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 continuar no assistente de configuração até que o app Proprietário do perfil seja concluído.

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

3.9.2 Suporte de perfil gerenciado

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

• [C-1-1] PRECISA oferecer suporte aos perfis gerenciados usando as APIs android.app.admin.DevicePolicyManager.
• [C-1-2] PRECISA permitir a criação de apenas um perfil gerenciado.
• [C-1-3] PRECISA usar um selo de ícone (semelhante ao de trabalho upstream do AOSP) para representar os apps e widgets gerenciados e outros elementos de interface com selo, como Recentes e Notificações.
• [C-1-4] PRECISA mostrar um ícone de notificação (semelhante ao crachá de trabalho upstream do AOSP) para indicar quando o usuário está em um app de perfil gerenciado.
• [C-1-5] PRECISA exibir 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 existe um perfil gerenciado, é NECESSÁRIO mostrar uma affordance visual no "Seletor" da 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 houver um perfil gerenciado, será NECESSÁRIO expor as seguintes affordances do usuário para o usuário principal e o perfil gerenciado:
  • Contabilização separada do uso de bateria, localização, dados móveis e armazenamento para o usuário principal e o perfil gerenciado.
  • Gerenciamento independente de aplicativos de VPN instalados no usuário principal ou no perfil gerenciado.
  • Gerenciamento independente de aplicativos instalados no usuário principal ou no perfil gerenciado.
  • Gerenciamento independente de contas no perfil do usuário principal ou gerenciado.
• [C-1-8] PRECISA garantir que os apps pré-instalados de discador, contatos e mensagens possam pesquisar e procurar informações do autor da chamada no perfil gerenciado (se houver) e no perfil principal, se o Controlador de políticas do dispositivo permitir.
• [C-1-9] PRECISA garantir que ele atenda a todos os requisitos de segurança aplicáveis a um dispositivo com vários usuários ativados (consulte a seção 9.5), mesmo que o perfil gerenciado não seja contabilizado como outro usuário além do usuário principal.

Se as implementações de dispositivos 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, atendendo aos requisitos a seguir para conceder acesso apenas a apps em execução em um perfil gerenciado.
  • As implementações de dispositivos PRECISAM respeitar a intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrar uma interface para configurar uma credencial separada da tela de bloqueio 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 Android Open Source Project.
  • As políticas de senha do DPC PRECISAM ser aplicadas apenas às credenciais da tela de bloqueio do perfil gerenciado, a menos que sejam chamadas na instância DevicePolicyManager retornada por getParentProfileInstance.
• Quando os contatos do perfil gerenciado aparecem no registro de chamadas pré-instalado, na interface em chamada, nas notificações de chamadas em andamento e perdidas, os contatos e os apps de mensagens DEVEM receber o mesmo selo usado para indicar os apps de perfil gerenciado.

3.9.3 Suporte gerenciado ao usuário

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

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

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

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

3.9.4 Requisitos do papel de gerenciamento de políticas do dispositivo

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

• [C-1-1] PRECISA oferecer suporte ao papel de gerenciamento de políticas do dispositivo, conforme definido na seção 9.1. O aplicativo que detém 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 pelo certificado de assinatura, a menos que o aplicativo seja pré-carregado.

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

• [C-2-1] As implementações de dispositivos PRECISAM oferecer suporte ao provisionamento sem um aplicativo detentor da função de gerenciamento de políticas do dispositivo (o AOSP fornece 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 estar instalado em todos os perfis de um usuário.
• [C-3-2] As implementações de dispositivos podem definir um aplicativo que atualiza o detentor 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ências a navegar nos dispositivos com mais facilidade. Além disso, o Android oferece APIs de plataforma que permitem que implementações do serviço de acessibilidade recebam callbacks para eventos do usuário e do sistema e gerem mecanismos de feedback alternativos, como conversão de texto em voz, retorno tátil e navegação por trackball/botão direcional.

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

• [C-1-1] PRECISA fornecer uma implementação do framework de acessibilidade do Android, conforme descrito na documentação do SDK das APIs de acessibilidade.
• [C-1-2] PRECISA gerar eventos de acessibilidade e entregar o AccessibilityEvent adequado para todas as implementações de AccessibilityService registradas, conforme documentado no SDK.
• [C-1-4] PRECISA fornecer uma funcionalidade de usuário para controlar os serviços de acessibilidade que declaram a AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_Button. As implementações de dispositivos com uma barra de navegação do sistema DEVEM permitir que o usuário tenha a opção de ter um botão na barra de navegação do sistema para controlar esses serviços.

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

• [C-2-1] PRECISA implementar esses serviços de acessibilidade pré-instalados como apps com reconhecimento de inicialização direta quando o armazenamento de dados é criptografado com criptografia baseada em arquivos (FBE, na sigla em inglês).
• DEVEM 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 exibição e os gestos de ampliação.

3,11. Conversão de texto em voz

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

Se implementações de dispositivo relatam o recurso android.hardware.audio.output, elas:

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

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

• [C-2-1] PRECISA fornecer recursos para que o usuário selecione um mecanismo TTS para uso no nível do sistema.

3,12. TV Input Framework

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

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

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

3,13 Configurações rápidas

O Android oferece um componente de interface para configurações rápidas que permite o acesso rápido a ações usadas com frequência ou urgentes.

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

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

3,14 Interface de mídia

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

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

• [C-1-3] PRECISA mostrar o ícone do aplicativo de terceiros sempre que exibir conteúdo fornecido por esse aplicativo.

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

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

3,15 Instant Apps

Se as implementações de dispositivos oferecerem suporte aos Instant Apps, elas PRECISAM atender aos seguintes requisitos:

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

• As implementações de dispositivos PRECISAM fornecer as funcionalidades do usuário abaixo para interagir com os Instant Apps. O AOSP atende aos requisitos da interface padrão do sistema, da tela de início e das configurações. Implementações de dispositivos:

  • [C-1-5] PRECISA fornecer recursos de usuário para visualizar e excluir Instant Apps armazenados localmente em cache para cada pacote de app individual.
  • [C-1-6] PRECISA fornecer uma notificação persistente para o usuário, que pode ser recolhida enquanto um app instantâneo está em execução em primeiro plano. Essa notificação do usuário PRECISA incluir que o Instant Apps não exige instalação e fornecer uma funcionalidade de usuário que o direcione para a tela de informações do aplicativo nas configurações. Para Apps instantâneos iniciados por intents da Web, conforme definido por uma intent com ação definida como Intent.ACTION_VIEW e com um esquema "http" ou "https", uma funcionalidade de usuário adicional DEVE permitir que o usuário não inicie o app instantâneo e inicie o link associado com o navegador da Web configurado, caso um navegador esteja disponível no dispositivo.
  • [C-1-7] PRECISA permitir que Apps instantâneos em execução sejam acessados pela função Recentes se ela estiver disponível no dispositivo.

• [C-1-8] É NECESSÁRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para as intents listadas neste SDK e tornar as intents visíveis para os Apps instantâneos.

3,16 Pareamento de dispositivo complementar

O Android inclui suporte ao pareamento de dispositivos complementares para gerenciar de forma mais eficaz a associação a dispositivos complementares, além de fornecer a API CompanionDeviceManager para que os apps acessem esse recurso.

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

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

3.17. Apps pesados

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

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

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

• [C-1-1] PRECISA ignorar o atributo cantSaveState definido pelos apps e NÃO PODE mudar o comportamento do app com base nesse atributo.

3,18. Contatos

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

RawContacts são "associados" 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 criados com pelo menos um valor não nulo para as colunas ACCOUNT_NAME e ACCOUNT_TYPE.

Implementações de dispositivos:

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

Se as implementações de dispositivos usarem uma conta local personalizada, faça o seguinte:

• [C-1-1] O ACCOUNT_NAME da conta local personalizada PRECISA ser retornado por ContactsContract.RawContacts.getLocalAccountName.
• [C-1-2] O ACCOUNT_TYPE da conta local personalizada PRECISA ser retornado por ContactsContract.RawContacts.getLocalAccountType.
• [C-1-3] Os contatos brutos inseridos por aplicativos de terceiros 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 PRECISAM 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 limpeza imediata dos contatos brutos (como se o parâmetro CALLER_IS_SYNCADAPTER fosse definido como verdadeiro), mesmo que o parâmetro CALLER\_IS\_SYNCADAPTER fosse definido como falso ou não fosse especificado.

4. Compatibilidade do empacotamento de aplicativos

Implementações de dispositivos:

• [C-0-1] PRECISA 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, as implementações de dispositivos são RECOMENDADAS para usar o sistema de gerenciamento de pacotes da implementação de referência do AOSP.

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

• [C-0-3] NÃO PODE estender os formatos de bytecode .apk, Manifesto do Android, Bytecode Dalvik ou RenderScript de forma a impedir que esses arquivos sejam instalados e executados corretamente em outros dispositivos compatíveis.

• [C-0-4] NÃO PODE permitir apps que não sejam o "instalador de registro" atual para o pacote desinstalarem silenciosamente o app sem qualquer 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 pacote do sistema que processa a intent PACKAGE_NEEDS_VERIFICATION e o app do gerenciador de armazenamento que processa a intent ACTION_MANAGE_STORAGE.

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

• [C-0-6] NÃO É POSSÍVEL instalar pacotes de apps de fontes desconhecidas, a menos que o app que solicita a instalação atenda a todos os requisitos a seguir:

  • Ele PRECISA declarar a permissão REQUEST_INSTALL_PACKAGES ou ter a android:targetSdkVersion definida como 24 ou menor.
  • Ele PRECISA ter recebido permissão do usuário para instalar apps de fontes desconhecidas.

• DEVE fornecer uma affordance para o usuário conceder/revogar a permissão de instalação de apps de fontes desconhecidas por app, mas PODERÁ optar por implementar como um ambiente autônomo e retornar RESULT_CANCELED para startActivityForResult(), se a implementação do dispositivo não permitir que os usuários tenham essa escolha. No entanto, mesmo nesses casos, eles DEVEM indicar ao usuário por que não há essa opção apresentada.

• [C-0-7] É NECESSÁRIO mostrar uma caixa de diálogo de aviso com a string de aviso fornecida pela API do sistema PackageManager.setHarmfulAppWarning para o usuário antes de iniciar uma atividade em um aplicativo que tenha sido marcado como possivelmente prejudicial pela mesma API do sistema PackageManager.setHarmfulAppWarning.

• DEVEM oferecer recursos para que o usuário opte por desinstalar ou iniciar um aplicativo na caixa de diálogo de aviso.

• [C-0-8] PRECISA implementar o suporte ao sistema de arquivos incremental, conforme documentado aqui.

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

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

5. Compatibilidade multimídia

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte aos formatos de mídia, codificadores, decodificadores, tipos de arquivo e formatos de contêiner definidos na seção 5.1 para cada codec declarado por MediaCodecList.
• [C-0-2] PRECISA declarar e informar o suporte aos codificadores e decodificadores disponíveis para aplicativos de terceiros via MediaCodecList.
• [C-0-3] PRECISA ser capaz de decodificar e disponibilizar corretamente para apps de terceiros todos os formatos que podem codificar. Isso inclui todos os bitstreams gerados pelos codificadores e os perfis informados no CamcorderProfile.

Implementações de dispositivos:

• DEVE visar a latência mínima do codec, ou seja,
  • NÃO DEVE consumir e armazenar buffers de entrada e retornar buffers de entrada apenas uma vez processados.
  • NÃO DEVE manter os buffers decodificados por mais tempo do que o especificado pelo padrão (por exemplo, SPS).
  • NÃO DEVE manter buffers codificados por mais tempo do que o exigido pela estrutura GOP.

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

O Google e a Open Handset Alliance nem o Google declaram 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 que as implementações desse código, inclusive em software de código aberto ou shareware, podem exigir licenças de patente dos respectivos detentores de patentes.

5.1. Codecs de mídia

5.1.1. Codificação de áudio

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

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

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

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

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

5.1.2. Decodificação de áudio

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

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

• [C-1-1] Perfil AAC MPEG-4 (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 ISO/IEC 23003-3 estendido HE AAC, que inclui o perfil de referência da USAC e o perfil de controle de intervalo dinâmico ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vórbis
• [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 serve apenas para decodificação, e um dispositivo tem permissão para fazer downsample e 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 fluxos multicanal (ou seja, mais de dois canais) para PCM usando o decodificador de áudio AAC padrão na API android.media.MediaCodec, o seguinte PRECISA ser aceito:

• [C-2-1] A decodificação PRECISA ser feita sem downmix (por exemplo, um stream AAC de 5.0 precisa ser decodificado para cinco canais de PCM, um stream AAC 5.1 precisa ser decodificado para seis canais de PCM).
• [C-2-2] Os metadados de intervalo dinâmico PRECISAM ser conforme definidos em "Controle de intervalo dinâmico (DRC)" no ISO/IEC 14496-3, e as 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] É MUITO RECOMENDADO que os requisitos C-2-1 e C-2-2 acima sejam atendidos por todos os decodificadores de áudio AAC.

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

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

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

• Pode ser compatível com o controle de volume e de intervalo dinâmico usando o perfil ISO/IEC 23003-4 de controle de intervalo dinâmico.

Se houver suporte para ISO/IEC 23003-4 e se os metadados ISO/IEC 23003-4 e ISO/IEC 14496-3 estiverem presentes em um bitstream decodificado:

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

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

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

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

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

Se as implementações de dispositivos oferecerem suporte a decodificadores de áudio diferentes do decodificador de áudio AAC padrão e puderem gerar áudio multicanal (ou seja, mais de dois canais) quando forem alimentados com conteúdo multicanal compactado:

• [C-SR-2] É 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 (ao usar um valor de 2) ou se é saída 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 produzir seis canais quando alimentado com conteúdo 5.1.
• [C-SR-3] Ao decodificar, o decodificador é RECOMENDADO para anunciar a máscara de canal que está sendo 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 arquivos/formatos de contêiner aceitos
Perfil AAC MPEG-4 (AAC LC)	Suporte a 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) ADTS AAC bruto (.aac, ADIF não compatíveis) MPEG-TS (.ts, não pesquisável, somente decodificação) Matroska (.mkv, somente decodificação)
Perfil MPEG-4 HE AAC (AAC+)	Suporte a 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)
MPEG-4 HE AACv2 Perfil (AAC+ aprimorado)	Suporte a 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 - Codec de fala de banda larga	3GPP (.3gp)
FLAC	Para codificador e decodificador: pelo menos os modos mono e estéreo PRECISAM ser compatíveis. Taxas de amostragem de até 192 kHz PRECISAM ser compatíveis, e as resoluções de 16 e 24 bits PRECISAM ser compatíveis. O processamento de dados de áudio FLAC de 24 bits 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 a 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. Suporte a formatos de toque RTTTL/RTX, OTA e iMelody.	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Decodificação: compatibilidade com conteúdo mono, estéreo, 5.0 e 5.1 com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz. Codificação: compatível com conteúdo mono e estéreo com taxas de amostragem de 8.000, 0.000, 0.000 e 1.4.000	Ogg (.ogg) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv) Webm (.webm)
PCM/WAVE	O codec PCM PRECISA ser compatível com PCM linear de 16 bits e flutuante de 16 bits. O extrator WAVE precisa ser compatível com PCM linear de 16, 24 e 32 bits e flutuante de 32 bits (taxas até o limite do hardware). As taxas de amostragem PRECISAM ser compatíveis entre 8 kHz e 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: compatível com conteúdo mono e estéreo com taxas de amostragem de 8.000, 0.400, 0.400 e 1.400 Hz	Ogg (.ogg) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv) Webm (.webm)

5.1.4. Codificação de imagem

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

As implementações de dispositivos PRECISAM ser compatíveis com a seguinte codificação de imagem:

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

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

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

5.1.5 Decodificação de imagem

Veja 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 de dispositivos 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 (mais de 9 bits por canal):

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

5.1.6. Detalhes dos codecs de imagem

Formato/Codec	Detalhes	Tipos de arquivos/formatos de contêiner compatíveis
JPEG	Básico+progressivo	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Raw		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 imagens expostos na API MediaCodec

• [C-1-1] PRECISA oferecer suporte ao formato de cores flexível YUV420 8:8:8 (COLOR_FormatYUV420Flexible) até CodecCapabilities.

• [C-SR-1] É MUITO RECOMENDADO para oferecer suporte ao formato de cores RGB888 para o modo de superfície de entrada.

• [C-1-3] PRECISA oferecer suporte a pelo menos um formato de cor plano ou semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). Eles são FORTEMENTE RECOMENDADOS para oferecer suporte a ambos.

5.1.7. Codecs de vídeo

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

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

• [C-1-1] Os codecs de vídeo PRECISAM oferecer suporte a tamanhos de buffer de bytes de saída e entrada que acomodem o maior frame compactado viável e descompactado conforme determinado pelo padrão e pela configuração, mas também sem alocação excessiva.

• [C-1-2] Os codificadores e decodificadores de vídeo PRECISAM oferecer suporte a formatos de cores flexíveis YUV420 8:8:8 (COLOR_FormatYUV420Flexible) até CodecCapabilities.

• [C-1-3] Os codificadores e decodificadores de vídeo PRECISAM oferecer suporte a pelo menos um formato de cor plano ou semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). Eles são MUITO RECOMENDADOS para oferecer suporte aos dois.

• [C-SR-1] Os codificadores e decodificadores de vídeo são FORTEMENTE RECOMENDADOS para oferecerem suporte a pelo menos um formato de cor plano ou semiplanar YUV420 8:8:8 otimizado por hardware (YV12, NV12, NV21 ou formato otimizado para fornecedor equivalente).

• [C-1-5] Decodificadores de vídeo com suporte a um formato de alta profundidade de bits (mais de 9 bits por canal) PRECISAM oferecer suporte à saída de um formato equivalente de 8 bits, se solicitado pelo aplicativo. Isso PRECISA ser refletido com a compatibilidade com um formato de cores YUV420 8:8:8 via android.media.MediaCodecInfo.

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

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

Se as implementações de dispositivos anunciarem suporte a atualizações intra usando FEATURE_IntraRefresh na classe MediaCodecInfo.CodecCapabilities, elas:

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

A menos que o aplicativo especifique de outra forma usando a chave de formato KEY_COLOR_FORMAT, as implementações do decodificador de vídeo:

• [C-4-1] O padrão PRECISA ser o formato de cor otimizado para exibição de hardware, se configurado usando a saída Surface.
• [C-4-2] O padrão é um formato de cores YUV420 8:8:8 otimizado para leitura da CPU, se configurado para não usar a saída da superfície.

5.1.8. Lista de codecs de vídeo

Formato/Codec	Detalhes	Tipos de arquivos/formatos de contêiner aceitos
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, somente decodificação)
H.264 AVC	Consulte detalhes nas seções 5.2 e 5.3	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, não pesquisável) Matroska (.mkv, somente decodificação)
H.265 HEVC	Consulte detalhes na seção 5.3	MPEG-4 (.mp4) Matroska (.mkv, somente decodificação)
MPEG-2	Perfil principal	MPEG2-TS (.ts, não pesquisável) MPEG-4 (.mp4, somente decodificação) Matroska (.mkv, somente decodificação)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, somente decodificação)
VP8	Consulte detalhes nas seções 5.2 e 5.3	WebM (.webm) Matroska (.mkv)
VP9	Consulte detalhes na seção 5.3	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 de codec de mídia, conforme descrito abaixo.

O Android inclui suporte à OMX, uma API de aceleração multimídia multiplataforma, e ao Codec 2.0, uma API de aceleração multimídia de baixa sobrecarga.

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

• [C-1-1] PRECISA oferecer suporte a codecs de mídia pelas APIs OMX ou Codec 2.0 (ou ambas), como no Android Open Source Project, e não desativar ou burlar as proteções de segurança. Especificamente, isso não significa que todo codec PRECISA usar a API OMX ou o Codec 2.0. No entanto, 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] É FORTEMENTE RECOMENDADO a inclusão de suporte para a API Codec 2.0.

Se as implementações de dispositivos não oferecerem suporte à API Codec 2.0, elas:

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

Se as implementações de dispositivos oferecerem suporte à API Codec 2.0, elas:

• [C-3-1] PRECISA incluir o codec de software Codec 2.0 correspondente do Android Open Source Project (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) com suporte no dispositivo.
• [C-3-2] PRECISA hospedar os codecs de software Codec 2.0 no processo de codec de software, conforme fornecido no Android Open Source Project, para permitir acesso mais restrito aos codecs de software.
• [C-3-3] Codecs que têm nomes que começam com "c2.android". PRECISAM ser baseados no código-fonte do Android Open Source Project.

5.1.10 Caracterização do codec de mídia

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

• [C-1-1] PRECISA retornar valores corretos da caracterização do codec de mídia pela API MediaCodecInfo.

Especificamente, as seguintes:

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

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

• [C-2-1] Todos os codecs de vídeo PRECISAM publicar dados alcançáveis de frame rate nos tamanhos a seguir se compatíveis com o codec:

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (codificador MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (outros)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (codificador MPEG4) 720 x 480 px (outro)	1.408 x 1.152 px (H263) 1280 x 720 px (outros)	1920 x 1080 px (exceto MPEG4)	3.840 x 2.160 px (HEVC, VP9)

• [C-2-2] Codecs de vídeo caracterizados por aceleração de hardware PRECISAM publicar informações sobre pontos de desempenho. Eles PRECISAM listar todos os pontos de desempenho padrão compatíveis (listados na API PerformancePoint), a menos que sejam cobertos por outro ponto de desempenho padrão compatível.
• Além disso, DEVEM publicar pontos de desempenho estendidos se oferecerem suporte a desempenho de vídeo sustentado que não seja um dos padrão 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:

• em duas janelas deslizantes, NÃO É POSSÍVEL TER mais de 15% da taxa de bits entre intervalos intraframe (I-frame).
• NÃO SEJA mais que 100% acima da taxa de bits 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 se incluírem uma porta de saída de vídeo ou declararem suporte a uma câmera usando a flag de recurso android.hardware.camera.any, elas:

• [C-1-1] PRECISA incluir suporte de pelo menos um dos codificadores de vídeo VP8 ou H.264 e disponibilizá-lo para aplicativos de terceiros.
• DEVE oferecer suporte a 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 os disponibilizarem para aplicativos de terceiros, elas:

• [C-2-1] PRECISA oferecer suporte a taxas de bits configuráveis dinamicamente.
• DEVE oferecer suporte a frame rates variáveis, em que o codificador de vídeo DEVE determinar a duração instantânea do frame com base nos carimbos de data/hora dos buffers de entrada e alocar o bucket de bits com base nessa duração.

Se as implementações de dispositivos forem compatíveis com o codificador de vídeo MPEG-4 SP e o disponibilizarem para apps de terceiros, elas:

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

Se as implementações de dispositivos fornecerem codificadores de vídeo ou imagem com aceleração de hardware e oferecerem suporte a uma ou mais câmeras de hardware conectadas ou conectáveis 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 de dispositivos fornecerem codificação HDR, elas:

• [C-SR-1] é ALTAMENTE RECOMENDADO para 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 as disponibilizarem para apps de terceiros, elas:

• [C-1-1] PRECISA oferecer suporte ao perfil de referência de nível 45.
• 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 oferecerem suporte ao codec H.264, elas:

• [C-1-1] PRECISA oferecer suporte ao perfil de referência de nível 3. No entanto, a compatibilidade com a ordem arbitrária de frações (ASO, na sigla em inglês), com a FMO (ordenação de macrobloco flexível) e com a de Slices redundantes (RS, na sigla em inglês) é OPCIONAL. Além disso, para manter a compatibilidade com outros dispositivos Android, é RECOMENDADO que ASO, FMO e RS não são usados para o perfil de referência por codificadores.
• [C-1-2] PRECISA 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 relatarem suporte à codificação H.264 para vídeos com resolução de 720p ou 1080p pelas APIs de mídia, elas:

• [C-2-1] PRECISA oferecer suporte aos perfis de codificação na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 240 px	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	20 qps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

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

• [C-1-1] PRECISA 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] PRECISA oferecer suporte à gravação de arquivos Matroska WebM.
• DEVEM fornecer um codec VP8 de hardware que atenda aos requisitos de codificação de hardware RTC do projeto WebM (em inglês) para garantir uma qualidade aceitável de streaming de vídeo da Web e serviços de videoconferência.

Se as implementações de dispositivos relatarem suporte à codificação VP8 para vídeos com resolução de 720p ou 1080p usando as APIs de mídia, elas:

• [C-2-1] PRECISA oferecer suporte aos perfis de codificação na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 180 px	640 x 360 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	800 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.4. VP9

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

• [C-1-2] PRECISA oferecer suporte ao Perfil 0 de Nível 3.
• [C-1-1] PRECISA oferecer suporte à gravação de arquivos Matroska WebM.
• [C-1-3] PRECISA gerar dados do CodecPrivate.
• DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.
• [C-SR-1] é MUITO RECOMENDADO para oferecer suporte aos perfis de decodificação de HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.

	SD	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3.840 x 2.160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se as implementações de dispositivos alegam oferecer suporte aos perfis 2 ou 3 usando as APIs Media:

• O suporte para o 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] PRECISA oferecer suporte ao perfil principal de nível 3.
• DEVE oferecer suporte aos perfis de codificação em HD conforme indicado na tabela a seguir.
• [C-SR-1] é FORTEMENTE RECOMENDADO para oferecer 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	3.840 x 2.160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

5,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] PRECISA oferecer suporte à resolução dinâmica de vídeo e à troca de frame rate nas APIs padrão do Android no mesmo stream para todos os codecs VP8, VP9, H.264 e H.265 em tempo real e até a resolução máxima aceita pelos codecs do 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] PRECISA oferecer suporte aos perfis de referência de nível 30 e 45.

5.3.3. MPEG-4

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

• [C-1-1] PRECISA oferecer suporte ao perfil simples de nível 3.

5.3.4. H.264

Se as implementações de dispositivos oferecerem suporte a decodificadores H.264, elas:

• [C-1-1] PRECISA oferecer suporte ao perfil principal de nível 3.1 e ao perfil de referência. O suporte a ordenação arbitrária de frações (ASO, na sigla em inglês), FMO (pedido de macrobloco flexível) 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 em HD (alta definição), como indicado na tabela a seguir.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo, as implementações do dispositivo:

• [C-2-1] PRECISA oferecer suporte aos perfis de decodificação de vídeo em HD de 720p mostrados na tabela a seguir.
• [C-2-2] PRECISA oferecer suporte aos perfis de decodificação de vídeo HD de 1080p mostrados na tabela a seguir.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p
Resolução do vídeo	320 x 240 px	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	30 fps	30 fps	60 qps	30 fps (60 fps^Televisão)
Taxa de bits do vídeo	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

Se as implementações de dispositivos oferecerem suporte ao codec H.265, elas:

• [C-1-1] PRECISA oferecer suporte ao nível 3 do perfil principal e aos perfis de decodificação de vídeo SD, conforme indicado na tabela a seguir.
• DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.
• [C-1-2] PRECISA oferecer suporte aos perfis de decodificação de HD, conforme indicado na tabela a seguir, se houver um decodificador de hardware.

Se a altura informada pelo método Display.getSupportedModes() for igual ou maior que a resolução do vídeo:

• [C-2-1] As implementações de dispositivos PRECISAM oferecer suporte a pelo menos uma decodificação H.265 ou VP9 de perfis 720, 1080 e UHD.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	352 x 288 pixels	720 x 480 px	1.280 x 720 px	1.920 x 1.080 px	3.840 x 2.160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30/60 fps (60 fps^Televisão com decodificação de hardware H.265)	60 qps
Taxa de bits do vídeo	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se as implementações de dispositivos alegam oferecer suporte a um perfil HDR usando as APIs Media:

• [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 bitstream e/ou contêiner.
• [C-3-2] As implementações de dispositivos PRECISAM mostrar corretamente o conteúdo HDR na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

5.3.6. VP8

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

• [C-1-1] PRECISA oferecer suporte aos perfis de decodificação de SD na tabela a seguir.
• DEVE usar um codec de hardware VP8 que atenda aos requisitos.
• DEVE oferecer suporte aos perfis de decodificação de 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:

• [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 fps (60 fps^Televisão)	30 (60 fps^Televisão)
Taxa de bits do vídeo	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

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

• [C-1-1] PRECISA oferecer suporte aos perfis de decodificação de vídeo SD, conforme indicado na tabela a seguir.
• DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.

Se as implementações de dispositivos forem compatíveis com o codec VP9 e um decodificador de hardware:

• [C-2-1] PRECISA oferecer suporte aos perfis de decodificação de 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:

• [C-3-1] As implementações de dispositivos PRECISAM oferecer suporte a pelo menos uma decodificação VP9 ou H.265 dos perfis 720, 1080 e UHD.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p	HD 1080p	Ultra HD
Resolução do vídeo	320 x 180 px	640 x 360 px	1.280 x 720 px	1.920 x 1.080 px	3.840 x 2.160 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps (60 fps^Televisão com decodificação de hardware VP9)	60 qps
Taxa de bits do vídeo	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Se as implementações de dispositivos alegam oferecer suporte a VP9Profile2 ou VP9Profile3 usando as APIs de mídia 'CodecProfileLevel':

• O suporte para o formato de 12 bits é OPCIONAL.

Se as implementações de dispositivos alegam oferecer suporte a um perfil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) usando as 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 e '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 bitstream e/ou do contêiner.
• [C-4-2] As implementações de dispositivos PRECISAM mostrar corretamente o conteúdo HDR na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

5.3.8. Dolby Vision

Se as implementações de dispositivos declararem suporte ao decodificador Dolby Vision usando HDR_TYPE_DOLBY_VISION, elas:

• [C-1-1] PRECISA fornecer um extrator compatível com Dolby Vision.
• [C-1-2] PRECISA mostrar corretamente o conteúdo do Dolby Vision na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.
• [C-1-3] PRECISA definir o ID da faixa das camadas de base compatíveis com versões anteriores (se houver) para que seja igual ao ID da faixa combinada da camada Dolby Vision.

5.3.9. AV1

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

• [C-1-1] PRECISA 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 estejam listados como DEVEEM desde o Android 4.3, a definição de compatibilidade das versões futuras está planejada para mudá-los para OBRIGATÓRIO. Os dispositivos Android novos e atuais são altamente RECOMENDADOS para atender aos requisitos listados como DEVE. Caso contrário, eles não poderão ter compatibilidade com o Android quando forem atualizados para a versão futura.

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

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

• [C-1-1] PRECISA permitir a captura de conteúdo de áudio bruto para qualquer stream de ENTRADA AudioRecord ou AAudio que seja aberto. No mínimo, as seguintes características PRECISAM ser compatíveis:

  • Formato:PCM linear de 16 bits
  • Taxas de amostragem:8000, 11025, 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: 8000, 11025, 16.000, 22050, 24.000, 32.000, 44.100, 48.000 Hz
  • Canais: o número de canais depende do número de microfones no dispositivo.

• [C-1-2] PRECISA capturar taxas de amostragem acima da média sem aumento de amostragem.

• [C-1-3] PRECISA incluir um filtro anti-aliasing adequado quando as taxas de amostragem fornecidas acima são capturadas com redução de amostragem.

• DEVE permitir 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] PRECISA respeitar a API MicrophoneInfo e preencher corretamente as informações dos microfones disponíveis no dispositivo acessível a 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] PRECISA capturar sem aumento de amostragem em qualquer proporção maior que 16.000:22.050 ou 44.100:48.000.
• [C-2-2] PRECISA incluir um filtro anti-aliasing adequado para todas as taxas de aumento ou redução.

5.4.2. Captura para reconhecimento de voz

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

• [C-1-1] PRECISA capturar a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION em uma das taxas de amostragem, 44.100 e 48.000.
• [C-1-2] PRECISA, por padrão, desativar qualquer processamento de áudio com redução de ruído ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.

• [C-1-3] PRECISA, por padrão, desativar qualquer controle automático de ganho ao gravar um stream de áudio da fonte AudioSource.VOICE_RECOGNITION.

• DEVE exibir características de amplitude em relação à frequência aproximadamente planas no intervalo de frequência média: especificamente ±3 dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.

• [C-SR-1] é RECOMENDADO para exibir níveis de amplitude na faixa de frequência baixa: especificamente de ±20 dB de 30 Hz a 100 Hz, em comparação com o intervalo de média-frequência de cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.

• [C-SR-2] é MUITO RECOMENDADO para exibir 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 de cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.

• DEVE definir a sensibilidade da entrada de áudio de modo que uma fonte de tom sinusoidal de 1.000 Hz seja reproduzida a 90 dB com Nível de pressão sonora (SPL, na sigla em inglês) (medido ao lado do microfone) para gerar uma resposta ideal de RMS 2500 em um intervalo de 1770 e 3530 para cada amostra flutuante de precisão de 16 bits/3530 para cada

• Grave o stream de áudio de reconhecimento de voz para que os níveis de amplitude de PCM rastreiem linearmente as mudanças de SPL de entrada em pelo menos 30 dB, de -18 dB a +12 dB com 90 dB de SPL no microfone.

• DEVE gravar o stream de áudio de reconhecimento de voz com distorção harmônica total (THD) menor que 1% para 1 kHz a um nível de entrada SPL de 90 dB no microfone.

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

• [C-2-1] PRECISA permitir que esse efeito de áudio seja controlável com a API android.media.audiofx.NoiseSuppressor.
• [C-2-2] PRECISA identificar de forma exclusiva cada implementação da tecnologia de supressão de ruído pelo campo AudioEffect.Descriptor.uuid.

5.4.3. Capturar para traçar novo trajeto de reprodução

A classe android.media.MediaRecorder.AudioSource inclui a fonte de áudio REMOTE_SUBMIX.

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

• [C-1-1] PRECISA implementar corretamente a fonte de áudio REMOTE_SUBMIX para que, quando um aplicativo usar a API android.media.AudioRecord para gravar dessa fonte de áudio, ele capture uma combinação de todos os streams de áudio, exceto:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. Cancelador de eco acústico

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

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

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

• [C-SR-1] são STRONGLY_RECOMMENDED para declarar isso pelo método de 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] são STRONGLY_RECOMMENDED para identificar exclusivamente cada implementação de tecnologia AEC por meio do campo AudioEffect.Descriptor.uuid.

5.4.5. Captura simultânea

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

• [C-1-1] PRECISA permitir o acesso simultâneo ao microfone por uma captura de serviço de acessibilidade com AudioSource.VOICE_RECOGNITION e pelo menos uma captura de aplicativo com qualquer AudioSource.
• [C-1-2] PRECISA permitir o acesso simultâneo ao microfone por um aplicativo pré-instalado que tenha um papel do Assistente e pelo menos um aplicativo capturando com qualquer AudioSource, exceto AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
• [C-1-3] PRECISA silenciar a captura de áudio de qualquer outro aplicativo, exceto um serviço de acessibilidade, enquanto um aplicativo estiver capturando com AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. No entanto, quando um app está capturando via AudioSource.VOICE_COMMUNICATION, outro app pode fazer a chamada de voz se ele for um app 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 interface na parte de cima, aquele que iniciou a captura mais recentemente vai receber o áudio.

5.4.6. Níveis de ganho do microfone [migrado para 5.4.2]

5,5. Reprodução de áudio

O Android inclui suporte para permitir que apps reproduzam áudio por meio de um periférico de saída de áudio, conforme definido na seção 7.8.2.

5.5.1. Reprodução de áudio bruto

Se as implementações de dispositivo declararem android.hardware.audio.output, elas:

• [C-1-1] PRECISA permitir a reprodução de conteúdo de áudio bruto com as seguintes características:

  • Formatos de origem: PCM linear, 16 bits, 8 bits, flutuante
  • Canais: mono, estéreo, configurações multicanais válidas com até oito canais
  • Taxas de amostragem (em Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 nas configurações de canal listadas acima.
    • 96.000 em mono e estéreo

5.5.2. Efeitos de áudio

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

Se as implementações de 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 controlada 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, controladas pelas subclasses AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.
• [C-SR-1] É FORTEMENTE RECOMENDADO para 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 o ajuste do volume de áudio separadamente em cada stream de áudio usando o tipo ou o uso de conteúdo, conforme definido por AudioAttributes, e o uso de áudio do carro, conforme definido publicamente em android.car.CarAudioManager.

5.5.4. Descarregamento de áudio

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

• [C-SR-1] É RECOMENDADO para cortar o conteúdo de áudio reproduzido entre dois clipes com o mesmo formato quando especificado pela API sem lacunas do AudioTrack e pelo contêiner de mídia do MediaPlayer.

5,6. Latência de áudio

A latência de áudio é o atraso no tempo em que um sinal de áudio passa por um sistema. Muitas classes de aplicativos dependem de latências curtas para alcançar efeitos sonoros em tempo real.

Para os fins desta seção, use as seguintes definições:

• latência de saída. É o intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e quando o som correspondente é apresentado ao ambiente em um transdutor no dispositivo ou quando o sinal sai do dispositivo por uma porta e pode ser observado externamente.
• latência de saída a frio. O tempo entre o início de um stream de saída e o momento da apresentação do primeiro frame com base em carimbos de data/hora, quando o sistema de saída de áudio estava ocioso e desligado antes da solicitação.
• latência de saída contínua. A latência de saída para os 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 para o dispositivo em um transdutor ou sinal que entra no dispositivo por uma porta e quando um aplicativo lê o frame correspondente de dados codificados em PCM.
• entrada perdida. A parte inicial de um sinal de entrada que não pode ser usado ou disponível.
• latência de entrada a frio. O tempo entre o início do stream e o recebimento do primeiro frame válido, quando o sistema de entrada de áudio ficou inativo e desligado antes da solicitação.
• latência de entrada contínua. A latência de entrada para os 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 que o app processe o sinal e tempo para reduzir a diferença de fase entre os fluxos de entrada e de saída.
• API OpenSL ES PCM da fila de buffer. O conjunto de APIs OpenSL ES relacionadas a PCM no Android NDK.
• API Native Audio da AAudio. O conjunto de APIs AAudio no Android NDK.
• Carimbo de data/hora. Um par que consiste em uma posição relativa de frame 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. Interrupção temporária ou valor de amostra incorreto no sinal de áudio, normalmente causado por um subfluxo de buffer para saída, excesso de buffer para entrada ou qualquer outra fonte de ruído digital ou analógico.
• desvio médio absoluto. A média do valor absoluto dos desvios da média para um conjunto de valores.
• latência do toque para tom. O tempo entre o toque na tela e o momento em que um tom gerado como resultado desse toque é ouvido no alto-falante.

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

• [C-1-1] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp e AAudioStream_getTimestamp tem precisão de +/- 2 ms.

• [C-1-2] Latência de saída fria de 500 milissegundos ou menos.

• [C-1-3] A abertura de um stream de saída usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

Se as implementações de dispositivos declararem android.hardware.audio.output, elas serão altamente RECOMENDADAS a atender ou exceder 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 tem precisão de +/- 1 ms.

Se as implementações de dispositivos atenderem aos requisitos acima, após qualquer calibração inicial, ao usar a API de áudio nativo da AAudio, para latência de saída contínua e latência de saída a frio em pelo menos um dispositivo de saída de áudio compatível, elas serão:

• [C-SR-5] É MUITO RECOMENDADO que você informe áudio de baixa latência declarando a flag de recurso android.hardware.audio.low_latency.
• [C-SR-6] É MUITO RECOMENDADO para atender aos requisitos de áudio de baixa latência pela API AAudio.
• [C-SR-7] FORTEMENTE RECOMENDADO para garantir que, para streams que retornem 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 de dispositivos não atenderem aos requisitos de áudio de baixa latência pela API de áudio nativo da AAudio, elas:

• [C-2-1] NÃO É POSSÍVEL informar suporte para áudio de baixa latência.

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

• [C-3-1] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp ou AAudioStream_getTimestamp, para +/- 2 ms. "Erro" aqui significa o desvio do valor correto.

• [C-3-2] Latência de entrada de frio de 500 milissegundos ou menos.

• [C-3-3] A abertura de um stream de entrada usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

Se as implementações de dispositivos incluírem android.hardware.microphone, elas serão altamente RECOMENDADAS para atender a estes requisitos de áudio de entrada:

• [C-SR-8] Latência de entrada a frio 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 de dispositivos declararem android.hardware.audio.output e android.hardware.microphone, elas:

• [C-SR-12] É RECOMENDADO que tenha uma latência de ida e volta contínua média de 50 milissegundos ou menos em cinco medições, com um desvio absoluto médio menor que 10 ms, em pelo menos um caminho compatível.

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] PRECISA oferecer suporte a esse codec ou contêiner por HTTP e HTTPS.

• [C-1-2] PRECISA oferecer suporte aos formatos de segmento de mídia correspondentes, conforme mostrado na tabela de formatos de segmento de mídia abaixo sobre o protocolo de rascunho HTTP Live Streaming, versão 7.

• [C-1-3] PRECISA oferecer suporte aos formatos de payload do RTSP correspondentes, conforme mostrado na tabela do 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ências	Compatibilidade necessária com o codec
Stream de transporte MPEG-2	ISO 13818 (link em inglês)	Codecs de vídeo: H264 AVC MPEG-4 SP MPEG-2 Consulte a seção 5.1.8 para detalhes sobre H264 AVC, MPEG2-4 SP e MPEG-2. Codecs de áudio: AAC Consulte a seção 5.1.3 para saber detalhes sobre o AAC e as variantes dele.
AAC com enquadramento ADTS e tags ID3	ISO 13818-7 (link em inglês)	Consulte a seção 5.1.1 para saber detalhes sobre o AAC e as variantes dele
WebVTT	WebVTT

RTSP (RTP, SDP)

Nome do perfil	Referências	Compatibilidade necessária com o codec
H264 AVC	RFC 6184 (link em inglês)	Consulte a seção 5.1.8 para ver detalhes sobre o H264 AVC
MP4A-LATM	RFC 6416 (em inglês)	Consulte a seção 5.1.3 para mais detalhes sobre o AAC e as variantes dele.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Consulte a seção 5.1.8 para ver detalhes sobre o H263
T263-2000	RFC 4629 (link em inglês)	Consulte a seção 5.1.8 para ver detalhes sobre o H263
AMR	RFC 4867 (link em inglês)	Consulte detalhes sobre AMR-NB na seção 5.1.3.
AMR-WB	RFC 4867 (link em inglês)	Consulte detalhes sobre AMR-WB na seção 5.1.3.
MP4V-ES	RFC 6416 (em inglês)	Consulte a seção 5.1.8 para detalhes sobre o MPEG-4 SP
mpeg4-genérico	RFC 3640 (em inglês)	Consulte a seção 5.1.3 para mais detalhes sobre o AAC e as variantes dele.
MP2T	RFC 2250 (link em inglês)	Consulte a seção Fluxo de transporte MPEG-2 abaixo da HTTP Live Streaming para mais detalhes.

5,8. Mídia segura

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

• [C-1-1] PRECISA declarar compatibilidade com Display.FLAG_SECURE.

Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE e oferecerem suporte ao protocolo de exibição sem fio, elas:

• [C-2-1] PRECISA proteger o link com um mecanismo com criptografia forte, como HDCP 2.x ou mais recente, para as telas conectadas por protocolos sem fio, como o Miracast.

Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE e oferecerem suporte a uma tela externa com fio, elas:

• [C-3-1] PRECISA oferecer suporte a 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 dispositivos informarem suporte ao recurso android.software.midi pela classe android.content.pm.PackageManager, elas:

• [C-1-1] PRECISA oferecer suporte a MIDI em todos os transportes de hardware compatíveis com MIDI a que oferecem conectividade genérica não MIDI. Esses transportes são:

  • Modo host USB, seção 7.7
  • MIDI sobre Bluetooth LE atuando em função central, seção 7.4.3

• [C-1-2] PRECISA oferecer suporte ao transporte de software MIDI entre apps (dispositivos MIDI virtuais).

• [C-1-3] PRECISA incluir libamidi.so (suporte a MIDI nativo)

• DEVE oferecer suporte a MIDI sobre o modo de periférico USB, seção 7.7

5,10 Áudio profissional

Se as implementações do dispositivo relatarem suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager, elas:

• [C-1-1] PRECISA relatar a compatibilidade com o recurso android.hardware.audio.low_latency.
• [C-1-2] PRECISA ter a latência de ida e volta contínua do áudio, conforme definido na seção 5.6 Latência de áudio de 25 milissegundos ou menos em pelo menos um caminho compatível.
• [C-1-3] PRECISA incluir portas USB compatíveis com o modo host USB e o modo de periférico USB.
• [C-1-4] PRECISA relatar a compatibilidade com o recurso android.software.midi.
• [C-1-5] PRECISA atender aos requisitos de latência e áudio USB usando a API de áudio nativo da AAudio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] PRECISA ter latência de saída de frio de 200 milissegundos ou menos.
• [C-1-7] PRECISA ter latência de entrada a frio de 200 milissegundos ou menos.
• [C-1-8] PRECISA ter uma latência média do Toque para o tom de 80 milissegundos ou menos em pelo menos 5 medições no caminho de dados do alto-falante para o microfone.
• [C-SR-1] É RECOMENDADO para atender às latências definidas na seção 5.6 Latência de áudio, de 20 milissegundos ou menos, acima de cinco medições com um desvio absoluto médio inferior a cinco milissegundos entre o caminho do alto-falante e do microfone.
• [C-SR-2] É FORTEMENTE RECOMENDADO para atender aos requisitos de áudio do Pro para latência de áudio de ida e volta contínua, latência de entrada a frio e latência de saída a frio, além de requisitos de áudio USB usando a API de áudio nativo da AAudio no caminho MMAP.

• [C-SR-3] É FORTEMENTE RECOMENDADO para fornecer um nível consistente de desempenho da CPU enquanto o áudio está ativo e a carga da CPU varia. Isso precisa ser testado usando o app Android SynthMark. O SynthMark usa um sintetizador de software em execução em um framework de áudio simulado que mede o desempenho do sistema. Consulte a documentação do SynthMark para uma explicação sobre as comparações. O app SynthMark precisa ser executado usando a opção "Automated Test" e ter os seguintes resultados:

  • Voicemark.90 >= 32 vozes
  • latênciamark.Fixed.little <= 15 ms
  • latênciamark.dynamic.little <= 50 ms

• DEVE minimizar a imprecisão e o desvio do relógio de áudio em relação ao horário padrão.

• DEVE minimizar o deslocamento do relógio de áudio em relação ao CLOCK_MONOTONIC da CPU quando ambos estiverem ativos.

• DEVE minimizar a latência de áudio em transdutores no dispositivo.

• DEVE minimizar a latência de áudio no áudio digital USB.

• DEVE documentar as medições de latência de áudio em todos os caminhos.

• DEVE minimizar a instabilidade nos tempos de entrada do 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 fornecer zero falhas de áudio em condições normais de uso na latência relatada.

• DEVE fornecer zero diferença de latência entre os canais.

• DEVE minimizar a latência média de MIDI em todos os transportes.

• DEVE minimizar a variabilidade de latência MIDI sob carga (instabilidade) 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 nos transdutores do dispositivo, incluindo o período imediatamente após a inicialização a frio.

• DEVE fornecer zero diferença de relógio de áudio entre os lados de entrada e saída dos endpoints correspondentes, quando ambos estiverem ativos. Exemplos de endpoints correspondentes incluem o microfone e o alto-falante do dispositivo ou a entrada e saída da entrada de áudio.

• DEVE processar callbacks de conclusão do buffer de áudio para os lados de entrada e saída de endpoints correspondentes na mesma linha de execução quando ambos estiverem ativos e inserir o 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 entrar no 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 de toque sob carga (instabilidade).

Se as implementações de dispositivos atenderem a todos os requisitos acima, elas:

• [C-SR-4] É RECOMENDADO que você informe o suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager.

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

• [C-2-1] PRECISA ter uma latência de áudio contínua média de ida e volta, conforme definido na seção 5.6 Latência de áudio, de 20 milissegundos ou menos, acima de cinco medições com um desvio absoluto médio inferior a cinco milissegundos no caminho da entrada de áudio usando um dongle de loopback de áudio.
• [C-SR-5] É MUITO RECOMENDADO para obedecer à seção Especificações para dispositivos móveis (fones de ouvido) da Especificação de fones de ouvido com fio (v1.1).

Se as implementações do dispositivo omitirem uma entrada de áudio de 3,5 mm com quatro condutores e incluirem portas USB com suporte ao modo host USB, elas:

• [C-3-1] PRECISA implementar a classe de áudio USB.
• [C-3-2] PRECISA ter uma latência de áudio contínua de ida e volta de 25 milissegundos ou menos, acima de 5 medições com um desvio absoluto médio menor que 5 milissegundos na porta do modo de host USB usando a classe de áudio USB. Isso pode ser medido usando um adaptador USB-3, 5 mm e um dongle de loopback de áudio ou uma interface de áudio USB com cabos patch conectando as entradas às saídas.
• [C-SR-6] É RECOMENDADO para oferecer suporte a E/S simultâneas de até oito canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usados com periféricos de áudio USB que também oferecem suporte a esses requisitos.
• [C-SR-7] É ALTAMENTE RECOMENDADO para atender a esse grupo de requisitos usando a API de áudio nativa da AAudio no caminho MMAP.

Se as implementações de dispositivos incluírem 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 ou reamostragem de profundidade de bits em pelo menos uma configuração.

5,11. Capturar para não processados

O Android inclui suporte à 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 do dispositivo tiverem a intenção de oferecer suporte a fontes de áudio não processadas e disponibilizá-las para apps de terceiros, elas:

• [C-1-1] PRECISA informar o suporte pela propriedade android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] PRECISA exibir características aproximadamente planas de amplitude em comparação com a frequência no intervalo de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz para cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-3] PRECISA exibir níveis de amplitude no intervalo de baixa frequência, especificamente de ±20 dB de 5 Hz a 100 Hz, em comparação com o intervalo de média de frequência de cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-4] PRECISA exibir níveis de amplitude no intervalo de alta frequência: especificamente de ±30 dB de 7.000 Hz a 22 KHz em comparação com o intervalo de média de frequência de cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-5] PRECISA definir a sensibilidade à entrada de áudio de modo que uma fonte de tons sinusoidal de 1.000 Hz, reproduzida a 94 dB, com nível de pressão sonora (SPL, na sigla em inglês) gere uma resposta com REMQ de 520 para amostras de 16 bits (ou escala completa de -36 dB para amostras de ponto flutuante/de precisão dupla) para gravar cada microfone de ponto flutuante/precisão dupla usado.

• [C-1-6] PRECISA ter uma proporção sinal/ruído (SNR, na sigla em inglês) de 60 dB ou mais para cada microfone usado para gravar a fonte de áudio não processada. (enquanto o SNR é medido como a diferença entre SPL de 94 dB e SPL equivalente de ruído próprio, ponderado por A).

• [C-1-7] PRECISA ter uma distorção harmônica total (THD) menor que 1% para 1 kHZ a 90 dB de nível de entrada de SPL em cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-8] não pode ter nenhum outro processamento de sinal (por exemplo, controle automático de ganho, filtro de passagem alta ou cancelamento de eco) no caminho além de um multiplicador para levar o nível para a faixa desejada. Resumindo:

  • [C-1-9] Se algum processamento de sinal estiver presente na arquitetura por qualquer motivo, ele PRECISA ser desativado e introduzir efetivamente nenhum atraso ou latência extra no caminho do sinal.
  • [C-1-10] O multiplicador de nível, embora permitido estar no caminho, NÃO PODE introduzir atraso ou latência no caminho do sinal.

Todas as medições de SPL são feitas diretamente ao lado do microfone em teste. Para várias configurações de microfone, esses requisitos se aplicam a cada um deles.

Se as implementações de dispositivo declararem android.hardware.microphone, mas não oferecerem suporte a fontes de áudio não processadas, elas:

• [C-2-1] PRECISA retornar null para o método da API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), a fim de indicar corretamente a falta de suporte.
• [C-SR-1] ainda é FORTEMENTE RECOMENDADO para atender ao maior número possível dos requisitos do caminho do indicador da origem de gravação não processada.

5,12. Vídeo HDR

O Android 13 é compatível com as tecnologias HDR, conforme descrito em um documento a seguir.

Formato pixel

Se um decodificador de vídeo anunciar compatibilidade com COLOR_FormatYUVP010:

• [C-1-1] PRECISA oferecer suporte ao formato P010 para leitura de CPU (ImageReader, MediaImage, ByteBuffer). No Android 13, o P010 é relaxado para permitir o salto arbitrário para os planos Y e UV.

• [C-1-2] O buffer de saída P010 PRECISA poder ser amostrado pela GPU (quando alocado com o uso de GPU_SAMPLING). Isso permite a composição da GPU e o mapeamento de tons personalizado por apps.

Se um decodificador de vídeo anunciar compatibilidade com COLOR_Format32bitABGR2101010, ele:

• [C-2-1] PRECISA oferecer suporte ao formato RGBA_1010102 para a superfície de saída e legível pela CPU (saída ByteBuffer).

Se um codificador de vídeo anunciar compatibilidade com COLOR_FormatYUVP010, ele:

• [C-3-1] PRECISA oferecer suporte ao formato P010 para superfície de entrada e entrada gravável da CPU (ImageWriter, MediaImage, ByteBuffer).

Observação: no Android 13, a P010 é relaxada para permitir saltos arbitrários para os planos Y e UV. Esse formato P010 PODE ser otimizado e diferente do formato Camera2 P010.

Se um codificador de vídeo anunciar compatibilidade com COLOR_Format32bitABGR2101010, ele:

• [C-4-1] PRECISA oferecer suporte ao formato RGBA_1010102 para a superfície de entrada e a entrada gravável da CPU (ImageWriter, ByteBuffer). 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, as implementações de dispositivos:

• [C-5-1] NÃO PODE presumir que os metadados HDR são 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.

• DEVE agregar metadados dinâmicos HDR para gerar metadados estáticos HDR adequados para streams codificados e enviá-los ao final de cada sessão de codificação.

Se as implementações de dispositivos oferecerem suporte à captura HDR usando as APIs CamcorderProfile, elas:

• [C-6-1] também PRECISA oferecer suporte à captura HDR com as APIs Camera2.

• [C-6-2] PRECISA oferecer suporte a pelo menos um codificador de vídeo acelerado por hardware para cada tecnologia HDR com suporte.

• [C-6-3] PRECISA oferecer suporte, no mínimo, à captura de HLG.

• [C-6-4] PRECISA oferecer suporte à gravação de metadados HDR (se aplicável à tecnologia HDR) no arquivo de vídeo capturado. Para AV1, HEVC e DolbyVision, isso significa incluir os metadados no bitstream codificado.

• [C-6-5] PRECISA oferecer suporte a P010 e COLOR_FormatYUVP010.

• [C-6-6] PRECISA oferecer suporte ao mapeamento de tons HDR para SDR no decodificador acelerado por hardware padrão do perfil capturado. Em outras palavras, se um dispositivo puder capturar HDR10+ HEVC, o decodificador HEVC padrão PRECISA ser capaz de decodificar o stream capturado em SDR.

Requisitos de edição de HDR

Se as implementações de dispositivos incluírem codificadores de vídeo com suporte à edição HDR, elas:

• DEVE usar latência mínima para gerar os metadados HDR quando ausentes e DEVEM lidar com situações em que os metadados estão presentes em alguns frames, mas não em outros. Esses metadados DEVEM ser precisos (por exemplo, representar o pico de luminância 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] PRECISA oferecer suporte aos seguintes formatos de entrada do codificador de vídeo que preservam totalmente o sinal decodificado em HDR:

  • RGBA_1010102 (já na curva de transferência de destino) para a superfície de entrada e o ByteBuffer e PRECISA anunciar a compatibilidade com COLOR_Format32bitABGR2101010.

Se a implementação do dispositivo incluir codecs com suporte a FEATURE_HdrEditing, o dispositivo:

• [C-7-4] É NECESSÁRIO anunciar o suporte à extensão OpenGL EXT_YUV_target.

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

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte às Ferramentas para desenvolvedores do Android fornecidas no SDK do Android.

• Android Debug Bridge (adb)

  • [C-0-2] PRECISA oferecer suporte ao adb, conforme documentado no SDK do Android e nos comandos de shell fornecidos no AOSP, que podem ser usados por desenvolvedores de apps, incluindo dumpsys cmd stats.
  • [C-0-11] PRECISA oferecer suporte ao comando shell cmd testharness. O upgrade de implementações de dispositivo de uma versão anterior do Android sem um bloco de dados persistente pode ser isento de C-0-11.
  • [C-0-3] NÃO PODE alterar o formato ou o conteúdo de eventos do sistema do dispositivo (batterystats , discostats, impressões digitais, gráficosstats, netstats, notificação, procstats) registrados pelo comando dumpsys.
  • [C-0-10] É NECESSÁRIO registrar, sem omissão, e tornar os seguintes eventos acessíveis e disponíveis para o comando do shell cmd stats e a classe da API do sistema StatsManager.
    • ActivityForegroundStateChanged
    • Anomalia detectada
    • AppBreadcrumbReported
    • Ocorreram AppCrash
    • O AppStart ocorreu
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • CobrançaStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • Alarme de ativação ocorreu
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] PRECISA fazer com que o daemon do adb do lado do dispositivo fique inativo por padrão e É PRECISO haver um mecanismo acessível ao usuário para ativar o Android Debug Bridge.
  • [C-0-5] PRECISA oferecer suporte ao adb seguro. O Android inclui suporte ao adb seguro. O adb seguro permite o uso do adb em hosts autenticados conhecidos.
  • [C-0-6] PRECISA fornecer um mecanismo que permita a conexão do adb em uma máquina host. Especificamente:

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

  • [C-3-1] PRECISA implementar o adb via rede de área local (como Ethernet ou Wi-Fi).
  • [C-3-2] PRECISA fornecer drivers para o Windows 7, 8 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.

  Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet, elas:

  • [C-4-1] PRECISA que o método AdbManager#isAdbWifiSupported() retorne true.

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

  • [C-5-1] PRECISA que o método AdbManager#isAdbWifiQrSupported() retorne true.

• Serviço de monitoramento de depuração Dalvik (ddms)

  • [C-0-7] PRECISA oferecer suporte a todos os recursos de ddms, conforme documentado no SDK do Android. Como o ddms usa o adb, o suporte para ddms PRECISA estar inativo por padrão, mas PRECISA ser aceito sempre que o usuário ativar o Android Debug Bridge, conforme acima.

• SysTrace (em inglês)

  • [C-0-9] PRECISA oferecer suporte à ferramenta Systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão e ter um mecanismo acessível ao usuário para ativá-lo.

• Perfetto (link em inglês)

  • [C-SR-1] É FORTEMENTE RECOMENDADO para expor um binário /system/bin/perfetto ao usuário do shell que o cmdline está em conformidade com a documentação do perfetto (link em inglês).
  • [C-SR-2] O binário do perfetto é FORTEMENTE RECOMENDADO para aceitar como entrada uma configuração protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (link em inglês).
  • [C-SR-3] O binário do perfetto é FORTEMENTE RECOMENDADO para escrever como saída um rastro de protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (link em inglês).
  • [C-SR-4] É RECOMENDADO que você forneça, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto (link em inglês).

• Baixa memória assassina

  • [C-0-12] É NECESSÁRIO gravar um Atom LMK_KILL_OCCURRED_FIELD_NUMBER no registro destatsd quando um app é encerrado pelo Low Memory Killer.

• Modo arcabouço de testes. Se as implementações do dispositivo oferecerem suporte ao comando shell cmd testharness e executarem cmd testharness enable, elas:

  • [C-2-1] PRECISA retornar true para ActivityManager.isRunningInUserTestHarness().
  • [C-2-2] PRECISA implementar o modo de arcabouço de testes, conforme descrito na documentação desse modo.

• Informações de trabalho da GPU

  Implementações de dispositivos:

  • [C-0-13] PRECISA implementar o comando do shell dumpsys gpu --gpuwork para exibir os dados de trabalho agregados da GPU retornados pelo tracepoint do kernel power/gpu_work_period ou não exibir dados se o tracepoint não tiver suporte. A implementação do AOSP é frameworks/native/services/gpuservice/gpuwork/.

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

• [C-1-1] PRECISA fornecer uma affordance para o desenvolvedor do app ativar/desativar as camadas de depuração da GPU.
• [C-1-2] PRECISA, quando as camadas de depuração de GPU estiverem ativadas, enumerar as camadas em bibliotecas fornecidas por ferramentas externas (ou seja, que não fazem parte da plataforma ou do pacote do aplicativo) encontradas no diretório base dos aplicativos depuráveis para oferecer suporte aos métodos de API vkEnumerateInstanceLayerProperties() e vkCreateInstance().

6.2. Opções do desenvolvedor

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

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

• [C-0-1] PRECISA respeitar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar configurações relacionadas ao desenvolvimento de aplicativos. A implementação upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários iniciem as Opções do desenvolvedor depois de pressionarem sete (7) vezes no item de menu Configurações > Sobre o dispositivo > Número da versão.
• [C-0-2] É NECESSÁRIO ocultar as Opções do desenvolvedor por padrão.
• [C-0-3] PRECISA fornecer um mecanismo claro que não conceda tratamento preferencial a um app de terceiros em vez de outro para ativar as Opções do desenvolvedor. PRECISA fornecer um documento ou site visível publicamente que descreva como ativar as Opções do desenvolvedor. Este documento ou site PRECISA estar disponível para um link nos documentos do SDK do Android.
• DEVE manter uma notificação visual contínua para o usuário quando as "Opções do desenvolvedor" estiverem ativadas e a segurança do usuário for uma preocupação.
• PODE limitar temporariamente o acesso ao menu "Opções do desenvolvedor", ocultando ou desativando visualmente o menu para evitar distrações em cenários em que a segurança do usuário é preocupante.

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 que é considerado opcional e a implementação do dispositivo não tiver esse componente:

• [C-0-2] As definições de classe completas (conforme documentado pelo SDK) para as APIs do componente ainda PRECISAM ser apresentadas.
• [C-0-3] Os comportamentos da API PRECISAM ser implementados como ambiente autônomo 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 independentes 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 relatar informações precisas de configuração de hardware de maneira consistente pelos métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para a mesma impressão digital do build.

Um exemplo típico de cenário em que esses requisitos se aplicam é a API telefony: mesmo em dispositivos que não sejam telefônicos, essas APIs precisam ser implementadas como um ambiente autônomo razoável.

7.1. Tela e gráficos

O Android inclui instalações que ajustam automaticamente os recursos de aplicativos e os layouts de interface de forma adequada para o dispositivo, a fim de garantir que aplicativos de terceiros sejam executados corretamente em várias configurações de hardware. Nas telas compatíveis com Android em que todos os apps compatíveis de terceiros 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 diagonal físico. A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
• pontos por polegada (dpi). O número de pixels abrangidos por um intervalo linear horizontal ou vertical de 1". Quando os valores de dpi são listados, os dpi horizontal e vertical precisam estar dentro do intervalo.
• proporção. A proporção dos pixels da dimensão maior com a menor dimensão da tela. Por exemplo, uma tela de 480 x 854 pixels seria 854/480 = 1,779, ou aproximadamente “16:9”.
• pixel de densidade independente (dp, na sigla em inglês). A unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como pixels = dps * (densidade/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] PRECISA informar o tamanho correto do layout para o Configuration.screenLayout, conforme definido na documentação do SDK do Android. Especificamente, as implementações de dispositivos PRECISAM informar as dimensões lógicas de tela em pixels de densidade independente (dp, na sigla em inglês), conforme abaixo:

  • Dispositivos com o Configuration.uiMode definido como qualquer valor diferente de UI_MODE_TYPE_WATCH e que informam um tamanho de small para o Configuration.screenLayout PRECISAM ter pelo menos 426 dp x 320 dp.
  • Dispositivos com um tamanho de normal para a Configuration.screenLayout PRECISAM ter pelo menos 480 dp x 320 dp.
  • Dispositivos com um tamanho de large para a Configuration.screenLayout PRECISAM ter pelo menos 640 dp x 480 dp.
  • Dispositivos com um tamanho de xlarge para a Configuration.screenLayout PRECISAM ter pelo menos 960 dp x 720 dp.

• [C-0-2] PRECISA 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 incluírem telas compatíveis com Android com cantos arredondados, elas:

• [C-1-1] PRECISA garantir que pelo menos um dos requisitos a seguir seja atendido:

  • O raio dos cantos arredondados será menor ou igual a 38 dp.
  • Quando uma caixa de 15 dp por 15 dp está ancorada em cada canto da tela lógica, pelo menos um pixel de cada caixa fica visível na tela.

• DEVE incluir affordance do usuário para alternar para o modo de exibição com os cantos retangulares.

Se as implementações do dispositivo incluírem telas compatíveis com Android que sejam dobráveis ou uma articulação dobrável entre vários painéis e disponibilizem essas telas para renderizar apps de terceiros, elas:

• [C-2-1] PRECISA implementar a versão estável mais recente disponível da API de extensões ou a versão estável da API secundária para ser usada pela biblioteca do Window Manager Jetpack.

Se as implementações do dispositivo incluírem telas compatíveis com Android dobráveis ou uma articulação dobrável entre vários painéis e se a articulação ou dobra cruzar uma janela do app em tela cheia, elas:

• [C-3-1] PRECISA informar a posição, os limites e o estado da articulação ou dobra usando extensões ou APIs secundárias para o aplicativo.

Para ver detalhes sobre como implementar corretamente as APIs de arquivo secundário ou de extensão, consulte a documentação pública do Gerenciador de janelas do Jetpack.

7.1.1.2 Proporção da tela

Embora não haja restrições à 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 usando o valor de metadados android.max_aspect.
  • O app declara que é redimensionável usando o 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 dispositivos 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 interface do Android define um conjunto de densidades lógicas padrão para ajudar os desenvolvedores a direcionar os recursos do aplicativo.

• [C-0-1] Por padrão, as implementações do dispositivo PRECISAM informar apenas uma das densidades de framework do Android listadas em DisplayMetrics pela API DENSITY_DEVICE_STABLE, e esse valor NÃO PODE mudar em nenhum momento. No entanto, o dispositivo PODE informar uma densidade arbitrária diferente de acordo com as mudanças de configuração de tela feitas pelo usuário (por exemplo, tamanho da tela) definidas após a inicialização inicial.

• As implementações de dispositivos DEVEM definir a densidade padrão do framework do Android que é numericamente mais próxima da densidade física da tela, a menos que a densidade lógica coloque o tamanho da tela informado abaixo do mínimo compatível. 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 que o menor tamanho de tela compatível (320 dp de largura), as implementações de dispositivos DEVEM informar a próxima densidade padrão mais baixa de framework Android.

Se houver uma affordance para mudar o tamanho de exibição do dispositivo:

• [C-1-1] O tamanho de exibição NÃO PODE ser dimensionado maior que 1,5 vez a densidade nativa nem produzir uma dimensão mínima efetiva menor que 320 dp (equivalente ao qualificador de recurso sw320dp), o que ocorrer primeiro.
• [C-1-2] O tamanho de exibição NÃO PODE ser dimensionado menor que 0,85 vezes a densidade nativa.
• Para garantir boa usabilidade e tamanhos de fonte consistentes, é RECOMENDADO que o seguinte dimensionamento de opções de exibição nativa seja fornecido, obedecendo aos limites especificados acima:
  • Pequeno: 0,85x
  • Padrão: 1x (escala de display nativa)
  • Grande: 1,15x
  • Maior: 1,3x
  • Maior 1,45x

7.1.2. Métricas de display

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

• [C-1-1] É NECESSÁRIO informar os valores corretos de todas as métricas de tela 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 vão:

• [C-2-1] PRECISA informar os valores corretos da tela compatível com o Android, conforme definido na API android.util.DisplayMetrics, para a view.Display padrão emulada.

7.1.3. Orientação da tela

Implementações de dispositivos:

• [C-0-1] PRECISA informar quais orientações de tela são compatíveis (android.hardware.screen.portrait e/ou android.hardware.screen.landscape) e PRECISA informar pelo menos uma orientação. 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] PRECISA informar o valor correto para a orientação atual do dispositivo, sempre que consultado por android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.

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

• [C-1-1] PRECISA oferecer suporte à orientação dinâmica dos aplicativos para a orientação 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] NÃO PODE mudar o tamanho ou a densidade da tela informada ao mudar a orientação.
• PODE selecionar a orientação retrato ou paisagem como padrão.

7.1.4. Aceleração gráfica 2D e 3D

OpenGL ES 7.1.4.1

Implementações de dispositivos:

• [C-0-1] PRECISA identificar corretamente as versões do OpenGL ES com suporte (1.1, 2.0, 3.0, 3.1, 3.2) usando as APIs gerenciadas (como o método GLES10.getString()) e as APIs nativas.
• [C-0-2] PRECISA incluir suporte a todas as APIs gerenciadas e nativas correspondentes para cada versão do OpenGL ES identificada.

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

• [C-1-1] PRECISA oferecer suporte ao OpenGL ES 1.1 e 2.0, conforme incorporado e detalhado na documentação do SDK do Android.
• [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte ao OpenGL ES 3.1.
• DEVE oferecer suporte a OpenGL ES 3.2.

Os testes dEQP do OpenGL ES são particionados 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 no nível informado automaticamente indica que pode passar nos testes de dEQP em todas as listas de teste desse nível e de versões anteriores.

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

• [C-2-1] PRECISA gerar relatórios pelas APIs gerenciadas e nativas do OpenGL ES sobre qualquer outra extensão do OpenGL ES implementada e, por outro lado, NÃO PRECISA informar strings de extensão incompatíveis.
• [C-2-2] PRECISA oferecer suporte às extensões EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
• [C-2-3] PRECISA informar a versão máxima dos testes dEQP do OpenGL ES com suporte pela flag de recurso android.software.opengles.deqp.level.
• [C-2-4] PRECISA ser compatível pelo menos com a versão 132383489 (a partir de 1o de março de 2020), conforme informado na flag de recurso android.software.opengles.deqp.level.
• [C-2-5] PRECISA passar em todos os testes dEQP do OpenGL ES nas listas de 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] É FORTEMENTE RECOMENDADO oferecer suporte às extensões EGL_KHR_partial_update e OES_EGL_image_external.
• DEVE gerar relatórios com precisão usando o método getString(), qualquer formato de compactação de textura com suporte, que geralmente é específico do fornecedor.
• DEVE oferecer suporte às extensões EGL_IMG_context_priority e EGL_EXT_protected_content.

Se as implementações de dispositivos declararem suporte ao OpenGL ES 3.0, 3.1 ou 3.2, elas:

• [C-3-1] PRECISA exportar os símbolos de função correspondentes para essa versão, além dos símbolos de função do OpenGL ES 2.0 na biblioteca libGLESv2.so.
• [C-SR-3] É FORTEMENTE RECOMENDADO oferecer suporte à extensão OES_EGL_image_external_essl3.

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

• [C-4-1] PRECISA ser compatível com o pacote de extensão OpenGL ES para Android na íntegra.

Se as implementações de dispositivos oferecerem suporte integralmente ao Pacote de extensões para Android (link em inglês) do OpenGL ES, elas:

• [C-5-1] PRECISA identificar o suporte pela flag de recurso android.hardware.opengles.aep.

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

• [C-6-1] também PRECISA oferecer suporte à extensão EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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

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

• [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de suporte ao Vulkan 1.3.
• [C-4-1] NÃO PODE oferecer suporte a uma versão de variante do Vulkan, ou seja, a parte da variante da versão principal do Vulkan PRECISA ser zero.

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

• [C-SR-2] É FORTEMENTE RECOMENDADO a inclusão de suporte ao Vulkan 1.3.

Os testes dEQP do Vulkan são particionados em várias listas de testes, cada uma com uma data/versão associada. Eles estão na árvore de origem do Android em external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt. Um dispositivo que oferece suporte ao Vulkan em um nível autoinformado indica que pode passar nos testes de dEQP em todas as listas de teste desse nível e anteriores.

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

• [C-1-1] PRECISA informar o valor inteiro correto com as flags de recurso android.hardware.vulkan.level e android.hardware.vulkan.version.
• [C-1-2] PRECISA enumerar pelo menos um VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] PRECISA implementar totalmente as APIs do Vulkan 1.0 para cada VkPhysicalDevice enumerado.
• [C-1-4] PRECISA enumerar as camadas, contidas em bibliotecas nativas chamadas de libVkLayer*.so no diretório da biblioteca nativa do pacote do app, usando as APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
• [C-1-5] NÃO É POSSÍVEL enumerar as camadas fornecidas por bibliotecas fora do pacote do aplicativo nem 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] PRECISA informar todas as strings de extensão com suporte às APIs nativas do Vulkan e, por outro lado, NÃO PODE reportar strings de extensão a que elas não oferecem suporte corretamente.
• [C-1-7] PRECISA oferecer suporte às extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
• [C-1-8] PRECISA informar a versão máxima dos testes de dEQP do Vulkan com suporte pela flag de recurso android.software.vulkan.deqp.level.
• [C-1-9] PRECISA pelo menos oferecer suporte à versão 132317953 (a partir de 1o de março de 2019), conforme informado na flag de recurso android.software.vulkan.deqp.level.
• [C-1-10] PRECISA passar em todos os testes de dEQP do Vulkan nas listas de teste entre a versão 132317953 e a versão especificada na flag de recurso android.software.vulkan.deqp.level.
• [C-1-11] NÃO PODE enumerar o suporte para as extensões VK_KHR_video_queue, VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.
• [C-SR-3] É RECOMENDADO A compatibilidade com as extensões VK_KHR_driver_properties e VK_GOOGLE_display_timing.
• DEVE oferecer suporte a VkPhysicalDeviceProtectedMemoryFeatures e VK_EXT_global_priority.
• [C-1-12] NÃO PODE enumerar o suporte para a extensão VK_KHR_performance_query.
• [C-SR-4] São RECOMENDADOS para atender aos requisitos especificados pelo perfil de referência do Android 2021.

Se as implementações de dispositivos não incluírem suporte para o Vulkan 1.0, elas:

• [C-2-1] NÃO PODE declarar nenhuma das flags de recurso do Vulkan (por exemplo, android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NÃO PODE enumerar nenhum VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices().

Se as implementações de dispositivos incluírem suporte ao Vulkan 1.1 e declararem qualquer uma das flags de recurso do Vulkan, elas:

• [C-3-1] PRECISA expor o suporte ao semáforo externo SYNC_FD, aos tipos de identificador e à extensão VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] As implementações de dispositivos PRECISAM ser compatíveis com o Android RenderScript, conforme detalhado na documentação do SDK do Android.

7.1.4.4 Aceleração gráfica 2D

O Android inclui um mecanismo para os aplicativos declararem 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 desativá-la, se o desenvolvedor solicitar, definindo android:hardwareAccelerated="false" ou desativando a aceleração de hardware diretamente pelas APIs View do Android.
• [C-0-2] PRECISA exibir um comportamento consistente com a documentação do SDK do Android sobre aceleração de hardware.

O Android inclui um objeto TextureView que permite aos desenvolvedores integrar diretamente texturas OpenGL ES aceleradas por hardware como destinos de renderização em uma hierarquia de interface.

Implementações de dispositivos:

• [C-0-3] PRECISA oferecer suporte à API TextureView e exibir um comportamento consistente com a implementação upstream do Android.

Telas de ampla gama 7.1.4.5

Se as implementações de dispositivos alegarem suporte a telas de ampla gama usando Configuration.isScreenWideColorGamut() , elas:

• [C-1-1] PRECISA ter uma tela calibrada por cores.
• [C-1-2] PRECISA ter uma tela com a gama que cubra toda a gama de cores sRGB no espaço xyY CIE 1931.
• [C-1-3] PRECISA ter uma tela com uma gama de pelo menos 90% de DCI-P3 no espaço xyY CIE 1931.
• [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.1 ou 3.2 e informá-lo corretamente.
• [C-1-5] PRECISA anunciar o 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] É FORTEMENTE RECOMENDADO para oferecer suporte a GL_EXT_sRGB.

Por outro lado, se as implementações de dispositivos não forem compatíveis com telas de ampla gama, elas:

• [C-2-1] DEVE cobrir 100% ou mais de sRGB no espaço xyY da CIE 1931, embora a gama de cores da tela esteja indefinida.

7.1.5. Modo de compatibilidade de aplicativo legado

O Android especifica um "modo de compatibilidade" em que o framework opera em um modo equivalente ao tamanho de tela "normal" (320 dp de largura) em benefício de aplicativos legados não desenvolvidos para versões antigas do Android que são anteriores à independência de tamanho de 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 especificamente permitido neste documento.

Todas as telas compatíveis com a implementação do dispositivo:

• [C-0-1] PRECISA 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 ser 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 os recursos de compartilhamento de mídia e as APIs de desenvolvedor para acessar telas externas.

Se as implementações de dispositivos oferecerem suporte a uma tela externa por uma conexão de tela com fio, sem fio ou integrada, elas:

• [C-1-1] PRECISA 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] PRECISA incluir um mecanismo de entrada, como uma tela touchscreen 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 Editor de método de entrada (IME) de terceiros, elas:

• [C-1-1] PRECISA declarar a flag de recurso android.software.input_methods.
• [C-1-2] PRECISA implementar totalmente Input Management Framework
• [C-1-3] PRECISA ter um teclado de software pré-instalado.

Implementações de dispositivos:

• [C-0-1] NÃO PODE incluir um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.enabled (QWERTY ou 12 teclas).
• DEVEM incluir implementações adicionais de teclado de software.
• PODE incluir um teclado físico.

7.2.2. Navegação sem toque

O Android oferece suporte a botões direcional, trackball e roda como mecanismos para navegação sem toque.

Implementações de dispositivos:

• [C-0-1] PRECISA 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] PRECISA fornecer um mecanismo de interface do usuário alternativo razoável para seleção e edição de texto, compatível com os 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 sem toque.

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 touch são essenciais para o paradigma de navegação do Android e, portanto, as implementações de dispositivos:

• [C-0-1] PRECISA fornecer uma funcionalidade 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 televisão. A função Home DEVE ser o mecanismo para essa funcionalidade do usuário.
• DEVE fornecer botões para as funções Recentes e Voltar.

Se as funções Home, Recents ou Back forem fornecidas, elas:

• [C-1-1] PRECISA ser acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou gesto) quando alguma delas estiver acessível.
• [C-1-2] PRECISA fornecer uma indicação clara de qual ação acionaria cada função. Ter um ícone visível impresso no botão, mostrar um ícone de software na parte da barra de navegação da tela ou orientar o usuário em um fluxo de demonstração passo a passo guiado durante a experiência de configuração são exemplos dessa indicação.

Implementações de dispositivos:

• [C-SR-1] é MUITO RECOMENDADO não fornecer o mecanismo de entrada para a função de menu, já que ela foi descontinuada e substituída pela barra de ações desde o Android 4.0.

• [C-SR-2] É FORTEMENTE RECOMENDADO que todas as funções de navegação sejam canceláveis. "Cancelável" é definido como a capacidade do usuário de impedir a execução da função de navegação (por exemplo, ir para a página inicial, voltar etc.) se o deslizamento não for liberado além de um determinado limite.

Se as implementações de dispositivos fornecerem a função de menu, elas:

• [C-2-1] PRECISA mostrar o botão flutuante de ação sempre que o pop-up do menu flutuante de ações não estiver vazio e a barra de ações estiver visível.
• [C-2-2] NÃO É POSSÍVEL modificar a posição do pop-up flutuante de ação exibido ao selecionar o botão flutuante na barra de ações. No entanto, É POSSÍVEL renderizar esse pop-up em uma posição modificada na tela quando ele é exibido selecionando a função "Menu".

Se as implementações de dispositivos não fornecerem a função Menu, para compatibilidade com versões anteriores, elas: * [C-3-1] 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 estar acessível, a menos que esteja oculta com outras funções de navegação.

Se as implementações de dispositivos fornecerem a função Assist, elas:

• [C-4-1] PRECISA tornar a função Assist acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou fazer um gesto) quando outras teclas de navegação estiverem acessíveis.
• [C-SR-3] É MUITO RECOMENDADO usar a função HOMEM e mantê-la pressionada 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 (não disponível para apps) e NÃO PODEM ocultar nem interferir na parte da tela disponível para apps.
• [C-5-2] PRECISA disponibilizar uma parte da tela para aplicativos que atendam aos requisitos definidos na seção 7.1.1.
• [C-5-3] PRECISA respeitar as flags definidas pelo app com o método de API View.setSystemUiVisibility(), para que essa parte distinta da tela (também conhecida como a barra de navegação) fique ocultada corretamente, conforme documentado no SDK.

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() Só pode ser usado para informar a área de reconhecimento de gestos do Google Home.
• [C-6-2] Gestos que começam em um retângulo de exclusão conforme fornecido pelo aplicativo em primeiro plano via View#setSystemGestureExclusionRects(), mas fora de WindowInsets#getMandatorySystemGestureInsets(), NÃO PODEM ser interceptados para a função de navegação, desde que o reto de exclusão seja permitido dentro do limite de exclusão máximo especificado na documentação de View#setSystemGestureExclusionRects().
• [C-6-3] PRECISA enviar ao app em primeiro plano um evento MotionEvent.ACTION_CANCEL quando os toques começam a ser interceptados por um gesto do sistema, se o app em primeiro plano já tiver recebido um evento MotionEvent.ACTION_DOWN.
• [C-6-4] PRECISA oferecer uma funcionalidade do usuário para alternar para uma navegação baseada em botões na tela (por exemplo, em "Configurações").
• DEVE fornecer a função de início ao deslizar para cima a partir da borda de baixo da orientação atual da tela.
• DEVE fornecer a função "Recentes" deslizando para cima e pressionando antes de soltar, na mesma área que o gesto "Início".
• Os gestos que começam em WindowInsets#getMandatorySystemGestureInsets() NÃO DEVEM ser afetados por retângulos de exclusão fornecidos pelo app em primeiro plano usando View#setSystemGestureExclusionRects().

Se uma função de navegação for fornecida de 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 fornecida como um gesto de deslizar das bordas esquerda e direita da orientação atual da tela.
• [C-7-2] Se os painéis do sistema deslizável personalizados forem fornecidos nas bordas esquerda ou direita, eles PRECISAM ser colocados no 1/3 da parte de cima da tela com uma indicação visual clara e persistente de que arrastar os painéis invocaria os painéis mencionados acima e, portanto, não "Voltar". Um painel do sistema PODE ser configurado por um usuário para ficar abaixo do 1/3 superior das bordas da tela, mas o painel do sistema NÃO PODE usar mais do que 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, que se comportam como REQUIRED no SDK implementado.
• [C-7-4] Quando o app em primeiro plano tem View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BYD_SWIPEK (barras de status deslizáveis ou do sistema) implementadas como barras de status do sistema escondidas.

Se a função de navegação de retorno for fornecida e o usuário cancelar o gesto de Voltar:

• [C-8-1] OnBackInvokedCallback.onBackCancelled() PRECISA ser chamado.
• [C-8-2] O OnBackInvokedCallback.onBackInvoked() NÃO PODE ser chamado.
• [C-8-3] O evento KEYCODE_BACK NÃO PODE 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, então:

• O sistema PRECISA fornecer uma animação para o aplicativo em primeiro plano que sugira que o usuário está voltando, conforme fornecido no AOSP.

Se as implementações do dispositivo oferecerem suporte à API do sistema setNavBarMode para permitir que qualquer app do sistema com a permissão android.permission.STATUS_BAR defina o modo da barra de navegação, elas:

• [C-9-1] PRECISA oferecer suporte a ícones para crianças ou à navegação baseada em botões, conforme fornecido no código AOSP.

7.2.4. Entrada por tela touch

O Android inclui suporte a vários sistemas de entrada de ponteiro, como telas sensíveis ao toque, touchpads e dispositivos de entrada por toque falsos. As implementações de dispositivos baseados em touchscreen são associadas a uma tela para que o usuário tenha a impressão de manipular itens diretamente na tela. Como o usuário está tocando diretamente na tela, o sistema não precisa de affordances 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 ao mouse ou ao toque).
• DEVE dar suporte a ponteiros totalmente rastreados de forma independente.

Se as implementações de dispositivos incluírem uma tela touchscreen (de toque único ou melhor) em uma tela principal compatível com o Android, elas:

• [C-1-1] PRECISA informar TOUCHSCREEN_FINGER para o campo da API Configuration.touchscreen.
• [C-1-2] PRECISA informar as flags de recurso android.hardware.touchscreen e android.hardware.faketouch.

Se as implementações de dispositivos incluírem uma tela touchscreen que possa rastrear mais de um único toque em uma tela principal compatível com Android, elas:

• [C-2-1] PRECISA informar as flags de recurso apropriadas android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand correspondentes ao tipo de tela touchscreen específica do dispositivo.

Se as implementações de dispositivos dependerem de um dispositivo de entrada externo, como mouse ou trackball (ou seja, sem tocar diretamente na tela) para entrada em uma tela principal compatível com o Android e atenderem aos requisitos de toque falso na seção 7.2.5, elas:

• [C-3-1] NÃO É POSSÍVEL reportar uma flag de recurso que comece com android.hardware.touchscreen.
• [C-3-2] PRECISA informar apenas android.hardware.faketouch.
• [C-3-3] É NECESSÁRIO informar TOUCHSCREEN_NOTOUCH no campo da API Configuration.touchscreen.

7.2.5. Entrada de toque falsa

A interface de toque simulada fornece um sistema de entrada do usuário que se aproxima de um subconjunto de recursos da tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela se aproxima do toque, mas exige que o usuário primeiro aponte ou foque e clique. Vários dispositivos de entrada, como mouse, trackpad, mouse aéreo baseado em giroscópio, ponteiro giroscópio, joystick e trackpad multitoque, podem oferecer suporte a interações falsas por toque. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada de alta fidelidade sem toque (baseado no ponteiro), como um mouse ou trackpad que pode emular adequadamente entradas por toque (incluindo suporte básico a gestos) e indica que o dispositivo oferece suporte a um subconjunto emulado de funcionalidade de tela touchscreen.

Se as implementações de dispositivos não incluírem uma tela touchscreen, mas incluirem outro sistema de entrada de ponteiro que querem 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] PRECISA informar as posições absolutas da tela X e Y da localização do ponteiro e mostrar um ponteiro visual na tela.
• [C-1-2] PRECISA informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre no ponteiro que desce ou sobe na tela.
• [C-1-3] PRECISA oferecer suporte ao ponteiro para cima e para baixo em um objeto na tela, o que permite que os usuários emulem o toque em um objeto na tela.
• [C-1-4] PRECISA oferecer suporte ao ponteiro para baixo, para cima, para baixo e para cima no mesmo lugar de um objeto na tela dentro de um limite de tempo, o que permite que os usuários emulem toques duplos em um objeto na tela.
• [C-1-5] PRECISA oferecer suporte ao ponteiro para baixo em um ponto arbitrário na tela, ele se mover para qualquer outro ponto arbitrário na tela, seguido por um ponteiro para cima, o que permite que os usuários emulem uma ação de arrastar 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, apontem para cima na tela, o que permite que os usuários deslizem um objeto na tela.

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

• [C-2-1] PRECISA declarar compatibilidade com android.hardware.faketouch.
• [C-2-2] PRECISA oferecer suporte ao rastreamento distinto de duas ou mais entradas de ponteiro independentes.

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

• [C-3-1] PRECISA declarar compatibilidade com android.hardware.faketouch.
• [C-3-2] PRECISA oferecer suporte ao rastreamento distinto de cinco (rastreamento de uma mão) ou mais entradas de ponteiro de maneira totalmente independente.

7.2.6. Suporte a controles de jogos

7.2.6.1. Mapeamentos de botões

Implementações de dispositivos:

• [C-1-1] PRECISA ser capaz de mapear eventos 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 dispositivo incorporarem um controlador ou enviarem com um controlador separado na caixa, que forneça meios de inserir todos os eventos listados nas tabelas abaixo, elas:

• [C-2-1] PRECISA declarar a flag de recurso android.hardware.gamepad.

Botão	Uso de HID^2	Botão do Android
R^1	0x09 0x0001	KEYCODE_BOT_A (96)
B^1	0x09 0x0002	KEYCODE_BOT_B (97)
X^1	0x09 0x0004	KEYCODE_BOT_X (99)
A^1	0x09 0x0005	KEYCODE_BOT_Y (100)
Botão direcional para cima^1 Botão direcional para baixo^1	0x01 0x0039^3	Eixo_HAT_Y^4
Botão direcional à esquerda1 Botão direcional à direita^1	0x01 0x0039^3	Eixo_HAT_X^4
Botão do ombro esquerdo^1	0x09 0x0007	KEYCODE_Button_L1 (102)
Botão do ombro direito^1	0x09 0x0008	KEYCODE_Botão_R1 (103)
Clique com o botão esquerdo do mouse^1	0x09 0x000E	KEYCODE_BOT_THUMBL (106)
Clique com o botão direito do mouse^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 longe do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima está sendo pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e para a esquerda sendo pressionadas.

4 MotionEvent

Controles analógicos^1	Uso de HID	Botão do Android
Gatilho esquerdo	0x02 0x00C5	AXIS_LTRIGGER
Gatilho correto	0x02 0x00C4	EIXO_RTRIGGER
Joystick esquerdo	0x01 0x0030 0x01 0x0031	EIXO_X Eixo_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 dos dispositivos.

7,3 Sensores

Se as implementações do 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] PRECISA informar com precisão a presença ou ausência de sensores de acordo com a classe android.content.pm.PackageManager.
• [C-0-2] PRECISA retornar uma lista precisa de sensores com suporte usando SensorManager.getSensorList() e métodos semelhantes.
• [C-0-3] PRECISA se comportar de maneira razoável com todas as outras APIs de sensores. Por exemplo, retornando true ou false conforme apropriado quando os aplicativos tentam registrar listeners, não chamando listeners quando os sensores correspondentes não estão presentes etc.

Se as implementações do dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, elas:

• [C-1-1] PRECISA informar todas as medições do sensor usando os valores relevantes do Sistema Internacional de Unidades (métricas) para cada tipo de sensor, conforme definido na documentação do SDK do Android.
• [C-1-2] PRECISA informar os dados do sensor com latência máxima de 100 milissegundos + 2 * sample_time para o caso de um stream do sensor com uma latência máxima solicitada de 0 ms quando o processador do aplicativo estiver ativo. Esse atraso não inclui atrasos de filtragem.
• [C-1-3] PRECISA informar a primeira amostra do sensor em até 400 milissegundos + 2 * sample_time do sensor que está 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 de dispositivos PRECISAM fornecer continuamente amostras de dados periódicas que DEVEM ter uma instabilidade abaixo de 3%, em que a instabilidade é definida como o desvio padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.
• [C-1-5] PRECISA garantir que o fluxo de eventos do sensor NÃO possa impedir que a CPU do dispositivo entre em um estado de suspensão ou desperte de um estado de suspensão.
• [C-1-6] PRECISA informar o horário do evento em nanossegundos, conforme definido na documentação do SDK do Android, representando a hora em que o evento ocorreu e sincronizado com o relógio SystemClock.elapsedRealtimeNano().
• [C-SR-1] São RECOMENDADOS ALTAMENTE para ter erros de sincronização de carimbo de data/hora abaixo de 100 milissegundos e DEVEM ter erros de sincronização de carimbo de data/hora abaixo de 1 milissegundo.
• Quando vários sensores estiverem ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia relatado de cada sensor individual.

A lista acima não é abrangente. O comportamento documentado do SDK do Android e das documentações de código aberto do Android em sensores é considerado oficial.

Se as implementações do dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, elas:

• [C-1-6] PRECISA definir uma resolução diferente de zero para todos os sensores e informar o valor usando o método da API Sensor.getResolution().

Alguns tipos de sensor são compostos, o que significa que podem ser derivados de dados fornecidos por um ou mais sensores. Alguns exemplos são os sensores de orientação e de aceleração linear.

Implementações de dispositivos:

• DEVEM implementar esses tipos de sensor, quando incluem os sensores físicos de pré-requisito, conforme descrito em Tipos de sensor.

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

• [C-2-1] PRECISA implementar o sensor, conforme descrito na documentação do Android Open Source sobre sensores compostos.

Se as implementações do dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores de terceiros e o sensor informar apenas um valor, as implementações do dispositivo:

• [C-3-1] PRECISA definir a resolução como 1 para o sensor e informar o valor pelo método da API Sensor.getResolution().

Se as implementações do dispositivo incluírem um tipo de sensor específico que oferece suporte ao SensorAdditionalInfo#TYPE_VEC3_CALIBRATION e o sensor for exposto a desenvolvedores terceirizados, elas:

• [C-4-1] NÃO PODE incluir nenhum parâmetro de calibração fixo e determinado pela fábrica nos dados fornecidos.

Se as implementações de dispositivos incluírem uma combinação de acelerômetro de três eixos, um sensor de giroscópio de três eixos ou um sensor magnetômetro, elas serão:

• [C-SR-2] MUITO RECOMENDADO para 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] É MUITO RECOMENDADO incluir um acelerômetro de três eixos.

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

• [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
• [C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android.
• [C-1-4] PRECISA ser capaz de 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] PRECISA ter um desvio padrão não superior a 0,05 m/s^, em que o desvio padrão deve ser calculado por eixo, em amostras coletadas durante um período de pelo menos 3 segundos com a taxa de amostragem mais rápida.
• DEVE relatar eventos de até pelo menos 200 Hz.
• DEVE ter uma resolução de pelo menos 16 bits.
• DEVE ser calibrada durante o uso se as características mudarem ao longo do ciclo de vida e compensadas, além de preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• DEVE ser compensado por temperatura.

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

• [C-2-1] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER.
• [C-SR-4] É FORTEMENTE RECOMENDADO a implementação do sensor composto TYPE_SIGNIFICANT_MOTION.
• [C-SR-5] É FORTEMENTE RECOMENDADO implementar e informar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. Os dispositivos Android são MUITO RECOMENDADOS para atender a esse requisito para que possam fazer upgrade para a versão futura da plataforma, em que isso pode se tornar OBRIGATÓRIO.
• É NECESSÁRIO implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER, conforme descrito no documento do SDK do Android.

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

• [C-3-1] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
• [C-SR-6] São STRONGLY_RECOMMENDED para 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 deles PRECISA estar abaixo de 2 mW e 0,5 mW quando o dispositivo estiver em uma condição dinâmica ou estática.

Se as implementações de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, elas:

• [C-5-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR-7] É FORTEMENTE RECOMENDADO para implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

Se as implementações de dispositivos incluírem um acelerômetro de três eixos, um sensor de giroscópio de três eixos e um sensor magnetômetro, elas:

• [C-6-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

7.3.2. Magnetômetro

Implementações de dispositivos:

• [C-SR-1] É RECOMENDADO incluir um magnetômetro de três eixos (bússola).

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

• [C-1-1] PRECISA implementar o sensor TYPE_MAGNETIC_FIELD.
• [C-1-2] PRECISA relatar eventos com até uma frequência de pelo menos 10 Hz e DEVE relatar eventos de até 50 Hz.
• [C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android.
• [C-1-4] PRECISA ser capaz de medir entre -900 μT e +900 μT em cada eixo antes da saturação.
• [C-1-5] PRECISA ter um valor de compensação do ferro rígido menor que 700 μT e deve ter um valor abaixo de 200 μT, posicionando o magnetômetro longe dos campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímãs).
• [C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 μT.
• [C-1-7] PRECISA oferecer suporte à calibragem on-line e à compensação do viés físico de ferro, além de preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• [C-1-8] PRECISA ter a compensação de ferro suave aplicada. A calibração pode ser feita durante o uso ou durante a produção do dispositivo.
• [C-1-9] PRECISA ter um desvio padrão, calculado por eixo, em amostras coletadas durante um período de pelo menos 3 segundos com a taxa de amostragem mais rápida, não superior a 1,5 μT. DEVE ter um desvio padrão não superior a 0,5 μT.
• [C-1-10] PRECISA implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se as implementações de dispositivos incluírem um magnetômetro de três eixos, um sensor de acelerômetro e um sensor de giroscópio de três eixos, elas:

• [C-2-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

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

• PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se as implementações de dispositivos incluírem um magnetômetro de três eixos, um acelerômetro e um sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR, elas:

• [C-3-1] PRECISA consumir menos de 10 mW.
• DEVE consumir menos de 3 mW quando o sensor estiver registrado no modo de lote a 10 Hz.

7.3.3. GPS

Implementações de dispositivos:

• [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um receptor GPS/GNSS.

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

• [C-1-1] PRECISA oferecer suporte a saídas de local a uma taxa de pelo menos 1 Hz quando solicitado via LocationManager#requestLocationUpdate.
• [C-1-2] PRECISA determinar o local em condições de céu aberto (sinais fortes, multicaminho insignificante, HDOP < 2) em até 10 segundos (tempo rápido para a primeira correção) quando conectado a uma conexão de Internet com velocidade de dados de 0,5 Mbps ou mais rápida. Esse requisito geralmente é atendido com o uso de alguma forma de técnica de GPS/GNSS assistida ou prevista para minimizar o tempo de bloqueio do GPS/GNSS (os dados de assistência incluem horário de referência, local de referência e efêmeras/relógios de satélite).
  • [C-1-6] Depois de fazer esse cálculo, as implementações do dispositivo PRECISAM determinar a localização dele em céu aberto em até cinco segundos, quando as solicitações de localização forem reiniciadas, até uma hora após o cálculo inicial, mesmo quando a solicitação subsequente for feita sem uma conexão de dados e/ou após uma reinicialização.

• Em condições de céu aberto após determinar a localização, enquanto está estacionário ou em movimento com menos de 1 metro por segundo ao quadrado de aceleração:

  • [C-1-3] PRECISA determinar a localização dentro de 20 metros e a velocidade dentro de 0, 5 metro por segundo, pelo menos 95% do tempo.
  • [C-1-4] PRECISA rastrear e informar simultaneamente por meio de GnssStatus.Callback pelo menos oito satélites de uma constelação.
  • DEVE ser capaz de rastrear simultaneamente, pelo menos, 24 satélites, de várias constelações (por exemplo, GPS + pelo menos um de Glonass, Beidou, Galileo).

• [C-SR-2] É FORTEMENTE RECOMENDADO para continuar a fornecer saídas de localização de GPS/GNSS normais pela API GNSS Location Provider durante uma chamada de emergência.

• [C-SR-3] É FORTEMENTE RECOMENDADO para informar medições de GNSS de todas as constelações rastreadas (conforme relatado em mensagens GnssStatus), exceto SBAS.

• [C-SR-4] É FORTEMENTE RECOMENDADO a informar o AGC e a frequência de medição do GNSS.

• [C-SR-5] É FORTEMENTE RECOMENDADO para informar todas as estimativas de precisão (incluindo rolamento, velocidade e vertical) como parte de cada localização GPS/GNSS.

• [C-SR-6] É FORTEMENTE RECOMENDADO para informar medições GNSS assim que elas são encontradas, mesmo que uma localização calculada com o GPS/GNSS ainda não tenha sido relatada.

• [C-SR-7] É RECOMENDADO para informar pseudodistâncias e pseudodistâncias de GNSS que, em condições de céu aberto após determinar a localização, enquanto estacionárias ou em movimento com menos de 0,2 metro por segundo ao quadrado de aceleração, são suficientes para calcular uma posição dentro de 20 metros e velocidade dentro de 0,29 metros por segundo, pelo menos 0,29 por segundo.

7.3.4. Giroscópio

Implementações de dispositivos:

• [C-SR-1] É MUITO RECOMENDADO incluir um sensor de giroscópio.

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

• [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
• [C-1-4] PRECISA ter uma resolução de 12 bits ou mais.
• [C-1-5] PRECISA ser compensado pela temperatura.
• [C-1-6] PRECISA 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 superior a 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar de acordo com a taxa de amostragem, mas PRECISA ser restrita por esse valor. Em outras palavras, se você medir a variância do giroscópio na taxa de amostragem de 1 Hz, ela DEVE ser menor que 1e-7 rad^2/s^2.
• [C-SR-2] O erro de calibração é FORTEMENTE RECOMENDADO ser menor que 0,01 rad/s quando o dispositivo está parado em temperatura ambiente.
• [C-SR-3] É FORTEMENTE RECOMENDADO ter uma resolução de 16 bits ou mais.
• DEVE relatar eventos de até pelo menos 200 Hz.

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

• [C-2-1] PRECISA implementar o sensor TYPE_GYROSCOPE.
• [C-SR-4] É altamente recomendável implementar o sensor TYPE_GYROSCOPE_UNCALIBRATED.

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

• [C-3-1] PRECISA implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] São STRONGLY_RECOMMENDED para implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Se as implementações de dispositivos incluírem um giroscópio de três eixos, um sensor de acelerômetro e um sensor de magnetômetro, elas:

• [C-4-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

Se as implementações de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, elas:

• [C-5-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR-6] É FORTEMENTE RECOMENDADO para implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

Implementações de dispositivos:

• [C-SR-1] É FORTEMENTE RECOMENDADO a inclusão de um barômetro (sensor de pressão de ar ambiente).

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

• [C-1-1] PRECISA implementar e informar o sensor TYPE_PRESSURE.
• [C-1-2] PRECISA entregar eventos com frequência de 5 Hz ou mais.
• [C-1-3] PRECISA ser compensado pela temperatura.
• [C-SR-2] É MUITO RECOMENDADO para informar medições de pressão no intervalo de 300 hPa a 1.100 hPa.
• DEVE ter uma precisão absoluta de 1hPa.
• DEVE ter uma precisão relativa de 0,12 hPa em um intervalo de 20 hPa (equivalente a uma precisão de cerca de 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] PRECISA definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura ambiente, que PRECISA medir a temperatura ambiente (cabine do veículo/sala) em que 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 temperatura ambiente, como a temperatura da CPU, elas:

• [C-2-1] NÃO PODE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura.

Se as implementações de dispositivos incluírem um sensor para monitorar a temperatura da pele, elas:

• [C-SR-1] É RECOMENDADO A compatibilidade com a 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 relatarem apenas uma leitura binária de "perto" ou "longe", elas:

• [C-1-1] PRECISA medir a proximidade de um objeto na mesma direção que a tela. Ou seja, o sensor de proximidade PRECISA estar orientado para detectar objetos próximos à tela, já que a intent principal desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se as implementações do dispositivo incluem um sensor de proximidade com qualquer outra orientação, ele NÃO PODE SER acessível por essa API.
• [C-1-2] PRECISA ter 1 bit de precisão ou mais.
• [C-1-3] PRECISA usar 0 centímetros como a leitura próxima e 5 centímetros como a leitura distante.
• [C-1-4] PRECISA informar um alcance e uma resolução máximos de 5.

7.3.9. Sensores de alta fidelidade

Se as implementações de dispositivos incluírem um conjunto de sensores de qualidade mais alta, conforme definido nesta seção, e os disponibilizarem para apps de terceiros, elas:

• [C-1-1] PRECISA identificar o recurso pela flag de recurso android.hardware.sensor.hifi_sensors.

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

• [C-2-1] PRECISA ter um sensor TYPE_ACCELEROMETER que:

  • PRECISA ter um intervalo de medição entre pelo menos -8 g e +8 g, e é FORTEMENTE RECOMENDADO que tenha um intervalo de medição entre pelo menos -16 g e +16 g.
  • PRECISA ter uma resolução de medição de pelo menos 2.048 LSB/g.
  • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais. DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
  • PRECISA ter um ruído de medição menor ou igual a 400 μg/✓Hz.
  • PRECISA implementar uma forma sem ativação desse sensor com uma capacidade de armazenamento em buffer de pelo menos 3.000 eventos.
  • PRECISA ter um consumo de energia em lote não inferior a 3 mW.
  • [C-SR-1] É FORTEMENTE 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 com menos de 30 μg ≥ Hz testada à temperatura ambiente.
  • DEVE ter uma mudança de viés x temperatura de ≤ +/- 1 mg/°C.
  • DEVE ter uma não linearidade de linha de melhor ajuste ≤ 0,5%, e a mudança de sensibilidade x temperatura de ≤ 0,03%/C°.
  • DEVE ter sensibilidade entre eixos de < 2,5 % e variação de sensibilidade entre eixos < 0,2% na faixa de temperatura de operação do dispositivo.

• [C-2-2] PRECISA ter um TYPE_ACCELEROMETER_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_ACCELEROMETER.

• [C-2-3] PRECISA ter um sensor TYPE_GYROSCOPE que:

  • PRECISA ter um intervalo de medição entre -1.000 e +1.000 dps.
  • PRECISA ter uma resolução de medida de pelo menos 16 LSB/dps.
  • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais. DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
  • PRECISA ter um ruído de medição não superior a 0,014°/s/concordate.
  • [C-SR-2] É MUITO 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 abaixo de 0,001 °/s cione Hz testada à temperatura ambiente.
  • DEVE ter uma mudança de viés x temperatura ≤ +/- 0,05 °/ s / °C.
  • DEVE ter uma mudança de sensibilidade x 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 menor ou igual a 0,007 °/s/shaped Hz.
  • DEVE ter um erro de calibração inferior a 0,002 rad/s na faixa de temperatura de 10 ~ 40 °C quando o dispositivo estiver parado.
  • DEVE ter sensibilidade à g menor que 0,1°/s/g.
  • DEVE ter sensibilidade entre eixos < 4 % e variação de sensibilidade entre eixos < 0,3% na faixa de temperatura de operação do dispositivo.

• [C-2-4] PRECISA ter um TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_GYROSCOPE.

• [C-2-5] PRECISA ter um sensor TYPE_GEOMAGNETIC_FIELD que:

  • PRECISA ter um intervalo de medição entre -900 e +900 μT.
  • PRECISA ter uma resolução de medida de pelo menos 5 LSB/uT.
  • PRECISA ter uma frequência de medição mínima de 5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 50 Hz ou mais.
  • PRECISA ter um ruído de medição menor que 0,5 uT.

• [C-2-6] PRECISA ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_GEOMAGNETIC_FIELD, além de:

  • PRECISA implementar uma forma sem ativação desse sensor com uma capacidade de armazenamento em buffer de pelo menos 600 eventos.
  • [C-SR-3] É FORTEMENTE RECOMENDADO que tenha o espectro de ruído branco de 1 Hz a pelo menos 10 Hz quando a taxa do relatório for de 50 Hz ou maior.

• [C-2-7] PRECISA ter um sensor TYPE_PRESSURE que:

  • PRECISA ter um intervalo de medição entre 300 e 1.100 hPa.
  • PRECISA ter uma resolução de medida de pelo menos 80 LSB/hPa.
  • PRECISA ter uma frequência de medição mínima de 1 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 10 Hz ou mais.
  • PRECISA ter um ruído de medição não superior a 2 Pa/cioneHz.
  • PRECISA implementar uma forma sem ativação desse sensor com uma capacidade de armazenamento em buffer de pelo menos 300 eventos.
  • PRECISA ter um consumo de energia em lote não inferior a 2 mW.

• [C-2-8] PRECISA ter um sensor TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] PRECISA ter um sensor TYPE_SIGNIFICANT_MOTION que:

  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.

• [C-2-10] PRECISA ter um sensor TYPE_STEP_DETECTOR que:

  • PRECISA implementar uma forma sem ativação desse sensor com uma capacidade de armazenamento em buffer de pelo menos 100 eventos.
  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.
  • PRECISA ter um consumo de energia em lote não inferior a 4 mW.

• [C-2-11] PRECISA ter um sensor TYPE_STEP_COUNTER que:

  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.

• [C-2-12] PRECISA ter um sensor TILT_DETECTOR que:

  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.

• [C-2-13] O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro, giroscópio e magnetômetro PRECISA estar a no máximo 2, 5 milissegundos um do outro. O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro e pelo giroscópio PRECISA ter no máximo 0,25 milissegundo de um do outro.

• [C-2-14] PRECISA ter carimbos de data/hora do evento do sensor do giroscópio na mesma base de tempo que o subsistema da câmera e em até 1 milissegundo de erro.

• [C-2-15] PRECISA entregar amostras aos aplicativos em até cinco 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 de 2,0 mW quando o dispositivo está em movimento quando qualquer combinação dos seguintes sensores está ativada:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] PODE ter um sensor TYPE_PROXIMITY, mas, se presente, PRECISA ter uma capacidade mínima de buffer de 100 eventos de sensor.

Observe que todos os requisitos de consumo de energia nesta seção não incluem o consumo de energia do processador do aplicativo. Ele inclui a energia detida por toda a cadeia de sensores: o sensor, qualquer circuito de suporte, qualquer sistema de processamento de sensor dedicado etc.

Se as implementações do dispositivo incluírem suporte direto a sensores, elas:

• [C-3-1] PRECISA declarar corretamente o suporte aos tipos de canal direto e ao nível de taxas de relatórios diretos usando as APIs isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
• [C-3-2] PRECISA oferecer suporte a pelo menos um dos dois tipos de canal direto para todos os sensores que declaram suporte ao canal direto do sensor.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DEVE oferecer suporte a 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 a documentação sobre como medir a segurança biométrica.

Se as implementações de dispositivos incluírem uma tela de bloqueio segura, elas:

• DEVE incluir um sensor biométrico

Os sensores biométricos podem ser classificados como Classe 3 (anteriormente Forte), Classe 2 (anteriormente Fraco) ou Classe 1 (anteriormente Conveniência) com base nas taxas de aceitação de spoofing e impostores e na segurança do pipeline biométrico. Essa classificação determina os recursos que o sensor biométrico tem para interagir com a plataforma e com aplicativos de terceiros. Os sensores precisam atender a outros requisitos, conforme detalhado abaixo, se quiserem ser classificados como Classe 1, Classe 2 ou Classe 3. As biometrias de Classe 2 e Classe 3 recebem recursos adicionais, conforme detalhado abaixo.

Se as implementações do dispositivo disponibilizarem um sensor biométrico para aplicativos de terceiros por android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, elas:

• [C-4-1] PRECISA atender aos requisitos de biometria de Classe 3 ou Classe 2, conforme definido neste documento.
• [C-4-2] PRECISA reconhecer e respeitar cada nome de parâmetro definido como uma constante na classe Authenticators e todas as combinações deles. Por outro lado, NÃO É POSSÍVEL respeitar ou reconhecer as constantes inteiras passadas aos métodos canAuthenticate(int) e setAllowedAuthenticators(int) além das documentadas como constantes públicas em Authenticators e suas combinações.
• [C-4-3] PRECISA implementar a ação ACTION_BIOMETRIC_ENROLL em dispositivos que têm biometria de Classe 3 ou de Classe 2. Essa ação PRECISA apresentar apenas os pontos de entrada de registro para biometria de Classe 3 ou de Classe 2.

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

• [C-5-1] PRECISA, por padrão, exigir uma etapa de confirmação extra (por exemplo, o pressionamento de um botão).
• [C-SR-1] É FORTEMENTE RECOMENDADO ter uma configuração que permita que os usuários substituam a preferência do aplicativo e sempre exija uma etapa de confirmação acompanhada.
• [C-SR-2] É FORTEMENTE RECOMENDADO que a ação de confirmação seja protegida, de modo que um comprometimento do sistema operacional ou do kernel não possa fazer spoofing. Por exemplo, isso significa que a ação de confirmação com base em um botão físico é roteada por um pin de entrada/saída de uso geral (GPIO, na sigla em inglês) somente de entrada de um elemento de segurança (SE) que não pode ser conduzida por nenhum outro meio além do pressionamento de um botão físico.
• [C-5-2] PRECISA implementar também um fluxo de autenticação implícito (sem etapa de confirmação) correspondente a setConfirmationRequired(boolean), que pode ser configurado para usar em fluxos de login.

Se as implementações de dispositivos tiverem vários sensores biométricos, elas:

• [C-SR-3] É RECOMENDADO que apenas uma biometria seja confirmada por autenticação (por exemplo, se a impressão digital e os sensores faciais estiverem disponíveis no dispositivo, onAuthenticationSucceeded precisa ser enviado depois que qualquer um deles for confirmado).

Para que as implementações de dispositivos permitam o acesso a chaves de keystore para aplicativos de terceiros, elas:

• [C-6-1] PRECISA atender aos requisitos de Classe 3, conforme definido na seção abaixo.
• [C-6-2] PRECISA apresentar apenas biometrias de Classe 3 quando a autenticação exigir BIOMETRIC_STRONG ou quando a autenticação for invocada com um CryptoObject.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Class 1 (anteriormente Convenience), elas:

• [C-1-1] PRECISA ter uma taxa de aceitação falsa menor que 0,002%.
• [C-1-2] PRECISA divulgar que esse modo pode ser menos seguro que um PIN, padrão ou senha fortes e enumerar claramente os riscos de ativá-lo, se as taxas de aceitação de spoofing e impostores forem maiores que 7%, conforme medido pelos Android Biometrics Test Protocols.
• [C-1-9] PRECISA desafiar o usuário quanto à autenticação principal recomendada (por exemplo, PIN, padrão e senha) após no máximo 20 tentativas falsas e no máximo 90 segundos de espera para a verificação biométrica, em que um teste falso tem uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
• [C-SR-4] É RECOMENDADO ALTAMENTE a redução do número total de testes falsos para a verificação biométrica especificada em [C-1-9] se as taxas de aceitação de spoofing e impostores forem superiores a 7%, conforme medido pelos Protocolos de Teste de Biometria do Android.
• [C-1-3] Tentativas de limite de taxa PRECISA para verificação biométrica, em que um teste falso é aquele com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
• [C-SR-5] É FORTEMENTE RECOMENDADO as tentativas de limite de taxa por pelo menos 30 segundos após cinco testes falsos para verificação biométrica para o número máximo de testes falsos por [C-1-9], em que um teste falso é aquele com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
• [C-SR-6] É FORTEMENTE RECOMENDADO ter toda a lógica de limitação de taxa no TEE.
• [C-1-10] PRECISA desativar a biometria depois que a espera de autenticação primária for acionada, conforme descrito em [C-0-2] da seção 9.11.
• [C-1-11] PRECISA ter uma taxa de aceitação de spoofing e impostor não superior a 30%, com (1) uma taxa de aceitação de impostor e de spoofing para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) de nível A não superior a 30% e (2) uma taxa de aceitação de impostor e de impostor de espécies PAI de nível B medidas não superior a 40%.
• [C-1-4] PRECISA evitar a adição de novas biometrias sem antes estabelecer uma cadeia de confiança, pedindo que o usuário confirme já existente ou adicione uma nova credencial do 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] PRECISA remover completamente todos os dados biométricos identificáveis de um usuário quando a conta dele for removida, inclusive por meio de uma redefinição para a configuração original.
• [C-1-6] PRECISA respeitar a sinalização individual dessa biometria (ou seja, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
• [C-1-7] PRECISA desafiar o usuário quanto à autenticação principal recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 24 horas ou menos. Observação: o upgrade de dispositivos lançados com o Android 9 ou versões anteriores PRECISA desafiar o usuário quanto à autenticação principal recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos.
• [C-1-8] PRECISA contestar o usuário quanto à autenticação principal recomendada (por exemplo: PIN, padrão, senha) ou biometria de Classe 3 (STRONG) após uma das seguintes opções:
  • um tempo limite de inatividade de 4 horas OU
  • 3 tentativas de autenticação biométrica falharam.
  • O tempo limite de inatividade e a contagem de autenticação com falha são redefinidos após qualquer confirmação bem-sucedida das credenciais do dispositivo. Observação: o upgrade de dispositivos lançados com o Android 9 ou versões anteriores podem estar isentos do C-1-8.
• [C-SR-7] É FORTEMENTE RECOMENDADO usar a lógica no framework fornecido pelo Android Open Source Project para aplicar as restrições especificadas em [C-1-7] e [C-1-8] para novos dispositivos.
• [C-SR-8] É RECOMENDADO que tenha uma taxa de rejeição falsa de menos de 10%, conforme medido no dispositivo.
• [C-SR-9] É RECOMENDADO que tenha uma latência inferior a 1 segundo, medida a partir do momento em que a biometria é detectada, até a tela ser desbloqueada, para cada biometria registrada.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Class 2 (anteriormente fraco), elas:

• [C-2-1] PRECISA atender a todos os requisitos da Classe 1 acima.

• [C-2-2] PRECISA ter uma taxa de aceitação de impostor e de impostor não superior a 20%, com (1) taxa de aceitação de impostor e spoofing para espécies de instrumento de ataque de apresentação de nível A (PAI, na sigla em inglês) não superior a 20% e (2) uma taxa de aceitação de impostor e de impostor de espécies de Nível B de PAI não superior a 30%, medidas pelo Android Biometrics.

• [C-2-3] PRECISA realizar a correspondência biométrica em um ambiente de execução isolado fora do usuário do Android ou do espaço do kernel, 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] PRECISA ter todos os dados identificáveis criptografados e autenticados criptograficamente para que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação no site do Android Open Source Project.

• [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 de um modo que impeça que os frames da câmera sejam 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.
  • Para soluções RGB de câmera única, os frames da câmera PODEM ser legíveis fora do ambiente de execução isolado para oferecer suporte a operações como a visualização para registro, mas NÃO PODEM ser alterados.

• [C-2-6] NÃO PODE ativar aplicativos de terceiros para distinguir entre registros biométricos individuais.

• [C-2-7] NÃO PODE permitir acesso não criptografado a dados biométricos identificáveis ou dados derivados deles (como embeddings) para o processador de aplicativos fora do contexto do TEE. O upgrade de dispositivos lançados no Android 9 ou versões anteriores não está isento do C-2-7.

• [C-2-8] PRECISA ter um pipeline de processamento seguro, de modo que um sistema operacional ou um comprometimento do kernel não permita que dados sejam injetados diretamente para autenticar falsamente como o usuário. Observação: se as implementações de dispositivos já tiverem sido lançadas no Android 9 ou versões anteriores e não puderem atender ao requisito C-2-8 com uma atualização de software do sistema, elas PODEM ser isentas da exigência.

• [C-SR-10] É MUITO RECOMENDADO incluir a detecção de presença em todas as modalidades biométricas e a detecção de atenção para biometria facial.

• [C-2-9] PRECISA disponibilizar o sensor biométrico para aplicativos de terceiros.

Se as implementações de dispositivo quiserem tratar um sensor biométrico como Class 3 (anteriormente Strong), elas:

• [C-3-1] PRECISA atender a todos os requisitos da Classe 2 acima, exceto [C-1-7] e [C-1-8].
• [C-3-2] PRECISA ter uma implementação de keystore suportada por hardware.
• [C-3-3] PRECISA ter uma taxa de aceitação de spoofing e impostor não superior a 7%, com (1) uma taxa de aceitação de impostor e de spoofing para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) nível A não superior a 7% e (2) uma taxa de aceitação de spoofing e impostor de espécies PAI de nível B não superior a 20%, conforme medido pelo Biometrics Test Protocol.
• [C-3-4] PRECISA desafiar o usuário quanto à autenticação principal recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos.
• [C-3-5] PRECISA gerar novamente o ID do autenticador para todas as biometrias de Classe 3 compatíveis com o dispositivo, se alguma delas for registrada novamente.
• [C-3-6] É necessário ativar chaves de keystore com biometria para aplicativos de terceiros.

Se as implementações de dispositivos contiverem um sensor de impressão digital sob a tela (UDFPS, na sigla em inglês), elas:

• [C-SR-11] São RECOMENDADOS PARA evitar que a área de toque do UDFPS interfira na navegação com três botões, o que alguns usuários podem exigir para fins de acessibilidade.

7.3.11. Sensor de posição

Implementações de dispositivos:

• PODE suportar o sensor de pose com 6 graus de liberdade.

Se as implementações de dispositivos oferecerem suporte a sensores de posição com 6 graus de liberdade, elas:

• [C-1-1] PRECISA implementar e informar o sensor TYPE_POSE_6DOF.
• [C-1-2] PRECISA ser mais preciso do que apenas o vetor de rotação.

7.3.12. Sensor de ângulo de dobradiça

Se as implementações de dispositivos oferecerem suporte a um sensor de ângulo de dobradiça, elas:

• [C-1-1] PRECISA 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] PRECISA retornar um sensor de ativação para getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 [Movido para 7.4.9]

7,4. Conectividade de dados

7.4.1. Telefonia

A "telefonia", conforme usada pelas APIs do Android e neste documento, se refere especificamente ao hardware relacionado à realização de chamadas de voz e ao envio de mensagens SMS por uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ter comutação por pacote, elas são para os fins do Android consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade de "telefonia" e as APIs do Android se referem especificamente a ligações e SMS. Por exemplo, implementações de dispositivos que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas dispositivos de telefonia, independentemente de usarem 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] PRECISA declarar a flag de recurso android.hardware.telephony e outras flags de recursos secundários de acordo com a tecnologia.
• [C-1-2] PRECISA implementar o suporte completo da API para essa tecnologia.
• DEVE permitir todos os tipos de serviço de celular disponíveis (2G, 3G, 4G, 5G etc.) durante chamadas de emergência, independentemente dos tipos de rede definidos pela SetAllowedNetworkTypeBitmap().

Se as implementações de dispositivos não incluírem hardware de telefonia, elas:

• [C-2-1] PRECISA implementar as APIs completas como ambiente autônomo.

Se as implementações de dispositivos oferecerem suporte a eUICCs ou eSIMs/chips incorporados e incluírem um mecanismo próprio para disponibilizar a funcionalidade de eSIM para desenvolvedores terceiros, elas:

• [C-3-1] PRECISA declarar a flag de recurso android.hardware.telephony.euicc.

Se as implementações de dispositivos não definirem a propriedade do sistema ro.telephony.iwlan\_operation\_mode como "legada", elas:

• [C-4-1] NÃO PODE informar "NETWORK_TYPE_IWLAN" por NetworkRegistrationInfo#getAccessNetworkTechnology() quando NetworkRegistrationInfo#getTransportType() é relatado como TRANSPORT_TYPE_WWAN para a mesma instância 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 de serviço de comunicação avançada (RCS) e precisarem atender aos requisitos da operadora de celular relacionados ao uso de um único registro de IMS para todo o tráfego de sinalização de IMS, elas:

• [C-5-1] PRECISA 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] PRECISA declarar a flag de recurso android.hardware.telephony.ims.singlereg e fornecer uma implementação completa da API SipTransport, da API GbaService, das indicações do portador usando a HAL IRadio 1.6 e do provisionamento pelo Servidor de configuração automática (ACS) ou outro mecanismo de provisionamento reservado usando a API IMS Configuration.

Se as implementações de dispositivos informarem o recurso android.hardware.telephony:

• [C-6-1] SmsManager#sendTextMessage e SmsManager#sendMultipartTextMessage PRECISAM resultar em chamadas correspondentes para CarrierMessagingService para fornecer 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 APIs SmsManager ao enviar e receber mensagens SMS e MMS. A implementação de referência do AOSP em pacotes/apps/mensagens atende a esse requisito.
• [C-6-3] O aplicativo que responde a Intent#ACTION_DIAL PRECISA oferecer suporte à entrada de códigos arbitrários de discador 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 exibir a transcrição visual do correio de voz aos usuários se for compatível com transcrições visuais do correio de voz.
• [C-6-5] PRECISA representar todas as SubscriptionInfo com UUIDs de grupo equivalentes como uma única assinatura em todas as affordances visíveis ao usuário que mostram e controlam as informações do chip. Exemplos de tais affordances incluem interfaces de configurações que correspondem a Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
• [C-6-6] NÃO PODE mostrar ou permitir o controle de SubscriptionInfo com um UUID de grupo não nulo e bit oportunista em qualquer affordance visível ao usuário que permita a configuração ou o controle das configurações do chip.

Se as implementações do dispositivo informarem o recurso android.hardware.telephony e exibirem uma barra de status do sistema:

• [C-7-1] É NECESSÁRIO selecionar uma assinatura ativa representativa para um determinado UUID de grupo para mostrar ao usuário em qualquer affordance que forneça informações de status do chip. Exemplos de tais affordances incluem o ícone de sinal celular da barra de status ou o bloco de configurações rápidas.
• [C-SR-1] É FORTEMENTE RECOMENDADO que a assinatura representativa seja escolhida como a assinatura de dados ativa, a menos que o dispositivo esteja em uma ligação em que é RECOMENDADO que a assinatura representativa seja a assinatura ativa.

Se as implementações de dispositivos informarem o recurso android.hardware.telephony:

• [C-6-7] PRECISA ser capaz de abrir e utilizar 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] NÃO É POSSÍVEL aplicar nenhum dos seguintes comportamentos a apps de operadoras ativas (conforme designado por TelephonyManager#getCarrierServicePackageName) automaticamente ou sem confirmação explícita do usuário:
  • Revogar ou limitar o acesso à rede
  • Revogar permissões
  • Restringir a execução de apps em segundo ou primeiro plano além dos recursos de gerenciamento de energia atuais incluídos no AOSP
  • Desativar ou desinstalar o app

Se as implementações de dispositivos informarem o recurso android.hardware.telephony e todas as assinaturas não oportunistas ativas que compartilham um UUID de grupo forem desativadas, removidas fisicamente do dispositivo ou marcadas como oportunistas, o dispositivo:

• [C-8-1] PRECISA desativar automaticamente todas as assinaturas oportunistas ativas restantes no mesmo grupo.

Se as implementações de dispositivos incluírem a telefonia GSM, mas não a telefonia CDMA, elas:

• [C-9-1] NÃO PODE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] PRECISA gerar uma IllegalArgumentException em tentativas de definir qualquer tipo de rede 3GPP2 em bitmasks do tipo de rede preferencial 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:

• [C-10-1] PRECISA declarar a flag de recurso android.hardware.telephony.euicc.mep.

7.4.1.1 Compatibilidade com bloqueio de número

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

• [C-1-1] PRECISA incluir suporte para bloqueio de número
• [C-1-2] PRECISA implementar totalmente o BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.

• [C-1-3] PRECISA bloquear todas as chamadas e mensagens de um número de telefone em "BlockedNumberProvider" sem nenhuma interação com apps. A única exceção é quando o bloqueio de números é temporariamente suspenso, conforme descrito na documentação do SDK.

• [C-1-4] PRECISA gravar no provedor de registros de chamadas da plataforma para uma chamada bloqueada e filtrar chamadas com BLOCKED_TYPE fora da visualização padrão de registros no app discador pré-instalado.

• [C-1-5] NÃO PODE gravar uma mensagem bloqueada no provedor de telefonia.

• [C-1-6] PRECISA implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada pelo método TelecomManager.createManageBlockedNumbersIntent().

• [C-1-7] NÃO PODE permitir que usuários secundários acessem ou editem os números bloqueados no dispositivo, já que a plataforma Android pressupõe que o usuário principal tem controle total dos serviços de telefonia, uma única instância, no dispositivo. Todas as IUs relacionadas ao bloqueio PRECISAM estar ocultas para usuários secundários, e a lista de bloqueio PRECISA ainda ser respeitada.

• DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.

• DEVE fornecer uma funcionalidade de usuário para mostrar chamadas bloqueadas no app discador pré-instalado.

7.4.1.2 API Telecom

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

• [C-1-1] PRECISA oferecer suporte às APIs ConnectionService descritas no SDK.
• [C-1-2] PRECISA mostrar uma nova chamada recebida e fornecer funcionalidade ao usuário para aceitar ou rejeitar a chamada recebida quando o usuário estiver em uma chamada em andamento feita por um app de terceiros que não oferece suporte ao recurso de espera especificado via CAPABILITY_SUPPORT_HOLD.
• [C-1-3] PRECISA ter um aplicativo que implemente o InCallService.

• [C-SR-1] É FORTEMENTE RECOMENDADO que você notifique o usuário de que atender a uma chamada recebida vai encerrar uma chamada em andamento.

  A implementação do AOSP atende a esses requisitos por uma notificação de alerta, que indica ao usuário que atender a uma chamada recebida fará com que a outra seja interrompida.

• [C-SR-2] É FORTEMENTE RECOMENDADO pré-carregar o app discador padrão que mostra uma entrada de registro de chamadas e o nome de um app de terceiros no registro de chamadas quando o app de terceiros define a chave extra EXTRA_LOG_SELF_MANAGED_CALLS no PhoneAccount como true.

• [C-SR-3] São RECOMENDADOS para processar os eventos KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK do fone de ouvido para as APIs android.telecom, conforme mostrado abaixo:

  • Chame Connection.onDisconnect() quando um pressionamento breve do evento de tecla for detectado durante uma chamada em andamento.
  • Chame Connection.onAnswer() quando um pressionamento breve do evento de tecla for detectado durante uma ligação.
  • Chame Connection.onReject() quando o evento de tecla for pressionado durante uma ligação.
  • Alterne o status de silenciamento da CallAudioState.

7.4.1.3 Descarregamento de sinal de atividade NAT-T da rede celular

Implementações de dispositivos:

• DEVE incluir suporte para descarga de sinal de atividade de celular.

Se as implementações de dispositivos incluírem suporte à descarga de sinal de atividade de rede celular e expõem a funcionalidade a apps de terceiros, elas:

• [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
• [C-1-2] PRECISA oferecer suporte a pelo menos um slot de sinal de atividade simultâneo na rede celular.
• [C-1-3] PRECISA oferecer suporte ao máximo de slots de sinal de atividade móveis simultâneos que forem compatíveis com a HAL de rádio celular.
• [C-SR-1] É RECOMENDADO PARA oferecer suporte a pelo menos três slots de sinal de atividade de celular por instância de rádio.

Se as implementações de dispositivos não incluírem suporte para descarga de sinal de atividade celular, elas:

• [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementações de dispositivos:

• DEVE incluir suporte para uma ou mais formas de 802.11.

Se as implementações de dispositivos incluírem suporte para o 802.11 e exporem a funcionalidade a um aplicativo de terceiros, elas:

• [C-1-1] PRECISA implementar a API do Android correspondente.
• [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.wifi.
• [C-1-3] PRECISA implementar a API multicast, conforme descrito na documentação do SDK.
• [C-1-4] PRECISA oferecer suporte a multicast DNS (mDNS) e NÃO PODE filtrar pacotes mDNS (224.0.0.251) em qualquer momento de operação, incluindo:
  • Mesmo quando a tela não está ativa.
  • Para implementações de dispositivos Android Television, mesmo nos estados de energia em espera.
• [C-1-5] NÃO PODE tratar a chamada do método da API WifiManager.enableNetwork() como uma indicação suficiente para alternar o Network ativo no momento que é usado por padrão para o tráfego do aplicativo e é retornado por métodos de 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 com êxito que a rede Wi-Fi está fornecendo acesso à Internet.
• [C-1-6] São RECOMENDADOS PARA, quando o método da API ConnectivityManager.reportNetworkConnectivity() for chamado, reavaliar o acesso à Internet no Network e, quando a avaliação determinar que o Network atual não oferece mais acesso à Internet, mudar para qualquer outra rede disponível (por exemplo, dados móveis) que ofereça acesso à Internet.
• [C-1-7] PRECISA randomizar o endereço MAC de origem e o número da sequência dos frames de solicitação da sondagem, uma vez no início de cada verificação, enquanto a STA estiver desconectada.
• [C-1-8] PRECISA usar um endereço MAC consistente (NÃO DEVE randomizar o endereço MAC no meio da verificação).
• [C-1-9] PRECISA iterar o número da sequência da solicitação de sondagem normalmente (sequencialmente) entre as solicitações de sondagem em uma verificação.
• [C-1-10] PRECISA randomizar o número da sequência da solicitação de sondagem entre a última solicitação de uma verificação e a primeira solicitação de sondagem da próxima verificação.
• [C-SR-1] É FORTEMENTE RECOMENDADO para randomizar o endereço MAC de origem usado em toda a comunicação do STA com um ponto de acesso (AP) durante a associação e a associação.
  • O dispositivo PRECISA usar um endereço MAC aleatório diferente para cada SSID (FQDN para Passpoint) com que se comunica.
  • O dispositivo PRECISA oferecer ao usuário uma opção para controlar a aleatoriedade por SSID (FQDN para Passpoint) com opções não aleatórias e aleatórias, além de definir o modo padrão para que as novas configurações de Wi-Fi sejam aleatórias.
• [C-SR-2] É FORTEMENTE RECOMENDADO usar um BSSID aleatório para qualquer AP que criar.
  • O endereço MAC PRECISA ser aleatório e mantido de acordo com o SSID usado pelo AP.
  • O DISPOSITIVO PODE fornecer ao usuário a opção de desativar esse recurso. Se essa opção for fornecida, a ordem aleatória PRECISA estar ativada por padrão.

Se as implementações de dispositivos incluírem suporte ao modo de economia de energia Wi-Fi, conforme definido no padrão IEEE 802.11, elas:

• DEVE desativar o modo de economia de energia do Wi-Fi sempre que um app adquirir um bloqueio WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY usando as 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 ele está no modo de Bloqueio de baixa latência do Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) PRECISA ser menor que a latência durante um modo Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] É RECOMENDADO PARA minimizar a latência de ida e volta do Wi-Fi sempre que um bloqueio de baixa latência (WIFI_MODE_FULL_LOW_LATENCY) for adquirido e entrar em vigor.

Se as implementações de dispositivos oferecerem suporte a Wi-Fi e usarem esse recurso para a verificação de localização, elas:

• [C-2-1] PRECISA fornecer uma funcionalidade de usuário para ativar/desativar a leitura de valor pelo método de 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 forem compatíveis com Wi-Fi Direct, elas:

• [C-1-1] PRECISA implementar a API Android correspondente, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA informar o recurso de hardware android.hardware.wifi.direct.
• [C-1-3] PRECISA permitir o funcionamento normal do Wi-Fi.
• [C-1-4] PRECISA oferecer suporte a operações com Wi-Fi e Wi-Fi Direct simultaneamente.
• [C-SR-1] É FORTEMENTE RECOMENDADO para randomizar o endereço MAC de origem de todas as conexões Wi-Fi Direct recém-criadas.

7.4.2.2. Configuração de link direto encapsulado Wi-Fi

Implementações de dispositivos:

• DEVE incluir suporte à Configuração de link direto com túnel de Wi-Fi (TDLS, na sigla em inglês), conforme descrito na documentação do SDK do Android.

Se as implementações do dispositivo incluírem suporte a TDLS e TDLS for ativado pela API WiFiManager, elas:

• [C-1-1] PRECISA declarar suporte a TDLS por meio de WifiManager.isTdlsSupported.
• DEVE usar TDLS apenas quando for possível E benéfico.
• DEVE ter alguma heurística e NÃO usar TDLS quando o desempenho puder ser pior do que passar pelo ponto de acesso Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementações de dispositivos:

• DEVE incluir compatibilidade com o 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] PRECISA implementar as APIs WifiAwareManager, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA declarar a flag de recurso android.hardware.wifi.aware.
• [C-1-3] PRECISA oferecer suporte às operações Wi-Fi e Wi-Fi Aware simultaneamente.
• [C-1-4] PRECISA 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 alcance do Aware esteja em andamento ou um caminho de dados do Aware esteja ativo (a ordem aleatória não é esperada enquanto o caminho dos dados estiver ativo).

Se as implementações do dispositivo incluírem 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, elas:

• [C-2-1] PRECISA implementar as APIs de descoberta com reconhecimento de local: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint do Wi-Fi

Se as implementações de dispositivos forem compatíveis com 802.11 (Wi-Fi), elas:

• [C-1-1] PRECISA incluir suporte ao Passpoint de Wi-Fi.
• [C-1-2] PRECISA implementar as APIs WifiManager relacionadas ao Passpoint, conforme descrito na documentação do SDK.
• [C-1-3] PRECISA oferecer suporte ao padrão IEEE 802.11u, especificamente relacionado à descoberta e seleção de rede, como o Generic Publicidade Service (GAS) e o Access Network Query Protocol (ANQP).
• [C-1-4] PRECISA declarar a flag de recurso android.hardware.wifi.passpoint.
• [C-1-5] PRECISA seguir a implementação do AOSP para descobrir, associar e associar a redes Passpoint.
• [C-1-6] PRECISA oferecer suporte pelo menos ao seguinte subconjunto de protocolos de provisionamento de dispositivos, conforme definido no Passpoint R2 da Wi-Fi Alliance: autenticação EAP-TTLS e SOAP-XML.
• [C-1-7] PRECISA processar o certificado do servidor AAA, conforme descrito na especificação de ponto de acesso 2.0 R3.
• [C-1-8] PRECISA permitir o controle do usuário do provisionamento pelo seletor de Wi-Fi.
• [C-1-9] PRECISA manter as configurações do Passpoint persistentes nas reinicializações.
• [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte ao recurso de aceitação dos Termos e Condições.
• [C-SR-2] É RECOMENDADO para oferecer suporte ao recurso de informações de locais.

Se um controle de desativação do usuário global do Passpoint for fornecido, as implementações:

• [C-3-1] PRECISA 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 Localização de Wi-Fi.

Se as implementações do dispositivo incluírem suporte à localização por Wi-Fi e exporem a funcionalidade a apps de terceiros, elas:

• [C-1-1] PRECISA implementar as APIs WifiRttManager, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA declarar a flag de recurso android.hardware.wifi.rtt.
• [C-1-3] PRECISA randomizar o endereço MAC de origem para 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] PRECISA ter precisão de até 2 metros na largura de banda de 80 MHz no percentil 68 (conforme calculado com a função de distribuição cumulativa).
• [C-SR-1] É RECOMENDADO que ele informe com precisão a uma distância de até 1,5 metro a 80 MHz de largura de banda no 68o percentil (conforme calculado com a Função de distribuição cumulativa).

7.4.2.6. Descarregamento de sinal de atividade Wi-Fi

Implementações de dispositivos:

• DEVE incluir suporte para descarga de sinal de atividade Wi-Fi.

Se as implementações de dispositivos incluírem suporte à descarga de sinal de atividade de Wi-Fi e exporem a funcionalidade a apps de terceiros, elas:

• [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
• [C-1-2] PRECISA oferecer suporte a pelo menos três slots de sinal de atividade simultâneos por Wi-Fi.

Se as implementações de dispositivos não incluírem suporte para descarga de sinal de atividade 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 ao Wi-Fi Easy Connect (DPP).

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

• [C-1-1] PRECISA que o método WifiManager#isEasyConnectSupported() retorne true.

7.4.2.8. Validação do certificado do servidor Wi-Fi empresarial

Se o certificado do servidor Wi-Fi não for validado ou o nome de domínio do servidor Wi-Fi não estiver definido, as implementações do dispositivo:

• [C-SR-1] É RECOMENDADO que você não forneça ao usuário a opção de adicionar manualmente a rede Wi-Fi empresarial no app Configurações.

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 permitir que o usuário defina configurações WPA/WPA2/WPA3-Enterprise, elas:

• [C-4-1] PRECISA oferecer ao usuário a opção de usar o TOFU.

7.4.3. Bluetooth

Se as implementações de dispositivos oferecerem suporte ao perfil de áudio Bluetooth, elas:

• DEVE oferecer suporte a codecs de áudio avançados e codecs de áudio Bluetooth (por exemplo, LDAC) com A2DP.

Se as implementações de dispositivos forem compatíveis com HFP, A2DP e AVRCP, elas:

• DEVE oferecer suporte a pelo menos cinco dispositivos conectados no total.

Se as implementações de dispositivos declararem o recurso android.hardware.vr.high_performance, elas:

• [C-1-1] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.

Se as implementações de dispositivos incluírem suporte a Bluetooth e Bluetooth de baixa energia, elas:

• [C-2-1] PRECISA declarar os recursos relevantes da plataforma (android.hardware.bluetooth e android.hardware.bluetooth_le, respectivamente) e implementar as APIs da plataforma.
• DEVE implementar perfis Bluetooth relevantes, como A2DP, AVRCP, OBEX, HFP etc., conforme apropriado para o dispositivo.

Se as implementações de dispositivos incluírem suporte ao Bluetooth de baixa energia (BLE), elas:

• [C-3-1] PRECISA declarar o recurso de hardware android.hardware.bluetooth_le.
• [C-3-2] PRECISA ativar as APIs Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e em android.bluetooth.
• [C-3-3] PRECISA informar o valor correto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar se a lógica de filtragem das classes da API ScanFilter está implementada.
• [C-3-4] PRECISA informar o valor correto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar se o Low Energy Advertising é compatível.
• [C-3-5] PRECISA implementar um tempo limite de endereço particular solucionável (RPA, na sigla em inglês) de no máximo 15 minutos e alternar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo estiver usando BLE ativamente para verificação ou publicidade. Para evitar ataques de tempo limite, 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 leitura em lote para o chipset Bluetooth.
• DEVE ser compatível com vários anúncios com pelo menos quatro espaços.

Se as implementações de dispositivos oferecerem suporte ao Bluetooth LE e usarem essa tecnologia para buscar a localização, elas:

• [C-4-1] PRECISA fornecer uma funcionalidade de usuário para ativar/desativar o valor lido pela API do sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se as implementações de dispositivos incluírem suporte ao Bluetooth LE e ao perfil de aparelhos auditivos, conforme descrito em Suporte para áudio de aparelho auditivo usando Bluetooth LE, elas:

• [C-5-1] PRECISA retornar true para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Se as implementações de dispositivos incluírem suporte a Bluetooth ou Bluetooth de baixa energia (BLE), elas:

• [C-6-1] PRECISA restringir o acesso a todos os metadados Bluetooth (como resultados da verificação) que podem ser usados para derivar a localização do dispositivo, a menos que o app solicitante passe por 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 ao Bluetooth ou Bluetooth Low Energy e o manifesto do app não incluir uma declaração do desenvolvedor informando que eles não estão derivando a localização do Bluetooth, elas:

• [C-6-2] PRECISA bloquear o acesso ao Bluetooth atrás do android.permission.ACCESS_FINE_LOCATION.

Se as implementações de dispositivos retornarem true para a API BluetoothAdapter.isLeAudioSupported(), elas:

• [C-7-1] PRECISA oferecer suporte ao cliente unicast.
• [C-7-2] PRECISA oferecer suporte a 2 milhões de PHY.
• [C-7-3] PRECISA oferecer suporte à publicidade estendida de LE.
• [C-7-4] PRECISA oferecer suporte a pelo menos duas conexões CIS em um CIG.
• [C-7-5] É NECESSÁRIO ativar o cliente BAP unicast, o coordenador de conjunto CSIP, o servidor MCP, o controlador VCP e o servidor CCP simultaneamente.
• [C-SR-1] É FORTEMENTE RECOMENDADO para ativar o cliente unicast HAP.

Se as implementações de dispositivos retornarem true para a API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), elas:

• [C-8-1] PRECISA oferecer suporte a pelo menos dois links BIS em uma GRANDE.
• [C-8-2] PRECISA ativar a fonte de transmissão BAP e o assistente de transmissão BAP simultaneamente.
• [C-8-3] PRECISA oferecer suporte à publicidade LE Periodic.

Se as implementações de dispositivos retornarem true para a API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), elas:

• [C-9-1] PRECISA oferecer suporte a PAST (Transferência periódica de sincronização de publicidade).
• [C-9-2] PRECISA oferecer suporte à publicidade LE Periodic.

Se as implementações de dispositivo declararem FEATURE_BLUETOOTH_LE, elas:

• [C-10-1] PRECISA ter medições de RSSI dentro de +/-9 dB para 95% das medições a 1 m de distância de um dispositivo de referência que transmite a ADVERTISE_TX_POWER_HIGH no ambiente de linha de visão.
• [C-10-2] PRECISA incluir correções de Rx/Tx para reduzir os desvios por canal, para que as medições em cada um dos três canais, em cada uma das antenas (se forem usadas várias) fiquem dentro de +/-3 dB umas das outras em 95% das medições.
• [C-SR-2] É MUITO RECOMENDADO para medir e compensar o deslocamento Rx para garantir que o RSSI médio do BLE seja de -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 forma que estejam em "planos paralelos" com telas voltadas para a mesma direção.
• [C-SR-3] É MUITO RECOMENDADO para medir e compensar o deslocamento Tx para garantir que o RSSI médio do BLE seja -60 dBm +/-10 dB ao ler a partir 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 tal forma que estejam em "planos paralelos" com telas voltadas para a mesma direção.

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

Se as implementações de dispositivos forem compatíveis com o Bluetooth versão 5.0, elas:

• [C-SR-4] É FORTEMENTE RECOMENDADO oferecer suporte para:
  • LE 2M PHY
  • Codec LE PHY
  • Extensão de publicidade LE
  • Publicidade periódica
  • Pelo menos 10 conjuntos de anúncios
  • Pelo menos oito conexões simultâneas do LE. Cada conexão pode estar em qualquer um dos papéis de topologia de conexão.
  • Privacidade da camada de links do LE
  • Um tamanho de "lista de resoluções" de pelo menos oito entradas

7.4.4. Comunicação a curta distância (NFC, na sigla em inglês)

Implementações de dispositivos:

• DEVE incluir um transceptor e hardware relacionado para comunicação a curta distância (NFC, na sigla em inglês).
• [C-0-1] PRECISA implementar as APIs android.nfc.NdefMessage e android.nfc.NdefRecord, mesmo que não incluam suporte a NFC ou declare o recurso android.hardware.nfc, já que as classes representam um formato de representação de dados independente de protocolo.

Se as implementações de dispositivos incluírem hardware NFC e planejam disponibilizá-lo para apps de terceiros, elas:

• [C-1-1] PRECISA informar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature().
• PRECISA ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões NFC, conforme mostrado abaixo:
• [C-1-2] PRECISA atuar como leitor/gravador do Fórum NFC (conforme definido pela especificação técnica do NFC Forum) NFCForum-TS-DigitalProtocolo-1.0 usando os seguintes padrões NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6.319-4)
  • IsoDep (ISO 14443-4)
  • Tipos de tag do fórum NFC 1, 2, 3, 4, 5 (definidos pelo fórum NFC)

• [C-SR-1] É FORTEMENTE RECOMENDADO que seja capaz de ler e gravar mensagens NDEF, além de dados brutos, por meio dos seguintes padrões NFC. Observe que, embora os padrões NFC sejam indicados como FORTEMENTE RECOMENDADOS, a definição de compatibilidade para uma versão futura pretende mudá-los para PRECISA. Esses padrões são opcionais nesta versão, mas serão necessários em versões futuras. É altamente recomendável que dispositivos atuais e novos que executam essa versão do Android atendam a esses requisitos agora para que possam fazer upgrade para as próximas versões da plataforma.

• [C-1-13] PRECISA pesquisar todas as tecnologias com suporte no modo de descoberta NFC.

• DEVE estar no modo de descoberta NFC enquanto o dispositivo estiver ativado 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) de produtos Thinfilm NFC Barcode.

Os links disponíveis publicamente não estão disponíveis para as especificações JIS, ISO e NFC do Fórum citadas acima.

O Android inclui suporte ao modo de emulação de cartão host de NFC (HCE, na sigla em inglês).

Se as implementações de dispositivos 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] PRECISA informar a constante de recurso android.hardware.nfc.hce.
• [C-2-2] PRECISA oferecer suporte às APIs NFC HCE, conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem um chipset de controlador NFC capaz de HCE para NfcF e implementarem o recurso para aplicativos de terceiros, elas:

• [C-3-1] PRECISA informar a constante de recurso android.hardware.nfc.hcef.
• [C-3-2] PRECISA implementar as APIs de emulação de cartão NfcF, conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem suporte geral a NFC, conforme descrito nesta seção, e aceitarem tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) na função de leitor/gravador:

• [C-4-1] PRECISA implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
• [C-4-2] É NECESSÁRIO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). Esse não é um recurso padrão do Android e, portanto, não aparece como uma constante na classe android.content.pm.PackageManager.

7.4.5. APIs e protocolos de rede

7.4.5.1. Capacidade mínima de rede

Implementações de dispositivos:

• [C-0-1] PRECISA incluir suporte para uma ou mais formas de rede de dados. Especificamente, as implementações de dispositivos PRECISAM incluir suporte 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 PAN do Bluetooth.
• Também DEVE incluir suporte para 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) for 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] PRECISA incluir uma pilha de rede IPv6 e oferecer suporte à comunicação IPv6 usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, além das APIs nativas, como soquetes AF_INET6.
• [C-0-3] PRECISA ativar o IPv6 por padrão.
  • PRECISA garantir que a comunicação do IPv6 seja tão confiável quanto com o IPv4, por exemplo:
    • [C-0-4] PRECISA manter a conectividade IPv6 no modo Soneca.
    • [C-0-5] A limitação de taxa NÃO PODE fazer o dispositivo perder a conectividade IPv6 em qualquer rede compatível com IPv6 que use ciclos de vida de RA de pelo menos 180 segundos.
• [C-0-6] PRECISA fornecer aplicativos de terceiros com conectividade IPv6 direta à rede quando conectados a uma rede IPv6, sem que nenhuma forma de conversão de endereço ou porta 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 estão visíveis como o IP e a porta de origem para os servidores da Internet (Web).

O nível obrigatório de suporte a IPv6 depende do tipo de rede, conforme mostrado nos requisitos a seguir.

Se as implementações de dispositivos forem compatíveis com Wi-Fi, elas:

• [C-1-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.

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

• [C-2-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 na Ethernet.

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

• [C-3-1] PRECISA oferecer suporte à operação de IPv6 (somente IPv6 e possivelmente de pilha dupla) na rede celular.

Se as implementações de dispositivos oferecem suporte a mais de um tipo de rede (por exemplo, Wi-Fi e dados móveis), eles:

• [C-4-1] PRECISA 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 cativos

Um portal cativo se refere a uma rede que exige login para ter acesso à Internet.

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

• [C-1-1] PRECISA fornecer um aplicativo de portal cativo para processar a intent ACTION_CAPTIVE_PORTAL_SIGN_IN e mostrar a página de login do portal cativo enviando essa intent para a API System ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] PRECISA realizar a detecção de portais cativos e permitir login pelo aplicativo quando o dispositivo estiver conectado a qualquer tipo de rede, incluindo rede celular/móvel, Wi-Fi, Ethernet ou Bluetooth.
• [C-1-3] PRECISA oferecer suporte ao login em portais cativos usando DNS de texto não criptografado quando o dispositivo estiver configurado para usar o modo estrito de DNS particular.
• [C-1-4] PRECISA 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 estiver se comunicando explicitamente com o portal cativo.
• [C-1-5] PRECISA garantir que, enquanto o usuário fizer login em um portal cativo, a rede padrão usada pelos aplicativos (como retornada por ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback e usada por padrão por APIs de rede Java, como java.net.Socket, e APIs nativas, como connect()), seja qualquer outra rede disponível que forneça acesso à Internet, se disponível.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

• [C-0-1] PRECISA ter a configuração de sincronização automática principal ativada por padrão para que o método getMasterSyncAutomatically() retorne "true".

7.4.7. Economia de dados

Se as implementações de dispositivos incluírem uma conexão limitada, elas serão:

• [C-SR-1] É MUITO RECOMENDADO fornecer o modo de economia de dados.

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

• [C-1-1] PRECISA oferecer suporte a todas as APIs na classe ConnectivityManager, conforme descrito na documentação do SDK.

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

• [C-2-1] PRECISA retornar o valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().
• [C-2-2] NÃO PODE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Elementos de segurança

Se as implementações de dispositivos oferecerem suporte a elementos de segurança compatíveis com a Open Mobile API e os disponibilizarem para apps de terceiros, elas:

• [C-1-1] PRECISA enumerar os leitores de elementos de segurança disponíveis pela API android.se.omapi.SEService.getReaders().

• [C-1-2] PRECISA declarar as flags de recurso corretas usando android.hardware.se.omapi.uicc para o dispositivo com elementos de segurança baseados em UICC, android.hardware.se.omapi.ese para o dispositivo com elementos de segurança baseados em eSE e android.hardware.se.omapi.sd para o dispositivo com elementos de segurança baseados em SD.

7.4.9. UWB

Se as implementações de dispositivos incluírem suporte a 802.1.15.4 e expõem a funcionalidade a um aplicativo de terceiros, elas:

• [C-1-1] PRECISA implementar a API do Android correspondente no android.uwb.
• [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.uwb.
• [C-1-3] PRECISA oferecer suporte a todos os perfis UWB relevantes definidos na implementação do Android.
• [C-1-4] PRECISA fornecer uma funcionalidade de usuário para permitir que ele ative/desative o estado de rádio UWB.
• [C-1-5] PRECISA determinar que os apps que usam o recurso UWB mantenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICE).

• [C-SR-1] É FORTEMENTE RECOMENDADO a passar nos testes de conformidade e certificação relevantes definidos por organizações padrão, incluindo FIRA, CCC e CSA.

  • [C-1-6] PRECISA garantir que as medidas de distância estejam dentro de +/-15 cm para 95% das medições no ambiente de linha de visão a 1 m de distância em uma câmara não reflexiva.
  • [C-1-7] PRECISA garantir que a média das medidas de distância a 1 m do dispositivo de referência esteja dentro de [0,75 m, 1,25 m], em que a distância das informações empíricas é medida a partir da borda superior do DUT voltado para cima e inclinado em 45 graus.
  • [C-SR-2] É RECOMENDADO que você siga as etapas de configuração de medição especificadas em Calibragem de presença.

7,5. Câmeras

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

• [C-1-1] PRECISA declarar a flag de recurso android.hardware.camera.any.
• [C-1-2] PRECISA ser possível para que um aplicativo aloque simultaneamente três bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo sensor da câmera de maior resolução no dispositivo, enquanto a câmera estiver aberta para fins de visualização básica e captura.
• [C-1-3] PRECISA garantir que o aplicativo de câmera padrão pré-instalado processe as intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE para remover a localização do usuário nos metadados da imagem antes de enviá-la ao aplicativo receptor quando ele não tiver ACCESS_FINE_LOCATION.

Se as implementações de dispositivos forem compatíveis com a capacidade de saída HDR de 10 bits, elas:

• [C-2-1] PRECISA oferecer suporte pelo menos ao perfil HLG HDR em todos os dispositivos de câmera com suporte à saída de 10 bits.
• [C-2-2] PRECISA oferecer suporte à saída de 10 bits para a câmera principal traseira ou frontal.
• [C-SR-1] É RECOMENDADO para 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 compatíveis com BACKWARD_COMPATIBLE de uma câmera lógica e para a própria câmera lógica.

Para dispositivos de câmera lógica com suporte a HDR de 10 bits e 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 compatíveis com versões anteriores usando o controle CONTROL_ZOOM_RATIO na câmera lógica.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera localizada na lateral do dispositivo oposta à tela. Ou seja, ela captura cenas no outro lado do dispositivo, como uma câmera tradicional.

Implementações de dispositivos:

• DEVE incluir uma câmera traseira.

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

• [C-1-1] PRECISA informar a flag de recurso android.hardware.camera e android.hardware.camera.any.
• [C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
• DEVE ter foco automático de hardware ou de software implementado no driver da câmera (transparente ao software do aplicativo).
• PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
• PODE incluir um flash.

Se a câmera tiver flash:

• [C-2-1] A lâmpada NÃO PODE ser acesa enquanto uma instância android.hardware.Camera.PreviewCallback tiver sido registrada em uma superfície de visualização da Câmera, a menos que o app 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 integrado de câmera do sistema do dispositivo, mas apenas a aplicativos de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela. Ou seja, uma câmera normalmente usada para imagens do usuário, por exemplo, para videoconferências e aplicativos semelhantes.

Implementações de dispositivos:

• PODE incluir uma câmera frontal.

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

• [C-1-1] PRECISA informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
• [C-1-3] NÃO PODE usar uma câmera frontal como padrão para a API Camera nem configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera no dispositivo.
• [C-1-4] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo quando o aplicativo atual tiver solicitado explicitamente que a tela da câmera seja girada por meio de uma chamada para o método android.hardware.Camera.setDisplayOrientation(). Por outro lado, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo quando o aplicativo atual não solicita explicitamente que a tela da câmera seja girada com uma chamada para o método android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NÃO É POSSÍVEL espelhar os streams de vídeo ou de imagem estática finais retornados para callbacks do aplicativo nem confirmados para o armazenamento de mídia.
• [C-1-6] PRECISA espelhar a imagem mostrada pela pós-visualização da mesma maneira que o stream 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 do dispositivo puderem ser giradas pelo usuário (por exemplo, automaticamente com um acelerômetro ou manualmente por 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 nem sempre está conectada.

Se as implementações de dispositivos forem compatíveis com uma câmera externa, elas:

• [C-1-1] PRECISA declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
• [C-1-2] PRECISA oferecer suporte à classe de vídeo USB (UVC 1.0 ou mais recente) se a câmera externa se conectar pela porta do host USB.
• [C-1-3] PRECISA passar nos testes de CTS da câmera com um dispositivo físico de câmera externa conectado. Detalhes dos testes CTS da câmera estão disponíveis em source.android.com.
• DEVE oferecer suporte a compactação de vídeo, como MJPEG, para permitir a transferência de streamings de imagens não codificados de alta qualidade (ou seja, streams de imagens brutos ou compactados de forma independente).
• PODE oferecer suporte a várias câmeras.
• PODE oferecer suporte à codificação de vídeo baseada em câmera.

Se a codificação de vídeo baseada na câmera for compatível:

• [C-2-1] Um stream MJPEG simultâneo não codificado (QVGA ou resolução maior) PRECISA estar acessível à implementação do dispositivo.

7.5.4. Comportamento da API Camera

O Android inclui dois pacotes de API para acessar a câmera, a API android.hardware.camera2 mais recente, que expõe controles de câmera de nível inferior ao app, incluindo fluxos de burst/streaming de cópia zero e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, remoção de ruído, nitidez e muito mais.

O pacote de API mais antigo, android.hardware.Camera, está marcado como descontinuado no Android 5.0, mas ainda deve estar disponível para uso dos apps. As implementações em dispositivos Android PRECISAM garantir o suporte contínuo à API, conforme descrito nesta seção e no SDK do Android.

Todos os recursos comuns entre a classe android.hardware.Camera descontinuada e o pacote android.hardware.camera2 mais recente PRECISAM ter desempenho e qualidade equivalentes nas duas APIs. Por exemplo, com configurações equivalentes, a velocidade e a precisão do foco automático precisam ser idênticas, e a qualidade das imagens capturadas precisa ser a mesma. Os recursos que dependem de semânticas diferentes das duas APIs não precisam ter velocidade ou qualidade correspondentes, mas DEVEM ser o mais próximo possível.

As implementações de dispositivos PRECISAM implementar os seguintes comportamentos para as APIs relacionadas à câmera em todas as câmeras disponíveis. Implementações de dispositivos:

• [C-0-1] É NECESSÁRIO usar android.hardware.PixelFormat.YCbCr_420_SP para dados de visualização fornecidos aos callbacks de aplicativos quando um aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] PRECISA estar ainda 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, 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âmeras nas câmeras frontal e traseira para android.hardware.Camera. O codificador de vídeo em hardware e a câmera podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA ser compatível com a conversão para YV12.
• [C-0-4] PRECISA oferecer suporte aos formatos android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG como saídas usando a 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] ainda PRECISA implementar a API Camera completa incluída na documentação do SDK do Android, independente de o dispositivo incluir foco automático de hardware ou outros recursos. Por exemplo, câmeras que não têm foco automático 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. Observe que isso se aplica a câmeras fronteiras. Por exemplo, mesmo que a maioria das câmeras frontal não ofereça suporte ao foco automático, os callbacks de API ainda precisam ser "falsos", conforme descrito.
• [C-0-6] PRECISA reconhecer e respeitar cada nome de parâmetro definido como uma constante nas classes android.hardware.Camera.Parameters e android.hardware.camera2.CaptureRequest. Por outro lado, as implementações de dispositivos NÃO PODEM respeitar ou reconhecer constantes de string transmitidas ao método android.hardware.Camera.setParameters() que não sejam aquelas documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos PRECISAM oferecer suporte a todos os parâmetros padrão de câmera, se o hardware permitir, e NÃO PODEM oferecer suporte a tipos personalizados de parâmetros de Câmera. Por exemplo, as implementações de dispositivos com suporte à captura de imagem usando técnicas de geração de imagem em High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera Camera.SCENE_MODE_HDR.
• [C-0-7] PRECISA informar o nível adequado de suporte com a propriedade android.info.supportedHardwareLevel, conforme descrito no SDK do Android, e informar as sinalizações de recurso do framework adequadas.
• [C-0-8] Também PRECISA declarar os recursos individuais da câmera de android.hardware.camera2 pela propriedade android.request.availableCapabilities e declarar as flags de recurso adequadas. É NECESSÁRIO definir a flag de recurso se algum dos dispositivos de câmera conectados oferecer suporte a ele.
• [C-0-9] PRECISA transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada da imagem for adicionada ao armazenamento de mídia.
• [C-0-10] PRECISA 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 ao armazenamento de mídia.
• [C-0-11] PRECISA ter todas as câmeras acessíveis pela API android.hardware.Camera descontinuada, também acessível pela API android.hardware.camera2.
• [C-0-12] PRECISA garantir que a aparência facial NÃO seja alterada, incluindo, mas não se limitando a alterações na geometria, tom ou suavização da pele facial em 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, são RECOMENDADOS ALTAMENTE para oferecer suporte a um dispositivo de câmera lógico que liste a capacidade CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, que consiste em 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 para apps de terceiros, elas:

• [C-1-1] PRECISA 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, tais câmeras:

• [C-1-1] PRECISA estar orientada para que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é mantido na orientação paisagem, as câmeras PRECISAM capturar imagens na orientação paisagem. Isso se aplica a qualquer orientação natural do dispositivo, ou seja, aos dispositivos principais no modo paisagem e modo retrato.

Os dispositivos que atenderem a todos os critérios a seguir estão isentos do requisito acima:

• O dispositivo implementa telas de geometria variável, como telas dobráveis ou articuladas.
• Quando o estado da dobra ou articulação do dispositivo muda, ele alterna entre a orientação retrato principal para paisagem principal (ou vice-versa).

7,6. Memória e armazenamento

7.6.1. Mínimo de memória e armazenamento

Implementações de dispositivos:

• [C-0-1] PRECISA incluir um Gerenciador de downloads que os aplicativos POSSAM usar para fazer o download de arquivos de dados e PRECISAM ser capazes de fazer o download de arquivos individuais com 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] PRECISA oferecer armazenamento para ser compartilhado por aplicativos, também geralmente conhecido como "armazenamento externo compartilhado", "armazenamento compartilhado do aplicativo" ou pelo caminho do Linux "/sdcard" no qual ele é montado.
• [C-0-2] PRECISA ser configurado com o armazenamento compartilhado montado por padrão, ou seja, "fora da caixa", independentemente de o armazenamento ser implementado em um componente de armazenamento interno ou em uma mídia de armazenamento removível (por exemplo, slot de cartão Secure Digital).
• [C-0-3] PRECISA 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] PRECISA ativar o armazenamento com escopo por padrão para todos os apps destinados ao nível 29 da API ou mais recente, exceto na seguinte situação:
  • Quando o app solicita android:requestLegacyExternalStorage="true" no manifesto.
• [C-0-5] É NECESSÁRIO editar os metadados de local, como tags GPS Exif, armazenados em arquivos de mídia quando esses arquivos são acessados pelo MediaStore, exceto quando o app de chamada tem a permissão ACCESS_MEDIA_LOCATION.

As implementações de dispositivos podem atender aos requisitos acima usando uma das seguintes opções:

• Armazenamento removível acessível pelo usuário, como um slot para cartão SD.
• Uma parte do armazenamento interno (não removível), conforme implementado no Android Open Source Project (AOSP).

Se as implementações de dispositivos usarem o armazenamento removível para atender aos requisitos acima, elas:

• [C-1-1] PRECISA implementar uma interface do usuário de aviso ou pop-up alertando o usuário quando não há mídia de armazenamento inserida no slot.
• [C-1-2] PRECISA incluir uma mídia de armazenamento com formato FAT (por exemplo, cartão SD) ou mostrar na caixa e em outros materiais disponíveis no momento da compra. Essa mídia precisa ser comprada separadamente.

Se as implementações de dispositivos 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 interno do app.
• 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 de periférico USB, elas:

• [C-3-1] PRECISA fornecer um mecanismo para acessar os dados no armazenamento compartilhado do aplicativo em um computador host.
• DEVE expor o conteúdo dos dois caminhos de armazenamento de forma transparente usando o serviço de verificação de mídia do Android e o android.provider.MediaStore.
• PODE usar armazenamento USB em massa, mas DEVE usar o Media Transfer Protocol para atender a esse requisito.

Se as implementações de dispositivos tiverem uma porta USB com modo de periférico USB e aceitarem o protocolo de transferência de mídia, elas:

• DEVE ser compatível com o host de referência do Android MTP, a 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 se espera que o dispositivo seja de natureza móvel, diferentemente da televisão, as implementações de dispositivo são:

• [C-SR-1] É MUITO RECOMENDADO implementar o armazenamento adotável em um local estável de longo prazo, já que desconectá-los acidentalmente 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 dentro do compartimento da bateria ou de outra tampa protetora, as implementações do dispositivo serão:

• [C-SR-2] É MUITO RECOMENDADO implementar o armazenamento adotável.

7,7. USB

Se as implementações de dispositivos tiverem uma porta USB, elas:

• DEVE oferecer suporte ao modo de periférico USB e DEVE oferecer suporte ao modo host USB.
• DEVE ser compatível com a desativação da sinalização de dados por USB.

7.7.1. Modo USB periférico

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo de periféricos:

• [C-1-1] A porta PRECISA estar conectada a um host USB que tenha uma porta USB padrão tipo A ou tipo C.
• [C-1-2] PRECISA informar o valor correto de iSerialNumber no descritor de dispositivo USB padrão por android.os.Build.SERIAL.
• [C-1-3] PRECISA detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão de resistor Type-C e PRECISA detectar mudanças no anúncio se eles oferecerem suporte a USB Type-C.
• [C-SR-1] A porta DEVE usar o formato USB micro-B, micro-AB ou tipo C. Dispositivos Android novos e atuais são altamente RECOMENDADOS a atender a esses requisitos para que possam fazer upgrade para as próximas versões da plataforma.
• [C-SR-2] A porta DEVE estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação da tela do software para todos os apps (incluindo a tela inicial), para que a tela seja mostrada corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É altamente RECOMENDADO que dispositivos Android novos e atuais atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
• [C-SR-3] DEVE implementar suporte para acionar corrente de 1,5 A durante o sinal de luz HS e o tráfego, conforme especificado na Especificação de carregamento de bateria USB, revisão 1.2. Dispositivos Android novos e atuais são altamente RECOMENDADOS a atender a esses requisitos para que possam fazer upgrade para as próximas versões da plataforma.
• [C-SR-4] É MUITO RECOMENDADO não oferecer suporte a métodos de carregamento próprios que modifiquem a tensão do Vbus além dos níveis padrão ou que alterem as funções do coletor/fonte. 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 indicado como "Fortemente RECOMENDADO", em versões futuras do Android, poderemos EXIGIR que todos os dispositivos type-C ofereçam suporte à interoperabilidade total com carregadores padrão tipo C.
• [C-SR-5] É MUITO RECOMENDADO oferecer suporte ao Power Delivery para troca de papéis de energia e dados quando houver suporte para o modo host USB e USB Type-C.
• DEVE oferecer suporte ao Power Delivery para carregamento de alta tensão e suporte a modos alternativos, como a saída de tela.
• DEVE implementar a API e a especificação do Android Open Accessory (AOA), conforme documentado na documentação do SDK do Android.

Se as implementações de dispositivos incluírem uma porta USB e implementarem a especificação de AOA, elas:

• [C-2-1] PRECISA declarar suporte ao recurso de hardware android.hardware.usb.accessory.
• [C-2-2] A classe de armazenamento em massa USB PRECISA incluir a string "android" no final da string iInterface de descrição da interface do armazenamento USB em massa.

7.7.2. Modo host USB

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

• [C-1-1] PRECISA implementar a API de host USB do Android, conforme documentado no SDK do Android, e PRECISA declarar suporte ao recurso de hardware android.hardware.usb.host.
• [C-1-2] PRECISA implementar o suporte para conectar periféricos USB padrão. Em outras palavras, é NECESSÁRIO:
  • Ter uma porta tipo C no dispositivo ou enviar com cabos adaptando uma porta própria no dispositivo a uma porta USB-C padrão (dispositivo USB-C).
  • Ter um tipo A no dispositivo ou enviar com cabos adaptando uma porta própria 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 padrão tipo A.
• [C-1-3] NÃO PODE enviar com um adaptador que converta de portas USB tipo A ou micro-AB para uma porta tipo C (receptáculo).
• [C-SR-1] É RECOMENDADO A implementação da 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 fonte de corrente de pelo menos 1,5 A, conforme especificado na seção "Parâmetros de terminação" da Revisão 1.2 da especificação do cabo e do conector USB-C para conectores USB-C, ou ao uso do intervalo de saída da porta de carregamento downstream(CDP, na sigla em inglês), conforme especificado nas Especificações de carregamento da bateria USB-2.
• DEVE implementar e oferecer suporte aos padrões USB-C.

Se as implementações de dispositivos incluírem uma porta USB com suporte ao modo host e a classe de áudio USB, elas:

• [C-2-1] PRECISA oferecer suporte à classe HID USB.
• [C-2-2] PRECISA oferecer suporte à detecção e ao mapeamento dos seguintes campos de dados HID especificados nas Tabelas de uso de HID USB e na Solicitação de uso do comando de voz para as constantes KeyEvent, conforme mostrado abaixo:
  • ID de uso da página de uso (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • ID de uso da página de uso (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • ID de uso da página de uso (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • ID de uso da página de uso (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Se as implementações de dispositivos 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] PRECISA reconhecer qualquer dispositivo MTP (protocolo de transferência de mídia) conectado remotamente e tornar o conteúdo acessível pelas intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se as implementações de dispositivos incluírem uma porta USB com suporte ao modo host e USB Type-C, elas:

• [C-4-1] PRECISA implementar a funcionalidade Dual Role Port (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 coletor USB (modo host) PODE estar desativada por padrão, mas PRECISA ser possível para o usuário ativá-la.
• [C-SR-2] É MUITO RECOMENDADO para oferecer suporte ao DisplayPort, oferecer suporte a taxas de dados USB SuperSpeed e ser FORTEMENTE RECOMENDADO para oferecer suporte ao Power Delivery para troca de funções de energia e dados.
• [C-SR-3] É RECOMENDADO NÃO oferecer suporte ao modo de acessório do adaptador de áudio, conforme descrito no Apêndice A da Revisão 1.2 da especificação do cabo e do conector USB-C.
• DEVE 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 de dispositivos incluírem um microfone, elas:

• [C-1-1] PRECISA informar a constante de recurso android.hardware.microphone.
• [C-1-2] PRECISA atender aos requisitos de gravação de áudio da seção 5.4.
• [C-1-3] PRECISA atender aos requisitos de latência de áudio na seção 5.6.
• [C-SR-1] É FORTEMENTE RECOMENDADO para oferecer suporte à gravação quase ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos omitirem um microfone, elas:

• [C-2-1] NÃO PODE informar a constante de recurso android.hardware.microphone.
• [C-2-2] PRECISA implementar a API de gravação de áudio pelo menos como ambiente autônomo, 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 condutores de 3,5 mm ou uma porta de modo host USB usando a classe de áudio USB, elas:

• [C-1-1] PRECISA informar a constante de recurso android.hardware.audio.output.
• [C-1-2] PRECISA atender aos requisitos de reprodução de áudio da seção 5.5.
• [C-1-3] PRECISA atender aos requisitos de latência de áudio na seção 5.6.
• [C-SR-1] É MUITO RECOMENDADO para oferecer suporte à reprodução quase ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos não incluírem uma porta de saída de áudio ou alto-falante, elas:

• [C-2-1] NÃO É POSSÍVEL informar o recurso android.hardware.audio.output.
• [C-2-2] PRECISA implementar as APIs relacionadas à saída de áudio como um ambiente autônomo.

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 em protocolos baseados em rádio, como Bluetooth, Wi-Fi ou rede celular, não se qualifica como uma "porta de saída".

7.8.2.1. Portas de áudio analógico

Para serem compatíveis com fones de ouvido e outros acessórios de áudio que usam o plugue de áudio de 3,5 mm em todo o ecossistema Android, se as implementações do dispositivo incluírem uma ou mais portas de áudio analógico, elas:

• [C-SR-1] É RECOMENDADO que você inclua pelo menos uma das portas de áudio para ser um conector de 3,5 mm com 4 condutores.

Se as implementações do dispositivo tiverem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

• [C-1-1] PRECISA oferecer suporte à reprodução de áudio para fones de ouvido estéreo ou fones de ouvido estéreo com um microfone.
• [C-1-2] PRECISA oferecer suporte a plugues de áudio TRRS com a ordem de pinagem CTIA.
• [C-1-3] PRECISA oferecer suporte à detecção e ao mapeamento dos códigos de tecla para as três faixas de impedância equivalentes entre o microfone e os condutores de terra no plugue de áudio:
  • 70 ohm ou menos: KEYCODE_HEADSETHOOK
  • 210–290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] PRECISA acionar o ACTION_HEADSET_PLUG na inserção do plugue, mas somente depois que todos os contatos no plugue estiverem tocando nos segmentos relevantes na entrada.
• [C-1-5] PRECISA ser capaz de operar com pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohm.
• [C-1-6] PRECISA ter uma tensão de polarização de microfone entre 1,8 V e 2,9 V.
• [C-1-7] PRECISA detectar e mapear para o código de tecla da seguinte faixa de impedância equivalente entre o microfone e os condutores de aterramento no plugue de áudio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR-2] É FORTEMENTE RECOMENDADO a compatibilidade com plugues de áudio na ordem de pin-out de OMTP.
• [C-SR-3] É RECOMENDADO para oferecer suporte à gravação de áudio de fones de ouvido estéreo com um microfone.

Se as implementações do dispositivo tiverem uma entrada de áudio de 3, 5 mm com quatro condutores e oferecer suporte a um microfone e transmitirem android.intent.action.HEADSET_PLUG com o microfone de valor extra definido como 1, elas:

• [C-2-1] PRECISA oferecer suporte à detecção de microfone no acessório de áudio conectado.

7.8.2.2. Portas digitais de áudio

Consulte a Seção 2.2.1 para ver os requisitos específicos dos dispositivos.

7.8.3. Quase ultrassom

O áudio quase ultrassom é a banda de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

• PRECISA informar corretamente o suporte ao recurso de áudio quase ultrassom pela API AudioManager.getProperty, da seguinte maneira:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND for "true", os requisitos a seguir PRECISAM ser atendidos pelas fontes de áudio VOICE_RECOGNITION e UNPROCESSED:

• [C-1-1] A resposta de energia média do microfone na faixa de 18,5 kHz a 20 kHz PRECISA estar no máximo 15 dB abaixo da resposta a 2 kHz.
• [C-1-2] A proporção não ponderada do microfone para ruído acima de 18,5 kHz a 20 kHz para um tom de 19 kHz a -26 dBFS PRECISA ser inferior a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND for "true":

• [C-2-1] A resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser inferior a 40 dB abaixo da resposta a 2 kHz.

7.8.4. Integridade do sinal

Implementações de dispositivos:

• DEVE fornecer um caminho de sinal de áudio sem falhas para streams de entrada e saída em dispositivos portáteis, conforme definido por zero falhas medidas durante um teste de um minuto por caminho. Use o "Teste de Glitch automatizado" do OboeTester (em inglês).

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 DEVEM ser testadas.

Atualmente, o OboeTester oferece suporte a caminhos da AAudio. Portanto, as combinações abaixo DEVEM ser testadas em busca de falhas usando a AAudio:

Modo de desempenho	Compartilhamento	Taxa de amostragem de saída	Em Poss	Out Poss
BAIXO_LATÊNCIA	EXCLUSIVO	NÃO ESPECIFICADO	1	2
BAIXO_LATÊNCIA	EXCLUSIVO	NÃO ESPECIFICADO	2	1
BAIXO_LATÊNCIA	COMPARTILHADO	NÃO ESPECIFICADO	1	2
BAIXO_LATÊNCIA	COMPARTILHADO	NÃO ESPECIFICADO	2	1
NUNCA	COMPARTILHADO	48000	1	2
NUNCA	COMPARTILHADO	48000	2	1
NUNCA	COMPARTILHADO	44100	1	2
NUNCA	COMPARTILHADO	44100	2	1
NUNCA	COMPARTILHADO	16000	1	2
NUNCA	COMPARTILHADO	16000	2	1

Um stream confiável DEVE atender aos seguintes critérios de relação sinal-ruído (SNR, na sigla em inglês) e distorção harmônica total (THD, na sigla em inglês) para seno para 2.000 Hz.

Transdutor	THD	SNR
Alto-falante integrado principal, medido com um microfone de referência externo	Menor que 3%	>= 50 dB
microfone integrado principal, medido com um alto-falante de referência externo	Menor que 3%	>= 50 dB
Entradas de 3,5 mm analógicas integradas, testadas com o adaptador de loopback	Menos de 1%	>= 60 dB
Adaptadores USB fornecidos com o telefone, testados com o adaptador de loopback	Menor que 1%	>= 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 esses comportamentos corretamente, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android inclui suporte ao Modo RV, um recurso que processa a renderização estereoscópica de notificações e desativa componentes da interface do sistema monocular enquanto um app de RV tem o foco do usuário.

7.9.2. Modo de realidade virtual: alto desempenho

Se as implementações de dispositivos oferecerem suporte ao modo RV, elas:

• [C-1-1] PRECISA ter pelo menos dois núcleos físicos.
• [C-1-2] PRECISA declarar o recurso android.hardware.vr.high_performance.
• [C-1-3] PRECISA oferecer suporte ao modo de desempenho sustentado.
• [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.2.
• [C-1-5] PRECISA oferecer suporte a android.hardware.vulkan.level 0.
• DEVE oferecer suporte a android.hardware.vulkan.level 1 ou mais recente.
• [C-1-6] PRECISA 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 e {GL22/} e expor as extensões E na lista de extensões disponíveis.EGL_EXT_image_gl_colorspace
• [C-1-8] PRECISA implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures e expor as extensões na lista de extensões GL disponíveis.
• [C-SR-1] É MUITO RECOMENDADO para 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] É FORTEMENTE RECOMENDADO para oferecer suporte ao Vulkan 1.1.
• [C-SR-3] É MUITO RECOMENDADO para implementar VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image e expor essas extensões na lista de extensões do Vulkan disponíveis.
• [C-SR-4] são RECOMENDADOS para 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 é pelo menos 2.
• [C-1-7] A GPU e a tela PRECISAM sincronizar o acesso ao buffer frontal compartilhado para que a renderização de olho alternada do conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de ruptura visíveis.
• [C-1-9] PRECISA implementar suporte às flags AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, conforme descrito no NDK.
• [C-1-10] PRECISA implementar suporte a AHardwareBuffers com qualquer combinação das flags de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para pelo menos os seguintes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] É FORTEMENTE RECOMENDADO para oferecer suporte à alocação de AHardwareBuffers com mais de uma camada e flags e formatos especificados em C-1-10.
• [C-1-11] PRECISA oferecer suporte à decodificação H.264 a pelo menos 3.840 x 2.160 a 30 fps, compactado a uma média de 40 Mbps (equivalente a quatro instâncias de 1920 x1080 a 30 fps a 10 Mbps ou 2 instâncias de 1.920 x 20 Mbps a 108ps).
• [C-1-12] PRECISA oferecer suporte a HEVC e VP9, PRECISA ser capaz de decodificar pelo menos 1.920 x 1.080 a 30 fps comprimido a uma média de 10 Mbps e DEVE ser capaz de decodificar 3.840 x 2.160 a 30 fps a 20 Mbps a 20 Mbps a 20 Mbps (equivalente a 20 Mbps a 20 Mbps).
• [C-1-13] PRECISA oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
• [C-1-14] PRECISA ter uma tela incorporada, e a resolução dela PRECISA ser de pelo menos 1920 x 1080.
• [C-SR-6] É FORTEMENTE RECOMENDADO ter uma resolução de tela de pelo menos 2.560 x 1.440.
• [C-1-15] A tela PRECISA ser atualizada para pelo menos 60 Hz no modo RV.
• [C-1-17] A tela PRECISA oferecer suporte a um modo de baixa persistência com menos de 5 milissegundos de persistência, que é definida como a quantidade de tempo em que um pixel está emitindo luz.
• [C-1-18] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE seção 7.4.3.
• [C-1-19] PRECISA oferecer suporte e informar adequadamente o Tipo de canal direto para todos os seguintes tipos de sensor padrão:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] É FORTEMENTE RECOMENDADO oferecer suporte ao tipo de canal direto TYPE_HARDWARE_BUFFER em todos os tipos de canais diretos listados acima.
• [C-1-21] PRECISA atender aos requisitos relacionados ao giroscópio, acelerômetro e magnetômetro para android.hardware.hifi_sensors, conforme especificado na seção 7.3.9.
• [C-SR-8] É FORTEMENTE RECOMENDADO oferecer suporte ao recurso android.hardware.sensor.hifi_sensors.
• [C-1-22] PRECISA ter latência de movimento total para fótons não superior a 28 milissegundos.
• [C-SR-9] É FORTEMENTE RECOMENDADO que tenham movimento de ponta a ponta para latência de fótons não superior a 20 milissegundos.
• [C-1-23] PRECISA ter a proporção do primeiro frame, que é a proporção entre o brilho de pixels no primeiro frame após uma transição de preto para branco e o brilho de pixels brancos em estado estável, de pelo menos 85%.
• [C-SR-10] É RECOMENDADO que a proporção do primeiro frame seja 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 de núcleos de CPU exclusivos do aplicativo de primeiro plano superior.

Se houver suporte ao núcleo exclusivo, então o núcleo:

• [C-2-1] NÃO PODE 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 dos dispositivos.

7,11. Classe de desempenho de mídia

A classe de desempenho de mídia da implementação do dispositivo pode ser extraída da 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 do R (versão 30). O valor especial de 0 designa que o dispositivo não pertence a uma classe de desempenho de mídia.

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

• [C-1-1] PRECISA retornar pelo menos um valor de android.os.Build.VERSION_CODES.R.

• [C-1-2] PRECISA ser uma implementação de dispositivo portátil.

• [C-1-3] PRECISA atender a todos os requisitos de "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 nas versões T, S ou R.

Consulte a seção 2.2.7 para ver os requisitos específicos do dispositivo.

8. Desempenho e potência

Alguns critérios de desempenho e potência mínimos 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 da experiência do usuário

Uma interface do usuário tranquila pode ser fornecida ao usuário final se houver determinados requisitos mínimos para garantir um frame rate e tempos de resposta consistentes para aplicativos e jogos. As implementações de dispositivos, dependendo do tipo, podem ter requisitos mensuráveis de latência da interface do usuário e alternância de tarefas, conforme descrito na seção 2.

8.2. Desempenho do acesso a E/S de arquivos

Fornecer um valor de referência comum para um desempenho consistente do acesso a arquivos no armazenamento de dados particulares do aplicativo (partição /data) permite que os desenvolvedores de apps definam uma expectativa adequada que ajudaria o design do software. As implementações de dispositivos, dependendo do tipo, podem ter determinados requisitos descritos na seção 2 para as seguintes operações de leitura e gravação:

• Desempenho de gravação sequencial. Medida por meio da gravação de um arquivo de 256 MB usando um buffer de gravação de 10 MB.
• Desempenho de gravação aleatória. Medida por gravação de um arquivo de 256 MB usando buffer de gravação de 4 KB.
• Desempenho de leitura sequencial. Medida pela leitura de um arquivo de 256 MB usando um buffer de gravação de 10 MB.
• Desempenho de leitura aleatória. Medida por meio da leitura de um arquivo de 256 MB usando um buffer de gravação de 4 KB.

8.3. Modos de economia de energia

Se as implementações de dispositivos incluírem recursos para melhorar o gerenciamento de energia do dispositivo incluídos no AOSP (por exemplo, bucket do App em espera e Soneca) ou estenderem os recursos para aplicar restrições mais fortes do que o bucket RESTRITO de App em espera, elas:

• [C-1-1] NÃO PODE se desviar da implementação do AOSP para os algoritmos de acionamento, manutenção, ativação e uso das configurações globais do sistema ou DeviceConfig dos modos de economia de energia "App em espera" e "Soneca".
• [C-1-2] NÃO PODE se desviar da implementação do AOSP para usar configurações globais ou DeviceConfig para gerenciar a limitação de jobs, alarmes e rede para apps em cada bucket de App em espera.
• [C-1-3] NÃO PODE se desviar da implementação do AOSP para o número de buckets do App em espera usados para o App em espera.
• [C-1-4] PRECISA implementar os buckets do App em espera e o recurso "Soneca", conforme descrito em Gerenciamento de energia.
• [C-1-5] PRECISA retornar true para PowerManager.isPowerSaveMode() quando o dispositivo estiver no modo de economia de energia.
• [C-1-6] PRECISA oferecer recursos ao usuário para mostrar todos os apps isentos dos modos de economia de energia App em espera e Soneca ou de qualquer otimização de bateria. Além disso, PRECISA implementar a intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS para solicitar que o usuário permita que um app ignore otimizações de bateria.
• [C-SR-1] É FORTEMENTE RECOMENDADO para fornecer ao usuário affordance para ativar e desativar o recurso de economia de bateria.
• [C-SR-2] É FORTEMENTE RECOMENDADO para fornecer funcionalidade ao usuário para mostrar todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".

Se as implementações de dispositivos estenderem os recursos de gerenciamento de energia incluídos no AOSP e essa extensão aplicar restrições mais rigorosas do que o bucket raro de apps 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 de suspensão, conforme definido pela Interface de energia e configuração avançada (ACPI, na sigla em inglês).

Se as implementações de dispositivo implementarem estados de energia S4 conforme definido pela ACPI, elas:

• [C-1-1] PRECISA entrar nesse estado somente após o usuário realizar uma ação explícita para colocar o dispositivo em um estado inativo (por exemplo, fechar uma tampa que faça parte fisicamente do dispositivo ou desligar um veículo ou televisão) e antes de o usuário reativar o dispositivo (por exemplo, abrir a tampa ou ligar o veículo ou a televisão novamente).

Se as implementações de dispositivos implementarem estados de energia do S3 conforme definido pela ACPI, elas:

• [C-2-1] PRECISA atender ao C-1-1 acima ou PRECISA entrar no estado S3 apenas quando aplicativos de terceiros não precisam dos recursos do sistema (por exemplo, a tela, a CPU).

  Por outro lado, PRECISA sair do estado S3 quando aplicativos de terceiros precisam dos recursos do sistema, conforme descrito neste SDK.

  Por exemplo, embora aplicativos de terceiros solicitem a manutenção da tela ligada até FLAG_KEEP_SCREEN_ON ou mantenha a CPU em execução pelo 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 tomado medidas explícitas para colocar o dispositivo em um estado inativo. Por outro lado, quando uma tarefa implementada por apps de terceiros com o JobScheduler for acionada ou quando o Firebase Cloud Messaging for entregue a esses apps, o dispositivo PRECISA sair do estado S3, a menos que o usuário tenha colocado o dispositivo no estado inativo. Esses não são exemplos abrangentes, e o AOSP implementa extensos sinais de ativação que acionam uma ativação desse estado.

8.4. Contabilidade de consumo de energia

Uma contabilidade e um relatório 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] É MUITO 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 Android Open Source Project.
• [C-SR-2] É MUITO RECOMENDADO informar todos os valores de consumo de energia em miliamperes/hora (mAh).
• [C-SR-3] É MUITO 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] É MUITO RECOMENDADO disponibilizar esse uso de energia pelo comando do shell adb shell dumpsys batterystats 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 desse componente a um aplicativo.

8.5. Desempenho consistente

Em apps de alto desempenho e longa duração, a performance pode variar drasticamente, seja por causa dos outros apps executados em segundo plano ou da limitação da CPU devido aos limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo for compatível, o aplicativo em primeiro plano na parte superior possa solicitar que o sistema otimize a alocação dos recursos para lidar com essas flutuações.

Implementações de dispositivos:

• [C-0-1] PRECISA informar o suporte ao modo de desempenho sustentado com precisão usando o método da API PowerManager.isSustainedPerformanceModeSupported().

• DEVE oferecer suporte ao modo de desempenho sustentado.

Se as implementações de dispositivos relatarem suporte ao modo de desempenho sustentado, elas:

• [C-1-1] PRECISA fornecer ao aplicativo em primeiro plano um nível consistente de desempenho por pelo menos 30 minutos, quando solicitado pelo app.
• [C-1-2] PRECISA respeitar a API Window.setSustainedPerformanceMode() e outras APIs relacionadas.

Se as implementações de dispositivos incluírem dois ou mais núcleos de CPU, elas:

• DEVEM fornecer pelo menos um núcleo exclusivo que possa ser reservado pelo aplicativo 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] PRECISA informar, pelo método de API Process.getExclusiveCores(), os números de ID dos núcleos exclusivos que podem ser reservados pelo aplicativo em primeiro plano.
• [C-2-2] Não pode permitir nenhum processo de espaço do usuário, exceto os drivers de dispositivo usados pelo aplicativo para execução nos núcleos exclusivos, mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

Se as implementações de dispositivos não oferecerem suporte a um núcleo exclusivo, elas:

• [C-3-1] PRECISA retornar uma lista vazia usando o método de API Process.getExclusiveCores().

9. Compatibilidade do modelo de segurança

Implementações de dispositivos:

• [C-0-1] PRECISA implementar um modelo de segurança consistente com o da Plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs da documentação do desenvolvedor Android.

• [C-0-2] PRECISA oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades.

Se as implementações de dispositivo declararem o recurso android.hardware.security.model.compatible, elas:

• [C-1-1] PRECISA ser compatível com os requisitos listados nas subseções a seguir.

9,1. Permissões

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao modelo de permissões do Android e ao modelo de papéis do Android, conforme definido na documentação do desenvolvedor Android. Especificamente, eles PRECISAM aplicar cada permissão e papel definidos conforme descrito na documentação do SDK. Nenhuma permissão e nenhum papel pode ser omitido, alterado ou ignorado.

• PODE adicionar outras permissões, desde que as novas strings de ID de permissão não estejam no namespace android.\*.

• [C-0-2] As permissões com um protectionLevel de PROTECTION_FLAG_PRIVILEGED só podem ser concedidas a apps pré-instalados nos caminhos privilegiados da imagem do sistema (bem como nos arquivos APEX) e estar no subconjunto de permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito, lendo e respeitando as permissões da lista de permissões para cada app dos arquivos no caminho etc/permissions/ e usando o caminho system/priv-app.

Permissões com um nível de proteção perigoso são as permissões de execução. Aplicativos com targetSdkVersion > 22 as solicitam no momento da execução.

Implementações de dispositivos:

• [C-0-3] PRECISA mostrar uma interface dedicada para o usuário decidir se vai conceder as permissões de execução solicitadas e também fornecer uma interface para o usuário gerenciar essas permissões.
• [C-0-4] PRECISA ter apenas uma implementação das duas interfaces do usuário. Se a implementação do dispositivo for compatível com um dispositivo complementar, esse dispositivo poderá oferecer uma interface adicional.

• [C-0-5] NÃO PODE conceder permissões de execução a apps, a menos que:

  • forem instalados no momento do envio do dispositivo;

  • O consentimento do usuário pode ser obtido antes que o aplicativo use a permissão,

    OU

  • As permissões de execução são concedidas pela política de concessão de permissão padrão ou pela manutenção de um papel da plataforma.

• [C-0-6] PRECISA conceder a permissão android.permission.RECOVER_KEYSTORE apenas a apps do sistema que registram um Agente de recuperação protegido corretamente. Um Agente de recuperação protegido corretamente é definido como um agente de software no dispositivo que é sincronizado com um armazenamento remoto fora do dispositivo. Ele é equipado com hardware seguro com proteção equivalente ou mais forte do que descrito no Serviço do Google Cloud Key Vault para evitar ataques de força bruta no fator de conhecimento da tela de bloqueio.

Implementações de dispositivos:

• [C-0-7] PRECISA aderir às propriedades de permissão de localização do Android quando um app solicita os dados de localização ou de atividades físicas usando a API padrão do Android ou um mecanismo próprio. Esses dados incluem, entre outros:

  • A 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 o local do dispositivo (por exemplo, SSID, BSSID, ID do celular ou local da rede a que o dispositivo está conectado).
  • Atividade física do usuário ou classificação da atividade física.

Mais especificamente, implementações de dispositivos:

• [C-0-8] PRECISA ter o consentimento do usuário para permitir que um app acesse os dados de local ou atividade física.
• [C-0-9] PRECISA conceder uma permissão de execução APENAS ao app que tiver permissão suficiente, conforme descrito no SDK. Por exemplo, o TelephonyManager#getServiceState requer android.permission.ACCESS_FINE_LOCATION).

As únicas exceções às propriedades de permissão de localização do Android acima são para os apps que não acessam a localização para derivar ou identificar o local do usuário. Especificamente:

• Quando os apps têm a permissão RADIO_SCAN_WITHOUT_LOCATION.
• Para 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 a hardRestricted a um app.
  • Um app recebe o hardRestricted em uma versão anterior do Android.

• [C-0-11] Os apps com uma permissão softRestricted PRECISAM ter acesso limitado e não podem ter acesso total até estarem na lista de permissões, conforme descrito no SDK, em que o acesso total e limitado é definido para cada permissão softRestricted (por exemplo, READ_EXTERNAL_STORAGE).

• [C-0-12] NÃO PODE fornecer nenhuma função ou API personalizada para ignorar as restrições de permissão definidas nas APIs setPermissionPolicy e setPermissionGrantState.

• [C-0-13] PRECISA usar as APIs AppOpsManager para registrar e rastrear todos os acessos programáticos a dados protegidos por permissões perigosas de atividades e serviços do Android.

• [C-0-14] PRECISA atribuir funções apenas a aplicativos com funcionalidades que atendam aos requisitos da função.

• [C-0-15] não pode definir papéis que sejam cópias ou superconjuntos de papéis definidos 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:
  • Localização (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Câmera (CAMERA)
  • Microfone (RECORD_AUDIO)
  • Sensor corporal (BODY_SENSORS)
  • Atividade física (ACTIVITY_RECOGNITION)

Se as implementações de dispositivos fornecerem ao usuário uma funcionalidade para escolher quais apps podem ser desenhados sobre outros apps com uma atividade que processe a intent ACTION_MANAGE_OVERLAY_PERMISSION, elas:

• [C-2-1] PRECISA garantir que todas as atividades com filtros de intent para a intent ACTION_MANAGE_OVERLAY_PERMISSION tenham a mesma tela da interface, independente do app inicial ou de qualquer informação fornecida.

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

• [C-3-1] PRECISA mostrar uma exoneração de responsabilidade durante a configuração do dispositivo totalmente gerenciado (configuração do proprietário do dispositivo) informando que o administrador de TI poderá permitir que os apps controlem 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 das permissões no dispositivo.

Se as implementações do dispositivo pré-instalarem qualquer pacote que tenha qualquer um dos papéis System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence ou System Visual Intelligence, os pacotes:

• [C-4-1] PRECISA 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. Este é mais restrito do que o FORTEMENTE RECOMENDADO listado na seção 9.8.6.
• [C-4-3] NÃO PODE SER vinculado a outros apps, exceto aos seguintes apps do sistema: Bluetooth, Contatos, Mídia, Telefonia, SystemUI e componentes que fornecem APIs de Internet.Isso é mais restrito que o FORTEMENTE RECOMENDADO listado na seção 9.8.6.

9,2. UID e isolamento de processos

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 de Unixstyle exclusivo e em um processo separado.
• [C-0-2] PRECISA oferecer suporte à execução de vários aplicativos com o mesmo ID do usuário do Linux, desde que os aplicativos sejam assinados e construídos 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] PRECISA oferecer suporte ao modelo de permissões de acesso a arquivos do Android, conforme definido na Referência de segurança e permissões.

9,4. Ambientes de execução alternativos

As implementações de dispositivos PRECISAM manter a consistência do modelo de segurança e permissão do Android, mesmo que incluam ambientes de execução que executam aplicativos usando outro software ou tecnologia que não o Dalvik Executable Format ou o código nativo. Resumindo:

• [C-0-1] Os ambientes de execução alternativos PRECISAM ser apps Android e seguir o modelo de segurança padrão do Android, conforme descrito na seção 9.

• [C-0-2] Ambientes de execução alternativos NÃO PODEM ter 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] Ambientes de execução alternativos NÃO PODEM permitir que aplicativos usem recursos protegidos por permissões do Android restritas a apps do sistema.

• [C-0-4] Ambientes de execução alternativos PRECISAM respeitar o 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 do ID do usuário compartilhado e do certificado de assinatura.

• [C-0-5] Ambientes de execução alternativos NÃO PODEM ser iniciados, conceder ou receber acesso às sandboxes correspondentes a outros apps Android.

• [C-0-6] Ambientes de execução alternativos NÃO PODEM ser iniciados, concedidos ou concedidos a outros aplicativos os privilégios 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 chave usada para assinar outros aplicativos incluídos nas implementações do dispositivo.

• [C-0-8] Ao instalar aplicativos, ambientes de execução alternativos PRECISAM receber o consentimento do usuário para as permissões do Android usadas pelo app.

• [C-0-9] Quando um app precisa usar um recurso do dispositivo para que 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 pode acessar esse recurso.

• [C-0-10] Quando o ambiente de execução não grava os recursos do aplicativo dessa maneira, ele PRECISA listar todas as permissões retidas pelo próprio ambiente de execução ao instalar qualquer aplicativo que use esse ambiente de execução.

• Ambientes de execução alternativos DEVEM instalar apps pelo PackageManager em sandboxes separados do Android (IDs de usuário do Linux etc.).

• Os tempos de execução alternativos PODEM fornecer um único sandbox do Android compartilhado por todos os apps que usam o tempo de execução alternativo.

9,5 Suporte a multiusuário

O Android inclui suporte para vários usuários e oferece suporte ao isolamento total e clone perfis de usuário com isolamento parcial(ou seja, um único perfil de usuário extra do tipo android.os.usertype.profile.CLONE).

• As implementações de dispositivos PODEM, mas NÃO DEVEM habilitar o uso de vários usuários se usarem mídia removível para armazenamento externo principal.

Se as implementações de dispositivos tiverem suporte para vários usuários, elas:

• [C-1-2] PRECISA, para cada usuário, implementar um modelo de segurança consistente com o da Plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs.
• [C-1-3] PRECISA ter diretórios de armazenamento compartilhado de aplicativos separados e isolados (também conhecidos como /sdcard) para cada instância de usuário.
• [C-1-4] PRECISA garantir que os aplicativos pertencentes e executados em nome de um determinado usuário não possam listar, ler nem gravar nos arquivos de outro usuário, mesmo que os dados de ambos os 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 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 vão ser necessárias para mudar para o MTP ou um sistema semelhante a fim de fornecer aos PCs host o acesso aos dados do usuário atual.

Se as implementações de dispositivos incluírem suporte para vários usuários, para todos os usuários, exceto aqueles criados especificamente para executar instâncias duplas do mesmo app, elas:

• [C-2-1] PRECISA ter diretórios de armazenamento compartilhado de aplicativos separados e isolados (também conhecidos como /sdcard) para cada instância de usuário.
• [C-2-2] PRECISA garantir que os aplicativos pertencentes e executados em nome de um determinado usuário não possam listar, ler ou gravar nos arquivos de 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 perfil de usuário extra do tipo android.os.usertype.profile.CLONE no usuário principal (e somente contra ele) para executar instâncias duplas do mesmo app. Essas instâncias duplas compartilham armazenamento parcialmente isolado, são apresentadas ao usuário final na tela de início ao mesmo tempo e aparecem na mesma visualização de recentes. Por exemplo, isso pode ser usado para permitir que o usuário instale duas instâncias separadas de um único app em um dispositivo dual chip.

Se as implementações de dispositivos criarem o perfil de usuário adicional discutido acima, elas:

• [C-3-1] PRECISA fornecer acesso apenas ao armazenamento ou aos dados que já estejam acessíveis ao perfil de usuário pai ou que pertençam diretamente a esse perfil de usuário extra.
• [C-3-2] NÃO PODE ter este perfil de trabalho.
• [C-3-3] PRECISA ter diretórios de dados particulares do app isolados da conta do usuário pai.
• [C-3-4] NÃO PODE 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) nem permitir que um proprietário do dispositivo seja provisionado sem remover o perfil de usuário adicional primeiro.

9,6. Aviso de SMS premium

O Android inclui suporte para alertar usuários sobre qualquer mensagem SMS premium enviada. As mensagens SMS premium são mensagens de texto enviadas a um serviço registrado com uma operadora que podem receber cobranças do usuário.

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

• [C-1-1] PRECISA 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 Android Sandbox inclui recursos que usam o sistema de controle de acesso obrigatório (MAC, na sigla em inglês) do Security-Enhanced Linux (SELinux), o sandbox seccomp e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:

• [C-0-1] PRECISA manter a compatibilidade com os aplicativos atuais, mesmo quando o SELinux ou qualquer outro recurso de segurança for implementado 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 for detectada e bloqueada pelo recurso implementado abaixo do framework do Android, mas PODE ter uma interface do usuário visível quando ocorrer uma violação de segurança desbloqueada que resulte em uma exploração bem-sucedida.
• [C-0-3] NÃO PODE tornar o SELinux ou qualquer outro recurso de segurança implementado abaixo do framework do Android configurável para o usuário ou desenvolvedor de apps.
• [C-0-4] NÃO PODE permitir que um aplicativo que possa afetar outro aplicativo por uma API (como uma API Device Administration) configure uma política que viole a compatibilidade.
• [C-0-5] PRECISA 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 Android Open Source Project.
• [C-0-6] PRECISA implementar um mecanismo de sandbox do aplicativo do kernel que permita a filtragem de chamadas do sistema usando uma política configurável de programas com várias linhas de execução. O Android Open Source Project atende a esse requisito ao ativar o seccomp-BPF com a sincronização de grupos de linhas de execução (TSYNC), conforme descrito na seção de configuração do kernel em source.android.com.

A integridade do kernel e os recursos de autoproteção são essenciais para a segurança do Android. Implementações de dispositivos:

• [C-0-7] PRECISA implementar mecanismos de proteção contra estouro do buffer da pilha do kernel. Exemplos desses mecanismos são CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] PRECISA implementar proteções rigorosas de memória do kernel em que o código executável é somente leitura, dados somente leitura não são executáveis nem graváveis e dados graváveis não são executáveis (por exemplo, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] PRECISA implementar a verificação de limites de tamanho de objetos estáticos e dinâmicos, a verificação de cópias entre o espaço do usuário e o espaço do kernel (por exemplo, CONFIG_HARDENED_USERCOPY) em dispositivos originalmente fornecidos com o nível 28 da API ou mais recente.
• [C-0-10] NÃO PODE executar a memória do espaço do usuário ao executar no modo kernel (por exemplo, hardware PXN ou emulado via 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 PODE ler nem gravar memória do espaço do usuário no kernel fora das APIs normais de acesso à cópia do usuário (por exemplo, PAN de hardware ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente fornecidos com o nível 28 da API ou mais recente.
• [C-0-12] PRECISA implementar o isolamento da tabela de página do kernel se o hardware for vulnerável à CVE-2017-5754 em todos os dispositivos originalmente enviados 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] PRECISA implementar o aumento da proteção de previsão da ramificação se o hardware for vulnerável ao CVE-2017-5715 em todos os dispositivos originalmente fornecidos com o nível 28 da API ou mais recente (por exemplo, CONFIG_HARDEN_BRANCH_PREDICTOR).
• [C-SR-1] FORTEMENTE RECOMENDADO para manter os dados do kernel que são gravados somente durante a inicialização marcados como somente leitura após a inicialização (por exemplo, __ro_after_init).

• [C-SR-2] São RECOMENDADOS ALTAMENTE para randomizar o layout do código do kernel e memória e evitar exposições que possam comprometer essa ordem (por exemplo, CONFIG_RANDOMIZE_BASE com entropia do carregador de inicialização usando /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

• [C-SR-3] É FORTEMENTE RECOMENDADO para ativar a integridade do fluxo de controle (CFI) no kernel para fornecer mais proteção contra ataques de reutilização de código (por exemplo, CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] É MUITO RECOMENDADO não desativar a integridade do fluxo de controle (CFI), a pilha de chamadas de sombra (SCS) ou a limpeza de estouro de números inteiros (IntSan) em componentes em que ela está ativada.

• [C-SR-5] É RECOMENDADO que você ative CFI, SCS e IntSan para outros componentes de espaço do usuário sensíveis à segurança, conforme explicado em CFI e IntSan.

• [C-SR-6] É FORTEMENTE RECOMENDADO para ativar a inicialização de pilha no kernel para evitar usos de variáveis locais não inicializadas (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). Além disso, as implementações de dispositivos NÃO DEVEM presumir o valor usado pelo compilador para inicializar os locais.

• [C-SR-7] É FORTEMENTE RECOMENDADO para ativar a inicialização de heap no kernel para evitar usos de alocações de heap não inicializadas (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NÃO DEVEM assumir o valor usado pelo kernel para inicializar essas alocações.

Se as implementações de dispositivos usarem um kernel do Linux capaz de oferecer suporte ao SELinux, elas:

• [C-1-1] PRECISA implementar o SELinux.
• [C-1-2] PRECISA configurar o SELinux para o modo de aplicação global.
• [C-1-3] PRECISA configurar todos os domínios no modo de aplicação. Não são permitidos domínios de modo permissivo, incluindo domínios específicos de um dispositivo/fornecedor.
• [C-1-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes na pasta system/sepolicy fornecida no Android Open Source Project (AOSP) upstream, e a política PRECISA ser compilada com todas as regras de nunca permitir presentes, para domínios SELinux do AOSP e domínios específicos do dispositivo/fornecedor.
• [C-1-5] PRECISA executar aplicativos de terceiros direcionados ao nível 28 da API ou mais recente em sandboxes SELinux por aplicativo com restrições de SELinux por app no diretório de dados privados de cada aplicativo.
• DEVE manter a política SELinux padrão fornecida na pasta system/sepolicy do Android Open Source Project upstream e só incrementar essa política para a própria configuração específica do dispositivo.

Se as implementações de dispositivos usarem kernel diferente do Linux ou Linux sem SELinux, elas:

• [C-2-1] PRECISA usar um sistema de controle de acesso obrigatório equivalente ao SELinux.

Se as implementações de dispositivos usarem dispositivos de E/S compatíveis com DMA, elas:

• [C-SR-9] É VALMENTE RECOMENDADO para isolar cada dispositivo de E/S compatível com DMA, usando uma IOMMU (por exemplo, a SMMU ARM).

O Android contém vários recursos de defesa em profundidade essenciais para a segurança do dispositivo. Além disso, o Android se concentra na redução das 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] São RECOMENDADOS para serem testadas usando ferramentas de detecção de erros de memória do espaço do usuário, como MTE para dispositivos ARMv9, HWASan para dispositivos ARMv8+ ou ASan para outros tipos de dispositivos.
• [C-SR-11] São RECOMENDADOS para serem testados usando ferramentas de detecção de erros de memória do kernel, como KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS para dispositivos ARMv9, CONFIG_KASAN_SW_TAGS para dispositivos ARMv8 ou CONFIG_KASAN_GENERIC para outros tipos de dispositivos).
• [C-SR-12] É RECOMENDADO usar ferramentas de detecção de erros de memória na produção, como MTE, GWP-ASan e KFENCE.

Se as implementações de dispositivos usarem um TEE baseado em Arm TrustZone, elas:

• [C-SR-13] É FORTEMENTE 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] É FORTEMENTE RECOMENDADO que os aplicativos confiáveis restrinjam apenas a memória que foi compartilhada explicitamente com eles pelo protocolo acima. Se o dispositivo tiver suporte para o nível de exceção Arm S-EL2, isso precisará ser aplicado pelo gerenciador de partições seguras. Caso contrário, isso precisa ser aplicado 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 pelo UsageStatsManager.

Implementações de dispositivos:

• [C-0-1] PRECISA manter um período de retenção razoável desse histórico do usuário.
• [C-SR-1] São RECOMENDADOS ALTAMENTE para manter o período de armazenamento de 14 dias como 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 por meio do StatsManager e da API IncidentManager System.

Implementações de dispositivos:

• [C-0-2] É PRECISO incluir apenas os campos marcados com DEST_AUTOMATIC no relatório de incidentes criado pela classe IncidentManager da API System.
• [C-0-3] Não é NECESSÁRIO usar os identificadores de eventos do sistema para registrar qualquer outro evento que não esteja descrito nos documentos do SDK StatsLog. Se outros eventos de sistema forem registrados, eles PODEM usar um identificador atômico diferente no intervalo entre 100.000 e 200.000.

9.8.2. Gravações

Implementações de dispositivos:

• [C-0-1] NÃO É POSSÍVEL pré-carregar nem distribuir componentes de software prontos para uso que enviam informações particulares do usuário (por exemplo, toques de tecla, texto exibido na tela, relatório do bug) para fora do dispositivo sem o consentimento do usuário ou notificações claras contínuas.
• [C-0-2] PRECISA mostrar e receber o consentimento explícito do usuário, permitindo que informações sensíveis exibidas na tela do usuário sejam capturadas sempre que a transmissão ou gravação de tela for ativada usando o MediaProjection ou APIs próprias. NÃO PODE fornecer aos usuários uma affordance para desativar a exibição futura do consentimento do usuário.
• [C-0-3] O usuário PRECISA ter uma notificação contínua para o usuário enquanto a transmissão ou a gravação de tela está ativada. O AOSP atende a esse requisito mostrando um ícone de notificação contínua na barra de status.

Se as implementações do dispositivo incluírem uma funcionalidade no sistema que capture o conteúdo mostrado na tela e/ou grave o stream de áudio reproduzido no dispositivo de outra maneira que não seja pela API System ContentCaptureService ou outros meios reservados descritos na Seção 9.8.6 Captura de conteúdo, elas:

• [C-1-1] PRECISA ter uma notificação contínua para o usuário sempre que essa funcionalidade estiver ativada e estiver capturando/gravando ativamente.

Se as implementações do dispositivo incluírem um componente habilitado para uso imediato, capaz de gravar áudio ambiente e/ou gravar o áudio tocado no dispositivo para inferir informações úteis sobre o contexto do usuário, elas:

• [C-2-1] NÃO PODE armazenar no armazenamento persistente no dispositivo nem transmitir para fora do dispositivo o áudio bruto gravado ou qualquer formato que possa ser convertido de volta para o áudio original ou um quase fax, exceto com o consentimento explícito do usuário.

Um "indicador de microfone" se refere a uma visualização na tela, que fica constantemente visível para o usuário e não pode ser ocultada, o que os usuários entendem como um microfone está em uso(por meio de texto, cor, ícone ou alguma combinação exclusiva).

Um "indicador da câmera" se refere a uma visualização na tela que fica constantemente visível para o usuário e não pode ser ocultada, o que os usuários entendem quando a câmera está em uso, por meio de texto, cor, ícone exclusivos ou alguma combinação.

Após o primeiro segundo exibido, um indicador pode mudar visualmente, por exemplo, ficar menor, e não precisa ser mostrado como apresentado e entendido originalmente.

O indicador de microfone pode ser mesclado com um indicador de câmera exibido ativamente, desde que o texto, os ícones ou as cores indiquem ao usuário que o uso do microfone começou.

O indicador de câmera pode ser mesclado com um indicador de microfone exibido ativamente, desde que o texto, os ícones ou as cores indiquem ao usuário que o uso da câmera começou.

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

• [C-SR-1] É RECOMENDADO para mostrar o indicador de microfone quando um app está acessando dados de áudio pelo microfone, mas não quando o microfone é acessado apenas por HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou apps que detêm os papéis mencionados na Seção 9.1 Permissões com identificador CDD [C-3-X]. .
• [C-SR-2] São RECOMENDADOS a mostrar a lista de apps recentes e ativos usando o microfone conforme retornado de PermissionManager.getIndicatorAppOpUsageData(), com todas as mensagens de atribuição associadas a eles.
• [C-SR-3] É RECOMENDADO que não ocultem o indicador de microfone para apps do sistema que têm interfaces do usuário visíveis ou interação direta com o usuário.

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

• [C-SR-4] É FORTEMENTE RECOMENDADO para 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 só estiver sendo acessada por apps que detêm os papéis mencionados na Seção 9.1 Permissões com identificador CDD [C-3-X].
• [C-SR-5] É FORTEMENTE RECOMENDADO mostrar apps recentes e ativos usando a câmera conforme retornada de PermissionManager.getIndicatorAppOpUsageData(), além de qualquer mensagem de atribuição associada a eles.
• [C-SR-6] É FORTEMENTE RECOMENDADO para não ocultar o indicador de 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 de periférico USB, elas:

• [C-1-1] PRECISA apresentar uma interface do usuário solicitando 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] PRECISA pré-instalar os mesmos certificados raiz do repositório da autoridade de certificação (CA, na sigla em inglês) confiável, conforme fornecido no Android Open Source Project.
• [C-0-2] PRECISA enviar com um repositório de CAs raiz de usuário vazio.
• [C-0-3] PRECISA exibir um aviso ao usuário indicando que o tráfego de rede pode ser monitorado quando uma CA raiz do usuário é adicionada.

Se o tráfego do dispositivo for roteado por uma VPN, as implementações do dispositivo:

• [C-1-1] PRECISA 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 de VPN específico que fornece a VPN.

Se as implementações de dispositivos tiverem um mecanismo, ativado e pronto para uso por padrão, que encaminhe o tráfego de dados de rede por um servidor proxy ou gateway de VPN (por exemplo, pré-carregamento de um serviço de VPN com android.permission.CONTROL_VPN concedido):

• [C-2-1] PRECISA solicitar o consentimento do usuário antes de ativar esse mecanismo, a menos que a VPN seja ativada pelo controlador de política do dispositivo pelo DevicePolicyManager.setAlwaysOnVpnPackage(). Nesse caso, o usuário não precisa fornecer um consentimento separado, mas PRECISA ser notificado.

Se as implementações de dispositivos implementarem uma funcionalidade do usuário para ativar a função "VPN sempre ativa" de um app de VPN de terceiros, elas:

• [C-3-1] PRECISA desativar essa funcionalidade do usuário para apps que não são compatíveis com o serviço de VPN sempre ativada no arquivo AndroidManifest.xml, definindo o atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON como false.

9.8.5. Identificadores de dispositivo

Implementações de dispositivos:

• [C-0-1] PRECISA 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 chip e à Identidade internacional de assinante de dispositivos móveis (IMSI, na sigla em inglês) de um app, a menos que atenda a um dos seguintes requisitos:
  • é um app de operadora assinado verificado pelos fabricantes de dispositivos.
  • recebeu a permissão READ_PRIVILEGED_PHONE_STATE.
  • tem privilégios de operadora, conforme definido nos Privilégios de operadora do UICC.
  • é um proprietário de dispositivo ou perfil que recebeu a permissão READ_PHONE_STATE.
  • (Somente para o número de série do chip/ICCID) tem o requisito de regulamentações locais de que o app detecte mudanças na identidade do assinante.

9.8.6. Captura de conteúdo e pesquisa de apps

O Android, com a API do sistema ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query ou por outros meios próprios, oferece suporte a um mecanismo para implementações de dispositivos que capturam as seguintes interações de dados entre os aplicativos e o usuário:

• Texto e gráficos renderizados na tela, incluindo, mas não se limitando a, 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).
• Quaisquer outros eventos que um aplicativo fornece ao sistema pela API Content Capture ou pela API AppSearchManager, uma API Android e reservada de recursos semelhantes.
• Qualquer texto ou outro dado enviado por meio de TextClassifier API para o TextClassifier do sistema, ou seja, para o serviço do sistema para entender o significado do texto, além de gerar as próximas ações previstas com base no texto.
• Dados indexados pela implementação do AppSearch da plataforma, incluindo, mas não se limitando a, dados de texto, gráficos, de mídia ou outros dados semelhantes.

Se as implementações de dispositivos 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 uma das criptografias listadas como a versão 26+ da API descrita em SDK de criptografia.
• [C-1-2] NÃO É POSSÍVEL fazer backup de dados brutos ou criptografados usando métodos de backup do Android ou qualquer outro método de backup.
• [C-1-3] PRECISA enviar apenas 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 análises agregadas e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais" para evitar que qualquer dado por usuário seja introspectivo (por exemplo, implementado usando uma tecnologia de privacidade diferencial, como RAPPOR).
• [C-1-4] NÃO PODE associar esses dados a nenhuma identidade do usuário (como Account) no dispositivo, exceto com o consentimento explícito do usuário toda vez que os dados forem associados.
• [C-1-5] NÃO PODE compartilhar esses dados com outros componentes do SO que não sigam os requisitos descritos na seção atual (9.8.6 Captura de conteúdo), exceto com consentimento explícito do usuário sempre que eles forem compartilhados.
• [C-1-6] PRECISA fornecer funcionalidade do usuário para apagar os dados que a ContentCaptureService ou os meios reservados coletam se os dados estiverem armazenados de qualquer forma no dispositivo.
• [C-1-7] PRECISA oferecer uma funcionalidade do usuário para recusar os dados, coletados pelo AppSearch ou meios reservados para exibição na plataforma Android, por exemplo, na tela de início.
• [C-SR-1] É RECOMENDADO NÃO solicitar a permissão de INTERNET.
• [C-SR-2] É RECOMENDADO que só acesse a Internet usando APIs estruturadas com suporte de implementações de código aberto disponíveis publicamente.

Se as implementações de dispositivos incluírem um serviço que implemente a API do sistema ContentCaptureService, AppSearchManager.index ou qualquer serviço reservado que capture os dados conforme descrito acima, elas:

• [C-2-1] NÃO PODE permitir que os usuários substituam os serviços por um aplicativo ou serviço instalável pelo usuário e PRECISA permitir que apenas os serviços pré-instalados capturem esses dados.
• [C-2-2] NÃO PODE permitir que outros apps, além do mecanismo de serviços pré-instalados, capturem esses dados.
• [C-2-3] PRECISA fornecer recursos do usuário para desativar os serviços.
• [C-2-4] NÃO É POSSÍVEL omitir a funcionalidade do usuário para gerenciar as permissões do Android retidas pelos serviços e seguir o modelo de permissões do Android conforme descrito na Seção 9.1. Permissão.

• [C-SR-3] É FORTEMENTE RECOMENDADO para manter os serviços separados de outros componentes do sistema(por exemplo, não vincular os IDs de processos de serviço ou compartilhamento), exceto:

  • Telefonia, Contatos, interface do sistema e mídia

O Android, por meio de SpeechRecognizer#onDeviceSpeechRecognizer(), oferece a capacidade de realizar reconhecimento de fala no dispositivo, sem envolver a rede. Qualquer implementação do SpeechReconhecedor 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 PODE 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 seja o app em foco no momento.
• [C-0-2] PRECISA limpar os dados da área de transferência no máximo 60 minutos depois de terem sido colocados ou lidos na área de transferência.

9.8.8. Localização

O local inclui informações na classe Location do Android( como latitude, longitude, altitude), bem como identificadores que podem ser convertidos para local. A localização pode ser tão adequada quanto DGPS (Sistema de Posicionamento Global Diferencial) ou tão aproximada 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 com os tipos de local que derivam diretamente a localização de um usuário ou podem ser convertidos nesse local. Esta não é uma lista abrangente, mas deve ser usada como um exemplo do local que pode ser derivado direta ou indiretamente:

• GPS/GNSS/DGPS/PPP
  • Solução de Posicionamento Global, Sistema Global de Navegação por Satélite ou Solução de Posicionamento Global Diferencial
  • Isso também inclui medições brutas de GNSS e o status de GNSS
    • O local preciso pode ser derivado 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 futuras de modem celular com identificadores exclusivos

Como ponto de referência principal, consulte as APIs do Android que exigem as permissões ACCESS_FINE_Location ou ACCESS_COARSE_Location.

Implementações de dispositivos:

• [C-0-1] NÃO É POSSÍVEL ativar/desativar a configuração de localização do dispositivo e as configurações de busca de Wi-Fi/Bluetooth sem o consentimento explícito do usuário ou iniciação do usuário.
• [C-0-2] PRECISA fornecer ao usuário recursos para acessar informações relacionadas à localização, incluindo solicitações recentes de localização, permissões no nível do app e uso de busca por Wi-Fi/Bluetooth para determinar a localização.
• [C-0-3] PRECISA garantir que o app que está usando a API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] seja uma sessão de emergência iniciada pelo usuário (por exemplo, disque 911 ou envie uma mensagem de texto para 911). No entanto, para o Automotive, um veículo PODE iniciar uma sessão de emergência sem interação ativa do usuário caso um acidente/acidente seja detectado (por exemplo, para atender aos requisitos de chamadas eletrônicas).
• [C-0-4] PRECISA 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] PRECISA programar uma notificação para lembrar o usuário depois que um app em segundo plano acessar 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 versões mais recentes não podem conferir 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 É POSSÍVEL expor detalhes sobre qualquer outro app instalado para nenhum app direcionado à API de nível 30 ou mais recente, a menos que ele já possa acessar detalhes sobre o outro app instalado pelas APIs gerenciadas. Isso inclui, sem limitação, detalhes expostos por qualquer API personalizada adicionada pelo implementador do dispositivo ou acessíveis por meio do sistema de arquivos.
• [C-0-2] NÃO PODE conceder a nenhum app acesso de leitura ou gravação a arquivos em nenhum 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 DocumentsUI).
  • Provedor de downloads, que usa a autoridade do provedor de "downloads" para fazer o download de arquivos no 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 bugs de conectividade

Se as implementações de dispositivo declararem a flag de recurso android.hardware.telephony, elas:

• [C-1-1] PRECISA oferecer suporte à geração de relatórios de bugs de conectividade via BUGREPORT_MODE_TELEPHONY com o BugreportManager.
• [C-1-2] O usuário PRECISA ter o consentimento do usuário sempre que a BUGREPORT_MODE_TELEPHONY for usada para gerar um relatório e NÃO PODE solicitar o consentimento do usuário para todas as solicitações futuras do aplicativo.
• [C-1-3] NÃO PODE retornar o relatório gerado ao app solicitante sem o consentimento explícito do usuário.
• [C-1-4] Os relatórios gerados com BUGREPORT_MODE_TELEPHONY PRECISAM conter pelo menos as seguintes informações:
  • TelephonyDebugService despejados
  • TelephonyRegistry despejados
  • WifiService despejados
  • ConnectivityService despejados
  • Um despejo da instância CarrierService do pacote de chamada (se vinculado).
  • Buffer de registro de rádio
• [C-1-5] NÃO PODE incluir o seguinte nos relatórios gerados:
  • Qualquer tipo de informação que não esteja diretamente relacionada à depuração da conectividade.
  • Qualquer tipo de registros de tráfego de apps instalados pelo usuário ou perfis detalhados de apps/pacotes instalados pelo usuário (UIDs são aceitáveis, nomes de pacotes não são).
• PODE incluir outras informações que não estão associadas a nenhuma identidade do usuário. (por exemplo, registros do fornecedor).

Se as implementações do dispositivo incluírem outras informações (por exemplo, registros do fornecedor) nos relatórios de bugs e essas informações tiverem impacto na privacidade/segurança/bateria/armazenamento/memória, elas:

• [C-SR-1] É FORTEMENTE RECOMENDADO que uma configuração de desenvolvedor seja desativada por padrão. A implementação de referência do AOSP atende a isso oferecendo a opção Enable verbose vendor logging nas configurações do desenvolvedor para incluir outros registros de fornecedores específicos do dispositivo nos relatórios do bug.

9.8.11. Compartilhamento de blobs de dados

O Android, por meio do BlobStoreManager, permite que os apps contribuam com blobs de dados para o sistema serem compartilhados com um conjunto selecionado de apps.

Se as implementações de dispositivos forem compatíveis com 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() NÃO PODE ser modificado). A implementação de referência do AOSP atende a esses requisitos.
• [C-1-2] NÃO É POSSÍVEL enviar para fora do dispositivo nem 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 MusicRecognitionManager da API System, oferece suporte a um mecanismo para implementações de dispositivos para solicitar reconhecimento de música, receber uma gravação 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 implemente a API System MusicRecognitionManager ou qualquer serviço reservado que transmita dados de áudio, conforme descrito acima, elas:

• [C-1-1] PRECISA impor que o autor da chamada do MusicRecognitionManager tenha a permissão MANAGE_MUSIC_RECOGNITION.
• [C-1-2] PRECISA impor que um único aplicativo de reconhecimento de músicas pré-instalado implemente o MusicRecognitionService.
• [C-1-3] NÃO PODE permitir que os usuários substituam MusicRecognitionManagerService ou MusicRecognitionService por um app ou serviço instalável pelo usuário.
• [C-1-4] PRECISA garantir que, quando MusicRecognitionManagerService acessar o gravamento de áudio e encaminhá-lo para o aplicativo que implementa o MusicRecognitionService, o acesso ao áudio seja rastreado por meio de invocações de AppOpsManager.noteOp / startOp.

Se as implementações de dispositivo MusicRecognitionManagerService ou MusicRecognitionService armazenarem dados de áudio capturados, elas:

• [C-2-1] NÃO É POSSÍVEL armazenar impressões digitais de áudio ou áudio brutas no disco ou na memória por mais de 14 dias.
• [C-2-2] NÃO PODE compartilhar esses dados além do MusicRecognitionService, exceto com consentimento explícito do usuário sempre que eles são compartilhados.

9.8.13. SensorPrivacyManager

Se as implementações de dispositivos fornecerem ao usuário uma funcionalidade de software para desativar a entrada de câmera e/ou microfone para a implementação, elas:

• [C-1-1] PRECISA retornar "true" com precisão para o método de API supportsSensorToggle() relevante.
• [C-1-2] PRECISA, quando um app tentar acessar uma câmera ou um microfone bloqueado, apresentar ao usuário uma funcionalidade de usuário não dispensável que indique claramente que o sensor está bloqueado e exige a opção de continuar o bloqueio ou desbloquear de acordo com a implementação do AOSP que atende a esse requisito.
• [C-1-3] PRECISA transmitir apenas dados de áudio e câmera em branco (ou falsos) aos apps e não informar um código de erro devido ao usuário não ativar a câmera nem o microfone pela funcionalidade do usuário apresentada de acordo com [C-1-2] acima.

9,9. Criptografia do armazenamento de dados

Todos os dispositivos PRECISAM atender aos requisitos da seção 9.9.1. Os dispositivos iniciados em um nível de 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 iniciado.

9.9.1. Inicialização direta

Implementações de dispositivos:

• [C-0-1] PRECISA 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 com reconhecimento de inicialização direta que os locais de armazenamento criptografados por 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] PRECISA criptografar os dados particulares do aplicativo (partição /data), bem como a partição de armazenamento compartilhado do aplicativo (partição /sdcard) se ela for uma parte permanente e não removível do dispositivo.
• [C-0-2] PRECISA ativar a criptografia do armazenamento de dados por padrão no momento em que o usuário concluir a configuração pronta.

• [C-0-3] PRECISA atender ao requisito de criptografia de armazenamento de dados acima implementando um dos dois métodos de criptografia a seguir:

  • Criptografia baseada em arquivos (FBE, na sigla em inglês) e Criptografia de metadados, conforme descrito na seção 9.9.3.1.
  • Criptografia em nível de bloco por usuário, conforme descrito na seção 9.9.3.2.

Observação: as implementações de dispositivos enviadas com uma API de nível 28 ou anterior e que não atendem aos requisitos da versão 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 correspondentes ao nível da API em que o dispositivo foi enviado.

9.9.3. Métodos de criptografia

Se as implementações de dispositivos forem criptografadas, elas:

• [C-1-1] PRECISA inicializar sem solicitar credenciais ao usuário e permitir que apps com reconhecimento de inicialização direta acessem o armazenamento criptografado do dispositivo após a transmissão da mensagem ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] PRECISA permitir o acesso ao armazenamento criptografado por credenciais (CE, na sigla em inglês) somente depois que o usuário desbloquear o dispositivo fornecendo credenciais (por exemplo, senha, PIN, padrão ou impressão digital) e a mensagem ACTION_USER_UNLOCKED for transmitida.
• [C-1-13] NÃO PODE oferecer nenhum método para desbloquear o armazenamento protegido por CE sem as credenciais fornecidas pelo usuário, uma chave de garantia registrada ou um currículo na implementação da reinicialização atendendo aos requisitos na seção 9.9.4.
• [C-1-4] PRECISA usar a Inicialização verificada.

9.9.3.1. Criptografia baseada em arquivos e metadados

Se as implementações de dispositivos usam criptografia baseada em arquivos com criptografia de metadados, elas:

• [C-1-5] PRECISA 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çado com um comprimento de chave de criptografia de 256 bits, operada 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] PRECISA criptografar nomes de arquivos 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 do arquivo, conteúdos do arquivo e criptografia de metadados do sistema de arquivos PRECISAM ser usadas, não Adiantum.
• [C-1-13] PRECISA usar uma função de derivação de chaves com criptografia forte e não reversível (por exemplo, HKDF-SHA512) para derivar subchaves necessárias (por exemplo, chaves por arquivo) das chaves CE e DE. "Criptograficamente forte e irreversível" significa que a função de derivação de chave tem uma força de segurança de pelo menos 256 bits e se comporta como uma família de funções pseudoaleatórias nas entradas.
• [C-1-14] NÃO PODE usar as mesmas chaves ou subchaves de criptografia baseada em arquivos (FBE, na sigla em inglês) para diferentes propósitos criptográficos. Por exemplo, para criptografia e derivação de chaves ou para dois algoritmos de criptografia diferentes.
• [C-1-15] PRECISA garantir que todos os blocos não excluídos de conteúdos de arquivos criptografados no armazenamento permanente sejam criptografados usando combinações de chave de criptografia e vetor de inicialização (IV, na sigla em inglês) 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 comprimento de IV de 32 bits.
• [C-1-16] PRECISA garantir que todos os nomes de arquivo criptografados não excluídos no armazenamento permanente em diretórios distintos sejam criptografados usando combinações distintas de chave de criptografia e vetor de inicialização (IV, na sigla em inglês).

• [C-1-17] PRECISA garantir que todos os blocos de metadados do sistema de arquivos criptografados no armazenamento permanente sejam criptografados usando combinações distintas de chave de criptografia e vetor de inicialização (IV, na sigla em inglês).

• Chaves que protegem as áreas de armazenamento CE e DE e os metadados do sistema de arquivos:

  • [C-1-7] PRECISA estar vinculado criptograficamente 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 CE PRECISAM estar vinculadas às credenciais da tela de bloqueio de um usuário.
  • [C-1-9] As chaves CE PRECISAM ser vinculadas a uma senha padrão quando o usuário não especifica as credenciais da tela de bloqueio.
  • [C-1-10] PRECISA ser exclusiva e distinta. Em outras palavras, nenhuma chave CE ou DE do usuário corresponde a nenhuma chave CE ou DE de outro usuário.
  • [C-1-11] PRECISA usar as criptografias, os comprimentos e os modos obrigatoriamente aceitos.
  • [C-1-12] PRECISA ser apagado com segurança durante o desbloqueio e bloqueio do carregador de inicialização, conforme descrito aqui.

• DEVE tornar os apps essenciais pré-instalados (por exemplo, Alarme, Telefone, Messenger) com reconhecimento de inicialização direta.

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 da criptografia de metadados com base no recurso "dm-default-key" do kernel do Linux.

Observação: as implementações de dispositivos enviadas no nível 28 da API ou anteriores e que não atendem aos requisitos da versão 9.9.3 em 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 dispositivos usarem criptografia no nível de bloco por usuário, elas:

• [C-1-1] PRECISA ativar o suporte multiusuário, conforme descrito na seção 9.5.
• [C-1-2] PRECISA fornecer partições por usuário, usando partições brutas ou volumes lógicos.
• [C-1-3] PRECISA usar chaves de criptografia exclusivas e distintas por usuário para a criptografia dos dispositivos de bloco subjacentes.

• [C-1-4] PRECISA usar o AES-256-XTS para a criptografia no nível de bloco das partições do usuário.

• As chaves que protegem os dispositivos criptografados no nível de bloco por usuário:

  • [C-1-5] PRECISA estar vinculado criptograficamente 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-6] PRECISA estar vinculado às credenciais correspondentes da tela de bloqueio do usuário.

A criptografia no 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 opção "Retomar na reinicialização" permite desbloquear o armazenamento CE de todos os apps, incluindo aqueles que ainda não têm 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.

A implementação de "Retomar na reinicialização" precisa continuar para garantir que, quando um dispositivo cai nas mãos de um invasor, seja extremamente difícil para esse invasor recuperar os dados criptografados por CE, mesmo que o dispositivo esteja ligado, o armazenamento CE esteja desbloqueado e o usuário o desbloqueie após receber uma OTA. Para resistência a ataques de pessoas com informações privilegiadas, também presumimos que o invasor tenha acesso às chaves de assinatura criptográficas para a transmissão.

Especificamente:

• [C-0-1] O armazenamento CE NÃO PODE ser legível, mesmo para o invasor que tenha o dispositivo fisicamente e que tenha estes recursos e limitações:

  • Pode usar a chave de assinatura de qualquer fornecedor ou empresa para assinar mensagens arbitrárias.
  • Pode fazer com que um OTA seja recebido pelo dispositivo.
  • 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 pode modificar a operação de hardware resistente a adulterações (por exemplo, Titan M).
  • Não é possível ler a RAM do dispositivo ativo.
  • Não conseguir a credencial do usuário (PIN, padrão, senha) ou fazer com que ela seja inserida.

Por exemplo, uma implementação de dispositivo que implemente e obedeça a todas as descrições encontradas neste link estará em conformidade com [C-0-1].

9,10 Integridade do dispositivo

Os requisitos abaixo garantem que o status da integridade do dispositivo seja transparente. Implementações de dispositivos:

• [C-0-1] PRECISA informar corretamente, pelo método PersistentDataBlockManager.getFlashLockState() da API do sistema, se o estado do carregador de inicialização permite a atualização da imagem do sistema.

• [C-0-2] PRECISA oferecer suporte à Inicialização verificada para garantir a integridade do dispositivo.

Se as implementações do dispositivo já tiverem sido lançadas sem suporte para a Inicialização verificada 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.

A Inicialização verificada é um recurso que garante a integridade do software do dispositivo. Se as implementações de dispositivos forem compatíveis com o recurso, elas:

• [C-1-1] PRECISA declarar a flag de recurso da plataforma android.software.verified_boot.
• [C-1-2] PRECISA fazer a verificação em todas as sequências de inicialização.
• [C-1-3] PRECISA iniciar a verificação usando uma chave de hardware imutável que é a raiz de confiança e ir até a partição do sistema.
• [C-1-4] PRECISA implementar cada estágio da verificação para conferir a integridade e a autenticidade de todos os bytes no estágio seguinte antes de executar o código na etapa seguinte.
• [C-1-5] PRECISA usar algoritmos de verificação tão fortes quanto as recomendações atuais do NIST para algoritmos de hash (SHA-256) e tamanhos de chave pública (RSA-2048).
• [C-1-6] NÃO PODE permitir que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário concorde em tentar inicializar de qualquer maneira. Nesse caso, os dados de blocos de armazenamento não verificados não PODEM ser usados.
• [C-1-7] NÃO PODE permitir que partições verificadas no dispositivo sejam modificadas, a menos que o usuário tenha desbloqueado explicitamente o carregador de inicialização.
• [C-SR-1] Se houver vários chips distintos no dispositivo (por exemplo, rádio, processador de imagem especializado), o processo de inicialização de cada um deles será FORTEMENTE RECOMENDADO para verificar cada estágio na inicialização.
• [C-1-8] PRECISA usar um armazenamento inviolável para armazenar se o carregador de inicialização está desbloqueado. Um armazenamento à prova de adulterações significa que o carregador de inicialização pode detectar se o armazenamento foi adulterado no Android.
• [C-1-9] PRECISA solicitar ao usuário enquanto usa o dispositivo e exigir confirmação física antes de permitir uma transição do modo bloqueado do carregador de inicialização para o modo desbloqueado.
• [C-1-10] PRECISA implementar a proteção contra reversão para partições usadas pelo Android (por exemplo, inicialização e partições do sistema) e usar armazenamento à prova de adulterações para armazenar os metadados usados para determinar a versão mínima permitida do SO.
• [C-1-11] PRECISA 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 quaisquer espaços NVRAM).
• [C-SR-2] São RECOMENDADOS ALTAMENTE para verificar todos os arquivos APK de apps privilegiados com uma cadeia de confiança enraizada em partições protegidas pela Inicialização verificada.
• [C-SR-3] É FORTEMENTE RECOMENDADO para verificar todos os artefatos executáveis carregados por um app privilegiado de fora do arquivo APK (como um código carregado dinamicamente ou código compilado) antes de executá-los ou FOR FORTEMENTE RECOMENDADOS para não executá-los de forma alguma.
• DEVE implementar proteção contra reversão para qualquer componente com firmware persistente (por exemplo, modem, câmera) e PRECISA usar armazenamento à prova de adulterações para armazenar os metadados usados para determinar a versão mínima permitida.

Se as implementações de dispositivos já tiverem sido 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 para esses requisitos com uma atualização de software do sistema, elas PODEM ser isentas dos requisitos.

O Android Open Source Project 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] PRECISA ser compatível com a 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 PODE permitir que as solicitações de leitura em um arquivo protegido sejam bem-sucedidas quando o conteúdo de leitura não for verificado com base em uma chave confiável.

Se as implementações de dispositivos já tiverem sido lançadas sem a possibilidade de verificar o conteúdo do arquivo com base em uma chave confiável em uma versão anterior do Android e não for possível adicionar suporte a esse recurso com uma atualização de software do sistema, elas PODEM ser isentas da exigência. 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] É RECOMENDADO A compatibilidade com a API Android Protected Confirmation.

Se as implementações de dispositivos oferecerem suporte à API Confirmação protegida pelo Android, elas:

• [C-3-1] PRECISA informar true para a API ConfirmationPrompt.isSupported().

• [C-3-2] PRECISA 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 a interação do usuário.

• [C-3-3] PRECISA garantir que o usuário possa analisar e aprovar a mensagem solicitada, mesmo que o SO Android, incluindo o kernel, seja 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 com a API KeyChain ou a API Keystore. Implementações de dispositivos:

• [C-0-1] PRECISA permitir a importação ou geração de pelo menos 8.192 chaves.
• [C-0-2] A autenticação da tela de bloqueio PRECISA implementar um intervalo de tempo entre as tentativas com falha. Com "n" como a contagem de tentativas com falha, o intervalo de tempo PRECISA ser de pelo menos 30 segundos para 9 < n < 30. Para n > 29, o valor do intervalo de tempo PRECISA ser de pelo menos 30*2^floor((n-30)/10)) segundos ou pelo menos 24 horas, o que for menor.
• Não devem limitar o número de chaves que podem ser geradas

Quando a implementação do dispositivo é compatível com uma tela de bloqueio segura, ela:

• [C-1-1] PRECISA fazer backup da implementação de keystore com um ambiente de execução isolado.
• [C-1-2] PRECISA ter implementações de algoritmos criptográficos RSA, AES, ECDSA, ECDH (se houver suporte a IKeyMintDevice), 3DES, HMAC e funções de hash da família MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos com suporte do sistema Android Keystore em uma área isolada com segurança do código em execução no kernel e em versões mais recentes. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o código do kernel ou do espaço do usuário possa acessar o estado interno do ambiente isolado, incluindo a DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
• [C-1-3] PRECISA executar 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 faça a autenticação da tela de bloqueio. O Android Open Source Project fornece a Camada de abstração de hardware (HAL, na sigla em inglês) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
• [C-1-4] PRECISA oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é realizada em um hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas entre um número suficiente de dispositivos para evitar que as chaves sejam usadas como identificadores de dispositivos. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidas. Se mais de 100 mil unidades de uma SKU forem produzidas, uma chave diferente poderá ser usada para cada 100 mil unidades.

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior do Android, esse dispositivo estará isento da exigência de ter um keystore apoiado por um ambiente de execução isolado e oferecer suporte ao atestado de chaves, 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] PRECISA permitir que o usuário escolha o tempo limite de suspensão para fazer 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 é ligado podem NÃO ter a configuração de tempo limite de suspensão.
• [C-1-6] PRECISA 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] É FORTEMENTE RECOMENDADO para oferecer suporte ao IKeyMintDevice versão 1.

9.11.1. Tela de bloqueio segura, autenticação e dispositivos virtuais

A implementação do AOSP segue um modelo de autenticação em níveis 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] É FORTEMENTE RECOMENDADO definir apenas um dos seguintes como 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

Observe que os métodos de autenticação acima são referidos como os métodos de autenticação principais recomendados neste documento.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação principais recomendados e usarem um novo método de autenticação como uma maneira segura de bloquear a tela, o novo método de autenticação:

• [C-2-1] PRECISA ser o método de autenticação do usuário, conforme descrito em Exigir autenticação do usuário para o uso de chaves.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio se forem baseados em um secret conhecido e usarem um novo método de autenticação a ser tratado como uma maneira segura de bloquear a tela:

• [C-3-1] A entropia do menor comprimento 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 principais recomendados de autenticação (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 do controlador de política de dispositivo (DPC) tiver definido a política de requisitos de senha por meio do 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 APASSWORD_WEUALQualidade().
• [C-3-5] Os novos métodos de autenticação PRECISAM usar os métodos de autenticação principais recomendados (por exemplo, PIN, padrão e senha) uma vez a cada 72 horas ou menos OU divulgar claramente ao usuário que não será feito backup de alguns dados para preservar a privacidade deles.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação principais recomendados para desbloquear a tela de bloqueio e usarem um novo método de autenticação baseado na biometria para ser tratado como uma maneira segura de bloquear a tela, o novo método:

• [C-4-1] PRECISA atender a todos os requisitos descritos na seção 7.3.10 para a Classe 1 (anteriormente Conveniência).
• [C-4-2] PRECISA ter um mecanismo de fallback para usar um dos métodos de autenticação principais recomendados, que é baseado em um secret conhecido.
• [C-4-3] PRECISA ser desativado e só permite que a autenticação principal recomendada desbloqueie a tela quando o aplicativo Device Policy Controller (DPC) tiver definido a política de recurso de proteção de teclado chamando o método DevicePolicyManager.setKeyguardDisabledFeatures() com qualquer uma das sinalizações 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 de Classe 3 (anteriormente Forte), conforme descrito na seção 7.3.10:

• [C-5-1] Os métodos PRECISAM ser desativados se o aplicativo Device Policy Controller (DPC) tiver definido a política de qualidade de requisitos de senha usando o DevicePolicyManager.setRequiredPasswordComplexity() com um bucket de complexidade mais restritivo que PASSWORD_COMPLEXITY_LOW ou usando o método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] O usuário PRECISA ser desafiado quanto à 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 PRECISAM 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] Elas PRECISAM ter um mecanismo de fallback para usar um dos métodos principais de autenticação recomendados, que é baseado em um secret conhecido e atender aos requisitos para serem tratados 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 principais recomendados para desbloquear a tela quando o aplicativo Device Policy Controller (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 que PASSWORD_COMPLEXITY_NONE.
• [C-6-3] O usuário PRECISA ser desafiado por um dos métodos de autenticação principais recomendados (por exemplo, PIN, padrão ou senha) pelo menos uma vez a cada quatro horas ou menos. Quando um token físico atende aos requisitos de implementações do TrustAgent em C-X, as restrições de tempo limite definidas em C-9-5 são aplicadas.
• [C-6-4] O novo método NÃO PODE ser tratado como uma tela de bloqueio segura e PRECISA seguir as restrições listadas em C-8 abaixo.

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

• [C-7-1] PRECISA ter uma indicação clara no menu de configurações e na tela de bloqueio quando o bloqueio do dispositivo é adiado ou quando pode ser desbloqueado por agentes de confiança. Por exemplo, o AOSP atende a esse requisito mostrando uma descrição de texto para "Bloquear configuração automaticamente" e "O botão liga/desliga é bloqueado instantaneamente" no menu de configurações e um ícone distinguível na tela de bloqueio.
• [C-7-2] PRECISA respeitar e implementar totalmente todas as APIs do agente de confiança na classe DevicePolicyManager, como a constante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NÃO PODE implementar completamente a função TrustAgentService.addEscrowToken() em um dispositivo usado como dispositivo pessoal principal (por exemplo, portátil), mas PODE implementar totalmente a função em implementações de dispositivo que normalmente são compartilhadas (por exemplo, Android Television ou Automotive).
• [C-7-4] PRECISA criptografar todos os tokens armazenados adicionados por TrustAgentService.addEscrowToken().
• [C-7-5] NÃO PODE armazenar a chave de criptografia ou o token de garantia no mesmo dispositivo em que a chave é usada. Por exemplo, uma chave armazenada em um smartphone pode desbloquear uma conta de usuário em uma TV. Para dispositivos automotivos, não é permitido armazenar o token de garantia em nenhuma parte do veículo.
• [C-7-6] PRECISA informar o usuário sobre as implicações de segurança antes de ativar o token de garantia para descriptografar o armazenamento de dados.
• [C-7-7] PRECISA ter um mecanismo de fallback para usar um dos métodos de autenticação principais recomendados.
• [C-7-8] O usuário PRECISA ser desafiado por um dos métodos principais de autenticação 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 preocupante.
• [C-7-9] O usuário PRECISA ser desafiado por um dos métodos principais de autenticação 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 preocupante.
• [C-7-10] NÃO PODE ser tratado como uma tela de bloqueio segura e PRECISA seguir as restrições listadas em C-8 abaixo.
• [C-7-11] NÃO PODE permitir que os TrustAgents em dispositivos pessoais principais (por exemplo, portáteis) desbloqueiem o dispositivo.Eles só podem ser usados para manter um dispositivo já desbloqueado no estado desbloqueado por até, no máximo, quatro horas. A implementação padrão do TrustManagerService no AOSP atende a esse requisito.
• [C-7-12] PRECISA usar um canal de comunicação criptograficamente seguro (por exemplo, UKEY2) para transmitir o token de garantia do dispositivo de armazenamento para o 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 seja segura, conforme descrito acima, e usarem um novo método de autenticação para desbloquear o bloqueio:

• [C-8-1] O novo método PRECISA ser desativado quando o aplicativo Device Policy Controller (DPC) tiver definido a política de qualidade de senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva que PASSWORD_QUALITY_NONE ou por DevicePolicyManager.setRequiredPasswordComplexity() com uma constante de complexidade mais restritiva que "PASSWORD_COMPLEXITY_NONE".
• [C-8-2] NÃO PODE 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 com o objetivo de mudar o estado de bloqueio.

Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e não ofereçam suporte a eventos de entrada associados, como via VirtualDeviceManager, elas:

• [C-9-1] PRECISA bloquear essas telas virtuais secundárias quando a tela padrão do dispositivo estiver bloqueada e desbloquear essas telas virtuais secundárias quando a tela padrão do dispositivo estiver desbloqueada.

Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e ofereçam suporte a eventos de entrada associados, como via VirtualDeviceManager, elas:

• [C-10-1] PRECISA oferecer suporte a estados de bloqueio separados por dispositivo virtual.
• [C-10-2] PRECISA desconectar todos os dispositivos virtuais após o tempo limite de inatividade
• [C-10-3] PRECISA ter um tempo limite de inatividade
• [C-10-4] PRECISA bloquear todas as telas quando o usuário iniciar um bloqueio total, inclusive com a funcionalidade de 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] PRECISA ter instâncias de dispositivos virtuais separadas por usuário.
• [C-10-6] PRECISA desativar a criação de eventos de entrada associados via VirtualDeviceManager quando indicado por DevicePolicyManager.setNearbyAppStreamingPolicy.
• [C-10-7] PRECISA 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] PRECISA desativar a interface de autenticação em dispositivos virtuais, incluindo a entrada do fator de conhecimento e a solicitação biométrica.
• [C-10-12] PRECISA restringir intents iniciadas em um dispositivo virtual para que sejam mostradas apenas no mesmo dispositivo virtual.
• [C-10-13] não pode usar um estado de bloqueio de dispositivo virtual como autorização de autenticação do usuário com o sistema Android Keystore. Consulte KeyGenParameterSpec.Builder.setUserAuthentication*.

Quando as implementações de dispositivos permitem que o usuário transfira o fator de conhecimento de autenticação principal de um dispositivo de origem para um dispositivo de destino, como na configuração inicial do dispositivo de destino, elas:

• [C-11-1] PRECISA criptografar o fator de conhecimento com garantias de proteção semelhantes às descritas no artigo de segurança Serviço do 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 ou usado remotamente para desbloquear qualquer dispositivo.
• [C-11-2] PRECISA, no dispositivo de origem , pedir ao usuário para confirmar o fator de conhecimento desse dispositivo antes de transferir o fator de conhecimento para o de destino.
• [C-11-3] PRECISA, em um dispositivo de destino sem um fator de conhecimento de autenticação principal definido, pedir ao usuário para confirmar um fator de conhecimento transferido no dispositivo de destino antes de definir esse fator de conhecimento como o principal fator de conhecimento de autenticação para o dispositivo de destino e antes de disponibilizar todos 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] PRECISA chamar grantTrust() com a sinalização somente quando estiver conectado a um dispositivo físico próximo com uma tela de bloqueio própria e quando o usuário autenticar a própria identidade nessa tela de bloqueio. Os dispositivos com proxy podem usar mecanismos de detecção no pulso ou no bolso após um desbloqueio único do usuário para atender ao requisito de autenticação do usuário.
• [C-12-2] PRECISA colocar a implementação do dispositivo no estado TrustState.TRUSTABLE quando a tela estiver desligada (por exemplo, ao pressionar um botão ou expirar o tempo limite da exibição) e o TrustAgent não revogar a confiança. O AOSP atende a esse requisito.
• [C-12-3] PRECISA mover o dispositivo apenas do estado TrustState.TRUSTABLE para o TrustState.TRUSTED se o TrustAgent ainda estiver concedendo confiança com base nos requisitos de C-12-1.
• [C-12-4] PRECISA chamar TrustManagerService.revokeTrust()
  • depois de no máximo 24 horas da concessão da confiança ou
  • Depois de um período 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 com o 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 soluções abaixo:
  • Implementações que usam UWB:
    • PRECISA atender aos requisitos de calibragem, certificação, precisão e conformidade da UWB descritos em 7.4.9.
    • PRECISA usar um dos modos de segurança do P-STS listados em 7.4.9.
  • Implementações usando a Rede de Reconhecimento de Vizinhança (NAN, na sigla em inglês) Wi-Fi:
    • PRECISA 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 mais recente) e seguir as etapas de configuração de medição especificadas em Calibragem de presença.
    • PRECISA usar o LTF seguro, conforme definido na IEEE 802.11az.

Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e ofereçam suporte a eventos de entrada associados, como via VirtualDeviceManager, e as telas não estiverem marcadas com VIRTUAL_DISPLAY_FLAG_SECURE, elas:

• [C-13-8] PRECISA bloquear atividades com o atributo android:canDisplayOnRemoteDevices ou os metadados android.activity.can_display_on_remote_devices definidos como falsos para que sejam iniciadas no dispositivo virtual.
• [C-13-9] É NECESSÁRIO bloquear atividades que não ativam explicitamente o streaming e que indicam que mostram conteúdo sensível, inclusive por SurfaceView#setSecure, FLAG_SECURE ou SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, da inicialização no dispositivo virtual.

Se as implementações do dispositivo oferecerem suporte a estados de energia de tela separados usando DeviceStateManager E, usando KeyguardDisplayManager, elas:

• [C-SR-2] É FORTEMENTE RECOMENDADO usar um requisito de atendimento de credencial definido na seção 9.11.1 ou uma biométrica que atenda a pelo menos especificações de Classe 1 definidas na seção 7.3.10 para permitir o desbloqueio independente da tela padrão do dispositivo.
• [C-SR-3] São RECOMENDADOS para restringir o desbloqueio separado da tela por um tempo limite de exibição definido.
• [C-SR-4] são FORTEMENTE RECOMENDADOS para permitir que o usuário bloqueie globalmente todas as telas por meio do bloqueio total no dispositivo portátil principal.

9.11.2. StrongBox

O sistema Android Keystore permite que os desenvolvedores de apps armazenem chaves criptográficas em um processador seguro dedicado, bem como no ambiente de execução isolado descrito acima. Esse processador seguro dedicado é chamado de "StrongBox". Os requisitos de C-1-3 a C-1-11 abaixo definem os requisitos que um dispositivo precisa atender para se qualificar como um StrongBox.

Implementações de dispositivos que têm um processador seguro dedicado:

• [C-SR-1] É RECOMENDADO A compatibilidade com o StrongBox. O StrongBox provavelmente se tornará um requisito em uma versão futura.

Se as implementações de dispositivos oferecerem suporte ao StrongBox, elas:

• [C-1-1] PRECISA declarar FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] PRECISA fornecer um hardware seguro dedicado que é usado para proteger o keystore e proteger a autenticação do usuário. O hardware seguro dedicado também pode ser usado para outros fins.

• [C-1-3] PRECISA ter uma CPU discreta que não compartilhe cache, DRAM, coprocessadores ou outros recursos principais com o processador do aplicativo (AP).

• [C-1-4] PRECISA garantir que qualquer periférico compartilhado com o AP não possa alterar o processamento do StrongBox nem receber informações do StrongBox. O AP PODE desativar ou bloquear o acesso ao StrongBox.

• [C-1-5] PRECISA ter um relógio interno com precisão razoável (+10%) imune a manipulação pelo AP.

• [C-1-6] PRECISA ter um gerador de número aleatório verdadeiro que produza uma saída imprevisível e distribuída de maneira uniforme.

• [C-1-7] PRECISA ter resistência a adulterações, incluindo contra penetração física e falhas.

• [C-1-8] PRECISA ter resistência de canal lateral, incluindo resistência contra vazamento de informações por meio de alimentação, tempo, radiação eletromagnética e canais laterais de radiação térmica.

• [C-1-9] PRECISA ter um armazenamento seguro que garanta confidencialidade, integridade, autenticidade, consistência e atualização do conteúdo. O armazenamento NÃO PODE ser lido ou modificado, exceto conforme permitido pelas APIs StrongBox.

• Para validar a conformidade com [C-1-3] a [C-1-9], as implementações de dispositivos:

  • [C-1-10] PRECISA incluir o hardware certificado 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 a Aplicação dos critérios comuns de potencial de ataque a smartcards (link em inglês).
  • [C-1-11] PRECISA incluir o firmware avaliado por um laboratório de testes credenciado nacionalmente que incorpore a avaliação de vulnerabilidade com potencial de alto ataque, de acordo com a Aplicação do Common Criteria do potencial de ataque a cartões inteligentes (em inglês).
  • [C-SR-2] É FORTEMENTE RECOMENDADO incluir o hardware que é avaliado usando uma meta de segurança, Avaliação de Garantia de Avaliação (EAL, na sigla em inglês) 5, aumentado por AVA_VAN.5. A certificação EAL 5 provavelmente se tornará um requisito em uma versão futura.
  • [C-SR-3] É FORTEMENTE RECOMENDADO para fornecer resistência a ataques de pessoas com informações privilegiadas (IAR, na sigla em inglês), o que significa que uma pessoa com acesso a chaves de assinatura do firmware não pode produzir firmware que faça com que o StrongBox vaze secrets, para contornar requisitos funcionais de segurança ou permitir o acesso a dados confidenciais do usuário. A maneira recomendada de implementar o IAR é permitir atualizações de firmware apenas quando a senha principal do usuário for fornecida pela HAL IAuthSecret.

9.11.3. Credencial de identidade

O sistema de credenciais de identidade é definido e alcançado implementando todas as APIs no pacote android.security.identity.*. Essas APIs permitem que os desenvolvedores de apps armazenem e recuperem documentos de identidade do usuário. Implementações de dispositivos:

• [C-SR-1] é MUITO RECOMENDADO 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] PRECISA implementar o sistema de credenciais de identidade (por exemplo, as APIs android.security.identity.*) com código que se comunica com um aplicativo confiável em uma área seguramente isolada do código em execução no kernel e em versões mais recentes. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o código do kernel ou do espaço do usuário possa acessar o estado interno do ambiente isolado, incluindo a 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 executadas inteiramente no app confiável, e o material da chave privada nunca PRECISA sair do ambiente de execução isolado, a menos que isso 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 das 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 inadequado ou comprometido.

O Android Open Source Project fornece uma implementação de referência de um aplicativo confiável (libeic) que pode ser usado para implementar o sistema de credenciais de identidade.

9,12 Exclusão de dados

Todas as implementações de dispositivos:

• [C-0-1] PRECISA fornecer aos usuários um mecanismo para realizar uma "redefinição para configuração original".
• [C-0-2] PRECISA excluir todos os dados do sistema de dados do usuário ao realizar uma "redefinição para configuração original".
• [C-0-3] PRECISA excluir os dados de modo que atendam aos padrões relevantes do setor, como o NIST SP800-88, ao realizar uma "Redefinir para configuração original".
• [C-0-4] PRECISA acionar o processo de "Redefinição para configuração original" acima quando a API DevicePolicyManager.wipeData() é chamada pelo app Device Policy Controller do usuário principal.
• PODE fornecer uma opção rápida de limpeza de dados que conduz apenas uma limpeza 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 apps pré-instalados do sistema podem ser executados e todos os apps de terceiros são desativados. Esse modo, conhecido como "modo de inicialização segura", oferece ao usuário a capacidade de desinstalar apps de terceiros potencialmente nocivos.

As implementações de dispositivos são:

• [C-SR-1] É MUITO RECOMENDADO a implementação do 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 uma opção para entrar no modo de inicialização segura de modo ininterrupto em apps de terceiros instalados no dispositivo, exceto quando o app de terceiros for um Controlador de políticas do dispositivo e tiver definido a flag UserManager.DISALLOW_SAFE_BOOT como verdadeira.

• [C-1-2] PRECISA oferecer ao usuário a capacidade de desinstalar apps de terceiros no modo de segurança.

• DEVE 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 de sistemas veiculares automotivos

Os dispositivos Android Automotive precisam trocar dados com subsistemas críticos do veículo usando a HAL do veículo para enviar e receber mensagens por redes de veículos, como o barramento CAN.

A troca de dados pode ser protegida implementando 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 da relação de faturamento fornecidos por uma operadora de celular usando o SubscriptionManager.setSubscriptionPlans().

Todas as implementações de dispositivos:

• [C-0-1] PRECISA retornar os planos de assinatura apenas para o app da operadora de celular que os forneceu originalmente.
• [C-0-2] NÃO PODE fazer backup nem upload remotamente de planos de assinatura.
• [C-0-3] PRECISA permitir apenas substituições, como SubscriptionManager.setSubscriptionOverrideCongested(), do app da operadora de celular que oferece planos de assinatura válidos.

9,16 Migração de dados do aplicativo

Se as implementações de dispositivos incluírem um recurso para migrar dados de um dispositivo para outro e não limitarem os dados do aplicativo copiados ao que é configurado pelo desenvolvedor do aplicativo no manifesto por meio do atributo android:fullBackupContent, elas:

• [C-1-1] NÃO PODE iniciar transferências de dados de app de dispositivos em que o usuário não tenha definido uma autenticação principal, conforme descrito em 9.11.1 Tela de bloqueio e autenticação seguras.
• [C-1-2] PRECISA 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 da transferência.
• [C-1-3] PRECISA usar o atestado de chaves de segurança para garantir que o dispositivo de origem e o de destino na migração sejam legítimos e tenham um carregador de inicialização bloqueado.
• [C-1-4] PRECISA migrar apenas os dados do aplicativo para o mesmo aplicativo no dispositivo de destino, com o mesmo nome de pacote E certificado de assinatura.
• [C-1-5] PRECISA mostrar uma indicação de que os dados do dispositivo de origem foram migrados por uma migração de dados entre dispositivos no menu de configurações. O usuário NÃO PODERÁ 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 PODE modificar o SELinux do Android e o modelo de permissão para o gerenciamento de máquinas virtuais protegidas.
• [C-1-3] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes no sistema/sepolicy fornecidas no Android Open Source Project (AOSP) upstream, e a política PRECISA ser compilada com todas as regras Nunca permitir presentes.
• [C-1-4] NÃO É POSSÍVEL permitir 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 PODE permitir que uma máquina virtual protegida execute um código que não faça parte da imagem de fábrica ou das atualizações dela. Tudo o que não for coberto pela Inicialização verificada do Android (por exemplo, arquivos transferidos da Internet ou transferidos) NÃO PODE ser executado 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] PRECISA executar todos os sistemas operacionais disponíveis no APEX de virtualização em uma máquina virtual protegida.
• [C-2-2] NÃO PODE permitir que uma máquina virtual protegida execute um sistema operacional que não esteja assinado pelo implementador do dispositivo ou pelo fornecedor do SO.
• [C-2-3] NÃO PODE permitir que uma máquina virtual protegida execute dados como código (por exemplo, SELinux nunca permitir execmem).
• [C-2-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes no system/sepolicy/microdroid fornecidos no Android Open Source Project (AOSP).
• [C-2-5] PRECISA implementar mecanismos de defesa em profundidade de máquinas virtuais protegidas (por exemplo, SELinux para pVMs), mesmo para sistemas operacionais não Microdroid.
• [C-2-6] PRECISA garantir que o firmware da pVM se recuse à inicialização se não conseguir verificar a imagem inicial.
• [C-2-7] PRECISA garantir que o firmware da pVM se recuse à inicialização se a integridade da 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 PODE permitir que uma 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] PRECISA excluir permanentemente uma página depois que ela for usada por uma VM e antes de ser retornada ao host (por exemplo, a pVM é destruída).
• [C-3-3] PRECISA garantir que o firmware da pVM seja carregado e executado antes de qualquer código em uma pVM.
• [C-3-4] PRECISA garantir que o BCC e os CDIs fornecidos para uma instância de pVM só possam ser derivados 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 PODE fornecer funcionalidade a uma pVM que permita ignorar o modelo de segurança do Android.

Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android:

• [C-5-1] PRECISA oferecer suporte à compilação isolada de uma atualização do tempo de execução do ART.

Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, para o gerenciamento de chaves:

• [C-6-1] PRECISA acessar a cadeia do DICE em um ponto que o usuário não possa modificar, mesmo em dispositivos desbloqueados. Para garantir que não seja falsificado.
• [C-6-2] PRECISA usar o DICE corretamente, ou seja, fornecer os valores corretos.

10. Teste de compatibilidade de software

As implementações de dispositivos PRECISAM ser aprovadas em todos os testes descritos nesta seção. No entanto, observe que nenhum pacote de teste de software é totalmente abrangente. Por esse motivo, os implementadores de dispositivos são altamente RECOMENDADOS para fazer o número mínimo de mudanças possível na referência e na implementação 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] PRECISA passar no conjunto de teste de compatibilidade (CTS) do Android, disponível no Android Open Source Project, usando o software de envio final no dispositivo.

• [C-0-2] PRECISA garantir a compatibilidade em casos de ambiguidade no CTS e para reimplementações 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á controlada independentemente dessa definição de compatibilidade, e várias revisões do CTS podem ser lançadas para o Android 13.

Implementações de dispositivos:

• [C-0-3] PRECISA passar pela versão mais recente do CTS no momento em que o software do dispositivo for concluído.

• DEVE usar a implementação de referência na árvore de código aberto do Android o máximo possível.

10,2 Verificador do CTS

O verificador do CTS está incluído no conjunto de teste de compatibilidade e se destina 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] PRECISA executar corretamente todos os casos aplicáveis no verificador do CTS.

O CTS Verifier tem testes para muitos tipos de hardware, incluindo alguns hardwares opcionais.

Implementações de dispositivos:

• [C-0-2] PRECISA passar em todos os testes de hardware que têm. Por exemplo, se um dispositivo tiver um acelerômetro, ele PRECISA executar corretamente o caso de teste do Acelerômetro no CTS Verifier.

Os casos de teste para recursos marcados 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 CTS Verifier, conforme mencionado acima. No entanto, como muitos builds são muito semelhantes, não é esperado que os implementadores de dispositivos executem explicitamente o CTS Verifier 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 incluídas, branding etc. 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 "em tempo real", ou seja, pode ser necessário reiniciar o dispositivo. Qualquer método pode ser usado, desde que possa substituir todo o software pré-instalado no dispositivo. Por exemplo, qualquer uma das abordagens a seguir atenderá a esse requisito:

  • Downloads "Over the Air (OTA)" com atualização off-line por reinicialização.
  • Atualizações "vinculadas" via USB de um PC host.
  • Atualizações "off-line" por meio de 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 às atualizações sem excluir permanentemente os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados particulares e os dados compartilhados do aplicativo. O software Android upstream inclui um mecanismo de atualização que atende a esse requisito.

• [C-0-3] Toda a atualização PRECISA ser assinada, e o mecanismo de atualização no dispositivo PRECISA verificar a atualização e a assinatura usando uma chave pública armazenada no dispositivo.

• [C-SR-1] O mecanismo de assinatura é FORTEMENTE RECOMENDADO para gerar hash da atualização com SHA-256 e validar o hash em relação à chave pública usando o ECDSA NIST P-256.

Se as implementações do dispositivo incluírem suporte a uma conexão de dados ilimitada, como 802.11 ou perfil Bluetooth PAN (rede de área pessoal), elas:

• [C-1-1] PRECISA oferecer suporte a downloads OTA com atualização off-line por reinicialização.

As implementações de dispositivos DEVEM verificar se a imagem do sistema é binária 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 DEVEM oferecer suporte às atualizações do sistema A/B. O AOSP implementa esse recurso usando a HAL de controle de inicialização.

Se um erro for encontrado em uma implementação de dispositivo após o lançamento, mas durante o ciclo de vida razoável do produto, que é determinado em consulta com a Equipe de Compatibilidade do Android para afetar a compatibilidade de apps de terceiros:

• [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 que acabamos de descrever.

O Android inclui recursos que permitem que o app Proprietário do dispositivo (se houver) 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

Veja a seguir um resumo das mudanças na definição de compatibilidade nesta versão:

4 de outubro de 2023

2. tipos de dispositivos

• 2.2.5. Modelo de segurança:

  Ver revisão

  • [9.8/H-1-14] PRECISA exibir o indicador de microfone, conforme descrito na seção 9.8.2 [9.8/C-3-1], quando um resultado de hotword bem-sucedido é transmitido para a voz.

• 2.2.7.1 Mídia:

  Ver revisão

  • [5.1/H-1-7] PRECISA 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 simultânea de transcodificação somente vídeo de 1080p a 720p usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo em 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] PRECISA 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 em hardware quando sob carga. O carregamento é definido como uma sessão simultânea de transcodificação somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware com a inicialização de reprodução de áudio e vídeo em 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] PRECISA ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de decodificação de áudio com taxa de bits de 128 kbps ou menor para todos os decodificadores de áudio quando estiver sob carga. O carregamento é definido como uma sessão simultânea de transcodificação de vídeo somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização de reprodução de áudio e vídeo de 1080p.

7.4. conectividade de dados

• 7.4.1.1. Compatibilidade com bloqueio de número:

  Ver revisão

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

• 7.4.1.2. API Telecom:

  Ver revisão

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

9.11. chaves e credenciais

• 9.11.2. StrongBox:

  Ver revisão

  é fornecida pela HAL IAuthSecret.

  A IAR vai se tornar um requisito OBRIGATÓRIO no Android 14.

26 de junho de 2023

2. tipos de dispositivos

• 2.2.1. Hardware

  • Remoção dos requisitos 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7

  • Outra atualização:

    Ver revisão

    É RECOMENDADO seguir as etapas de configuração da medição especificadas nos Requisitos da calibragem de presença.

• 2.5.1. Hardware

  Ver 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 muito grandes
    • 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 maior em telas pequenas/normais
    • hdpi ou maior em telas grandes
    • mdpi ou maior em telas muito grandes

  • [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 maior em telas grandes
    • tvdpi ou maior em telas muito grandes

  • [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 1.344 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 maior em telas muito grandes

3. software

• 3.2.3.5. Intents de aplicativos condicionais

  Ver 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

  Ver revisão

  Requisitos da calibragem de presença.

9. Compatibilidade do modelo de segurança

• 9.1 Permissões

  Ver revisão

  Implementações de dispositivos:

  • [C-0-5] NÃO PODE conceder permissões de execução a apps pré-instalados, a menos que:

    • 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,

    OR

    • As permissões de execução são concedidas pela política de concessão de permissão padrão ou por manter um papel de plataforma associadas a um padrão de intent em que o aplicativo pré-instalado é definido como gerenciador padrão.

• 9.11. chaves e credenciais

  • Remoção dos requisitos [C-13-10] e 9.11.4.

20 de março de 2023

2. tipos de dispositivos

• 2.2.3. software

  Ver revisão

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

  • A [C-17-13.2.3.1/ H-1-1] PRECISA ter uma atividade que processe a intent Settings#ACTION_CONFIG_EMBED_DEEP_LINK_ACTIVITY quando a funcionalidade dividida estiver ativada. A atividade PRECISA ser protegida por android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK e iniciar a atividade da intent analisada em Settings#EXTRA_CONFIG_EMBEDDED_DEEP_LINK_INTENT_URI.

  Encerrar novos requisitos

• 2.3.2. multimídia

  Ver revisão

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

  • [5.3.7/T-2-1SR1] É RECOMENDADO para 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

  Ver revisão

  Implementações de dispositivos automotivos:

  • [7.3/A-0-1SR1] PODE identificar a localização ao combinar GPS/GNSS com sensores adicionais. Se o Location for registrado, é MUITO RECOMENDADO implementar e informar os tipos de Sensor correspondentes e/ou IDs de propriedade do veículo usados.

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

3. software

• 3,18. Contatos

  Ver revisão

  Conta padrão para novos contatos:o Provedor de contatos fornece 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 para seleção de conta e salvar a configuração no Provedor de contatos quando uma conta for selecionada.

  • [C-2-2] PRECISA 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.

  Encerrar novos requisitos

• 3.2.3.5. Intents de aplicativos condicionais

  Ver revisão

  [Movido para 2.2.3]

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

  • [C-17-1] PRECISA 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 iniciar a atividade da intent analisada em Settings#EXTRA_CONFIG_EMBEDDED_DEEP_LINK_INTENT_URI.

  Encerrar novos requisitos

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

• 6.1. Ferramentas para desenvolvedores

  Ver revisão

  • Monkey
    • [C-0-8] PRECISA incluir o framework Monkey e disponibilizá-lo para o uso pelos aplicativos.

7. Compatibilidade de hardware

• 7.3.13. IEEE 802.1.15.4 (UWB)

  Ver revisão

  [Migração para a versão 7.4.9]

  Se as implementações de dispositivos incluírem suporte a 802.1.15.4 e expõem a funcionalidade a um aplicativo de terceiros, elas:

  • [C-1-1] PRECISA implementar a API do Android correspondente no android.uwb.
  • [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.uwb.
  • [C-1-3] PRECISA oferecer suporte a todos os perfis UWB relevantes definidos na implementação do Android.
  • [C-1-4] PRECISA fornecer uma funcionalidade de usuário para permitir que ele ative/desative o estado de rádio UWB.
  • [C-1-5] PRECISA determinar que os apps que usam o recurso UWB mantenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICE).
  • [C-1-6] É FORTEMENTE RECOMENDADO para passar nos testes de conformidade e certificação relevantes definidos por organizações padrão, incluindo FIRA, CCC e CSA.

  Encerrar novos requisitos

• 7.4.1. Telefonia

  Ver revisão

  Se as implementações de dispositivos incluirem telefonia GSM ou CDMA, se as implementações do dispositivo forem relacionadas ao recurso android.hardware.telephony, faça o seguinte:

  • [C-6-1] SmsManager#sendTextMessage e 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 APIs SmsManager ao enviar e receber mensagens SMS e MMS. A implementação de referência do AOSP em pacotes/apps/mensagens atende a esse requisito.
  • [C-6-3] O aplicativo que responde a Intent#ACTION_DIAL PRECISA oferecer suporte à entrada de códigos arbitrários de discador 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 exibir a transcrição visual do correio de voz aos usuários se for compatível com transcrições visuais do correio de voz.
  • [C-6-5] PRECISA representar todas as SubscriptionInfo com UUIDs de grupo equivalentes como uma única assinatura em todas as affordances visíveis ao usuário que mostram e controlam as informações do chip. Exemplos de tais affordances incluem interfaces de configurações que correspondem a Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
  • [C-6-6] NÃO PODE mostrar ou permitir o controle de SubscriptionInfo com um UUID de grupo não nulo e bit oportunista em qualquer affordance visível ao usuário que permita a configuração ou o controle das configurações do chip.

  Se as implementações de dispositivo incluirem telefonia GSM ou CDMAinformar o recurso android.hardware.telephony e mostrarem uma barra de status do sistema, faça o seguinte:

  • [C-6-7-1] PRECISA selecionar uma assinatura ativa representativa para um determinado UUID de grupo para mostrar ao usuário em recursos que forneçam informações de status do chip. Exemplos de tais affordances incluem o ícone de sinal celular da barra de status ou o bloco de configurações rápidas.
  • [C-SR-1] É FORTEMENTE RECOMENDADO que a assinatura representativa seja escolhida como a assinatura de dados ativa, a menos que o dispositivo esteja em uma ligação em que é RECOMENDADO que a assinatura representativa seja a assinatura ativa.

  Se as implementações de dispositivos incluirem telefonia GSM ou CDMAinformar o recurso android.hardware.telephony, faça o seguinte:

  • [C-6-87] PRECISA ser capaz de abrir e utilizar 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 É POSSÍVEL aplicar nenhum dos seguintes comportamentos a apps de operadoras ativas (conforme designado por TelephonyManager#getCarrierServicePackageName) automaticamente ou sem confirmação explícita do usuário:
    • Revogar ou limitar o acesso à rede
    • Revogar permissões
    • Restringir a execução de apps em segundo ou primeiro plano além dos recursos de gerenciamento de energia atuais incluídos no AOSP
    • Desativar ou desinstalar o app

  Se as implementações de dispositivos incluirem telefonia GSM ou CDMA, informarem o recurso android.hardware.telephony e todas as assinaturas ativas e não oportunistas que compartilham um UUID de grupo forem desativadas, removidas fisicamente do dispositivo ou marcadas como oportunistas, o dispositivo:

  • [C-78-1] PRECISA desativar automaticamente todas as assinaturas oportunistas ativas restantes no mesmo grupo.

  Se as implementações de dispositivos incluírem a telefonia GSM, mas não a telefonia CDMA, elas:

  • [C-89-1] NÃO PODE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-89-2] PRECISA gerar uma IllegalArgumentException em tentativas de definir qualquer tipo de rede 3GPP2 em bitmasks de tipo de rede preferencial 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:

  • [C-1110-1] PRECISA declarar a flag de recurso android.hardware.telephony.euicc.mep.

• 7.4.9. UWB

  Ver 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 a 802.1.15.4 e exporem a funcionalidade a um aplicativo de terceiros, elas:

  • [C-1-1] PRECISA implementar a API do Android correspondente no android.uwb.
  • [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.uwb.
  • [C-1-3] PRECISA oferecer suporte a todos os perfis UWB relevantes definidos na implementação do Android.
  • [C-1-4] PRECISA fornecer uma funcionalidade de usuário para permitir que ele ative/desative o estado de rádio UWB.
  • [C-1-5] PRECISA determinar que os apps que usam o recurso UWB mantenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICE).
  • [C-SR-1] É FORTEMENTE RECOMENDADO a passar nos testes de conformidade e certificação relevantes definidos por organizações padrão, incluindo FIRA, CCC e CSA.
  • [C-1-16] PRECISA garantir que as medidas 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] PRECISA garantir que a média das medidas de distância a 1 m do dispositivo de referência esteja dentro de [0,75 m, 1,25 m], em que a distância das informações empíricas é medida a partir da borda superior do DUT com a face voltada para cima e inclinada em 45 graus.
  • [C-SR-2] É RECOMENDADO que você siga as etapas de configuração de medição especificadas nos Requisitos para a calibragem de presença.

  É MUITO RECOMENDADO seguir as etapas de configuração de medição especificadas nos Requisitos para a calibragem de presença.

  Encerrar novos requisitos

• 7.8.2.2. Portas de áudio digitais

  Ver revisão

  Para ser compatível com fones de ouvido e outros acessórios de áudio usando conectores USB-C e implementando (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 dispositivos

• 2.2.3 Software

  Ver revisão

  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] PRECISA apresentar uma confirmação ao usuário de que os dados foram copiados para a área de transferência (por exemplo, uma miniatura ou 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 os dispositivos.

3. software

• 3.2.3.5. Intents de aplicativos condicionais

  Ver revisão

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

  • [C-17-1] PRECISA ter uma atividade que processe a intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY quando o recurso de divisão estiver ativado. A atividade PRECISA ser protegida por android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK e iniciar a atividade da intent analisada em Settings#EXTRA_CONFIG_EMBEDDED_DEEP_LINK_INTENT_URI.

  Se as implementações de dispositivos oferecerem suporte à VoiceInteractionService e tiverem mais de um aplicativo instalado ao mesmo tempo usando essa API:

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

• 3.4.1 Compatibilidade do WebView

  Ver revisão

  • [C-1-4]PRECISA renderizar o conteúdo fornecido ou o conteúdo do URL remoto em um processo diferente do aplicativo que instancia o WebView. Especificamente, o processo de renderizador separado PRECISA ter privilégio mínimo, ser executado como um ID de usuário separado, não ter acesso ao diretório de dados do app nem acesso direto à rede e só ter acesso aos serviços mínimos exigidos do sistema pelo binder. A implementação do WebView do AOSP atende a esse requisito.

7. Compatibilidade de hardware

• 7.4.2 IEEE 802.11 (Wi-Fi)

  Ver revisão

  Se as implementações de dispositivos incluírem suporte ao modo de economia de energia Wi-Fi, conforme definido no padrão IEEE 802.11, elas:

  • [C-3-1] PRECISA DEVE desativar o modo de economia de energia Wi-Fi sempre que um app adquirir bloqueio WIFI_MODE_FULL_HIGH_PERF ou bloqueio WIFI_MODE_FULL_LOW_LATENCY usando WifiManager.createWifiLock() e WifiManager.WifiLock.acquire()

• 7.4.3 Bluetooth

  Ver revisão

  Se as implementações de dispositivos incluírem suporte ao Bluetooth de baixa energia (BLE), elas:

  • [C-3-5] PRECISA implementar um tempo limite de endereço particular solucionável (RPA, na sigla em inglês) de no máximo 15 minutos e alternar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo estiver usando ativamente o BLE para verificação ou publicidade. Para evitar ataques de temporização, os intervalos de tempo limite também PRECISAM ser aleatórios entre 5 e 15 minutos.

• 7.5.5 Orientação da câmera

  Ver revisão

  Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, tais câmeras:

  • [C-1-1] PRECISA estar orientada para que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é mantido na orientação paisagem, as câmeras PRECISAM capturar imagens na orientação paisagem. Isso se aplica a qualquer orientação natural do dispositivo, ou seja, aos dispositivos principais no modo paisagem e modo retrato.

  Os dispositivos que atenderem a todos os critérios a seguir estão isentos do requisito acima:

  • O dispositivo implementa telas de geometria variável, como telas dobráveis ou articuladas.
  • Quando o estado da dobra ou articulação do dispositivo muda, ele alterna entre a orientação retrato principal para paisagem principal (ou vice-versa).

  Encerrar novos requisitos

9. Compatibilidade do modelo de segurança

• 9.11 Chaves e credenciais

  Ver revisão

  Quando a implementação do dispositivo é compatível com uma tela de bloqueio segura, ela:

  • [C-1-6] PRECISA ser compatível com IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice versão 1 ou IKeyMintDevice versão 2.

• 9.17 Framework de virtualização do Android

  Ver 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 PODE modificar, omitir ou substituir as regras de nunca permitir presentes no sistema/sepolicy fornecidas no Android Open Source Project (AOSP) upstream, e a política PRECISA ser compilada com todas as regras Nunca permitir 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 PODE modificar, omitir ou substituir as regras de nunca permitir presentes no system/sepolicy/microdroid fornecidos no Android Open Source Project (AOSP).

  Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, para o gerenciamento de chaves:

  • [C-6-2] PRECISA usar o DICE corretamente, ou seja, fornecer os valores corretos. No entanto, talvez ela não precise desse nível de detalhes.

15 de agosto de 2022

2. tipos de dispositivos

• 2.2.1 Hardware: mudanças nos requisitos de hardware, da seguinte maneira.

  • Dispositivos de entrada:

    Ver revisão

    Implementações de dispositivos portáteis:

    • [7.2.3/H-0-5] PRECISA chamar OnBackInvokedCallback.onBackStarted() na janela em foco atual quando o gesto "Voltar" for iniciado ou o botão "Voltar" (KEYCODE_BACK) estiver pressionado para BAIXO.
    • [7.2.3/H-0-6] PRECISA chamar OnBackInvokedCallback.onBackInvoked() quando o gesto "Voltar" for confirmado ou o botão "Voltar" for liberado (UP).
    • [7.2.3/H-0-7] PRECISA chamar OnBackInvokedCallback.onBackCancelled() quando o gesto de volta não for confirmado ou o evento KEYCODE_BACK for cancelado.

    Encerrar novos requisitos

    Se os dispositivos oferecem suporte ao protocolo Wi-Fi Neighbor Awareness Networking (NAN) declarando PackageManager.FEATURE_WIFI_AWARE e Local Wi-Fi (Tempo de retorno do Wi-Fi — RTT) ao declarar PackageManager.FEATURE_WIFI_RTT:

    • [7.4.2.5/H-1-1] PRECISA informar o intervalo com precisão a +/-1 metro a 160 MHz/mHz de largura de banda a 160 MHz/mHz no 68o percentil (conforme calculado com a Função de distribuição cumulativa), +/-2 metros a 80 MHz de largura de banda de 80 MHz, no 68o percentil, +/-4 metros a 40 MHz/80.m a largura de banda em 160 MHz/80.

    • [7.4.2.5/H-SR] São RECOMENDADOS fortemente para informar o intervalo com precisão a +/-1 metro a +/-1 metro a 160 MHz de largura de banda de 160 MHz no 90o percentil (conforme calculado com a Função de distribuição cumulativa), +/-2 metros a largura de banda de 80 MHz no 90o percentil, +/-4 metros na largura de banda do 90o M/0, a 40 + m/0 m na largura de banda de

    É RECOMENDADO seguir as etapas de configuração da medição especificadas nos Requisitos para a calibragem de presença.

    Encerrar novos requisitos

  • Latência de áudio:

    Ver 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] PRECISA ter uma latência média contínua de ida e volta de 500 800 milissegundos ou menos de 5 medições, com um Desvio médio absoluto menor que 50 100 ms, nos seguintes caminhos de dados: "adaptador de retorno de alto-falante para mm" (se houver suporte a mm), 3. pelo menos um caminho compatível.

    • [5.6/H-1-1] PRECISA ter uma latência média do Toque a tom de 500 milissegundos ou menos em pelo menos cinco medições do alto-falante para o caminho de dados do microfone.

    Encerrar novos requisitos

  • Entradas táteis:

    Ver revisão

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

    • [7,10/H]* NÃO DEVE usar um atuador tátil (vibrador) de massa giratória excêntrica (ERM).
    • [7,10/H]* DEVE posicionar o posicionamento do 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 retorno tátil claro em android.view.HapticFeedbackConstants, ou seja, (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_START, KEY_PRESS, TEXT_HAND_VILEASE_MOV, KEY_PRESS, TEXT_HAND_VILE
    • [7.10/H]* DEVE implementar todas as constantes públicas para o retorno tátil claro em android.os.VibrationEffect, ou seja, (Efeito_TICK, NOAA_CLICK, Efeito_HEAVY_CLICK e efeito_DOUBLE_CLICK) e todas as constantes viáveis públicas PRIMITIVE_*PRIK2 , rápido do Android 10e rápido e1.chip.1{1 Algumas dessas primitivas, como LOW_TICK e SPIN, só serão viáveis se a vibração for compatível com frequências relativamente baixas.

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

    Encerrar novos requisitos

    • [7.10/H]* DEVE usar esses mapeamentos de constantes táteis vinculados.

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

    Encerrar novos requisitos

    • [7.10/H]* DEVE verificar os recursos de escalonabilidade de amplitude executando android.os.Vibrator.hasAmplitudeControl().

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

    • [7,10/H]* DEVE mover o atuador tátil no eixo X (esquerda-direita) na orientação de retrato.

    • [7.10/H]* DEVE verificar e atualizar, se necessário, a configuração substituta para primitivos não compatíveis, conforme descrito na orientação de implementação para constantes.

    • [7.10/H]* DEVE fornecer suporte substituto para reduzir o risco de falha, conforme descrito aqui.

• 2.2.3 Software:

  • Cotntrols de dispositivo trivial de autenticação:

    Ver revisão

    • [3.8.16/H-1-5] PRECISA oferecer ao usuário uma opção para desativar os controles de dispositivo autenticados designados pelo app para os controles registrados pelos apps de terceiros usando a ControlsProviderService e a API Control Control.isAuthRequired.

  • Notificações MediaStyle:

    Ver revisão

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

    • [3.8.3.1/H-1-SR] É RECOMENDADO muito fornecer uma funcionalidade do usuário(por exemplo, "seletor de saída") acessada na interface do sistema para que os usuários alternem entre as rotas de mídia disponíveis(por exemplo, dispositivos Bluetooth e rotas fornecidas para MediaRouter2Manager) quando um app posta uma notificação do MediaStyle com um token MediaSession.

• 2.2.4 Desempenho e energia: novo requisito para apps que executam serviços em primeiro plano.

  Ver revisão

  Implementações de dispositivos portáteis:

  • [8.5/H-0-1] PRECISA fornecer funcionalidade de usuário no menu "Configurações" com a capacidade de interromper um app que esteja executando um serviço em primeiro plano e mostrar todos os apps que têm serviços ativos em primeiro plano e a duração de cada um desses serviços desde o início, conforme descrito no documento do SDK.
    • Alguns apps podem estar isentos de serem interrompidos ou listados em uma funcionalidade do usuário, conforme descrito no documento do SDK.

  Encerrar novos requisitos

• 2.2.7.1 Mídia: atualizações na seção "Mídia de requisitos para dispositivos portáteis" da seguinte maneira:

  Ver 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] PRECISA anunciar o número máximo de sessões de decodificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codecs pelos métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-2] PRECISA oferecer suporte a seis instâncias de sessões de decodificador de vídeo de hardware (AVC, HEVC, VP9, AV1 ou mais recentes) em qualquer combinação de codecs executada simultaneamente com resolução de 1080p a 30 fps.
  • [5.1/H-1-3] PRECISA anunciar o número máximo de sessões do 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] PRECISA oferecer suporte a seis instâncias de sessões de codificador de vídeo em hardware (AVC, HEVC, VP9, AV1 ou mais recentes) em qualquer combinação de codecs executada simultaneamente com resolução de 1080p a 30 fps.
  • [5.1/H-1-5] PRECISA anunciar o número máximo de sessões de codificadores e decodificadores de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codecs por meio dos métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-6] PRECISA oferecer suporte a seis instâncias de codificadores de vídeo de hardware e sessões de codificadores de vídeo em hardware (AVC, HEVC, VP9, AV1 ou mais recentes) em qualquer combinação de codecs executada simultaneamente a uma resolução de 1080p a 30 fps.
  • [5.1/H-1-7] PRECISA 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 simultânea de transcodificação somente vídeo de 1080p a 720p usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo em 1080p.
  • [5.1/H-1-8] PRECISA ter uma latência de inicialização de codec de 30 ms ou menos para uma sessão de codificação de áudio com taxa de bits de 128 kbps ou menor para todos os codificadores de áudio quando estiver sob carga. O carregamento é definido como uma sessão simultânea de transcodificação de vídeo somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware junto com a inicialização de gravação de áudio e vídeo em 1080p.
  • [5.1/H-1-9] PRECISA oferecer suporte a duas instâncias de sessões de decodificador de vídeo em hardware seguro (AVC, HEVC, VP9, AV1 ou mais recente) em qualquer combinação de codecs executada simultaneamente com resolução de 1080p a 30 fps.
  • [5.1/H-1-10] PRECISA oferecer suporte a três instâncias de sessões de decodificador de vídeo de hardware não 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 codecs executada simultaneamente a uma resolução de 1080p a 30 fps.
  • [5.1/ H-1-11] PRECISA oferecer suporte a um decodificador seguro para cada decodificador de hardware AVC, HEVC, VP9 ou AV1 no dispositivo.
  • [5.1/H-1-12] PRECISA ter uma latência de inicialização do decodificador de vídeo de 40 ms ou menos.
  • [5.1/H-1-13] PRECISA ter uma latência de inicialização do decodificador de áudio de 30 ms ou menos.
  • [5.1/H-1-14] PRECISA ser compatível com o decodificador de hardware AV1 Main 10, Level 4.1.
  • [5.1/H-SR] É altamente recomendado para oferecer suporte a granulação para decodificador de hardware AV1.
  • [5.1/H-1-15] PRECISA ter pelo menos um decodificador de vídeo por hardware compatível com 4K60.
  • [5.1/H-1-16] PRECISA ter pelo menos um codificador de vídeo de hardware compatível com 4K60.
  • [5.3/H-1-1] NÃO PODE cair 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 a 60 fps sob carga. O carregamento é definido como uma sessão simultânea de transcodificação de vídeo somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware e uma reprodução de áudio AAC de 128 kbps.
  • [5.3/H-1-2] NÃO PODE cair mais de 1 frame em 10 segundos durante uma mudança de resolução do vídeo em uma sessão de vídeo de 60 QPS sob carga. O carregamento é definido como uma sessão simultânea de transcodificação somente de vídeo de 1080p a 720p usando codecs de vídeo de hardware e uma reprodução de áudio AAC de 128 kbps.
  • [5.6/H-1-1] PRECISA ter uma latência de toque para tom de 80 milissegundos ou menos usando o teste toque a tom do OboeTester ou o teste de toque do CTS Verifier.
  • [5.6/H-1-2] PRECISA ter uma latência de ida e volta de áudio de 80 milissegundos ou menos em pelo menos um caminho de dados compatível.
  • [5.6/H-1-3] PRECISA oferecer suporte a áudio de 24 bits ou mais para saída estéreo de mais de 3,5 mm de áudio, se presente, e por áudio USB, se compatível com 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, um AudioTrack Java precisa ser usado pelo app. Nas configurações de baixa latência e streaming, o coletor de saída 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.
  • [5.6/H-1-4] PRECISA oferecer suporte a dispositivos de áudio USB com mais de quatro canais. Essa opção é usada pelos controladores de DJ para a prévia de músicas.
  • [5.6/H-1-5] PRECISA oferecer suporte a dispositivos MIDI compatíveis com a classe e declarar a sinalização de recurso MIDI.
  • [5.7/H-1-2] PRECISA 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 subamostra	1 MiB
  Tamanho mínimo do buffer de criptografia genérico	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 QPS

  Encerrar novos requisitos

• 2.2.7.2 Câmera: atualizações nos requisitos da Media Performance Class Camera.

  Ver 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] PRECISA ter uma câmera traseira principal com resolução de pelo menos 12 megapixels e compatível com captura de vídeo a 4k a 30 fps. A câmera traseira principal é a traseira com o menor ID de câmera.
  • [7.5/H-1-2] PRECISA ter uma câmera frontal principal com resolução de pelo menos 5 megapixels e oferecer suporte a captura de vídeo a 1080p a 30 fps. A câmera frontal principal é a frontal com o menor ID de câmera.
  • [7.5/H-1-3] PRECISA oferecer suporte à propriedade android.info.supportedHardwareLevel como FULL ou melhor para as duas câmeras principais.
  • [7.5/H-1-4] PRECISA oferecer suporte a CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para as duas câmeras principais.
  • [7.5/H-1-5] PRECISA ter latência de captura JPEG da câmera2 inferior a 1.000 ms para resolução de 1080p, conforme medido pelo PerformanceTest da câmera CTS em condições de iluminação ITS (3.000K) para as duas câmeras principais.
  • [7.5/H-1-6] PRECISA ter a latência de inicialização da câmera2 (abrir a câmera para o primeiro frame de visualização) menor que 500 ms, conforme medido pelo PerformanceTest da câmera CTS em condições de iluminação ITS (3000K) para as duas câmeras principais.
  • [7.5/H-1-8] PRECISA 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] PRECISA ter uma câmera principal traseira compatível com 720p ou 1080p a 240 fps.
  • [7.5/H-1-10] PRECISA ter ZOOM_RATIO mínimo menor que 1,0 para as câmeras principais se houver uma câmera RGB ultra grande angular voltada para a mesma direção.
  • [7.5/H-1-11] PRECISA implementar streaming simultâneo front-back nas câmeras principais.
  • [7.5/H-1-12] PRECISA oferecer suporte a CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para a câmera frontal e a traseira principal.
  • [7.5/H-1-13] PRECISA 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] PRECISA oferecer suporte ao recurso STREAM_USE_CASE para a câmera frontal principal e a traseira principal.

  Encerrar novos requisitos

• 2.2.7.3 Hardware: atualizações nos requisitos da classe de desempenho de mídia para hardware.

  Ver 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] PRECISA ter uma resolução de tela de pelo menos 1080p.
  • [7.1.1.3/H-2-1] PRECISA ter uma densidade de tela de pelo menos 400 dpi.
  • [7.6.1/H-2-1] PRECISA ter pelo menos 8 GB de memória física.

  Encerrar novos requisitos

• 2.2.7.4 Desempenho: atualizações na classe de desempenho de mídia para desempenho.

  Ver 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] PRECISA garantir um desempenho de gravação sequencial de pelo menos 125 MB/s.
  • [8.2/H-1-2] PRECISA garantir um desempenho de gravação aleatória de pelo menos 10 MB/s.
  • [8.2/H-1-3] PRECISA garantir um desempenho de leitura sequencial de pelo menos 250 MB/s.
  • [8.2/H-1-4] PRECISA garantir um desempenho de leitura aleatória de pelo menos 40 MB/s.

  Encerrar novos requisitos

• 2.5.1 Hardware: atualizações nos requisitos do acelerômetro de três eixos e do giroscópio de três eixos, bem como dos requisitos da câmera para visão externa.

  Ver revisão

  Implementações de dispositivos automotivos:

  • [7.3.1/A-0-4] PRECISA estar em conformidade com o sistema de coordenadas do sensor de carros do Android.
  • [7.3/A-SR] São STRONGLY_RECOMMENDED para incluir um acelerômetro de três eixos e um giroscópio de três eixos.
  • [7.3/A-SR] São STRONGLY_RECOMMENDED para 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] PRECISA relatar eventos com até uma frequência de pelo menos 100 Hz.

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

  • [7.3.1/A-SR] É MUITO RECOMENDADO para 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] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
  • [7.3.1/A-1-4] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

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

  Encerrar novos requisitos

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

  • [7.3.4/A-SR] É FORTEMENTE RECOMENDADO para 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] PRECISA implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES.
  • [7.3.4/A-4-2] PRECISA 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] PRECISA relatar eventos com até uma frequência de pelo menos 1 Hz.
  • [7.3.4/A-SR] STRONGLY_RECOMMENDED para relatar eventos com uma frequência de pelo menos 10 Hz.
  • DEVE se referir ao norte verdadeiro.
  • DEVE estar disponível mesmo quando o veículo estiver parado.
  • DEVE ter uma resolução de pelo menos 1 grau.

  Encerrar novos requisitos

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

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

  • [7.5,5/A-SR] É RECOMENDADO PARA que a dimensão longa da câmera se alinhe ao horizonte.

  • DEVE 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 visualização externa e carregarem o serviço Exterior View System (EVS), para essa câmera, elas:

  • [7.5/A-2-1] NÃO PODE girar nem espelhar a visualização da câmera 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] PRECISA informar o flag de recurso android.hardware.camera.any.
  • [7.5/A-3-2] não PRECISA declarar a câmera como uma câmera do sistema.
  • PODE ser compatível com 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.

  Encerrar novos requisitos

• 2.5.5 Modelo de segurança: novos requisitos para permissões de câmera para dispositivos automotivos.

  Ver revisão

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

  • [9.8.2/A-2-1] PRECISA exibir o indicador da câmera quando um app estiver acessando dados da câmera em tempo real, mas não quando a câmera só estiver sendo acessada por apps que detêm as funções mencionadas na Seção 9.1 Permissões com o identificador CDD [C-3-X].

  • [9.8.2/A-2-2] não pode ocultar o indicador de câmera para apps do sistema que têm interfaces do usuário visíveis ou interação direta com o usuário.

  Encerrar novos requisitos

• 2.6.1 Requisitos do tablet — Hardware: atualização dos requisitos de tamanho de tela de tablets.

  Ver revisão

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

  • 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 de build: caracteres ASCII atualizados em getSerial().

  Ver 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 sobre os formatos desses valores a que as implementações de dispositivos PRECISAM estar em conformidade.

  Parâmetro	Detalhes
  getSerial() (em inglês)	PRECISA (ser ou retornar) um número de série do hardware, que PRECISA estar disponível e ser exclusivo em dispositivos com o mesmo MODEL e MANUFACTURER. 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 Intents de aplicativos condicionais: atualização dos requisitos de intents de aplicativos condicionais.

  Ver revisão

  Se as implementações do dispositivo incluírem uma tela grande (geralmente com largura e altura de exibição de 600 dp+) e oferecerem suporte à funcionalidade dividida, elas:

  • [C-17-1] PRECISA 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 iniciar a atividade da intent analisada em Settings#EXTRA_CONFIG_EMBEDDED_DEEP_LINK_INTENT_URI.

  Encerrar novos requisitos

• 3.5.1 Restrição de aplicativo: atualizações nas restrições de aplicativos.

  Ver revisão

  Se as implementações de dispositivos implementarem um mecanismo reservado para restringir apps (por exemplo, mudar ou restringir comportamentos da API descritos no SDK) e esse mecanismo for mais restrito do que o bucket restrito para apps em espera, elas:

  • [C-1-1] PRECISA permitir que o usuário confira a lista de apps restritos.
  • [C-1-2] PRECISA fornecer recursos ao usuário para ativar / desativar todas essas restrições reservadas em cada app.
  • [C-1-3] NÃO PRECISA aplicar essas restrições de propriedade automaticamente sem evidência de mau comportamento de integridade do sistema, mas PODE: aplicar as restrições a apps após detecção de mau comportamento de integridade do sistema, como wakelocks travados, serviços de longa duração e outros critérios. Os critérios PODEM ser determinados por implementadores de dispositivos, mas PRECISAM estar relacionados ao impacto do app na integridade do sistema. Outros critérios que não são puramente relacionados à integridade do sistema, como a falta de popularidade do app no mercado, NÃO PODEM ser usados como critérios.
  • [C-1-4] Não deve aplicar automaticamente essas restrições de propriedade a apps quando um usuário desativou essas restrições manualmente e PODE sugerir que o usuário aplique essas restrições reservadas.

  • [C-1-5] PRECISA informar os usuários se essas restrições de propriedade forem aplicadas automaticamente a um app. Essas informações PRECISAM ser fornecidas no período de 24 horas antes da aplicação dessas restrições proprietárias.

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

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

  • [C-1-8] PRECISA 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 em primeiro plano.

  • [C-1-9] PRECISA informar todos esses eventos de restrições de propriedade via UsageStats.

  • [C-1-10] PRECISA fornecer um documento ou site público e claro que descreva como as restrições reservadas são aplicadas. O documento ou site PRECISA estar disponível para links nos documentos do SDK do Android e incluir:

    • Condições de acionamento de restrições reservadas.
    • O que e como um app pode ser restrito.
    • Como um app pode ser isento dessas restrições.
    • Como um app pode solicitar isenção de restrições de propriedade se oferecer suporte a 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] estará isento.

  Encerrar novos requisitos

• 3.8.1 Tela de início (tela inicial): atualiza o suporte a monochrome/adaptive-icon.

  Ver revisão

  Se as implementações de dispositivos oferecerem suporte a ícones monocromáticos, esses ícones:

  • [C-6-1] PRECISA ser usada somente quando o usuário as ativar explicitamente (por exemplo, por meio do menu "Configurações" ou do menu de seleção de plano de fundo).

  Encerrar novos requisitos

• 3.8.2 Widgets: atualização para a presença de widgets de apps de terceiros na tela de início.

  Ver revisão

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

  • [C-1-2] PRECISA incluir suporte integrado para AppWidgets e expor funcionalidades da interface do usuário para adicionar, configurar, visualizar e remover AppWidgets diretamente na tela de início.

• 3.8.3.1 Apresentação de notificações: esclarece a definição de notificações de alerta.

  Ver revisão

  As notificações de alerta são apresentadas ao usuário à medida que chegam, independentemente da plataforma em que ele está.

• 3.8.3.3 Não perturbe (Não perturbe) / Modo de prioridade: atualize para incluir o modo de prioridade nos requisitos de Não perturbe.

  Ver revisão

  3.8.3.3. Não perturbe (Não perturbe) / Modo de prioridade

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

• 3.8.6 Temas: novos requisitos para paletas de tons de cores dinâmicas.

  Ver revisão

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

  • [C-1-4] PRECISA 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] PRECISA gerar paletas de tons de cores dinâmicas usando estilos de temas de cores enumerados na documentação do Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.theme_styles), ou seja, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW e FRUIT_SALAD.

    A "Cor de origem" é usada para gerar paletas tonais de cores dinâmicas quando enviada com android.theme.customization.system_palette, conforme documentado em Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES.

  • [C-1-6] PRECISA ter um valor de chroma CAM16 de 5 ou maior.

    • DEVE ser derivada do plano de fundo via 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.

  Encerrar novos requisitos

• 3.8.17 Copiar: adicionamos uma nova seção de requisitos para conteúdo na área de transferência.

  Ver revisão

  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 qualquer componente, atividade, serviço ou por qualquer conexão de rede, sem 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 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 de qualquer item ClipData em que ClipData.getDescription().getExtras() contenha android.content.extra.IS_SENSITIVE, elas:

  • [C-1-1] PRECISA encobrir 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.

  Encerrar novos requisitos

• 3.9.1.1 Provisionamento do proprietário do dispositivo: atualizações nos requisitos de provisionamento do proprietário do dispositivo.

  Ver revisão

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

  • [C-1-1] PRECISA ser compatível com a inscrição de um cliente Device Policy (DPC) como um app proprietário do dispositivo, conforme descrito abaixo:
    • Quando a implementação do dispositivo não tem usuários nem dados do usuário configurados, ela:
      • [C-1-5] PRECISA registrar o aplicativo DPC como proprietário do dispositivo ou permitir que o app DPC escolha se quer se tornar proprietário do dispositivo ou proprietário do perfil se o dispositivo declarar suporte a comunicações a curta distância (NFC,na sigla em inglês) usando a flag de recurso android.hardware.nfc e receber uma mensagem NFC contendo um registro com o tipo MIME MIME_TYPE_PROVISIONING_NFC.
      • [C-1-8] PRECISA enviar a intent ACTION_GET_PROVISIONING_MODE após o provisionamento do proprietário do dispositivo ser acionado para que o app DPC possa escolher se vai se tornar proprietário do dispositivo ou do perfil, dependendo dos valores de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, a menos que possa ser determinado com base no contexto de que há apenas uma opção válida. (como para provisionamento baseado em NFC, quando o provisionamento do proprietário do perfil não é compatível).
      • [C-1-9] PRECISA enviar a intent ACTION_ADMIN_POLICY_COMPLIANCE ao app Proprietário do dispositivo se esse proprietário for estabelecido durante o provisionamento, independente do método de provisionamento usado. O usuário não pode continuar no assistente de configuração até que o app Proprietário do dispositivo seja concluído.
    • Quando a implementação do dispositivo tem usuários ou dados do usuário, ela:
      • [C-1-7] NÃO PODE mais registrar nenhum aplicativo DPC como o app Proprietário do dispositivo.
  • [C-1-2] PRECISA mostrar um aviso de divulgação adequado (conforme mencionado no AOSP) e receber o consentimento afirmativo do usuário final antes de um app ser definido como proprietário do dispositivo, a menos que o dispositivo esteja configurado programaticamente para o modo de demonstração no varejo antes da interação do usuário final na tela. exigir alguma ação afirmativa antes ou durante o processo de provisionamento do app para ser definido como proprietário do dispositivo. O consentimento pode ser por ação do usuário ou por algum meio programático, mas o aviso de divulgação apropriado (conforme mencionado no AOSP) PRECISA ser mostrado antes que o provisionamento do proprietário do dispositivo seja iniciado. Além disso, o mecanismo de consentimento programático do proprietário do dispositivo usado (pelas empresas) para provisionamento do proprietário do dispositivo NÃO PODE interferir na experiência pronta para uso para uso não empresarial.
  • [C-1-3] NÃO PODE codificar o consentimento nem impedir o uso de outros apps do proprietário do dispositivo.

  Se as implementações de dispositivos declararem android.software.device_admin, mas também incluirem uma solução reservada de gerenciamento de dispositivos Proprietário do dispositivo e fornecerem um mecanismo para promover um aplicativo configurado na solução como "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] PRECISA ter um processo 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 a um "Proprietário do dispositivo".
  • [C-2-2] PRECISA mostrar a mesma declaração de consentimento do proprietário do dispositivo AOSP que o fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o app DPC como "Proprietário do dispositivo".
  • [C-2-3] NÃO PODE codificar o consentimento nem impedir o uso de outros apps do proprietário do dispositivo.
  • PODEM ter dados do usuário no dispositivo antes de registrar o aplicativo DPC como "Proprietário do dispositivo".

• 3.9.4 Requisitos do papel "Gerenciamento de dispositivos": adição de uma seção para os requisitos do papel "Gerenciamento de dispositivos".

  Ver revisão

  3.9.4 Requisitos do papel de gerenciamento de políticas do dispositivo

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

  • [C-1-1] PRECISA oferecer suporte ao papel de gerenciamento de políticas do dispositivo, conforme definido na seção 9.1. O aplicativo que detém 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 pelo certificado de assinatura, a menos que o aplicativo seja pré-carregado.

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

  • [C-2-1] As implementações de dispositivos PRECISAM oferecer suporte ao provisionamento sem um aplicativo detentor da função de gerenciamento de políticas do dispositivo (o AOSP fornece 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 estar instalado em todos os perfis de um usuário.
  • [C-3-2] As implementações de dispositivos podem definir um aplicativo que atualiza o detentor 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.

  Encerrar novos requisitos

• 3.18 Contatos: como adicionar informações a novos contatos.

  Ver revisão

  Conta padrão para novos contatos:o Provedor de contatos fornece 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 para seleção de conta e salvar a configuração no Provedor de contatos quando uma conta for selecionada.

  • [C-2-2] PRECISA 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.

  Encerrar novos requisitos

4. Compatibilidade com empacotamento de aplicativos

• 4. Compatibilidade com empacotamento de aplicativos: atualizações na versão do esquema de assinatura do APK.

  Ver revisão

  Implementações de dispositivos:

  • [C-0-2] PRECISA oferecer suporte à verificação de arquivos ".apk" usando o Esquema de assinatura de APK v3.1 , o Esquema de assinatura de APK v3, o Esquema de assinatura de APK v2 e a 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 multimídia

• 5.1.2 Decodificação de áudio: adicionamos novos requisitos para decodificadores capazes de produzir áudio com vários canais.

  Ver revisão

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

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

  Se as implementações de dispositivos oferecerem suporte a decodificadores de áudio diferentes do decodificador de áudio AAC padrão e puderem gerar áudio multicanal (ou seja, mais de dois canais) quando forem alimentados com conteúdo multicanal compactado:

  • [C-SR] O decodificador é FORTEMENTE RECOMENDADO para 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 (ao usar um valor de 2) ou se é saída 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 produzir seis canais quando alimentado com conteúdo 5.1.
  • [C-SR] Ao decodificar, o decodificador é FORTEMENTE RECOMENDADO para anunciar a máscara do canal que está sendo usada no formato de saída com a chave KEY_CHANNEL_MASK, usando as constantes android.media.AudioFormat (exemplo: CHANNEL_OUT_5POINT1).

  Encerrar novos requisitos

• 5.4.1 Captura de áudio bruto e informações de microfone: atualizações nas fontes de áudio com suporte para streams de entrada de áudio.

  Ver revisão

  Se as implementações de 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 stream de ENTRADA AudioRecord ou AAudio aberto. No mínimo, as seguintes características PRECISAM ser aceitas:

    • Formato:PCM linear de 16 bits
    • Taxas de amostragem:8000, 11025, 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] PRECISA respeitar a API MicrophoneInfo e preencher corretamente as informações dos microfones disponíveis no dispositivo que podem ser acessados por apps 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 estão acessíveis aos aplicativos de terceiros pelas APIs AudioRecord.getActiveMicrophones() e MediaRecorder.getActiveMicrophones().

• 5.4.2 Captura para reconhecimento de voz: requisitos atualizados para stream de áudio de reconhecimento de voz e requisitos adicionais para níveis de ganho do microfone.

  Ver revisão

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

  • DEVE gravar o stream de áudio de reconhecimento de voz com amplitude aproximadamente plana em relação a 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 para que uma fonte de nível de potência do som (SPL, na sigla em inglês) de 90 dB a 1.000 Hz gere RMS de 2.500 para amostras de 16 bits.

  • DEVE exibir características de amplitude em relação à frequência aproximadamente planas no intervalo de frequência média: especificamente ±3 dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • [C-SR] é MUITO RECOMENDADO para exibir níveis de amplitude na faixa de frequência baixa: especificamente de ±20 dB de 30 Hz a 100 Hz, em comparação com o intervalo de média-frequência de cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • [C-SR] é MUITO RECOMENDADO para exibir 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 de cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • DEVE configurar a sensibilidade da entrada de áudio de modo que uma fonte de tom sinusoidal de 1.000 Hz seja reproduzida a 90 dB com Nível de pressão sonora (SPL, na sigla em inglês) (medido ao lado do microfone) para gerar uma resposta ideal de RMS 2500 em um intervalo de 1770 e 3530 para cada amostra flutuante de precisão de 16 bits/3530 para cada

  Encerrar novos requisitos

• 5.4.6 Níveis de ganho do microfone: os requisitos dos níveis de ganho do microfone foram movidos para a seção 5.4.2.

  Ver revisão

  5.4.6. Níveis de ganho do microfone [migrado para 5.4.2]

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

  • DEVE apresentar características de amplitude em relação à frequência aproximadamente plana no intervalo de frequência média: especificamente ±3 dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • [C-SR] é MUITO RECOMENDADO para exibir níveis de amplitude na faixa 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 de cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • [C-SR] é MUITO RECOMENDADO para exibir níveis de amplitude na faixa de alta frequência: especificamente de ±30 dB de 4.000 Hz a 22 KHz, em comparação com a faixa média de frequência de cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
  • DEVE definir a sensibilidade da entrada de áudio de modo que uma fonte de tons senoidal de 1.000 Hz, reproduzida a 90 dB com o Nível de pressão sonora (SPL, na sigla em inglês), gere uma resposta com RMS de 2.500 para amostras de 16 bits (ou escala completa de -22,35 dB para a fonte de ponto flutuante/amostra de precisão dupla de reconhecimento de áudio usada para gravar o microfone de ponto flutuante/precisão dupla).

• 5.5.4 Descarregamento de áudio: atualizações nos requisitos de reprodução de descarregamento de áudio.

  Ver revisão

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

  • [C-SR] É ALTAMENTE RECOMENDADO para cortar o conteúdo de áudio reproduzido entre dois clipes com o mesmo formato quando especificado pela API sem lacunas do AudioTrack e pelo contêiner de mídia do MediaPlayer.

• 5.6 Latência de áudio: atualizações nos requisitos de latência de áudio.

  Ver revisão

  Para os fins desta seção, use as seguintes definições:

  • instabilidade na saída a frio. A variabilidade entre medições separadas de valores de latência de saída de frio.
  • instabilidade de entrada a frio. A variabilidade entre medições separadas de valores de latência de entrada a frio.

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

  • [C-1-2] Latência de saída de frio de 500 milissegundos ou menos.
  • [C-1-3] A abertura de um stream de saída usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

  Se as implementações de dispositivos declararem android.hardware.audio.output, elas serão altamente RECOMENDADAS a atender ou exceder os seguintes requisitos:

  • [C-SR] Latência de saída fria de 100 milissegundos ou menos no caminho de dados do alto-falante. Os dispositivos novos e atuais que executam essa versão do Android são MUITO RECOMENDADOS para atender a esses requisitos agora. Em uma versão futura da plataforma, exigiremos uma latência de saída fria de 200 ms ou menos.
  • [C-SR] Minimizar a instabilidade da saída a frio.

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

  • [C-3-2] Latência de entrada de frio de 500 milissegundos ou menos.
  • [C-3-3] A abertura de um stream de entrada usando AAudioStreamBuilder_openStream() PRECISA levar menos de 1.000 milissegundos.

  Se as implementações de dispositivos incluírem android.hardware.microphone, elas serão altamente RECOMENDADAS para atender a estes requisitos de áudio de entrada:

  • [C-SR] Latência de entrada a frio de 100 milissegundos ou menos no caminho de dados do microfone. Dispositivos novos e existentes que executam essa versão do Android são MUITO RECOMENDADOS a atender a esses requisitos agora. Em uma versão futura da plataforma, vamos exigir uma latência de entrada fria de 200 ms ou menos como OBRIGATÓRIO.

  • [C-SR] Latência de entrada contínua de 30 milissegundos ou menos.
  • [C-SR] Minimize a instabilidade da entrada a frio.

• 5.10 Áudio profissional: atualizações nos requisitos de latência de áudio para suporte profissional a áudio.

  Ver revisão

  Se as implementações do dispositivo relatarem suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager, elas:

  • [C-1-2] PRECISA ter 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 ter 10 milissegundos ou menos em pelo menos um caminho compatível.
  • [C-1-5] PRECISA atender aos requisitos de latência e áudio USB usando a API de áudio nativo da AAudio e AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
  • [C-1-8] PRECISA ter uma latência média do Toque para o tom de 80 milissegundos ou menos em pelo menos cinco medições do alto-falante para o caminho de dados do microfone.
  • [C-SR] É MUITO RECOMENDADO para fornecer um nível consistente de desempenho da CPU enquanto o áudio está ativo e a carga da CPU varia. Isso precisa ser testado usando o app Android SynthMark. O SynthMark usa um sintetizador de software em execução em um framework de áudio simulado que mede o desempenho do sistema. Consulte a documentação do SynthMark para uma explicação sobre as comparações. É necessário executar o app SynthMark
  • DEVE ter uma latência da entrada por toque para a saída de áudio menor ou igual a 40 ms.

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

  • [C-2-1] PRECISA ter uma latência de áudio contínua média de ida e volta, conforme definido na seção 5.6 Latência de áudio, de 20 milissegundos ou menos, acima de cinco medições com desvio absoluto médio inferior a cinco milissegundos no caminho da entrada de áudio usando um dongle de loopback de áudio.

• Vídeo em HDR 5.12: adicionamos uma nova seção para requisitos de vídeo HDR.

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

• 6.1 Ferramentas para desenvolvedores: atualizações dos requisitos de conectividade e do kernel da GPU.

  Ver revisão

  Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi ou Ethernet, elas:

  • [C-4-1] PRECISA que o método AdbManager#isAdbWifiSupported() retorne true.

  Se as implementações do dispositivo oferecerem suporte a conexões adb a uma máquina host por Wi-Fi ou Ethernet e incluirem pelo menos uma câmera, elas:

  • [C-5-1] PRECISA que o método AdbManager#isAdbWifiQrSupported() retorne true.

  • Informações de trabalho da GPU

    Implementações de dispositivos:

    • [C-6-1] PRECISA implementar o comando de shell dumpsys gpu --gpuwork para exibir os dados de trabalho agregados da GPU retornados pelo tracepoint do kernel power/gpu_work_period ou não exibir dados se o tracepoint não tiver suporte. A implementação do AOSP é frameworks/native/services/gpuservice/gpuwork/.

  Encerrar novos requisitos

7. Compatibilidade de hardware

• 7.1.4.1 OpenGL ES: atualização para extensões recomendadas.

  Ver revisão

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

  • DEVE oferecer suporte às extensões EGL_IMG_context_priority e EGL_EXT_protected_content.

  Encerrar novos requisitos

• 7.1.4.2 Vulkan: atualizações da versão com suporte ao Vulkan.

  Ver revisão

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

  • [SR] É FORTEMENTE RECOMENDADO a inclusão de suporte para o Vulkan 1.3. Vulkan 1.1 (link em inglês)
  • NÃO É POSSÍVEL ser compatível com uma versão de variante do Vulkan, ou seja, a parte da variante da versão principal do Vulkan PRECISA ser zero.

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

  • [SR] É FORTEMENTE RECOMENDADO a inclusão de suporte para o Vulkan 1.3. Vulkan 1.1 (link em inglês)

  Se as implementações de dispositivos incluírem 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 PODE enumerar o suporte para a extensão VK_KHR_performance_query.
  • [C-SR] São RECOMENDADOS PARA atender aos requisitos especificados pelo perfil de referência do Android 2021.

• 7.2.3 Teclas de navegação:

  Ver revisão

  Implementações de dispositivos:

  • [C-SR] É MUITO RECOMENDADO que todas as funções de navegação sejam canceláveis. "Cancelável" é definido como a capacidade do usuário de impedir a execução da função de navegação (por exemplo, ir para a página inicial, voltar etc.) se o deslizamento não for liberado além de um determinado limite.

  Encerrar novos requisitos

  Se a função de navegação de retorno for fornecida e o usuário cancelar o gesto de Voltar:

  • [C-8-1] OnBackInvokedCallback.onBackCancelled() PRECISA ser chamado.
  • [C-8-2] O OnBackInvokedCallback.onBackInvoked() NÃO PODE ser chamado.
  • [C-8-3] O evento KEYCODE_BACK NÃO PODE 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, então:

  • O sistema PRECISA fornecer uma animação para o aplicativo em primeiro plano que sugira que o usuário está voltando, conforme fornecido no AOSP.

  Se as implementações do dispositivo oferecerem suporte à API do sistema setNavBarMode para permitir que qualquer app do sistema com a permissão android.permission.STATUS_BAR defina o modo da barra de navegação, elas:

  • [C-9-1] PRECISA oferecer suporte a ícones para crianças ou à navegação baseada em botões, conforme fornecido no código AOSP.

  Encerrar novos requisitos

• 7.3.1 Acelerômetro: atualizações nos requisitos de sensores para acelerômetros.

  Ver revisão

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

  • [C-1-2] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER.
  • [SR] é MUITO RECOMENDADO para implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
  • [SR] é MUITO RECOMENDADO para implementar e informar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. Os dispositivos Android são MUITO RECOMENDADOS a atender a esse requisito para que possam fazer upgrade para a versão futura da plataforma, em que isso pode se tornar OBRIGATÓRIO.
  • DEVE implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER, conforme descrito no documento do SDK do Android.

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

  • [C-2-1] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER.
  • [C-SR] É FORTEMENTE RECOMENDADO a implementação do sensor composto TYPE_SIGNIFICANT_MOTION.
  • [C-SR] É FORTEMENTE RECOMENDADO implementar e informar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. Os dispositivos Android são MUITO RECOMENDADOS para atender a esse requisito para que possam fazer upgrade para a versão futura da plataforma, em que isso pode se tornar OBRIGATÓRIO.
  • É NECESSÁRIO implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER, conforme descrito no documento do SDK do Android.

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

  • [C-3-1] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES.
  • [C-SR] São STRONGLY_RECOMMENDED para implementar e informar o sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

  Encerrar 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 de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, elas:

  • [C-5-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.

  Se as implementações de dispositivos incluírem um acelerômetro de três eixos, um sensor de giroscópio de três eixos e um sensor 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.

  Ver revisão

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

  • [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
  • [C-1-4] PRECISA ter uma resolução de 12 bits ou mais.
  • [C-1-5] PRECISA ser compensado pela temperatura.
  • [C-1-6] PRECISA 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 superior a 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar de acordo com a taxa de amostragem, mas PRECISA ser restrita por esse valor. Em outras palavras, se você medir a variância do giroscópio na taxa de amostragem de 1 Hz, ela DEVE ser menor que 1e-7 rad^2/s^2.
  • [C-SR] O erro de calibração é FORTEMENTE RECOMENDADO ser menor que 0,01 rad/s quando o dispositivo está parado na temperatura ambiente.
  • [C-SR] É MUITO RECOMENDADO ter uma resolução de 16 bits ou mais.
  • DEVE relatar eventos de até pelo menos 200 Hz.

  Encerrar novos requisitos

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

  • [C-2-1] PRECISA implementar o sensor TYPE_GYROSCOPE.

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

  • [C-3-1] PRECISA implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES.
  • [C-SR] São STRONGLY_RECOMMENDED para implementar e informar o sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

  Encerrar novos requisitos

  Se as implementações de dispositivos incluírem um giroscópio de três eixos, um sensor de acelerômetro e um sensor de magnetômetro, elas:

  • [C-4-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

  Se as implementações de dispositivos incluírem um acelerômetro de três eixos e um sensor de giroscópio de três eixos, elas:

  • [C-5-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.

• 7.3.10 Sensores biométricos (link em inglês): atualizações nos requisitos dos sensores biométricos.

  Ver revisão

  Os sensores biométricos podem ser classificados como Classe 3 (anteriormente Forte), Classe 2 (anteriormente Fraco) ou Classe 1 (anteriormente Conveniência) com base nas taxas de aceitação de spoofing e impostores e na segurança do pipeline biométrico. Essa classificação determina os recursos que o sensor biométrico tem para interagir com a plataforma e com aplicativos de terceiros. Os sensores precisarão 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. As biometrias de Classe 2 e Classe 3 têm recursos adicionais, conforme detalhado abaixo.

  Se as implementações de dispositivos quiserem tratar um sensor biométrico como Class 1 (anteriormente Convenience), elas:

  • [C-1-11] PRECISA ter uma taxa de aceitação de spoofing e impostor não superior a 30%, com (1) uma taxa de aceitação de impostor e de spoofing para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) de nível A não superior a 30% e (2) uma taxa de aceitação de impostor e de impostor de espécies PAI de nível B medidas não superior a 40%.

  Encerrar novos requisitos

  Se as implementações de dispositivos quiserem tratar um sensor biométrico como Class 2 (anteriormente fraco), elas:

  • [C-2-2] PRECISA ter uma taxa de aceitação de impostor e de impostor não superior a 20%, com (1) uma taxa de aceitação de impostor e de spoofing para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) nível A não superior a 20% e (2) uma taxa de aceitação de impostor e de spoofing de espécies PAI de nível B não superior a 30%.

  Se as implementações de dispositivo quiserem tratar um sensor biométrico como Class 3 (anteriormente Strong), elas:

  • [C-3-3] PRECISA ter uma taxa de aceitação de spoof e impostor de até 7%, com (1) uma taxa de aceitação de impostor e de spoofing para espécies de instrumento de ataque de apresentação (PAI, na sigla em inglês) nível A não superior a 7% e (2) uma taxa de aceitação de impostor e spoofing de espécies PAI de nível B do Protocolo B não superior a 20%, conforme medido pelo Android Biometrics.

• 7.3.13 IEEE 802.1.15.4 (UWB): foi adicionada uma nova seção de requisitos para UWB.

  Ver revisão

  7.3.13. IEEE 802.1.15.4 (UWB)

  Se as implementações de dispositivos incluírem suporte a 802.1.15.4 e expõem a funcionalidade a um aplicativo de terceiros, elas:

  • [C-1-1] PRECISA implementar a API do Android correspondente no android.uwb.
  • [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.uwb.
  • [C-1-3] PRECISA oferecer suporte a todos os perfis UWB relevantes definidos na implementação do Android.
  • [C-1-4] PRECISA fornecer uma funcionalidade de usuário para permitir que ele ative/desative o estado de rádio UWB.
  • [C-1-5] PRECISA determinar que os apps que usam o recurso UWB mantenham a permissão UWB_RANGING (no grupo de permissões NEARBY_DEVICE).
  • [C-1-6] É FORTEMENTE RECOMENDADO para passar nos testes de conformidade e certificação relevantes definidos por organizações padrão, incluindo FIRA, CCC e CSA.

  Encerrar novos requisitos

• 7.4.1 Telefonia: atualizações dos requisitos de telefonia para telefonia GSM e CDMA e configurações de uso da rede celular.

  Ver revisão

  Se as implementações de dispositivos oferecerem suporte a eUICCs ou eSIMs/chips incorporados e incluírem um mecanismo próprio para disponibilizar a funcionalidade de eSIM para desenvolvedores terceiros, elas:

  • [C-3-1] PRECISA declarar a flag de recurso android.hardware.telephony.euicc. fornecer uma implementação completa do EuiccManager API.

  Se as implementações de dispositivos incluírem telefonia GSM ou CDMA:

  • [C-6-1] SmsManager#sendTextMessage e 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 APIs SmsManager ao enviar e receber mensagens SMS e MMS. A implementação de referência do AOSP em pacotes/apps/mensagens atende a esse requisito.
  • [C-6-3] O aplicativo que responde a Intent#ACTION_DIAL PRECISA oferecer suporte à entrada de códigos arbitrários de discador 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 exibir a transcrição visual do correio de voz aos usuários se for compatível com transcrições visuais do correio de voz.
  • [C-6-5] PRECISA representar todas as SubscriptionInfo com UUIDs de grupo equivalentes como uma única assinatura em todas as affordances visíveis ao usuário que mostram e controlam as informações do chip. Exemplos de tais affordances incluem interfaces de configurações que correspondem a Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
  • [C-6-6] NÃO PODE mostrar ou permitir o controle de SubscriptionInfo com um UUID de grupo não nulo e bit oportunista em qualquer affordance visível ao usuário que permita a configuração ou o controle das configurações do chip.

  Se as implementações de dispositivos incluírem telefonia GSM ou CDMA e mostrarem uma barra de status do sistema:

  • [C-6-7] É NECESSÁRIO selecionar uma assinatura ativa representativa para um determinado UUID de grupo para mostrar ao usuário em recursos que forneçam informações de status do chip. Exemplos de tais affordances incluem o ícone de sinal celular da barra de status ou o bloco de configurações rápidas.
  • [C-SR] É FORTEMENTE RECOMENDADO que a assinatura representativa seja escolhida como a assinatura de dados ativa, a menos que o dispositivo esteja em uma ligação em que é FORTEMENTE RECOMENDADO que a assinatura representativa seja a assinatura ativa.

  Se as implementações de dispositivos incluírem telefonia GSM ou CDMA:

  • [C-6-8] PRECISA ser capaz de abrir e utilizar 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 PODE aplicar nenhum dos seguintes comportamentos a apps de operadoras ativas (conforme designado por TelephonyManager#getCarrierServicePackageName) automaticamente ou sem confirmação explícita do usuário:
    • Revogar ou limitar o acesso à rede
    • Revogar permissões
    • Restringir a execução de apps em segundo ou primeiro plano além dos recursos de gerenciamento de energia atuais incluídos no AOSP
    • Desativar ou desinstalar o app

  Se as implementações de dispositivos incluírem telefonia GSM ou CDMA e todas as assinaturas não oportunistas ativas que compartilham um UUID de grupo forem desativadas, removidas fisicamente do dispositivo ou marcadas como oportunistas, o dispositivo:

  • [C-7-1] PRECISA desativar automaticamente todas as assinaturas oportunistas ativas restantes no mesmo grupo.

  Se as implementações de dispositivos incluírem a telefonia GSM, mas não a telefonia CDMA, elas:

  • [C-8-1] NÃO PODE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-8-2] PRECISA gerar uma IllegalArgumentException em tentativas de definir qualquer tipo de rede 3GPP2 em bitmasks do tipo de rede preferencial 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:

  • [C-11-1] PRECISA declarar a flag de recurso android.hardware.telephony.euicc.mep.

  Encerrar novos requisitos

• 7.4.1.1 Compatibilidade com bloqueio de números: atualizações nos requisitos de bloqueio de números.

  Ver revisão

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

  • [C-1-4] NÃO PODE gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada.

  • [C-1-4] PRECISA gravar no provedor de registros de chamadas da plataforma para uma chamada bloqueada e filtrar chamadas com BLOCKED_TYPE fora da visualização padrão de registros no app discador pré-instalado.
  • DEVE fornecer uma funcionalidade de usuário para mostrar chamadas bloqueadas no app discador pré-instalado.

  Encerrar novos requisitos

• 7.4.1.3 Descarregamento de sinal de atividade NAT-T da rede celular: nova seção para descarregamento de sinal de atividade NAT-T da rede celular.

  Ver revisão

  7.4.1.3 Descarregamento de sinal de atividade NAT-T da rede celular

  Implementações de dispositivos:

  • DEVE incluir suporte para descarga de sinal de atividade de celular.

  Se as implementações de dispositivos incluírem suporte à descarga de sinal de atividade de rede celular e expõem a funcionalidade a apps de terceiros, elas:

  • [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
  • [C-1-2] PRECISA oferecer suporte a pelo menos um slot de sinal de atividade simultâneo na rede celular.
  • [C-1-3] PRECISA oferecer suporte ao máximo de slots de sinal de atividade móveis simultâneos que forem compatíveis com a HAL de rádio celular.
  • [C-SR] É FORTEMENTE RECOMENDADO oferecer suporte a pelo menos três slots de sinal de atividade de celular por instância de rádio.

  Se as implementações de dispositivos não incluírem suporte para descarga de sinal de atividade celular, elas:

  • [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

  Encerrar novos requisitos

• 7.4.2.5 Local do Wi-Fi (tempo de retorno do Wi-Fi – RTT): atualiza a precisão da localização do Wi-Fi.

  Ver revisão

  Se as implementações de dispositivos incluírem suporte à localização por Wi-Fi e exporem a funcionalidade a apps de terceiros, elas:

  • [C-1-4] PRECISA ter precisão de até 2 metros na largura de banda de 80 MHz no percentil 68 (conforme calculado com a função de distribuição cumulativa).
  • [C-SR] É MUITO RECOMENDADO que você informe com precisão a uma distância de até 1,5 metro na largura de banda de 80 MHz no 68o percentil (conforme calculado com a Função de distribuição cumulativa).

  Encerrar novos requisitos

• 7.4.2.6 Descarga de sinal de atividade Wi-Fi: atualização para adicionar requisitos de descarregamento de sinal de atividade da rede celular.

  Ver revisão

  Implementações de dispositivos:

  • DEVE incluir suporte para descarga de sinal de atividade Wi-Fi.

  Se as implementações de dispositivos incluírem suporte à descarga de sinal de atividade de Wi-Fi e exporem a funcionalidade a apps de terceiros, elas:

  • [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.
  • [C-1-2] PRECISA aceitar pelo menos três slots de sinal de atividade simultâneos por Wi-Fi
    e pelo menos um slot de sinal de atividade pela rede celular.

  Se as implementações de dispositivos não incluírem suporte para descarga de sinal de atividade Wi-Fi, elas:

  • [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

• 7.4.2.9 Trust on First Use (TOFU): seção de requisitos de confiança no primeiro uso adicionada.

  Ver 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 as configurações WPA/WPA2/WPA3-Enterprise, elas:

  • [C-4-1] PRECISA oferecer ao usuário a opção de usar o TOFU.

  Encerrar novos requisitos

• 7.4.3 Bluetooth: atualização dos requisitos de Bluetooth.

  Ver revisão

  Se as implementações de dispositivos oferecerem suporte ao perfil de áudio Bluetooth, elas:

  • DEVE oferecer suporte a codecs de áudio avançados e codecs de áudio Bluetooth (por exemplo, LDAC) com A2DP.

  Se as implementações de dispositivos retornarem true para a API BluetoothAdapter.isLeAudioSupported(), elas:

  • [C-7-1] PRECISA oferecer suporte ao cliente unicast.
  • [C-7-2] PRECISA oferecer suporte a 2 milhões de PHY.
  • [C-7-3] PRECISA oferecer suporte à publicidade estendida de LE.
  • [C-7-4] PRECISA oferecer suporte a pelo menos duas conexões CIS em um CIG.
  • [C-7-5] É NECESSÁRIO ativar o cliente BAP unicast, o coordenador de conjunto CSIP, o servidor MCP, o controlador VCP e o servidor CCP simultaneamente.
  • [C-SR] É MUITO RECOMENDADO para ativar o cliente unicast HAP.

  Se as implementações de dispositivos retornarem true para a API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), elas:

  • [C-8-1] PRECISA oferecer suporte a pelo menos dois links BIS em uma GRANDE.
  • [C-8-2] PRECISA ativar a fonte de transmissão BAP e o assistente de transmissão BAP simultaneamente.
  • [C-8-3] PRECISA oferecer suporte à publicidade LE Periodic.

  Se as implementações de dispositivos retornarem true para a API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), elas:

  • [C-9-1] PRECISA oferecer suporte a PAST (Transferência periódica de sincronização de publicidade).
  • [C-9-2] PRECISA oferecer suporte à publicidade LE Periodic.

  Se as implementações de dispositivo declararem FEATURE_BLUETOOTH_LE, elas:

  • [C-10-1] PRECISA ter medições de RSSI dentro de +/-9 dB para 95% das medições a 1 m de distância de um dispositivo de referência que transmite a ADVERTISE_TX_POWER_HIGH no ambiente de linha de visão.
  • [C-10-2] PRECISA incluir correções de Rx/Tx para reduzir os desvios por canal, para que as medições em cada um dos três canais, em cada uma das antenas (se forem usadas várias) fiquem dentro de +/-3 dB umas das outras em 95% das medições.
  • [C-SR] É MUITO RECOMENDADO para medir e compensar o deslocamento Rx para garantir que o RSSI médio do BLE seja de -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 forma que estejam em "planos paralelos" com telas voltadas para a mesma direção.
  • [C-SR] É MUITO RECOMENDADO para medir e compensar o deslocamento Tx para garantir que o RSSI médio do BLE seja -60 dBm +/-10 dB ao ler a partir 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 tal forma que estejam em "planos paralelos" com telas voltadas para a mesma direção.

  É RECOMENDADO seguir as etapas de configuração da medição especificadas nos Requisitos para a calibragem de presença.

  Se as implementações de dispositivos forem compatíveis com o Bluetooth versão 5.0, elas:

  • [C-SR] É FORTEMENTE RECOMENDADO oferecer suporte para:
    • LE 2M PHY
    • Codec LE PHY
    • Extensão de publicidade LE
    • Publicidade periódica
    • Pelo menos 10 conjuntos de anúncios
    • Pelo menos oito conexões simultâneas do LE. Cada conexão pode estar em qualquer um dos papéis de topologia de conexão.
    • Privacidade da camada de links do LE
    • Um tamanho de "lista de resoluções" de pelo menos oito entradas

  Encerrar novos requisitos

• 7.4.9 UWB: adicionamos uma seção de requisitos para hardware de UWB.

  Ver revisão

  7.4.9. UWB

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

  • [C-1-1] PRECISA garantir que as medidas 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] PRECISA garantir que a média das medidas de distância a 1 m do dispositivo de referência esteja dentro de [0,75 m, 1,25 m], em que a distância das informações empíricas é medida a partir da borda superior do DUT voltado para cima e inclinada 45 graus.

  É RECOMENDADO seguir as etapas de configuração da medição especificadas nos Requisitos para a calibragem de presença.

  Encerrar novos requisitos

• Câmeras 7.5: atualizações dos requisitos para o recurso de saída HDR de 10 bits.

  Ver revisão

  Se as implementações de dispositivos forem compatíveis com a capacidade de saída HDR de 10 bits, elas:

  • [C-2-1] PRECISA oferecer suporte pelo menos ao perfil HLG HDR em todos os dispositivos de câmera com suporte à saída de 10 bits.
  • [C-2-2] PRECISA oferecer suporte à saída de 10 bits para a câmera principal traseira ou frontal.
  • [C-SR] É FORTEMENTE RECOMENDADO oferecer suporte a 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 compatíveis com BACKWARD_COMPATIBLE de uma câmera lógica e para a própria câmera lógica.

  Para dispositivos de câmera lógica com suporte a HDR de 10 bits e 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 compatíveis com versões anteriores usando o controle CONTROL_ZOOM_RATIO na câmera lógica.

  Encerrar novos requisitos

• 7.7.2 USB Host Mode (em inglês): revisões para portas de função dupla.

  Ver revisão

  Se as implementações de dispositivos incluírem uma porta USB com suporte ao modo host e USB Type-C, elas:

  • [C-4-1] PRECISA implementar a funcionalidade Dual Role Port (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 do coletor USB (modo host) PODE estar desativada por padrão, mas PRECISA ser possível para o usuário ativá-la.

• 7.11 Media Performance Class (link em inglês): atualização para incluir o Android T.

  Ver revisão

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

  • [C-1-3] PRECISA atender a todos os requisitos de "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 nas versões T, S ou R.

  Encerrar novos requisitos

  Consulte a seção 2.2.7 para requisitos específicos do dispositivo.

9. Compatibilidade do modelo de segurança

• 9.1 Permissões: estenda os caminhos aceitos para listas de permissões de permissões de apps pré-instalados para arquivos APEX.

  Ver revisão

  • [C-0-2] Permissões com um protectionLevel de PROTECTION_FLAG_PRIVILEGED só podem ser concedidas a apps pré-instalados nos caminhos privilegiados da imagem do sistema (bem como arquivos APEX) e estar no subconjunto de permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito lendo e cumprindo as permissões da lista de permissões para cada app do caminho no system/priv-app como caminho privilegiado e usando o caminho system/priv-app como etc/permissions/.

• 9.7 Recursos de segurança: atualizações nos requisitos de inicialização para manter a integridade do kernel.

  Ver revisão

  Os recursos de integridade e autoproteção do kernel são essenciais para a segurança do Android. Implementações de dispositivos:

  • [C-SR] É MUITO RECOMENDADO para ativar a inicialização de pilha no kernel para evitar o uso de variáveis locais não inicializadas (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). Além disso, as implementações de dispositivos NÃO DEVEM presumir o valor usado pelo compilador para inicializar os locais.

  Encerrar 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 recortar/copiar/colar para proteger a privacidade do usuário.

  Ver revisão

  Implementações de dispositivos:

  • [C-0-1] NÃO PODE retornar dados cortados da área de transferência (por exemplo, pela API ClipboardManager), a menos que o app de terceiros seja o IME padrão ou seja 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 eles foram colocados ou lidos na área de transferência.

• 9.11 Chaves e credenciais: atualizações nos requisitos de tela de bloqueio segura, incluindo a adição de ECDH e 3DES aos algoritmos de criptografia.

  Ver revisão

  Quando a implementação do dispositivo é compatível com uma tela de bloqueio segura, ela:

  • [C-1-2] PRECISA ter implementações de RSA, AES, ECDSA, ECDH (se o IKeyMintDevice for compatível), 3DES, e algoritmos criptográficos, além dos algoritmos criptográficos, SHA1 e SHA-2 da família para oferecer suporte seguro ao código de área isolado do sistema de Keystore do Android e aos algoritmos isolados acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o código do kernel ou do espaço do usuário possa acessar o estado interno do ambiente isolado, incluindo a DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.

• 9.11.1 Tela de bloqueio segura, autenticação e dispositivos virtuais: adição de uma seção de requisitos para dispositivos virtuais e transferências de autenticação.

  Ver 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 por um dos métodos de autenticação principais recomendados (por exemplo, PIN, padrão ou senha) pelo menos uma vez a cada quatro horas ou menos. Quando um token físico atende aos requisitos de implementações do TrustAgent em C-X, as restrições de tempo limite definidas em C-9-5 se aplicam.

  Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e não ofereçam suporte a eventos de entrada associados, como via VirtualDeviceManager, elas:

  • [C-9-1] PRECISA bloquear essas telas virtuais secundárias quando a tela padrão do dispositivo estiver bloqueada e desbloquear essas telas virtuais secundárias quando a tela padrão do dispositivo estiver desbloqueada.

  Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e ofereçam suporte a eventos de entrada associados, como via VirtualDeviceManager, elas:

  • [C-10-1] PRECISA oferecer suporte a estados de bloqueio separados por dispositivo virtual.
  • [C-10-2] PRECISA desconectar todos os dispositivos virtuais após o tempo limite de inatividade
  • [C-10-3] PRECISA ter um tempo limite de inatividade
  • [C-10-4] PRECISA bloquear todas as telas quando o usuário iniciar um bloqueio total, inclusive com a funcionalidade de 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] PRECISA ter instâncias de dispositivos virtuais separadas por usuário.
  • [C-10-6] PRECISA desativar a criação de eventos de entrada associados via VirtualDeviceManager quando indicado por DevicePolicyManager.setNearbyAppStreamingPolicy.
  • [C-10-7] PRECISA 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] PRECISA desativar a interface de autenticação em dispositivos virtuais, incluindo a entrada do fator de conhecimento e a solicitação biométrica.
  • [C-10-12] PRECISA restringir intents iniciadas em um dispositivo virtual para que sejam mostradas apenas no mesmo dispositivo virtual.
  • [C-10-13] não pode usar um estado de bloqueio de dispositivo virtual como autorização de autenticação do usuário com o sistema Android Keystore. Consulte KeyGenParameterSpec.Builder.setUserAuthentication*.

  Quando as implementações de dispositivos permitem que o usuário transfira o fator de conhecimento de autenticação principal de um dispositivo de origem para um dispositivo de destino, como na configuração inicial do dispositivo de destino, elas:

  • [C-11-1] PRECISA criptografar o fator de conhecimento com garantias de proteção semelhantes às descritas no artigo de segurança Serviço do 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 ou usado remotamente para desbloquear qualquer dispositivo.
  • [C-11-2] PRECISA, no dispositivo de origem , pedir ao usuário para confirmar o fator de conhecimento desse dispositivo antes de transferir o fator de conhecimento para o de destino.
  • [C-11-3] PRECISA, em um dispositivo de destino sem um fator de conhecimento de autenticação principal definido, pedir ao usuário para confirmar um fator de conhecimento transferido no dispositivo de destino antes de definir esse fator de conhecimento como o principal fator de conhecimento de autenticação para o dispositivo de destino e antes de disponibilizar todos 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] PRECISA chamar grantTrust() com a sinalização somente quando estiver conectado a um dispositivo físico próximo com uma tela de bloqueio própria e quando o usuário autenticar a própria identidade nessa tela de bloqueio. Os dispositivos com proxy podem usar mecanismos de detecção no pulso ou no bolso após um desbloqueio único do usuário para atender ao requisito de autenticação do usuário.
  • [C-12-2] PRECISA colocar a implementação do dispositivo no estado TrustState.TRUSTABLE quando a tela estiver desligada (por exemplo, ao pressionar um botão ou expirar o tempo limite da exibição) e o TrustAgent não revogar a confiança. O AOSP atende a esse requisito.
  • [C-12-3] PRECISA mover o dispositivo apenas do estado TrustState.TRUSTABLE para o TrustState.TRUSTED se o TrustAgent ainda estiver concedendo confiança com base nos requisitos de C-12-1.
  • [C-12-4] PRECISA chamar TrustManagerService.revokeTrust() após no máximo 24 horas a partir da concessão de confiança, de uma janela inativa de 8 horas ou quando a conexão com o dispositivo físico próximo for perdida.

  Se as implementações de dispositivos permitirem que os aplicativos criem telas virtuais secundárias e ofereçam suporte a eventos de entrada associados, como via VirtualDeviceManager, e as telas não estiverem marcadas com VIRTUAL_DISPLAY_FLAG_SECURE, elas:

  • [C-13-8] PRECISA bloquear atividades com o atributo android:canDisplayOnRemoteDevices ou os metadados android.activity.can_display_on_remote_devices definidos como falsos para que sejam iniciadas no dispositivo virtual.
  • [C-13-9] É NECESSÁRIO bloquear atividades que não ativam explicitamente o streaming e que indicam que mostram conteúdo sensível, inclusive por SurfaceView#setSecure, FLAG_SECURE ou SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, da inicialização no dispositivo virtual.
  • [C-13-10] PRECISA desativar a instalação de apps iniciados em dispositivos virtuais.

  Encerrar novos requisitos

• 9.11.2 Strongbox: tornar a resistência a ataques internos (IAR) um requisito necessário.

  Ver revisão

  Para validar a conformidade com [C-1-3] a [C-1-9], as implementações de dispositivos:

  • [C-SR] é FORTEMENTE RECOMENDADO a fornecer resistência a ataques de pessoas com informações privilegiadas (IAR, na sigla em inglês), o que significa que uma pessoa com acesso a chaves de assinatura de firmware não pode produzir firmware que faça com que o StrongBox vaze chaves, para contornar requisitos de segurança funcionais ou permitir o acesso a dados confidenciais do usuário. A maneira recomendada de implementar o IAR é permitir atualizações de firmware apenas quando a senha principal do usuário for fornecida pela HAL IAuthSecret. A IAR vai se tornar um requisito OBRIGATÓRIO no Android 14.

• 9.11.3 Credencial de identidade: adicionamos informações sobre a implementação da referência do sistema de credenciais de identidade.

  Ver revisão

  O sistema de credenciais de identidade é definido e alcançado implementando todas as APIs no pacote android.security.identity.*. Essas APIs permitem que os desenvolvedores de apps armazenem e recuperem documentos de identidade do usuário. Implementações de dispositivos:

  O Android Open Source Project fornece uma implementação de referência de um aplicativo confiável (libeic) que pode ser usado para implementar o sistema de credenciais de identidade.

  Encerrar novos requisitos

• 9.11.4 Atestado de ID: adicionamos uma seção para o requisito de atestado de ID.

  Ver revisão

  9.11.4. Atestado de ID

  As implementações de dispositivos PRECISAM oferecer suporte ao atestado de IDs.

  Encerrar novos requisitos

• 9.17 Framework de virtualização do Android: adição de uma seção de requisitos para o framework de virtualização do Android.

  Ver 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 PODE modificar o SELinux do Android e o modelo de permissão para o gerenciamento de máquinas virtuais protegidas.
  • [C-1-3] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes no sistema/sepolicy fornecidas no Android Open Source Project (AOSP) upstream, e a política PRECISA ser compilada com todas as regras Nunca permitir presentes.
  • [C-1-4] NÃO É POSSÍVEL permitir 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 PODE permitir que uma máquina virtual protegida execute um código que não faça parte da imagem de fábrica ou das atualizações dela. Tudo o que não for coberto pela Inicialização verificada do Android (por exemplo, arquivos transferidos da Internet ou transferidos) NÃO PODE ser executado 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] PRECISA executar todos os sistemas operacionais disponíveis no APEX de virtualização em uma máquina virtual protegida.
  • [C-2-2] NÃO PODE permitir que uma máquina virtual protegida execute um sistema operacional que não esteja assinado pelo implementador do dispositivo ou pelo fornecedor do SO.
  • [C-2-3] NÃO PODE permitir que uma máquina virtual protegida execute dados como código (por exemplo, SELinux nunca permitir execmem).
  • [C-2-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes no system/sepolicy/microdroid fornecidos no Android Open Source Project (AOSP).
  • [C-2-5] PRECISA implementar mecanismos de defesa em profundidade de máquinas virtuais protegidas (por exemplo, SELinux para pVMs), mesmo para sistemas operacionais não Microdroid.
  • [C-2-6] PRECISA garantir que o firmware da pVM se recuse à inicialização se não conseguir verificar a imagem inicial.
  • [C-2-7] PRECISA garantir que o firmware da pVM se recuse à inicialização se a integridade da 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 PODE permitir que uma 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] PRECISA excluir permanentemente uma página depois que ela for usada por uma VM e antes de ser retornada ao host (por exemplo, a pVM é destruída).
  • [C-3-3] PRECISA garantir que o firmware da pVM seja carregado e executado antes de qualquer código em uma pVM.
  • [C-3-4] PRECISA garantir que o BCC e os CDIs fornecidos para uma instância de pVM só possam ser derivados 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 PODE fornecer funcionalidade a uma pVM que permita ignorar o modelo de segurança do Android.

  Se o dispositivo implementar suporte para as APIs do Framework de virtualização do Android:

  • [C-5-1] PRECISA oferecer suporte à compilação isolada de uma atualização do tempo de execução do ART.

  Se o dispositivo implementar suporte para as APIs do framework de virtualização do Android, para o gerenciamento de chaves:

  • [C-6-1] PRECISA acessar a cadeia do DICE em um ponto que o usuário não possa modificar, mesmo em dispositivos desbloqueados. Para garantir que não seja falsificado.
  • [C-6-2] PRECISA usar o DICE corretamente, ou seja, fornecer os valores corretos. Mas talvez não precise chegar nesse nível de detalhes.

  Encerrar novos requisitos

13. Entre em contato

Você pode participar do fórum de compatibilidade do Android e pedir esclarecimentos ou mencionar problemas que você acredita que o documento não aborda.