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

Esta página foi traduzida pela API Cloud Translation.

Definição de compatibilidade do Android 11

1. Introdução

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

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

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

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

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

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

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

1.1 Estrutura do documento

1.1.1. Requisitos por tipo de dispositivo

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

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

1.1.2. ID do requisito

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

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

Cada ID é definido da seguinte forma:

ID do tipo de dispositivo (mais informações em 2. Tipos de dispositivo)
- C: Core (requisitos aplicados a qualquer implementação de dispositivo Android)
- H: Dispositivo portátil Android
- T: dispositivo Android TV
- A: Implementação do Android Automotive
- W: Implementação do Android Watch
- Guia: implementação de 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 em 1 na mesma seção e na mesma condição.

1.1.3. ID do requisito na seção 2

O ID do requisito na Seção 2 começa com o ID da seção correspondente, 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

Embora o Projeto Android Open Source forneça uma pilha de software que pode ser usada para vários tipos e formatos de dispositivo, alguns deles têm um ecossistema de distribuição de aplicativos relativamente melhor estabelecido.

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

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

2.1 Configurações do dispositivo

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

2.2. Requisitos para dispositivos portáteis

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

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

Ter uma fonte de energia que ofereça mobilidade, como uma bateria.
Ter um tamanho físico de tela diagonal entre 3,3 polegadas (ou 2,5 polegadas para dispositivos lançados em um nível de API anterior ao Android 11) a 8 polegadas.

Os requisitos adicionais 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 dispositivos tablet Android estão marcados com um asterisco.

2.2.1. Hardware

Implementações de dispositivos portáteis:

[7.1.1.1/H-0-1] É necessário ter pelo menos uma tela compatível com Android que atenda a todos os requisitos descritos neste documento.
[7.1.1.3/H-SR] É ALTAMENTE RECOMENDADO oferecer aos usuários uma capacidade de mudar o tamanho da tela (densidade da tela).

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

[7.1.1.1/H-1-1]* A tela lógica disponibilizada para aplicativos de terceiros PRECISA ter pelo menos 5 cm nas bordas curtas e 6,3 cm nas bordas longas. Os dispositivos lançados em um nível de API anterior ao deste documento estão isentos desse requisito.

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

[7.1.1.1/H-2-1]* A tela lógica disponibilizada para aplicativos de terceiros PRECISA ter pelo menos 2,7 polegadas na borda curta. Os dispositivos lançados em um nível de API anterior ao deste documento estão 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] É OBRIGATÓRIO anunciar suporte para as extensões EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace e VK_EXT_hdr_metadata.

Implementações de dispositivos portáteis:

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

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

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

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

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

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

Implementações de dispositivos portáteis:

[7.3.11/H-SR] É RECOMENDADO oferecer suporte ao sensor de pose com seis graus de liberdade.
[7.4.3/H] DEVE incluir suporte para Bluetooth e Bluetooth LE.

Se as implementações de dispositivos portáteis incluem uma conexão com medição, elas:

[7.4.7/H-1-1] É OBRIGATÓRIO fornecer o modo de economia de dados.

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

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

Implementações de dispositivos portáteis:

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

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

[7.6.1/H-1-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 416 MB se a tela padrão usar resoluções de framebuffer de até qHD (por exemplo, FWVGA).
[7.6.1/H-2-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 592 MB se a tela padrão usar resoluções de framebuffer 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 1344 MB se a tela padrão usar resoluções de framebuffer de até QHD (por exemplo, QWXGA).

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

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

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

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[7.10/H-SR]* É ALTAMENTE RECOMENDADO não usar um atuador háptico (vibrador) de massa excêntrica rotativa(ERM, na sigla em inglês).
[7.10/H]* DEVE posicionar o atuador próximo ao local em que o dispositivo normalmente é segurado ou tocado pelas mãos.
[7.10/H-SR]* É ALTAMENTE RECOMENDADO implementar todas as constantes públicas para haptics claros em android.view.HapticFeedbackConstants, ou seja, CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START e GESTURE_END.
[7.10/H-SR]* É ALTAMENTE RECOMENDADO implementar todas as constantes públicas para haptics claras em android.os.VibrationEffect, ou seja, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK e EFFECT_DOUBLE_CLICK) e todas as constantes públicas para haptics avançados em android.os.VibrationEffect.Composition, ou seja, (PRIMITIVE_CLICK e PRIMITIVE_TICK).
[7.10/H-SR]* É ALTAMENTE RECOMENDADO usar estes mapeamentos de constantes hápticas vinculadas.
[7.10/H-SR]* É ALTAMENTE RECOMENDÁVEL seguir a avaliação de qualidade para as APIs createOneShot() e createWaveform().
[7.10/H-SR]* É ALTAMENTE RECOMENDADO verificar os recursos de escalonamento de amplitude executando android.os.Vibrator.hasAmplitudeControl().

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

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

[7.10/H]* PRECISA mover o atuador háptico no eixo X da orientação retrato.

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

[7.10/H-SR]* É ALTAMENTE RECOMENDADO que a frequência de ressonância do LRA do eixo X seja inferior a 200 Hz.

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

[7.10/H-SR]* É ALTAMENTE RECOMENDADO realizar uma avaliação de qualidade para constantes hápticas.

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 apps de terceiros:

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

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

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

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

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

2.2.3. Software

Implementações de dispositivos portáteis:

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

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

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

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

[3.8.4/H-1-1]* É PRECISO mostrar as notificações de conversa antes das não relacionadas a conversas, 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] É PRECISO 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 oferecerem suporte a uma tela de bloqueio segura, elas:

[3.9/H-1-1] É OBRIGATÓRIO implementar o conjunto completo de políticas de administração de dispositivos definidas na documentação do SDK do Android.
[3.9/H-1-2] É PRECISO declarar o suporte a perfis gerenciados usando a flag de recurso android.software.managed_users, exceto quando o dispositivo estiver configurado para se reportar como um dispositivo com pouca RAM ou para alocar armazenamento interno (não removível) como armazenamento compartilhado.

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

[3.8.16/H-1-1] É PRECISO declarar a flag de recurso android.software.controls e defini-la como true.
[3.8.16/H-1-2] É PRECISO fornecer ao usuário a capacidade de adicionar, editar, selecionar e operar os controles favoritos do dispositivo do usuário entre os controles registrados pelos aplicativos de terceiros usando as APIs ControlsProviderService e Control.
[3.8.16/H-1-3] É PRECISO fornecer acesso a essa característica do usuário em três interações de uma tela de início padrão.
[3.8.16/H-1-4] É PRECISO renderizar com precisão o nome e o ícone de cada app de terceiros que fornece controles pela API ControlsProviderService, bem como qualquer campo especificado fornecido pelas APIs Control.

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

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

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

2.2.4. Desempenho e bateria

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

Implementações de dispositivos portáteis:

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

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

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

Implementações de dispositivos portáteis:

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

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

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

2.2.5. Modelo de segurança

Implementações de dispositivos portáteis:

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

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

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

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

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

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

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] É PRECISO oferecer suporte a perfis restritos, um recurso que permite aos proprietários de dispositivos gerenciar outros usuários e os respectivos recursos no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.

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

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

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

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

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

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

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

2.2.7 Classe de desempenho de mídia portátil

Consulte a seção 7.11 para ver a definição da 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.R para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

[5.1/H-1-1] É OBRIGATÓRIO anunciar o número máximo de sessões de decodificador de vídeo de hardware que podem ser executadas simultaneamente em qualquer combinação de codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-2] É PRECISO oferecer suporte a 6 instâncias de sessões de decodificador de vídeo de hardware (AVC ou HEVC) em qualquer combinação de codecs executadas simultaneamente em resolução 720p a 30 fps.
[5.1/H-1-3] É OBRIGATÓRIO anunciar o número máximo de sessões de codificador de vídeo por hardware que podem ser executadas simultaneamente em qualquer combinação de codec usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-4] É PRECISO oferecer suporte a 6 instâncias de sessões de codificador de vídeo de hardware (AVC ou HEVC) em qualquer combinação de codecs executadas simultaneamente em resolução 720p a 30 fps.
[5.1/H-1-5] É PRECISO anunciar o número máximo de codificadores de vídeo de hardware e sessões de decodificador que podem ser executados simultaneamente em qualquer combinação de codecs usando os métodos CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-6] É PRECISO oferecer suporte a 6 instâncias de decodificador de vídeo de hardware e sessões de codificador de vídeo de hardware (AVC ou HEVC) em qualquer combinação de codec executada simultaneamente em resolução de 720p a 30 fps.
[5.1/H-1-7] É PRECISO ter uma latência de inicialização de codec de 65 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 (exceto o codec Dolby Vision) quando em carga. O carregamento aqui é definido como uma sessão de transcodificação de vídeo somente 1080p para 720p simultânea usando codecs de vídeo de hardware com a inicialização de gravação de áudio e vídeo de 1080p.
[5.1/H-1-8] É PRECISO ter uma latência de inicialização do codec de 50 ms ou menos para uma sessão de codificação de áudio de 128 kbps ou menos para todos os codificadores de áudio quando sob carga.A carga aqui é definida como uma sessão de transcodificação de vídeo de 1080p a 720p simultânea usando codecs de vídeo de hardware com a inicialização de gravação de áudio-vídeo de 1080p.
[5.3/H-1-1] NÃO PODE haver mais de 1 frame em 10 segundos (ou seja, menos de 0,333% de queda de frames) para uma sessão de vídeo de 1080p a 30 QPS sob carga. A carga é definida como uma sessão de transcodificação simultânea de 1080p para 720p usando codecs de vídeo de hardware, além de uma reprodução de áudio AAC de 128 kbps.
[5.3/H-1-2] NÃO É PERMITIDO perder mais de um frame em 10 segundos durante uma mudança de resolução de vídeo em uma sessão de vídeo de 30 QPS sob carga. O carregamento é definido como uma sessão de transcodificação de vídeo de 1080p para 720p simultânea usando codecs de vídeo de hardware, além de uma reprodução de áudio AAC de 128 Kbps.
[5.6/H-1-1] É PRECISO ter uma latência de toque para tom menor que 100 milissegundos usando o teste de toque para tom do OboeTester ou o teste de toque para tom do CTS Verifier.

2.2.7.2. Câmera

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

[7.5/H-1-1] É OBRIGATÓRIO ter uma câmera traseira principal com uma resolução de pelo menos 12 megapixels que ofereça suporte à gravação de vídeo em 4K a 30 fps. A câmera traseira principal é a que tem o ID mais baixo.
[7.5/H-1-2] É OBRIGATÓRIO ter uma câmera frontal principal com uma resolução de pelo menos 4 megapixels que ofereça suporte à gravação de vídeo em 1080p a 30 fps. A câmera frontal principal é a que tem o ID mais baixo.
[7.5/H-1-3] É PRECISO oferecer suporte à propriedade android.info.supportedHardwareLevel como FULL ou melhor para a câmera traseira principal e LIMITED ou melhor para a câmera frontal principal.
[7.5/H-1-4] É PRECISO oferecer suporte a CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para as duas câmeras principais.
[7.5/H-1-5] A latência de captura de JPEG do camera2 DEVE ser < 1000ms para resolução de 1080p, 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-6] A latência de inicialização da camera2 (abrir a câmera para o primeiro frame de visualização) PRECISA ser < 600ms, conforme medido pelo PerformanceTest da câmera do CTS sob condições de iluminação (3000K) para as duas câmeras principais.

2.2.7.3. Hardware

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

[7.1.1.1/H-1-1] É NECESSÁRIO ter uma resolução de tela de pelo menos 1080p.
[7.1.1.3/H-1-1] É PRECISO ter uma densidade de tela de pelo menos 400 dpi.
[7.6.1/H-1-1] É PRECISO ter pelo menos 6 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.R para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

[8.2/H-1-1] É PRECISO garantir um desempenho de gravação sequencial de pelo menos 100 MB/s.
[8.2/H-1-2] É PRECISO garantir um desempenho de gravação aleatória de pelo menos 10 MB/s.
[8.2/H-1-3] É PRECISO garantir um desempenho de leitura sequencial de pelo menos 200 MB/s.
[8.2/H-1-4] É PRECISO garantir um desempenho de leitura aleatória de pelo menos 25 MB/s.

2.3. Requisitos de televisão

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

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

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

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

2.3.1. Hardware

Implementações de dispositivos de TV:

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

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

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

Implementações de dispositivos de TV:

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

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

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

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

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

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

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

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

Implementações de dispositivos de TV:

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

2.3.2. Multimídia

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

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

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

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

Implementações de dispositivos de TV:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementações de dispositivos de TV:

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

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

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

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

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

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

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

2.3.3. Software

Implementações de dispositivos de TV:

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

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

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

Implementações de dispositivos de TV:

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

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

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

Implementações de dispositivos de TV:

[3.12/T-0-1] É NECESSÁRIO oferecer suporte ao TV Input Framework.

2.3.4. Desempenho e bateria

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

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

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

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

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

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

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

Implementações de dispositivos de TV:

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

2.3.5. Modelo de segurança

Implementações de dispositivos de TV:

[9.11/T-0-1] É NECESSÁRIO fazer backup da implementação do keystore com um ambiente de execução isolado.
[9.11/T-0-2] É OBRIGATÓRIO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash da família MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos aceitos pelo sistema do Keystore do Android em uma área isolada 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 o DMA. O upstream do Android Open Source Project (AOSP) atende a esse requisito usando a implementação do Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
[9.11/T-0-3] É PRECISO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e, somente quando bem-sucedida, permitir que as chaves vinculadas à autenticação sejam usadas. As credenciais da tela de bloqueio precisam ser armazenadas de forma que apenas o ambiente de execução isolado possa realizar a autenticação. O upstream do Android Open Source Project fornece a camada de abstração de hardware (HAL, na sigla em inglês) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
[9.11/T-0-4] É PRECISO oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser compartilhadas em um número suficiente de dispositivos para evitar que sejam usadas como identificadores. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de um SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

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

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

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

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

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

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

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

Implementações de dispositivos de TV:

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

2.4. Requisitos do relógio

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

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

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

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

2.4.1. Hardware

Assistir implementações de dispositivos:

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

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

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

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

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

Assistir implementações de dispositivos:

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

2.4.2. Multimídia

Nenhum requisito extra.

2.4.3. Software

Assistir implementações de dispositivos:

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

Assistir implementações de dispositivos:

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

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

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

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

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

2.4.4. Desempenho e bateria

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

[8.3/W-SR] É ALTAMENTE RECOMENDÁVEL oferecer ao usuário a capacidade de exibir todos os apps que estão isentos dos modos de economia de energia do App Standby e da Soneca.
[8.3/W-SR] É ALTAMENTE RECOMENDADO oferecer ao usuário a capacidade de ativar e desativar o recurso de economia de bateria.

Assistir implementações de dispositivos:

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

2.4.5. Modelo de segurança

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

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

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

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

2.5. Requisitos automotivos

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

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

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

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

2.5.1. Hardware

Implementações de dispositivos automotivos:

[7.1.1.1/A-0-1] É OBRIGATÓRIO ter uma tela com pelo menos 6 polegadas de tamanho físico na diagonal.
[7.1.1.1/A-0-2] É OBRIGATÓRIO ter um layout de tamanho de tela de pelo menos 750 dp x 480 dp.
[7.2.3/A-0-1] É OBRIGATÓRIO fornecer a função "Início" e PODE fornecer as funções "Voltar" e "Recentes".
[7.2.3/A-0-2] É PRECISO enviar o evento de pressionar normal e longo da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano.
[7.3/A-0-1] É OBRIGATÓRIO implementar e informar GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.
[7.3/A-0-2] O valor da flag NIGHT_MODE PRECISA ser consistente com o modo dia/noite do painel e PRECISA ser baseado na entrada do sensor de luz ambiente. O sensor de luz ambiente pode ser o mesmo que o fotômetro.
[7.3/A-0-3] É OBRIGATÓRIO fornecer o campo de informações adicionais do sensor TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor fornecido.
[7.3/A-0-1] PODE estimar a localização mesclando GPS/GNSS com outros sensores. Se o local for estimado, é ALTAMENTE RECOMENDADO implementar e informar os tipos de sensor e/ou os IDs de propriedade do veículo correspondentes usados.
[7.3/A-0-2] O local solicitado por LocationManager#requestLocationUpdates() NÃO PODE ser associado ao mapa.

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

[7.3.1/A-1-1] É PRECISO que o dispositivo possa informar eventos com frequência de pelo menos 100 Hz.
[7.3.1/A-1-2] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor do carro do Android.

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

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

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

[7.3.3/A-3-1] É PRECISO determinar a localização na primeira vez que o receptor GPS/GNSS for ligado ou após mais de 4 dias, em até 60 segundos.
[7.3.3/A-3-2] É PRECISO 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 localização (ou seja, solicitações que não são a primeira vez ou após mais de 4 dias). O requisito 7.3.3/C-1-2 geralmente é atendido em veículos sem conectividade de dados baseada em rede celular, usando previsões de órbita GNSS calculadas no receptor ou usando o último local conhecido do veículo com a capacidade de estimativa de posição por pelo menos 60 segundos com uma precisão de posição que atenda aos requisitos 7.3.3/C-1-3 ou uma combinação dos dois.

Implementações de dispositivos automotivos:

[7.4.3/A-0-1] É PRECISO oferecer suporte a Bluetooth e RECOMENDÁVEL oferecer suporte a Bluetooth LE.
[7.4.3/A-0-2] As implementações do Android Automotive PRECISAM oferecer suporte aos seguintes perfis Bluetooth:
- Ligações telefônicas pelo perfil viva-voz (HFP).
- Reprodução de mídia pelo perfil de distribuição de áudio (A2DP).
- Controle de reprodução de mídia pelo perfil de controle remoto (AVRCP).
- Compartilhamento de contatos usando o perfil de acesso à agenda telefônica (PBAP).
[7.4.3/A-SR] É ALTAMENTE RECOMENDADO oferecer suporte ao perfil de acesso a mensagens (MAP).
[7.4.5/A] DEVE incluir suporte para conectividade de dados baseada em rede celular.
[7.4.5/A] PODE usar a constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID da API do sistema para redes que precisam estar disponíveis para apps do sistema.

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

Implementações de dispositivos automotivos:

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

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

[7.5/A-1-1] NÃO É PERMITIDO ter câmeras de visão externa acessíveis pelas APIs de câmera do Android, a menos que elas obedeçam aos requisitos básicos da câmera.
[7.5/A-SR] É ALTAMENTE RECOMENDADO não girar ou espelhar horizontalmente a visualização da câmera.
[7.5.5/A-SR] É ALTAMENTE RECOMENDADO que a orientação seja feita de forma que a dimensão longa da câmera se alinhe ao horizonte.
[7.5/A-SR] É ALTAMENTE RECOMENDADO ter uma resolução de pelo menos 1,3 megapixels.
DEVE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
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.

Implementações de dispositivos automotivos:

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

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

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

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 seguintes densidades for usada:
- 280 dpi ou menos em telas pequenas/normais
- ldpi ou menor em telas extragrandes
- mdpi ou menor em telas grandes
[7.6.1/A-1-2] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 608 MB se qualquer uma das densidades a seguir for usada:
- xhdpi ou superior em telas pequenas/normais
- hdpi ou mais em telas grandes
- mdpi ou superior em telas extragrandes
[7.6.1/A-1-3] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 896 MB se qualquer uma das seguintes densidades for usada:
- 400 dpi ou mais em telas pequenas/normais
- xhdpi ou superior em telas grandes
- tvdpi ou superior em telas extragrandes
[7.6.1/A-1-4] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 1344 MB se qualquer uma das seguintes densidades for usada:
- 560 dpi ou mais em telas pequenas/normais
- 400 dpi ou mais em telas grandes
- xhdpi ou superior em telas extragrandes

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

2.5.2. Multimídia

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

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

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

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

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

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

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

[5.3/A-SR] H.265 HEVC

2.5.3. Software

Implementações de dispositivos automotivos:

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

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

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

Implementações de dispositivos automotivos:

[3.2.1/A-0-1] É PRECISO oferecer suporte e aplicar todas as constantes de permissões, conforme documentado na página de referência de permissões automotivas.
[3.2.3.1/A-0-1] É PRECISO carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intent para todos os padrões de filtro de intent públicos definidos pelas seguintes intents do app listadas aqui.
[3.4.1/A-0-1] É PRECISO fornecer uma implementação completa da API android.webkit.Webview.
[3.8.3/A-0-1] É PRECISO mostrar notificações que usam a API Notification.CarExtender quando solicitadas por aplicativos de terceiros.
[3.8.4/A-SR] É altamente recomendável implementar um assistente no dispositivo para processar a ação de assistência.

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

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

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

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

Implementações de dispositivos automotivos:

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

2.5.4. Desempenho e bateria

Implementações de dispositivos automotivos:

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

2.5.5. Modelo de segurança

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

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

Implementações de dispositivos automotivos:

[9.11/A-0-1] É NECESSÁRIO fazer backup da implementação do keystore com um ambiente de execução isolado.
[9.11/A-0-2] É OBRIGATÓRIO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash da família MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos aceitos pelo sistema do Keystore do Android em uma área isolada 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 pode acessar o estado interno do ambiente isolado, incluindo o DMA. O upstream do Android Open Source Project (AOSP) atende a esse requisito usando a implementação do Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
[9.11/A-0-3] É NECESSÁRIO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e, somente quando bem-sucedido, permitir que as chaves vinculadas à autenticação sejam usadas. As credenciais da tela de bloqueio precisam ser armazenadas de forma que apenas o ambiente de execução isolado possa realizar a autenticação. O upstream do Android Open Source Project fornece a camada de abstração de hardware (HAL, na sigla em inglês) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
[9.11/A-0-4] É PRECISO oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser compartilhadas em um número suficiente de dispositivos para evitar que sejam usadas como identificadores. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de um SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

Implementações de dispositivos automotivos:

[9.14/A-0-1] É PRECISO controlar as mensagens de subsistemas de veículos do framework do Android, por exemplo, adicionando tipos e fontes de mensagens permitidos a uma lista de permissões.
[9.14/A-0-2] É NECESSÁRIO monitorar ataques de negação de serviço do framework do Android ou de apps de terceiros. Isso protege contra softwares maliciosos que inundam a rede do veículo com tráfego, o que pode levar a um mau funcionamento dos subsistemas do veículo.

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

Implementações de dispositivos automotivos:

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

2.6. Requisitos para tablets

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

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

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

2.6.1. Hardware

Tamanho da tela

[7.1.1.1/Tab-0-1] PRECISA ter uma tela de 7 a 18 polegadas.

Giroscópio

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

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

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

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

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

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

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

Modo de realidade virtual (seção 7.9.1)

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

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

2.6.2. Modelo de segurança

Chaves e credenciais (seção 9.11)

Consulte a seção [9.11].

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

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

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

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

2.6.2. Software

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

3. Software

3.1. Compatibilidade com a API gerenciada

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

Implementações de dispositivos:

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

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

3.1.1. Extensões Android

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

Implementações de dispositivos Android:

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

3.1.2. Biblioteca do Android

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

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

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

3.2. Compatibilidade de API flexível

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

3.2.1. Permissões

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

3.2.2. Parâmetros do build

As APIs do Android incluem várias constantes na classe android.os.Build que 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 aos quais as implementações de dispositivos PRECISAM se conformar.

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

3.2.3. Compatibilidade de intents

3.2.3.1. Intents comuns de apps

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

Implementações de dispositivos:

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

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

3.2.3.2. Resolução de intents

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

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

[C-0-4] É OBRIGATÓRIO tentar validar todos os filtros de intent executando as etapas de validação definidas na especificação do Digital Asset Links conforme implementado pelo Gerenciador de pacotes no projeto upstream do Android Open Source.
[C-0-5] É OBRIGATÓRIO tentar a validação dos filtros de intent durante a instalação do aplicativo e definir todos os filtros de intent de URI validados com sucesso como gerenciadores de apps padrão para os URIs.
PODE definir filtros de intent de URI específicos como 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 de padrão por URI apropriado no menu de configurações.
É OBRIGATÓRIO fornecer ao usuário controles de Links do app por app nas Configurações da seguinte maneira:
- [C-0-6] O usuário PRECISA poder substituir de forma holística o comportamento padrão dos links de um app para que ele seja: sempre aberto, sempre perguntado ou nunca aberto, o que precisa se aplicar a todos os filtros de intent de URI candidatos de forma igual.
- [C-0-7] O usuário PRECISA ter acesso a uma lista dos filtros de intent de URI candidatos.
- A implementação do dispositivo PODE permitir que o usuário substitua filtros de intent de URI de candidatos específicos que foram verificados com sucesso, por filtro de intent.
- [C-0-8] A implementação do dispositivo PRECISA permitir que os usuários visualizem e substituam filtros de intent de URI de candidato específicos se a implementação do dispositivo permitir que alguns filtros de intent de URI de candidato sejam verificados com sucesso, enquanto outros podem falhar.

3.2.3.3. Namespaces de intent

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

3.2.3.4. Intents de transmissão

Os apps de terceiros dependem da plataforma para transmitir determinadas intents e receber notificações sobre mudanças no ambiente de hardware ou software.

Implementações de dispositivos:

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

3.2.3.5. Intents de aplicativo condicionais

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

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

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

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

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

[C-2-1] É necessário fornecer um menu de configurações que chame a intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar uma caixa de diálogo para mudar o app de SMS padrão.
[C-2-2] É OBRIGATÓRIO honrar a intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar uma caixa de diálogo que permita ao usuário mudar o app padrão do Telefone.
- É OBRIGATÓRIO usar a interface do app Telefone padrão selecionada pelo usuário para chamadas recebidas e realizadas, exceto para chamadas de emergência, que usariam o app Telefone pré-instalado.
[C-2-3] É OBRIGATÓRIO honrar a intent android.telecom.action.CHANGE_PHONE_ACCOUNTS para fornecer ao usuário a capacidade de configurar o ConnectionServices associado ao PhoneAccounts, bem como uma PhoneAccount padrão que o provedor de serviços de telecomunicações usará para fazer chamadas. A implementação do AOSP atende a esse requisito incluindo uma opção "Contas de chamada" no menu de configurações "Chamadas".
[C-2-4] É PRECISO permitir android.telecom.CallRedirectionService para um app que tenha o papel android.app.role.CALL_REDIRECTION.
[C-2-5] É PRECISO fornecer ao usuário a capacidade de escolher um app que tenha a função android.app.role.CALL_REDIRECTION.
[C-2-6] É NECESSÁRIO honrar as intents android.intent.action.SENDTO e android.intent.action.VIEW e fornecer uma atividade para enviar/exibir mensagens SMS.
[C-SR] É altamente recomendável 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 de discagem pré-carregado que possa processar essas intents e fornecer o cumprimento conforme descrito no SDK.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Se as implementações do dispositivo oferecerem o modo de economia de dados, elas: * [C-10-1] DEVEM fornecer uma interface do usuário nas configurações que processa a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, permitindo que os usuários adicionem ou removam aplicativos da lista de permissões.

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

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

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

[C-12-1] É OBRIGATÓRIO honrar a intent android.media.action.STILL_IMAGE_CAMERA e android.media.action.STILL_IMAGE_CAMERA_SECURE e iniciar a câmera no modo de imagem estática, conforme descrito no SDK.
[C-12-2] É OBRIGATÓRIO honrar a intent android.media.action.VIDEO_CAMERA para iniciar a câmera no modo de vídeo, conforme descrito no SDK.
[C-12-3] É OBRIGATÓRIO permitir que apenas aplicativos Android pré-instalados processem as seguintes intents: MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE e MediaStore.ACTION_VIDEO_CAPTURE, conforme descrito no documento do SDK.

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

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

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

[C-14-1] É PRECISO implementar totalmente as APIs AutofillService e AutofillManager e honrar 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 de dispositivos incluírem um app pré-instalado ou permitirem que apps de terceiros acessem as estatísticas de uso, elas:

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

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

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

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

[C-SR] É altamente recomendável honrar android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA e android.speech.tts.engine.GET_SAMPLE_TEXT. As intents têm uma atividade para fornecer a realização dessas intents, conforme descrito no SDK neste link.

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

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

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

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

[C-1-1] É OBRIGATÓRIO definir a flag de recurso android.software.activities_on_secondary_displays.
[C-1-2] É PRECISO garantir a compatibilidade da API de forma semelhante a uma atividade executada na tela principal.
[C-1-3] É PRECISO que a nova atividade seja exibida na mesma tela que a atividade que a iniciou, quando a nova atividade é iniciada sem especificar uma tela de destino pela API ActivityOptions.setLaunchDisplayId().
[C-1-4] É OBRIGATÓRIO destruir todas as atividades quando uma tela com a flag Display.FLAG_PRIVATE for removida.
[C-1-5] É OBRIGATÓRIO ocultar o conteúdo de forma segura em todas as telas quando o dispositivo estiver bloqueado com uma tela de bloqueio segura, a menos que o app 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 exibido, funcionar corretamente e manter a compatibilidade se uma atividade for iniciada na tela secundária.

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

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

3.3. Compatibilidade com a API nativa

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

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

3.3.1. Interfaces binárias do aplicativo

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

Implementações de dispositivos:

[C-0-1] PRECISA ser compatível com uma ou mais ABIs do Android NDK definidas.
[C-0-2] É PRECISO incluir suporte para que o código executado no ambiente gerenciado chame o código nativo usando a semântica padrão da Java Native Interface (JNI).
[C-0-3] PRECISA ser compatível com a origem (ou seja, compatível com o cabeçalho) e com o binário (para a ABI) com cada biblioteca necessária na lista abaixo.
[C-0-5] É OBRIGATÓRIO informar com precisão a interface binária de aplicativo (ABI) nativa aceita pelo dispositivo usando os parâmetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, cada um uma lista separada por vírgulas de ABIs ordenadas da mais para a menos preferida.
[C-0-6] É OBRIGATÓRIO informar, pelos parâmetros acima, um subconjunto da lista de ABIs a seguir e NÃO informar nenhuma ABI que não esteja na lista.
- armeabi (não é mais compatível como destino do NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] É OBRIGATÓRIO disponibilizar todas as bibliotecas a seguir, que fornecem APIs nativas, para apps que incluem código nativo:
- libaaudio.so (suporte de áudio nativo do AAudio)
- libamidi.so (suporte MIDI nativo, se o recurso android.software.midi for reivindicado conforme descrito na seção 5.9)
- libandroid.so (suporte nativo à atividade do Android)
- libc (biblioteca C)
- libcamera2ndk.so
- libdl (vinculador dinâmico)
- libEGL.so (gerenciamento de superfície OpenGL nativa)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (registro do Android)
- libmediandk.so (suporte a APIs de mídia nativas)
- libm (biblioteca matemática)
- libneuralnetworks.so (API Neural Networks)
- libOpenMAXAL.so (suporte ao OpenMAX AL 1.0.1)
- libOpenSLES.so (suporte a áudio do OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (suporte mínimo para C++)
- libvulkan.so (Vulkan)
- libz (compactação Zlib)
- Interface JNI
[C-0-8] NÃO é permitido adicionar ou remover as funções públicas das bibliotecas nativas listadas acima.
[C-0-9] É OBRIGATÓRIO listar outras bibliotecas que não são do AOSP expostas diretamente a apps de terceiros em /vendor/etc/public.libraries.txt.
[C-0-10] NÃO EXPORÃO NENHUM OUTRO TIPO DE BIBLIOTECA NATIVA, IMPLEMENTADA E FORNECIDA NO AOSP COMO BIBLIOTECAS DO SISTEMA, PARA TERCEIROS COM DESTINO AO NÍVEL 24 DA API OU SUPERIOR, POIS ELAS ESTÃO RESERVADAS.
[C-0-11] É OBRIGATÓRIO exportar todos os símbolos de função do OpenGL ES 3.1 e do pacote de extensões para Android, conforme definido no NDK, pela biblioteca libGLESv3.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.1 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
[C-0-12] É PRECISO exportar símbolos de função para os símbolos de função principais do Vulkan 1.0, bem como as extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 pela biblioteca libvulkan.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.2 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
DEVE ser criado usando o código-fonte e os arquivos de cabeçalho disponíveis no projeto de código aberto upstream do Android

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

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

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

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

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

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

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView

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

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

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

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

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

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

3.5. Compatibilidade comportamental da API

Implementações de dispositivos:

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

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

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

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

3.5.1. Restrição de aplicativo

Se as implementações de dispositivo implementarem um mecanismo reservado para restringir apps e esse mecanismo for mais restritivo do que o bucket raro para apps em espera, elas:

[C-1-1] É PRECISO fornecer uma affordance para que o usuário possa ver a lista de apps restritos.
[C-1-2] É necessário oferecer ao usuário a possibilidade de ativar / desativar as restrições em cada app.
[C-1-3] Não é permitido aplicar restrições automaticamente sem evidências de comportamento de integridade do sistema ruim, mas é permitido aplicar restrições em apps após a detecção de comportamento de integridade do sistema ruim, como wakelocks presos, serviços de execução longa e outros critérios. Os critérios podem ser determinados pelos implementadores do dispositivo, mas precisam estar relacionados ao impacto do app na integridade do sistema. Outros critérios que não estejam relacionados exclusivamente à integridade do sistema, como a falta de popularidade do app no mercado, NÃO devem ser usados como critérios.
[C-1-4] Não é necessário aplicar automaticamente restrições a apps quando um usuário desativou essa opção manualmente e pode sugerir que o usuário aplique restrições.
[C-1-5] É OBRIGATÓRIO informar aos usuários se as restrições de app são aplicadas automaticamente a um app. Essas informações precisam ser enviadas em até 24 horas após a aplicação das restrições.
[C-1-6] É PRECISO retornar true para ActivityManager.isBackgroundRestricted() quando o app restrito chamar essa API.
[C-1-7] NÃO DEVE restringir o app em primeiro plano que é usado explicitamente pelo usuário.
[C-1-8] É PRECISO suspender as restrições em um app que se torna o aplicativo em primeiro plano quando o usuário começa a usar explicitamente o app que costumava ser restrito.

3.6. Namespaces de API

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

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

Ou seja, eles:

[C-0-1] NÃO é permitido modificar as APIs expostas publicamente na plataforma Android alterando assinaturas de método ou classe ou removendo classes ou campos de classe.
[C-0-2] NÃO É PERMITIDO adicionar elementos expostos publicamente (como classes ou interfaces, ou campos ou métodos para 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 do Android upstream.

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 do idioma Java de nenhuma API exposta publicamente.
[C-0-4] NÃO PODE ser anunciado ou exposto aos desenvolvedores.

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

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

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

As restrições acima correspondem a 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 torná-las obrigatórias com a inclusão nesta definição de compatibilidade.

3.7. Compatibilidade com o ambiente de execução

Implementações de dispositivos:

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

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

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

3.8. Compatibilidade da interface do usuário

3.8.1. Acesso rápido (tela inicial)

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

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

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

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

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

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

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

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

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

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

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

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 oferecerem suporte a widgets de apps de terceiros, elas:

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

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

[C-2-1] É OBRIGATÓRIO informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] É necessário ter uma affordance que peça permissão ao usuário antes de adicionar um atalho solicitado por apps pelo método da API AppWidgetManager.requestPinAppWidget().

3.8.3. Notificações

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

3.8.3.1. Apresentação de notificações

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

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

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

Implementações de dispositivos:

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

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

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

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

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

Se as implementações de dispositivos oferecerem suporte a notificações de alerta:

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

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

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

Implementações de dispositivos:

[C-0-1] É PRECISO atualizar corretamente e rapidamente as notificações em 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] É OBRIGATÓRIO respeitar a chamada de API snoozeNotification(), dispensar a notificação e fazer um callback após a duração de suspensão definida na chamada de API.

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

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

3.8.3.3. Não perturbe

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

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

3.8.4. Pesquisar

O Android inclui APIs que permitem aos desenvolvedores incorporar a pesquisa aos apps e expor os dados deles na pesquisa global do sistema. Em geral, essa funcionalidade consiste em uma única interface do usuário em todo o sistema que permite a entrada de consultas, mostra sugestões à medida que os usuários digitam e exibe os resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para oferecer a pesquisa nos próprios apps e fornecer resultados à interface do usuário da pesquisa global comum.

As implementações de dispositivos Android DEVEM incluir a pesquisa global, uma interface de usuário de pesquisa única, compartilhada e em todo o sistema, capaz de sugerir resultados em tempo real em resposta à entrada do usuário.

Se as implementações de dispositivos implementarem a interface de pesquisa global, elas:

[C-1-1] É OBRIGATÓRIO implementar as APIs que permitem que aplicativos de terceiros adicionem sugestões à caixa de pesquisa quando ela for executada no modo de pesquisa global.

Se nenhum aplicativo de terceiros que use a pesquisa global estiver instalado:

O comportamento padrão DEVE ser mostrar os resultados e as sugestões do mecanismo de pesquisa da Web.

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

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

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

3.8.5. Alertas e avisos

Os aplicativos podem usar a API Toast para mostrar strings curtas não modais ao usuário final 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 em outros apps.

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

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

3.8.6. Temas

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

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

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

[C-1-1] NENHUM dos atributos do tema Holo expostos aos aplicativos PODE ser alterado.
[C-1-2] É PRECISO oferecer suporte à família de temas "Material" e NÃO ALTERAR nenhum dos atributos do tema Material ou os recursos expostos aos aplicativos.
[C-1-3] É PRECISO definir a família de fontes "sans-serif" como Roboto versão 2.x para os idiomas com suporte a Roboto ou fornecer uma característica para o usuário mudar a fonte usada para a família de fontes "sans-serif" como Roboto versão 2.x para os idiomas com suporte a Roboto.

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

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

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

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

[C-2-1] É OBRIGATÓRIO usar a cor branca para ícones de status do sistema (como intensidade do sinal e nível da bateria) e notificações emitidas pelo sistema, a menos que o ícone esteja indicando um status problemático ou um app solicite uma barra de status clara usando a flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
[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 solicitar 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 um plano de fundo, atrás de outros aplicativos.

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

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

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

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

3.8.8. Troca de atividades

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

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

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

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

3.8.9. Gerenciamento de entrada

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

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

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

3.8.10. Controle de mídia na tela de bloqueio

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

3.8.11. Protetores de tela (antes chamados de Sonhos)

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

3.8.12. Local

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

[C-1-2] É OBRIGATÓRIO mostrar o status atual do local no menu "Localização" em "Configurações".
[C-1-3] Modos de local NÃO devem ser mostrados no menu "Local" em "Configurações".

3.8.13. Unicode e fonte

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

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

[C-1-1] É PRECISO renderizar esses caracteres emoji em glifos coloridos.
[C-1-2] É PRECISO incluir suporte para:
- Fonte Roboto 2 com diferentes pesos: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light para os idiomas disponíveis no dispositivo.
- Cobertura completa do Unicode 7.0 para os alfabetos latino, grego e cirílico, incluindo os intervalos latino estendido A, B, C e D e todos os glifos no bloco de símbolos de moeda do Unicode 7.0.
DEVEM oferecer suporte a emojis de tom de pele e famílias diversas, conforme especificado no Relatório técnico Unicode 51.

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

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

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

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. Várias janelas

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

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

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

[C-2-1] É PRECISO carregar previamente uma tela de início redimensionável como padrão.
[C-2-2] A atividade acoplada de uma janela múltipla de tela dividida PRECISA ser cortada, mas DEVE mostrar algum conteúdo dela, se o app de inicialização for a janela em foco.
[C-2-3] É OBRIGATÓRIO honrar os valores declarados de AndroidManifestLayout_minWidth e AndroidManifestLayout_minHeight do aplicativo de inicialização de terceiros e não substituir esses valores ao mostrar algum conteúdo da atividade acoplada.

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

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

3.8.15. Corte de tela

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

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

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

3.8.16. Controles do dispositivo

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

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

3.9. Administração do dispositivo

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

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

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

3.9.1 Provisionamento de dispositivo

3.9.1.1 Provisionamento de proprietário do dispositivo

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

[C-1-1] É PRECISO oferecer suporte ao registro de um cliente de política de dispositivo (DPC, na sigla em inglês) como um app de proprietário do dispositivo, conforme descrito abaixo:
- Quando a implementação do dispositivo ainda não tem dados do usuário, ela:
  - [C-1-3] É OBRIGATÓRIO informar true para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  - [C-1-4] É OBRIGATÓRIO registrar o aplicativo DPC como o app de proprietário do dispositivo em resposta à ação de intent android.app.action.PROVISION_MANAGED_DEVICE.
  - [C-1-5] É PRECISO registrar o aplicativo DPC como o app de proprietário do dispositivo se o dispositivo declarar suporte à comunicação a curta distância (NFC) usando a flag de recurso android.hardware.nfc e receber uma mensagem NFC contendo um registro com o tipo MIME MIME_TYPE_PROVISIONING_NFC.
- Quando a implementação do dispositivo tem dados do usuário, ela:
  - [C-1-6] É OBRIGATÓRIO informar false para o DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  - [C-1-7] Não é mais permitido registrar nenhum aplicativo DPC como o app de proprietário do dispositivo.
[C-1-2] É PRECISO exigir alguma ação afirmativa antes ou durante o processo de provisionamento para consentir com a configuração do app como proprietário do dispositivo. O consentimento pode ser feito por ação do usuário ou por algum meio programático, mas o aviso de divulgação adequado (conforme mencionado no AOSP) PRECISA ser mostrado antes do provisionamento do proprietário do dispositivo ser iniciado. Além disso, o mecanismo de consentimento de proprietário de dispositivo programático usado (por empresas) para provisionamento de proprietário de dispositivo NÃO PODE interferir na experiência pronta para uso não empresarial.
[C-1-3] O consentimento não pode ser codificado de forma fixa nem impedir o uso de outros apps de proprietário do dispositivo.

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

[C-2-1] É PRECISO ter um processo em vigor para verificar se o app específico que está sendo promovido pertence a uma solução legítima de gerenciamento de dispositivos corporativos e se ele já foi configurado na solução proprietária para ter os direitos equivalentes de "proprietário do dispositivo".
[C-2-2] É PRECISO mostrar a mesma declaração de consentimento do proprietário do dispositivo do AOSP que o fluxo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o aplicativo DPC como "proprietário do dispositivo".
PODE ter dados do usuário no dispositivo antes de registrar o aplicativo DPC como "proprietário do dispositivo".

3.9.1.2 Provisionamento de perfil gerenciado

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

[C-1-1] É PRECISO implementar as APIs que permitem que um aplicativo de controlador de políticas de dispositivo (DPC) se torne o proprietário de um novo perfil gerenciado.
[C-1-2] A experiência dos usuários no processo de provisionamento de perfil gerenciado (o fluxo iniciado por android.app.action.PROVISION_MANAGED_PROFILE) PRECISA estar alinhada com a implementação do AOSP.
[C-1-3] É OBRIGATÓRIO fornecer as seguintes características de usuário nas Configurações para indicar ao usuário quando uma determinada função do sistema foi desativada pelo Device Policy Controller (DPC):
- Um ícone consistente ou outra característica de uso (por exemplo, o ícone de informações do AOSP upstream) para representar quando uma configuração específica é restrita por um administrador de dispositivos.
- Uma breve mensagem explicativa, fornecida pelo administrador do dispositivo pelo setShortSupportMessage.
- Ícone do aplicativo DPC.

3.9.2 Suporte a perfil gerenciado

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

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

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

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

3.9.3 Suporte gerenciado ao usuário

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

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

3.10. Acessibilidade

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

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

[C-1-1] É PRECISO 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 fornecer o AccessibilityEvent apropriado a todas as implementações registradas de AccessibilityService, conforme documentado no SDK.
[C-1-4] É OBRIGATÓRIO adicionar um botão na barra de navegação do sistema que permita ao usuário controlar o serviço de acessibilidade quando os serviços de acessibilidade ativados declararem o AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Para implementações de dispositivo sem barra de navegação do sistema, esse requisito não é aplicável, mas as implementações de dispositivo precisam fornecer uma característica do usuário para controlar esses serviços de acessibilidade.

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

[C-2-1] É PRECISO implementar esses serviços de acessibilidade pré-instalados como apps compatíveis com a inicialização direta quando o armazenamento de dados for criptografado com criptografia baseada em arquivos (FBE).
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 tela e os gestos de ampliação.

3.11. Conversão de texto em voz

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

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

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

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

[C-2-1] É PRECISO fornecer ao usuário uma affordance para permitir que ele selecione um mecanismo de TTS para uso no nível do sistema.

3.12. TV Input Framework

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

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

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

3.13. Configurações rápidas

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

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

[C-1-1] 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 é permitido adicionar automaticamente um bloco de um app de terceiros diretamente às Configurações rápidas.
[C-1-3] É OBRIGATÓRIO mostrar todos os blocos adicionados pelo usuário de apps de terceiros junto com os blocos de configurações rápidas fornecidos pelo sistema.

3.14. Interface de mídia

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

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

3.15. Instant Apps

As implementações de dispositivos precisam atender aos seguintes requisitos:

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

Se as implementações do dispositivo oferecerem suporte a apps instantâneos, elas:

[C-1-1] É OBRIGATÓRIO fornecer as seguintes affordances do usuário para interagir com apps instantâneos. O AOSP atende aos requisitos com a interface do sistema, as configurações e o iniciador padrão.
[C-1-2] É OBRIGATÓRIO fornecer uma ação do usuário para visualizar e excluir apps instantâneos armazenados em cache localmente para cada pacote de app individual.
[C-1-3] É OBRIGATÓRIO fornecer uma notificação persistente ao usuário que possa ser recolhida enquanto um app instantâneo estiver em execução em primeiro plano. Essa notificação precisa incluir que os apps instantâneos não exigem instalação e oferecer um affordance que direcione o usuário à tela de informações do aplicativo nas Configurações. Para apps instantâneos iniciados por intents da Web, conforme definido pelo uso de uma intent com a ação definida como Intent.ACTION_VIEW e com um esquema de "http" ou "https", uma affordance adicional do usuário DEVE permitir que o usuário não inicie o app instantâneo e inicie o link associado com o navegador da Web configurado, se um navegador estiver disponível no dispositivo.
[C-1-4] É PRECISO permitir que os apps instantâneos em execução sejam acessados pela função "Recentes", se ela estiver disponível no dispositivo.
[C-1-5] É OBRIGATÓRIO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para as intents listadas no SDK e torná-las visíveis para apps instantâneos.

3.16. Pareamento de dispositivo complementar

O Android inclui suporte ao pareamento de dispositivos complementares para gerenciar a associação com mais eficiência e oferece a API CompanionDeviceManager para que os apps acessem esse recurso.

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

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

3.17. Apps pesados

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

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

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

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

3.18. Contatos

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

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

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

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

Implementações de dispositivos:

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

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

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

4. Compatibilidade de empacotamento de apps

Implementações de dispositivos:

[C-0-1] É PRECISO ser capaz de instalar e executar arquivos ".apk" do Android gerados pela ferramenta "aapt" incluída no SDK oficial do Android.
Como o requisito acima pode ser desafiador, é RECOMENDÁVEL que as implementações de dispositivos usem o sistema de gerenciamento de pacotes da implementação de referência do AOSP.

Implementações de dispositivos:

[C-0-2] É PRECISO oferecer suporte à verificação de arquivos ".apk" usando o Esquema de assinatura de APK v3 , o Esquema de assinatura de APK v2 e a assinatura JAR.
[C-0-3] NÃO É PERMITIDO estender os formatos .apk, Android Manifest, Dalvik bytecode ou bytecode do RenderScript de modo a impedir a instalação e a execução correta desses arquivos em outros dispositivos compatíveis.
[C-0-4] NÃO É PERMITIDO que apps que não sejam o "instalador de registro" atual do pacote desinstalem o app silenciosamente sem nenhuma confirmação do usuário, conforme documentado no SDK para a permissão DELETE_PACKAGE. As únicas exceções são o app verificador de pacotes do sistema que processa a intent PACKAGE_NEEDS_VERIFICATION e o app gerenciador de armazenamento que processa a intent ACTION_MANAGE_STORAGE.
[C-0-5] PRECISA ter uma atividade que processe a intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] NÃO É PERMITIDO instalar pacotes de apps de fontes desconhecidas, a menos que o app que solicita a instalação atenda a todos os requisitos abaixo:
- Ele PRECISA declarar a permissão REQUEST_INSTALL_PACKAGES ou ter o android:targetSdkVersion definido como 24 ou menos.
- O usuário precisa ter concedido permissão para instalar apps de fontes desconhecidas.
DEVE fornecer uma capacidade do usuário para conceder/revogar a permissão de instalação de apps de fontes desconhecidas por aplicativo, mas PODE escolher implementar isso como uma operação nula e retornar RESULT_CANCELED para startActivityForResult(), se a implementação do dispositivo não permitir que os usuários tenham essa escolha. No entanto, mesmo nesses casos, eles PRECISAM indicar ao usuário por que essa opção não foi apresentada.
[C-0-7] É OBRIGATÓRIO mostrar uma caixa de diálogo de aviso com a string de aviso fornecida pela API do sistema PackageManager.setHarmfulAppWarning ao usuário antes de iniciar uma atividade em um aplicativo marcado pela mesma API do sistema PackageManager.setHarmfulAppWarning como potencialmente prejudicial.
DEVE fornecer uma capacidade para o usuário escolher desinstalar ou iniciar um aplicativo na caixa de diálogo de aviso.
[C-0-8] É PRECISO implementar suporte para o sistema de arquivos incrementais, conforme documentado aqui.
[C-0-9] PRECISA oferecer suporte à verificação de arquivos .apk usando o Esquema de assinatura de APK v4.
Se as implementações do dispositivo já foram lançadas em uma versão anterior do Android e não puderem atender aos requisitos [C-0-8] e [C-0-9] com uma atualização de software do sistema, elas PODEM ser isentas desses requisitos.

5. Compatibilidade com multimídia

Implementações de dispositivos:

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

Implementações de dispositivos:

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

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

Nem o Google nem a Open Handset Alliance representam que esses codecs estão livres de patentes de terceiros. Quem pretende usar esse código-fonte em produtos de hardware ou software deve saber que as implementações desse código, incluindo em software de código aberto ou shareware, podem exigir licenças de patente dos detentores relevantes.

5.1. Codecs de mídia

5.1.1. Codificação de áudio

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

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

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

Todos os codificadores de áudio precisam ter suporte a:

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

5.1.2. Decodificação de áudio

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

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

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

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

[C-2-1] A decodificação PRECISA ser realizada sem downmix. Por exemplo, um stream AAC 5.0 precisa ser decodificado para cinco canais de PCM, e um stream AAC 5.1 precisa ser decodificado para seis canais de PCM.
[C-2-2] Os metadados de alcance dinâmico precisam ser definidos em "Controle de alcance dinâmico (DRC)" na ISO/IEC 14496-3 e nas chaves DRC android.media.MediaFormat para configurar os comportamentos relacionados ao alcance 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.
[SR] É ALTAMENTE RECOMENDADO que os requisitos C-2-1 e C-2-2 acima sejam atendidos por todos os decodificadores de áudio AAC.

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

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

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

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

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

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

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

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

5.1.3. Detalhes dos codecs de áudio

Formato/Codec	Detalhes	Tipos de arquivo/formatos de contêiner com suporte
Perfil MPEG-4 AAC (AAC LC)	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) AAC bruto ADTS (.aac, ADIF não é compatível) MPEG-TS (.ts, não pesquisável, apenas decodificação) Matroska (.mkv, somente decodificação)
Perfil MPEG-4 HE AAC (AAC+)	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)
Perfil MPEG-4 HE AACv2 (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 - Wideband Speech Codec	3GPP (.3gp)
FLAC	Para o codificador e o decodificador: pelo menos os modos mono e estéreo precisam ter suporte. É necessário oferecer suporte a taxas de amostragem de até 192 kHz e resolução de 16 e 24 bits. 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-320 kbps.	MP3 (.mp3) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv, somente decodificação)
MIDI	MIDI tipos 0 e 1. DLS versões 1 e 2. XMF e XMF para celular. Compatível com os formatos de toque RTTTL/RTX, OTA e iMelody.	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis		Ogg (.ogg) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv) WebM (.webm)
PCM/WAVE	O codec PCM precisa ter suporte a PCM linear de 16 bits e ponto flutuante de 16 bits. O extrator WAVE precisa oferecer suporte a PCM linear de 16, 24 e 32 bits e ponto flutuante de 32 bits (taxas até o limite do hardware). As taxas de amostragem precisam ter suporte de 8 kHz a 192 kHz.	WAVE (.wav)
Opus	Decodificação: compatibilidade com conteúdo mono, estéreo, 5.0 e 5.1 com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz. Codificação: compatibilidade com conteúdo mono e estéreo com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv) WebM (.webm)

5.1.4. Codificação de imagem

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

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

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

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

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

5.1.5. Decodificação de imagem

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

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

[C-0-1] JPEG
[C-0-2] GIF
[C-0-3] PNG
[C-0-4] BMP
[C-0-5] WebP
[C-0-6] Bruto

Se as implementações do dispositivo oferecerem suporte à decodificação de vídeo HEVC, elas: * [C-1-1] TERÃO que oferecer suporte à decodificação de imagem HEIF (HEIC).

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

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

5.1.6. Detalhes dos codecs de imagem

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

Codificadores e decodificadores de imagem expostos pela API MediaCodec

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

5.1.7. Codecs de vídeo

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

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

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

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

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

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

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

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

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

5.1.8. Lista de codecs de vídeo

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

5.1.9. Segurança do codec de mídia

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

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

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

[C-1-1] É NECESSÁRIO oferecer suporte a codecs de mídia usando APIs OMX ou Codec 2.0 (ou ambas), como no Projeto Android Open Source, e não desativar ou contornar as proteções de segurança. Isso não significa que todos os codecs precisam usar a API OMX ou Codec 2.0, mas que o suporte a pelo menos uma dessas APIs precisa estar disponível e incluir as proteções de segurança presentes.
[C-SR] É ALTAMENTE RECOMENDADO incluir suporte à API Codec 2.0.

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

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

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

[C-3-1] É necessário incluir o codec de software Codec 2.0 correspondente do Projeto de código aberto do Android (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) aceito pelo dispositivo.
[C-3-2] É OBRIGATÓRIO incluir os codecs de software Codec 2.0 no processo de codec de software, conforme fornecido no Projeto de código aberto do Android, para permitir o acesso mais restrito a codecs de software.
[C-3-3] Codecs que têm nomes que começam com "c2.android". PRECISAM ser baseadas no código-fonte do Android Open Source Project.

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

Se as implementações do dispositivo oferecerem suporte a codecs de mídia, elas:

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

Especificamente, as seguintes:

[C-1-2] Codecs com nomes que começam com "OMX." PRECISA usar as APIs OMX e ter nomes que estejam em conformidade com as diretrizes de nomenclatura do OMX IL.
[C-1-3] Codecs com nomes que começam com "c2". PRECISA usar a API Codec 2.0 e ter nomes que estejam em conformidade com as diretrizes de nomenclatura do Codec 2.0 para Android.
[C-1-4] Codecs com nomes que começam com "OMX.google." ou "c2.android." NÃO pode ser caracterizado como fornecedor ou acelerado por hardware.
[C-1-5] Os codecs executados em um processo de codec (fornecedor ou sistema) que tenham acesso a drivers de hardware, exceto alocadores de memória e mapeadores, NÃO PODEM ser caracterizados como exclusivos de software.
[C-1-6] Os codecs que não estão presentes no Android Open Source Project ou não são baseados no código-fonte desse projeto PRECISAM ser caracterizados como fornecedores.
[C-1-7] Os codecs que usam aceleração de hardware PRECISAM ser caracterizados como acelerados por hardware.
[C-1-8] Os nomes dos codecs NÃO podem ser enganosos. Por exemplo, codecs com o nome "decoders" precisam ter suporte à decodificação, e aqueles com o nome "encoders" precisam ter suporte à codificação. Os codecs com nomes que contêm formatos de mídia PRECISAM ter suporte a esses formatos.

Se as implementações do dispositivo oferecerem suporte a codecs de vídeo:

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

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

[C-2-2] Os codecs de vídeo caracterizados como acelerados por hardware PRECISAM publicar informações sobre pontos de desempenho. Elas precisam listar todos os pontos de desempenho padrão aceitos (listados na API PerformancePoint), a menos que sejam cobertos por outro ponto de desempenho padrão aceito.
Além disso, eles precisam publicar pontos de desempenho estendidos se oferecerem suporte a desempenho de vídeo sustentado diferente de um dos padrões listados.

5.2. Codificação de vídeo

Se as implementações de dispositivos oferecerem suporte a qualquer codificador de vídeo e o disponibilizarem para apps de terceiros, elas:

NÃO deve ser, em duas janelas deslizantes, mais de 15% do bitrate entre intervalos intraframe (I-frame).
NÃO pode ser mais de 100% do que o bitrate em uma janela deslizante de 1 segundo.

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

[C-1-1] É PRECISO incluir o suporte a pelo menos um dos codificadores de vídeo VP8 ou H.264 e disponibilizá-lo para aplicativos de terceiros.
DEVE oferecer suporte aos codificadores de vídeo VP8 e H.264 e disponibilizá-los para aplicativos de terceiros.

Se as implementações de dispositivos oferecerem suporte a qualquer um dos codificadores de vídeo H.264, VP8, VP9 ou HEVC e disponibilizarem esse suporte para aplicativos de terceiros, elas:

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

Se as implementações de dispositivos oferecerem suporte ao codificador de vídeo MPEG-4 SP e o disponibilizarem para apps de terceiros, elas:

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

Se as implementações do dispositivo oferecem codificadores de imagem ou vídeo com aceleração de hardware e oferecem suporte a uma ou mais câmeras de hardware anexadas ou conectadas expostas pelas APIs android.camera:

[C-4-1] Todos os codificadores de vídeo e imagem com aceleração de hardware precisam oferecer suporte à codificação de frames das câmeras de hardware.
DEVE oferecer suporte à codificação de frames das câmeras de hardware por todos os codificadores de vídeo ou imagem.

5.2.1. H.263

Se as implementações de dispositivos oferecerem suporte a codificadores H.263 e disponibilizarem esse recurso para apps de terceiros, elas:

[C-1-1] É PRECISO oferecer suporte ao nível 45 do perfil de referência.
DEVE oferecer suporte a taxas de bits configuráveis dinamicamente para o codificador compatível.

5.2.2. H.264

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

[C-1-1] É PRECISO oferecer suporte ao perfil de referência de nível 3. No entanto, o suporte para ASO (ordenação arbitrária de fatias), FMO (ordenação flexível de macroblocos) e RS (fatias redundantes) é OPCIONAL. Além disso, para manter a compatibilidade com outros dispositivos Android, RECOMENDA-SE que os codificadores não usem ASO, FMO e RS para o perfil de referência.
[C-1-2] É PRECISO oferecer suporte aos perfis de codificação de vídeo SD (definição padrão) na tabela a seguir.
DEVE oferecer suporte ao nível 4 do perfil principal.
DEVE oferecer suporte aos perfis de codificação de vídeo em HD (alta definição), conforme indicado na tabela a seguir.

Se as implementações de dispositivos informarem suporte à codificação H.264 para vídeos com resolução de 720p ou 1080p pelas APIs de mídia, elas:

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

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

5.2.3. VP8

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

[C-1-1] PRECISA oferecer suporte aos perfis de codificação de vídeo SD.
DEVE oferecer suporte aos seguintes perfis de codificação de vídeo em HD (alta definição).
[C-1-2] É PRECISO oferecer suporte à gravação de arquivos WebM do Matroska.
DEVEM fornecer um codec VP8 de hardware que atenda aos requisitos de codificação de hardware do RTC do projeto WebM, para garantir a qualidade aceitável do streaming de vídeo da Web e dos serviços de videoconferência.

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

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

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

5.2.4. VP9

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

[C-1-2] É PRECISO oferecer suporte ao perfil 0 de nível 3.
[C-1-1] É PRECISO oferecer suporte à gravação de arquivos WebM do Matroska.
[C-1-3] É PRECISO gerar dados CodecPrivate.
DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.
[SR] É ALTAMENTE RECOMENDADO oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.

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

Se as implementações do dispositivo afirmarem oferecer suporte ao Perfil 2 ou 3 pelas APIs de mídia:

O suporte ao formato de 12 bits é OPCIONAL.

5.2.5. H.265

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

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

5.3. Decodificação de vídeo

Se as implementações de dispositivos oferecerem suporte aos codecs VP8, VP9, H.264 ou H.265, elas:

[C-1-1] É PRECISO oferecer suporte à resolução dinâmica de vídeo e à alternância de frame rate pelas APIs padrão do Android no mesmo fluxo para todos os codecs VP8, VP9, H.264 e H.265 em tempo real e com a resolução máxima compatível com cada codec no dispositivo.

5.3.1. MPEG-2

Se as implementações de dispositivos oferecerem suporte a decodificadores MPEG-2, elas:

[C-1-1] PRECISA oferecer suporte ao nível alto do perfil principal.

5.3.2. H.263

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

[C-1-1] É PRECISO oferecer suporte ao nível 30 e 45 do perfil de referência.

5.3.3. MPEG-4

Se as implementações do dispositivo tiverem decodificadores MPEG-4, elas:

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

5.3.4. H.264

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

[C-1-1] É PRECISO ter suporte ao perfil principal de nível 3.1 e ao perfil de referência. O suporte a ASO (ordenação arbitrária de fatias), FMO (ordenação flexível de macrobloqueio) e RS (fatias redundantes) é OPCIONAL.
[C-1-2] É PRECISO decodificar vídeos com os perfis SD (definição padrão) listados na tabela a seguir e codificados com o perfil de referência e o perfil principal de nível 3.1 (incluindo 720p30).
DEVE ser capaz de decodificar vídeos com os perfis de alta definição, conforme indicado na tabela a seguir.

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

[C-2-1] As implementações de dispositivos precisam oferecer suporte a pelo menos uma das decodificações H.265 ou VP9 dos perfis 720p, 1080p e UHD.

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

Se as implementações de dispositivos afirmarem oferecer suporte a um perfil HDR pelas APIs de mídia:

[C-3-1] As implementações de dispositivos precisam aceitar os metadados HDR necessários do aplicativo, além de oferecer suporte à extração e saída dos metadados HDR necessários do fluxo de bits e/ou do contêiner.
[C-3-2] As implementações de dispositivos PRECISAM exibir conteúdo HDR corretamente na tela do dispositivo ou em uma porta de saída de vídeo padrão, como HDMI.

5.3.6. VP8

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

[C-1-1] É PRECISO oferecer suporte aos perfis de decodificação SD na tabela a seguir.
DEVE usar um codec VP8 de hardware que atenda aos requisitos.
DEVE oferecer suporte aos perfis de decodificação em HD na tabela a seguir.

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

[C-2-1] As implementações de dispositivos precisam oferecer suporte a perfis de 720p na tabela a seguir.
[C-2-2] As implementações de dispositivos precisam oferecer suporte a perfis de 1080p na tabela a seguir.

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

5.3.7. VP9

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

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

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

[C-2-1] É PRECISO oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.

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

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

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

Se as implementações do dispositivo afirmarem oferecer suporte a VP9Profile2 ou VP9Profile3 pelas APIs de mídia CodecProfileLevel:

O suporte ao formato de 12 bits é OPCIONAL.

Se as implementações do dispositivo afirmarem que oferecem suporte a um perfil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) pelas APIs de mídia:

[C-4-1] As implementações de dispositivos precisam aceitar os metadados HDR necessários (KEY_HDR_STATIC_INFO para todos os perfis HDR, além de 'KEY_HDR10_PLUS_INFO' para perfis HDR10Plus) do aplicativo. Eles também precisam oferecer suporte à extração e saída dos metadados HDR necessários do fluxo de bits e/ou contêiner.
[C-4-2] As implementações de dispositivos PRECISAM exibir conteúdo HDR corretamente na tela do dispositivo ou em uma porta de saída de vídeo padrão, como HDMI.

5.3.8. Dolby Vision

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

[C-1-1] É PRECISO fornecer um extrator com tecnologia Dolby Vision.
[C-1-2] É NECESSÁRIO exibir corretamente o conteúdo do Dolby Vision na tela do dispositivo ou em uma porta de saída de vídeo padrão, como HDMI.
[C-1-3] É PRECISO definir o índice de faixa das camadas básicas compatíveis com versões anteriores (se houver) para que ele seja igual ao índice de faixa da camada Dolby Vision combinada.

5.3.9. AV1

Se as implementações do dispositivo oferecem suporte ao codec AV1, elas:

[C-1-1] É PRECISO oferecer suporte ao Perfil 0, incluindo conteúdo de 10 bits.

5.4. Gravação em áudio

Embora alguns dos requisitos descritos nesta seção sejam listados como "DEVE" desde o Android 4.3, a definição de compatibilidade para versões futuras está planejada para mudar para "PRECISA". É ALTAMENTE RECOMENDÁVEL que os dispositivos Android atuais e novos atendam a esses requisitos listados como "DEVE", caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

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

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

[C-1-1] É PRECISO permitir a captura de conteúdo de áudio bruto com as seguintes características:
- Formato: PCM linear, 16 bits
- Taxas de amostragem: 8.000, 11.025, 16.000, 44.100, 48.000 Hz
- Canais: mono
DEVE permitir a captura de conteúdo de áudio bruto com as seguintes características:
- Formato: PCM linear, de 16 e 24 bits
- Taxas de amostragem: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 Hz
- Canais: o mesmo número de canais que o número de microfones no dispositivo
[C-1-2] É OBRIGATÓRIO capturar acima das taxas de amostragem sem upsampling.
[C-1-3] É necessário incluir um filtro anti-aliasing adequado quando as taxas de amostragem fornecidas acima forem capturadas com redução de amostragem.
DEVE permitir a captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, o que significa as seguintes características:
- Formato: PCM linear, 16 bits
- Taxas de amostragem: 22.050, 48.000 Hz
- Canais: estéreo
- [C-1-4] É OBRIGATÓRIO honrar a API MicrophoneInfo e preencher corretamente as informações dos microfones disponíveis no dispositivo acessíveis aos aplicativos de terceiros pela API AudioManager.getMicrophones() e os microfones ativos que podem ser acessados pelos aplicativos de terceiros pelas APIs AudioRecord.getActiveMicrophones() e MediaRecorder.getActiveMicrophones(). 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] É OBRIGATÓRIO capturar sem upsampling em qualquer proporção maior que 16000:22050 ou 44100:48000.
[C-2-2] É OBRIGATÓRIO incluir um filtro anti-aliasing adequado para qualquer upsampling ou downsampling.

5.4.2. Captura para reconhecimento de voz

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

[C-1-1] É PRECISO capturar a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION em uma das taxas de amostragem, 44100 e 48000.
[C-1-2] É OBRIGATÓRIO desativar, por padrão, qualquer processamento de áudio de redução de ruído ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
[C-1-3] É OBRIGATÓRIO desativar por padrão qualquer controle de ganho automático ao gravar um fluxo de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
DEVE gravar o fluxo de áudio de reconhecimento de voz com amplitude aproximadamente plana em relação às características de frequência: especificamente, ±3 dB, de 100 Hz a 4.000 Hz.
DEVE gravar o stream de áudio de reconhecimento de voz com a sensibilidade de entrada definida de modo que uma fonte de nível de potência sonora (SPL) de 90 dB a 1.000 Hz produza um RMS de 2.500 para amostras de 16 bits.
DEVE gravar o stream de áudio de reconhecimento de voz para que os níveis de amplitude PCM acompanhem linearmente as mudanças de SPL de entrada em pelo menos um intervalo de 30 dB de -18 dB a +12 dB em relação a 90 dB SPL no microfone.
DEVE gravar o fluxo de áudio de reconhecimento de voz com distorção harmônica total (THD, na sigla em inglês) menor que 1% para 1 kHz em 90 dB SPL no nível de entrada do microfone.

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

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

5.4.3. Captura para redirecionamento da reprodução

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

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

[C-1-1] É PRECISO implementar corretamente a fonte de áudio REMOTE_SUBMIX para que, quando um app use a API android.media.AudioRecord para gravar dessa fonte de áudio, ele capture uma mistura de todos os streams de áudio, exceto:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. Cancelamento de eco acústico

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

DEVE implementar uma tecnologia de cancelamento de eco acústico (AEC) ajustada para comunicação por voz e aplicada ao caminho de captura ao capturar usando AudioSource.VOICE_COMMUNICATION

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

[C-SR] É STRONGLY_RECOMMENDED declarar isso pelo método da API AcousticEchoCanceler AcousticEchoCanceler.isAvailable().
[C-SR] são STRONGLY_RECOMMENDED para permitir que esse efeito de áudio seja controlável com a API AcousticEchoCanceler.
[C-SR] são FORTEMENTE_RECOMENDADOS para identificar de forma exclusiva cada implementação de tecnologia de AEC pelo 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] É PRECISO permitir o acesso simultâneo ao microfone por um serviço de acessibilidade que capture com AudioSource.VOICE_RECOGNITION e pelo menos um aplicativo que capture com qualquer AudioSource.
[C-1-2] É PRECISO permitir o acesso simultâneo ao microfone por um app pré-instalado que tenha uma função do Google Assistente e pelo menos uma captura de app com qualquer AudioSource, exceto AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
[C-1-3] A captura de áudio de qualquer outro aplicativo, exceto um serviço de acessibilidade, precisa ser silenciada enquanto um aplicativo está capturando com AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. No entanto, quando um app está capturando via AudioSource.VOICE_COMMUNICATION, outro app pode capturar a chamada de voz se for um app privilegiado (pré-instalado) com a permissão CAPTURE_AUDIO_OUTPUT.
[C-1-4] Se dois ou mais aplicativos estiverem fazendo capturas simultaneamente e nenhum deles tiver uma interface por cima, o que tiver iniciado a captura mais recentemente vai receber o áudio.

5.4.6. Níveis de ganho do microfone

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

DEVEM apresentar características aproximadamente planas de amplitude versus frequência na faixa de frequência média: especificamente ±3 dB de 100 Hz a 4.000 Hz para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
DEVEM definir a sensibilidade de entrada de áudio de modo que uma fonte de tom senoidal de 1.000 Hz reproduzida em 90 dB de nível de pressão sonora (SPL) gere uma resposta com RMS de 2.500 para amostras de 16 bits (ou -22,35 dB em escala completa para amostras de ponto flutuante/dupla precisão) para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
[C-SR] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de baixa frequência: especificamente de ±20 dB de 5 Hz a 100 Hz em comparação com o intervalo de média frequência para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.
[C-SR] são ALTAMENTE RECOMENDADOS para mostrar níveis de amplitude no intervalo de alta frequência: especificamente de ±30 dB de 4.000 Hz a 22 KHz em comparação com o intervalo de frequência média para cada microfone usado para gravar a fonte de áudio de reconhecimento de voz.

5.5. Reprodução de áudio

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

5.5.1. Reprodução de áudio bruto

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

[C-1-1] É PRECISO permitir a reprodução de conteúdo de áudio bruto com as seguintes características:
- Formatos de origem: PCM linear, 16 bits, 8 bits, ponto flutuante
- Canais: mono, estéreo, configurações válidas de multicanal com até 8 canais
- Taxas de amostragem (em Hz):
  - 8000, 11025, 16000, 22050, 32000, 44100, 48000 nas configurações de canal listadas acima
  - 96000 em mono e estéreo
DEVE permitir a reprodução de conteúdo de áudio bruto com as seguintes características:
- Taxas de amostragem: 24.000, 48.000

5.5.2. Efeitos de áudio

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

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

[C-1-1] PRECISA oferecer suporte às implementações EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controláveis pelas subclasses AudioEffect Equalizer e LoudnessEnhancer.
[C-1-2] PRECISA oferecer suporte à implementação da API do visualizador, controlável pela classe Visualizer.
[C-1-3] PRECISA oferecer suporte à implementação de EFFECT_TYPE_DYNAMICS_PROCESSING controlável pela subclasse AudioEffect DynamicsProcessing.
DEVE oferecer suporte às implementações EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controláveis pelas subclasses AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.
[C-SR] É ALTAMENTE RECOMENDADO oferecer suporte a efeitos em ponto flutuante e multicanal.

5.5.3. Volume de saída de áudio

Implementações de dispositivos automotivos:

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

5.6. Latência de áudio

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

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

Latência de saída. O intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e o momento em que o som correspondente é apresentado ao ambiente em um transdutor no dispositivo ou o sinal sai do dispositivo por uma porta e pode ser observado externamente.
Latência de saída fria. A latência de saída do primeiro frame, quando o sistema de saída de áudio estava inativo e desligado antes da solicitação.
latência de saída contínua. A latência de saída para frames subsequentes, depois que o dispositivo começa a reproduzir áudio.
latência de entrada. O intervalo entre o momento em que um som é apresentado pelo ambiente ao dispositivo em um transdutor no dispositivo ou o sinal entra no dispositivo por uma porta e o momento em que um aplicativo lê o frame correspondente de dados codificados em PCM.
perda de entrada. A parte inicial de um sinal de entrada que está indisponível ou não pode ser usado.
Latência de entrada fria. A soma do tempo de entrada perdido e a latência de entrada do primeiro frame, quando o sistema de entrada de áudio estava inativo e desligado antes da solicitação.
latente de entrada contínua. A latência de entrada para frames subsequentes, enquanto o dispositivo está capturando áudio.
Jitter de saída fria. A variabilidade entre medições separadas de valores de latência de saída fria.
Jitter de entrada fria. A variabilidade entre medições separadas de valores de latência de entrada fria.
latência de ida e volta contínua. A soma da latência de entrada contínua mais a latência de saída contínua mais um período de buffer. O período de buffer permite que o app processe o sinal e mitigue a diferença de fase entre os streams de entrada e saída.
API da fila de buffer de PCM do OpenSL ES. O conjunto de APIs OpenSL ES relacionadas ao PCM no Android NDK.
API de áudio nativa AAudio. O conjunto de APIs AAudio no Android NDK.
Carimbo de data/hora. Um par que consiste em uma posição de frame relativa em um stream e o tempo estimado em que esse frame entra ou sai do pipeline de processamento de áudio no endpoint associado. Consulte também AudioTimestamp.
glitch. Uma interrupção temporária ou um valor de amostra incorreto no sinal de áudio, normalmente causado por um buffer underrun para saída, buffer overrun para entrada ou qualquer outra fonte de ruído digital ou analógico.

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

[C-1-1] O carimbo de data/hora de saída retornado por AudioTrack.getTimestamp e AAudioStream_getTimestamp é preciso com uma margem de +/- 2 ms.
[C-1-2] Latência de saída fria de 500 milissegundos ou menos.

Se as implementações do dispositivo declararem android.hardware.audio.output, é ALTAMENTE RECOMENDÁVEL que elas atendam ou excedam os seguintes requisitos:

[C-SR] Latência de saída fria de 100 milissegundos ou menos. É MUITO RECOMENDÁVEL que os dispositivos novos e atuais que executam essa versão do Android atendam a esses requisitos. Em uma versão futura da plataforma em 2021, vamos exigir uma latência de saída fria de 200 ms ou menos.
[C-SR] Latência de saída contínua de 45 milissegundos ou menos.
[C-SR] Minimizar o jitter de saída a frio.
[C-SR] 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 do dispositivo atenderem aos requisitos acima, após qualquer calibração inicial, ao usar a fila de buffer PCM do OpenSL ES e as APIs de áudio nativas do AAudio, para latência de saída contínua e latência de saída fria em pelo menos um dispositivo de saída de áudio com suporte, elas são:

[C-SR] É ALTAMENTE RECOMENDADO informar áudio de baixa latência declarando a flag de recurso android.hardware.audio.low_latency.
[C-SR] É FORTEMENTE RECOMENDADO atender aos requisitos de áudio de baixa latência usando a API AAudio.
[C-SR] É ALTAMENTE RECOMENDADO garantir que, para streams que retornam AAUDIO_PERFORMANCE_MODE_LOW_LATENCY de AAudioStream_getPerformanceMode(), o valor retornado por AAudioStream_getFramesPerBurst() seja menor ou igual ao valor retornado por android.media.AudioManager.getProperty(String) para a chave de propriedade AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Se as implementações do dispositivo não atenderem aos requisitos de áudio de baixa latência usando a fila de buffer PCM do OpenSL ES e as APIs de áudio nativas do AAudio, elas:

[C-2-1] NÃO é necessário informar suporte a áudio de baixa latência.

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

[C-3-1] Limitar o erro nas marcações de tempo de entrada, conforme retornado por AudioRecord.getTimestamp ou AAudioStream_getTimestamp, a +/- 2 ms. "Erro" significa a variação em relação ao valor correto.
[C-3-2] Latência de entrada fria de 500 milissegundos ou menos.

Se as implementações do dispositivo incluírem android.hardware.microphone, é ALTAMENTE RECOMENDÁVEL que elas atendam a estes requisitos de áudio de entrada:

[C-SR] Latência de entrada fria de 100 milissegundos ou menos. É MUITO RECOMENDÁVEL que os dispositivos novos e atuais que executam essa versão do Android atendam a esses requisitos. Em uma versão futura da plataforma em 2021, vamos exigir uma latência de entrada fria de 200 ms ou menos.
[C-SR] Latência de entrada contínua de 30 milissegundos ou menos.
[C-SR] Latência de ida e volta contínua de 50 milissegundos ou menos.
[C-SR] Minimizar o jitter de entrada a frio.
[C-SR] Limitar o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp ou AAudioStream_getTimestamp, a +/- 1 ms.

5.7. Protocolos de rede

As implementações de dispositivos precisam oferecer suporte aos protocolos de rede de mídia para reprodução de áudio e vídeo, conforme especificado na documentação do SDK do Android.

Se as implementações do dispositivo incluírem um decodificador de áudio ou vídeo, elas:

[C-1-1] É PRECISO oferecer suporte a todos os codecs e formatos de contêiner necessários na seção 5.1 por HTTP(S).
[C-1-2] É necessário oferecer suporte aos formatos de segmento de mídia mostrados na tabela "Formatos de segmento de mídia" abaixo no rascunho do protocolo HTTP Live Streaming, versão 7.
[C-1-3] É PRECISO oferecer suporte ao seguinte perfil de vídeo de áudio RTP e codecs relacionados na tabela RTSP abaixo. Para exceções, consulte as notas de rodapé da tabela na seção 5.1.

Formatos de segmento de mídia

Formatos de segmentos	Referência(s)	Suporte a codec obrigatório
Stream de transporte MPEG-2	ISO 13818	Codecs de vídeo: H264 AVC MPEG-4 SP MPEG-2 Consulte a seção 5.1.3 para saber mais sobre o H.264 AVC, o MPEG2-4 SP, e o MPEG-2. Codecs de áudio: AAC Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes.
AAC com enquadramento ADTS e tags ID3	ISO 13818-7	Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes
WebVTT	WebVTT

Formatos de segmentos

Referência(s)

Suporte a codec obrigatório

Stream de transporte MPEG-2

ISO 13818

Codecs de vídeo:

H264 AVC
MPEG-4 SP
MPEG-2

Consulte a seção 5.1.3 para saber mais sobre o H.264 AVC, o MPEG2-4 SP,
e o MPEG-2.

Codecs de áudio:

Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes.

AAC com enquadramento ADTS e tags ID3

ISO 13818-7

Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes

WebVTT

RTSP (RTP, SDP)

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

5.8. Secure Media

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

[C-1-1] É PRECISO declarar suporte para Display.FLAG_SECURE.

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

[C-2-1] É OBRIGATÓRIO proteger a vinculação com um mecanismo criptograficamente seguro, como o HDCP 2.x ou mais recente, para as telas conectadas por protocolos sem fio, como o Miracast.

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

[C-3-1] É NECESSÁRIO 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 dispositivo informarem suporte ao recurso android.software.midi pela classe android.content.pm.PackageManager, elas:

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

5.10. Áudio profissional

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

[C-1-1] É PRECISO informar o suporte ao recurso android.hardware.audio.low_latency.
[C-1-2] A latência de áudio de ida e volta contínua, conforme definido na seção 5.6 Latência de áudio, PRECISA ser de 20 milissegundos ou menos e DEVE ser de 10 milissegundos ou menos em pelo menos um caminho compatível.
[C-1-3] É PRECISO incluir portas USB com suporte para o modo de host USB e o modo de periférico USB.
[C-1-4] É PRECISO informar o suporte ao recurso android.software.midi.
[C-1-5] É PRECISO atender às latências e aos requisitos de áudio USB usando a API de fila de buffer PCM do OpenSL ES e pelo menos um caminho da API de áudio nativo AAudio.
[SR] É ALTAMENTE RECOMENDADO atender às latências e aos requisitos de áudio USB usando a API AAudio native audio no caminho MMAP.
[C-1-6] A latência de saída fria PRECISA ser de 200 milissegundos ou menos.
[C-1-7] A latência de entrada fria PRECISA ser de 200 milissegundos ou menos.
[SR] É ALTAMENTE RECOMENDADO fornecer um nível consistente de desempenho da CPU enquanto o áudio está ativo e a carga da CPU está variando. Isso precisa ser testado usando a versão do app Android do id de confirmação SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. O SynthMark usa um sintetizador de software em execução em um framework de áudio simulado que mede o desempenho do sistema. O app SynthMark precisa ser executado usando a opção "Teste automatizado" e alcançar os seguintes resultados:
- voicemark.90 >= 32 vozes
- latencymark.fixed.little <= 15 msec
- latencymark.dynamic.little <= 50 msec

Consulte a documentação do SynthMark para uma explicação dos comparativos.

DEVE minimizar a imprecisão e a deriva do relógio de áudio em relação ao horário padrão.
DEVE minimizar a deriva do relógio de áudio em relação à CLOCK_MONOTONIC da CPU quando ambos estão ativos.
DEVE minimizar a latência de áudio em transdutores no dispositivo.
DEVE minimizar a latência de áudio por áudio digital USB.
DEVE documentar as medições de latência de áudio em todos os caminhos.
DEVE minimizar o jitter nos tempos de entrada de callback de conclusão do buffer de áudio, porque isso afeta a porcentagem utilizável da largura de banda total da CPU pelo callback.
DEVE não apresentar falhas de áudio no uso normal com a latência informada.
DEVE fornecer zero diferença de latência entre canais.
DEVE minimizar a latência média do MIDI em todos os transportes.
DEVE minimizar a variabilidade da latência MIDI sob carga (jitter) em todos os transportes.
DEVE fornecer carimbos de data/hora MIDI precisos em todos os transportes.
DEVE minimizar o ruído do sinal de áudio em transdutores no dispositivo, incluindo o período imediatamente após a inicialização a frio.
DEVE fornecer zero diferença de relógio de áudio entre os lados de entrada e saída dos endpoints correspondentes, quando ambos estão ativos. Exemplos de pontos finais correspondentes incluem o microfone e o alto-falante no dispositivo ou a entrada e a saída da entrada de áudio.
DEVE processar callbacks de conclusão de buffer de áudio para os lados de entrada e saída dos endpoints correspondentes na mesma linha de execução quando ambos estiverem ativos e entrar no callback de saída imediatamente após o retorno do callback de entrada. Ou, se não for viável processar os callbacks na mesma linha de execução, insira o callback de saída logo após inserir o callback de entrada para permitir que o aplicativo tenha um tempo consistente dos lados de entrada e saída.
DEVE minimizar a diferença de fase entre o buffer de áudio HAL para os lados de entrada e saída dos endpoints correspondentes.
DEVE minimizar a latência de toque.
DEVE minimizar a variabilidade da latência do toque sob carga (jitter).
DEVE ter uma latência da entrada de toque para a saída de áudio menor ou igual a 40 ms.

Se as implementações do dispositivo atenderem a todos os requisitos acima, elas:

[SR] É ALTAMENTE RECOMENDADO informar o suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager.

Se as implementações do dispositivo incluírem um conector de áudio de 3,5 mm com quatro condutores, elas:

[C-2-1] A latência de ida e volta contínua do áudio precisa ser de 20 milissegundos ou menos no caminho da entrada de áudio.
[SR] É ALTAMENTE RECOMENDADO obedecer à seção Especificações de dispositivos móveis (jack) da Especificação de fones de ouvido com áudio com fio (v1.1).
A latência de áudio de ida e volta contínua DEVE ser de 10 milissegundos ou menos no caminho da entrada de áudio.

Se as implementações do dispositivo omitirem uma entrada de áudio de 3,5 mm com quatro condutores e incluírem portas USB com suporte ao modo host USB, elas:

[C-3-1] É OBRIGATÓRIO implementar a classe de áudio USB.
[C-3-2] É PRECISO ter uma latência de áudio de ida e volta contínua de 20 milissegundos ou menos na porta do modo host USB usando a classe de áudio USB.
A latência de ida e volta contínua do áudio DEVE ser de 10 milissegundos ou menos na porta do modo host USB usando a classe de áudio USB.
[C-SR] É ALTAMENTE RECOMENDADO que ofereçam suporte a E/S simultânea de até 8 canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usados com periféricos de áudio USB que também oferecem suporte a esses requisitos.

Se as implementações do dispositivo incluem uma porta HDMI, elas:

DEVE oferecer suporte à saída em estéreo e oito canais com profundidade de 20 ou 24 bits e 192 kHz sem perda de profundidade de bits ou reamostragem, em pelo menos uma configuração.

5.11. Captura para "Não processado"

O Android inclui suporte para gravação de áudio não processado pela fonte de áudio android.media.MediaRecorder.AudioSource.UNPROCESSED. No OpenSL ES, ele pode ser acessado com a predefinição de gravação SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Se as implementações de dispositivos tiverem a intenção de oferecer suporte à fonte de áudio não processada e disponibilizá-la para apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO informar o suporte usando a propriedade android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] É PRECISO mostrar características aproximadamente planas de amplitude em relação à frequência na faixa de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz para cada microfone usado para gravar a fonte de áudio não processada.
[C-1-3] PRECISA mostrar níveis de amplitude na faixa de baixa frequência: especificamente de ±20 dB de 5 Hz a 100 Hz em comparação com a faixa de frequência média de cada microfone usado para gravar a fonte de áudio não processada.
[C-1-4] PRECISA apresentar 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 frequência média para cada microfone usado para gravar a fonte de áudio não processada.
[C-1-5] É PRECISO definir a sensibilidade de entrada de áudio de modo que uma fonte de tom senoidal de 1.000 Hz reproduzida a 94 dB de nível de pressão sonora (SPL) produza uma resposta com RMS de 520 para amostras de 16 bits (ou -36 dB em escala completa para amostras de ponto flutuante/dupla precisão) para cada microfone usado para gravar a fonte de áudio não processada.
[C-1-6] É OBRIGATÓRIO ter uma relação sinal-ruído (SNR) de 60 dB ou mais para cada microfone usado para gravar a fonte de áudio não processada. O SNR é medido como a diferença entre 94 dB SPL e SPL equivalente de ruído próprio, ponderado em A.
[C-1-7] PRECISA ter uma distorção harmônica total (THD) menor que 1% para 1 kHz a 90 dB SPL de nível de entrada em cada microfone usado para gravar a fonte de áudio não processada.
NÃO pode ter nenhum outro processamento de sinal (por exemplo, controle automático de ganho, filtro passa-alta ou cancelamento de eco) no caminho, exceto um multiplicador de nível para levar o nível ao intervalo desejado. Resumindo:
[C-1-8] Se qualquer processamento de sinal estiver presente na arquitetura por qualquer motivo, ele PRECISA ser desativado e introduzir zero atraso ou latência extra no caminho do sinal.
[C-1-9] O multiplicador de nível, embora permitido no caminho, NÃO PODE introduzir atraso ou latência no caminho do sinal.

Todas as medições de SPL são feitas diretamente ao lado do microfone em teste. Para várias configurações de microfone, esses requisitos se aplicam a cada microfone.

Se as implementações do dispositivo declararem android.hardware.microphone, mas não forem compatíveis com a fonte de áudio não processada, elas:

[C-2-1] É PRECISO retornar null para o método da API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) para indicar corretamente a falta de suporte.
[SR] ainda é FORTEMENTE RECOMENDADO para atender a tantos requisitos quanto possível para o caminho do indicador da fonte de gravação não processada.

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

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

[C-0-1] É PRECISO oferecer suporte às ferramentas para desenvolvedores do Android fornecidas no SDK do Android.
Android Debug Bridge (adb)
- [C-0-2] É PRECISO oferecer suporte ao adb conforme documentado no SDK do Android e aos comandos do shell fornecidos no AOSP, que podem ser usados por desenvolvedores de apps, incluindo dumpsys cmd stats
- [C-0-11] É PRECISO ter suporte ao comando de shell cmd testharness. A atualização de implementações de dispositivos de uma versão anterior do Android sem um bloco de dados persistente PODE ser isenta da C-0-11.
- [C-0-3] NÃO MUDAR o formato ou o conteúdo dos eventos do sistema do dispositivo (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrados pelo comando dumpsys.
- [C-0-10] É OBRIGATÓRIO registrar, sem omissão, e tornar os eventos a seguir acessíveis e disponíveis para o comando de shell cmd stats e a classe da API System StatsManager.
  - ActivityForegroundStateChanged
  - AnomalyDetected
  - AppBreadcrumbReported
  - AppCrashOccurred
  - AppStartOccurred
  - BatteryLevelChanged
  - BatterySaverModeStateChanged
  - BleScanResultReceived
  - BleScanStateChanged
  - ChargingStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - PluggedStateChanged
  - ScheduledJobStateChanged
  - ScreenStateChanged
  - SyncStateChanged
  - SystemElapsedRealtime
  - UidProcessStateChanged
  - WakelockStateChanged
  - WakeupAlarmOccurred
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - WifiScanStateChanged
- [C-0-4] O daemon adb do dispositivo PRECISA estar inativo por padrão, e é PRECISO ter um mecanismo acessível ao usuário para ativar a ponte de depuração do Android.
- [C-0-5] É PRECISO oferecer suporte ao adb seguro. O Android inclui suporte para adb seguro. O adb seguro ativa o adb em hosts autenticados conhecidos.
- [C-0-6] É PRECISO fornecer um mecanismo que permita que o adb seja conectado de uma máquina host. Especificamente:
Se as implementações de dispositivos sem uma porta USB forem compatíveis com o modo periférico, elas:
- [C-3-1] É PRECISO implementar o adb por uma rede de área local (como Ethernet ou Wi-Fi).
- [C-3-2] É OBRIGATÓRIO fornecer drivers para Windows 7, 8 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.
Se as implementações do dispositivo oferecem suporte a conexões adb com uma máquina host via Wi-Fi, elas:
- [C-4-1] O método AdbManager#isAdbWifiSupported() PRECISA retornar true.
Se as implementações do dispositivo oferecem suporte a conexões adb com uma máquina host via Wi-Fi e incluem pelo menos uma câmera, elas:
- [C-5-1] O método AdbManager#isAdbWifiQrSupported() PRECISA retornar true.
Serviço de monitoramento de depuração do Dalvik (ddms)
- [C-0-7] PRECISA oferecer suporte a todos os recursos do ddm, conforme documentado no SDK do Android. Como o ddms usa o adb, o suporte a ele DEVE estar inativo por padrão, mas PRECISA ser compatível sempre que o usuário ativar a ponte de depuração do Android, como acima.
Monkey
- [C-0-8] É PRECISO incluir o framework Monkey e disponibilizá-lo para uso de aplicativos.
SysTrace
- [C-0-9] PRECISA oferecer suporte à ferramenta systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão e PRECISA haver um mecanismo acessível ao usuário para ativar o Systrace.
Perfetto
- [C-SR] É ALTAMENTE RECOMENDADO expor um binário /system/bin/perfetto ao usuário do shell, em que o cmdline obedece à documentação do perfetto.
- [C-SR] O binário do perfetto é ALTAMENTE RECOMENDADO para aceitar como entrada uma configuração protobuf que esteja em conformidade com o esquema definido na documentação do perfetto.
- [C-SR] O binário do Perfetto é ALTAMENTE RECOMENDADO para gravar como saída um trace de protobuf que obedece ao esquema definido na documentação do Perfetto.
- [C-SR] É ALTAMENTE RECOMENDADO fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto.
Low Memory Killer
- [C-0-10] É PRECISO gravar um átomo LMK_KILL_OCCURRED_FIELD_NUMBER no registro de statsd quando um app for encerrado pelo Low Memory Killer.
Modo de teste do harness Se as implementações do dispositivo oferecem suporte ao comando de shell cmd testharness e executam cmd testharness enable, elas:
- [C-2-1] PRECISA retornar true para ActivityManager.isRunningInUserTestHarness()
- [C-2-2] É OBRIGATÓRIO implementar o modo de arcabouço de testes conforme descrito na documentação do modo de arcabouço de testes.

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

[C-1-1] É OBRIGATÓRIO fornecer uma capacidade para que o desenvolvedor do app ative/desative as camadas de depuração de GPU.
[C-1-2] Quando as camadas de depuração da GPU estiverem ativadas, é OBRIGATÓRIO enumerar as camadas em bibliotecas fornecidas por ferramentas externas (ou seja, que não fazem parte do pacote de plataforma ou aplicativo) encontradas no diretório de base de 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 configurem as configurações relacionadas ao desenvolvimento de apps.

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

[C-0-1] DEVE honrar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar configurações relacionadas ao desenvolvimento do app. A implementação upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários iniciem as opções do desenvolvedor depois de pressionar sete (7) vezes no item de menu Configurações > Sobre o dispositivo > Número da versão.
[C-0-2] É OBRIGATÓRIO ocultar as opções de desenvolvedor por padrão.
[C-0-3] É PRECISO fornecer um mecanismo claro que não dê tratamento preferencial a um app de terceiros em vez de outro para ativar as Opções do desenvolvedor. É NECESSÁRIO fornecer um documento ou site público que descreva como ativar as Opções do desenvolvedor. Esse documento ou site PRECISA ser vinculado aos documentos do SDK do Android.
DEVE ter 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 de opções para desenvolvedores, ocultando ou desativando o menu visualmente, para evitar distrações em cenários em que a segurança do usuário é uma preocupação.

7. Compatibilidade de hardware

Se um dispositivo incluir um componente de hardware específico com uma API correspondente para desenvolvedores terceirizados:

[C-0-1] A implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android.

Se uma API no SDK interagir com um componente de hardware declarado como opcional e a implementação do dispositivo não tiver esse componente:

[C-0-2] As definições de classe completas (como documentado pelo SDK) para as APIs de componentes AINDA precisam ser apresentadas.
[C-0-3] Os comportamentos da API precisam ser implementados como no-ops de maneira razoável.
[C-0-4] Os métodos da API precisam retornar valores nulos quando permitido pela documentação do SDK.
[C-0-5] Os métodos da API precisam retornar implementações sem operação de classes em que valores nulos não são permitidos pela documentação do SDK.
[C-0-6] Os métodos da API NÃO PODEM gerar exceções não documentadas pela documentação do SDK.
[C-0-7] As implementações de dispositivos PRECISAM informar de forma consistente informações precisas de configuração de hardware usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para o mesmo fingerprint de build.

Um exemplo típico de um cenário em que esses requisitos se aplicam é a API de telefonia: mesmo em dispositivos que não são smartphones, essas APIs precisam ser implementadas como no-ops razoáveis.

7.1. Tela e gráficos

O Android inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts da interface de forma adequada para o dispositivo, garantindo que os 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 com Android 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 físico diagonal. A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
pontos por polegada (dpi). O número de pixels englobados por uma extensão linear horizontal ou vertical de 1". Quando os valores de dpi são listados, tanto o dpi horizontal quanto o vertical precisam estar dentro do intervalo.
proporção. A proporção dos pixels da dimensão maior em relação à dimensão menor da tela. Por exemplo, uma tela de 480 x 854 pixels seria 854/480 = 1,779, ou aproximadamente "16:9".
pixel de densidade independente (dp). A unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como: pixels = dps * (density/160).

7.1.1. Configuração da tela

7.1.1.1. Tamanho e forma da tela

O framework da interface do Android oferece suporte a vários tamanhos de layout de tela lógicos e permite que os aplicativos consultem o tamanho do layout de tela da configuração atual usando Configuration.screenLayout com SCREENLAYOUT_SIZE_MASK e Configuration.smallestScreenWidthDp.

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO informar o tamanho correto do layout para o Configuration.screenLayout, conforme definido na documentação do SDK do Android. Especificamente, as implementações de dispositivo precisam informar as dimensões corretas da tela de pixel (dp) de densidade independente lógica, conforme abaixo:
- Dispositivos com Configuration.uiMode definido como qualquer valor diferente de UI_MODE_TYPE_WATCH e que informem um tamanho small para Configuration.screenLayout PRECISAM ter pelo menos 426 dp x 320 dp.
- Os dispositivos que informam um tamanho normal para o Configuration.screenLayout precisam ter pelo menos 480 dp x 320 dp.
- Os dispositivos que informam um tamanho large para o Configuration.screenLayout precisam ter pelo menos 640 dp x 480 dp.
- Os dispositivos que informam um tamanho xlarge para o Configuration.screenLayout precisam ter pelo menos 960 dp x 720 dp.
[C-0-2] É PRECISO respeitar corretamente o suporte declarado pelos aplicativos para tamanhos de tela usando o atributo <supports-screens> no AndroidManifest.xml, conforme descrito na documentação do SDK do Android.
PODE ter telas compatíveis com Android com cantos arredondados.

Se as implementações de dispositivos oferecerem suporte a UI_MODE_TYPE_NORMAL e incluirem telas compatíveis com o Android com cantos arredondados, elas:

[C-1-1] É OBRIGATÓRIO garantir que pelo menos um dos seguintes requisitos seja atendido:
O raio dos cantos arredondados é menor ou igual a 38 dp.
Quando uma caixa de 15 dp por 15 dp é ancorada em cada canto da tela lógica, pelo menos um pixel de cada caixa fica visível na tela.
DEVE incluir a capacidade do usuário de alternar para o modo de exibição com cantos retangulares.

Se as implementações de dispositivos incluírem telas compatíveis com o Android que sejam dobráveis ou incluírem uma articulação dobrável entre vários painéis de tela e disponibilizarem essas telas para renderização de apps de terceiros, elas:

[C-2-1] É PRECISO implementar a versão estável mais recente disponível da API Extensions ou a versão estável da API Sidecar para ser usada pela biblioteca Window Manager Jetpack.

Se as implementações de dispositivos incluírem telas compatíveis com o Android que sejam dobráveis ou uma articulação dobrável entre vários painéis de exibição, e se a articulação ou dobra atravessar uma janela de aplicativo em tela cheia, elas:

[C-3-1] É OBRIGATÓRIO informar a posição, os limites e o estado da articulação ou da dobra por extensões ou APIs sidecar para o aplicativo.

Para saber como implementar corretamente as APIs de sidecar ou extensão, consulte a documentação pública do Jetpack Window Manager.

7.1.1.2. Proporção da tela

Embora não haja restrição à proporção da tela física para 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 Configuration, PRECISA atender aos seguintes requisitos:

[C-0-1] As implementações de dispositivo com Configuration.uiMode definido como UI_MODE_TYPE_NORMAL PRECISAM ter um valor de proporção menor ou igual a 1,86 (aproximadamente 16:9), a menos que o app atenda a uma das seguintes condições:
- O app declarou que oferece suporte a uma proporção de tela maior pelo valor de metadados android.max_aspect.
- O app declara que é redimensionável pelo atributo android:resizeableActivity.
- O app é direcionado ao nível 24 da API ou mais recente e não declara um android:maxAspectRatio que restrinja a proporção permitida.
[C-0-2] As implementações de dispositivo com Configuration.uiMode definido como UI_MODE_TYPE_NORMAL PRECISAM ter um valor de proporção igual ou maior que 1,3333 (4:3), a menos que o app possa ser esticado para mais largura atendendo a uma das seguintes condições:
- O app declara que é redimensionável pelo atributo android:resizeableActivity.
- O app declara um android:minAspectRatio que restringe a proporção permitida.
[C-0-3] As implementações de dispositivo com Configuration.uiMode definido como UI_MODE_TYPE_WATCH PRECISAM ter um valor de proporção definido como 1,0 (1:1).

7.1.1.3. Densidade da tela

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

[C-0-1] Por padrão, as implementações de dispositivo PRECISAM informar apenas uma das densidades do framework do Android listadas em DisplayMetrics pela API DENSITY_DEVICE_STABLE, e esse valor PRECISA permanecer o mesmo. No entanto, o dispositivo PODE informar uma densidade arbitrária diferente de acordo com as mudanças de configuração de exibição feitas pelo usuário (por exemplo, tamanho da tela) definidas após a inicialização inicial.
As implementações de 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 essa densidade lógica reduza o tamanho da tela informado abaixo do mínimo suportado. Se a densidade do framework padrão do Android que é numericamente mais próxima da densidade física resultar em um tamanho de tela menor do que o menor tamanho de tela compatível com suporte (largura de 320 dp), as implementações de dispositivo PRECISAM informar a próxima densidade padrão mais baixa do framework do Android.

Se houver uma affordance para mudar o tamanho da tela do dispositivo:

[C-1-1] O tamanho da tela NÃO PODE ser dimensionado em mais de 1,5 vezes a densidade nativa ou produzir uma dimensão mínima de tela menor que 320 dp (equivalente ao qualificador de recursos sw320dp), o que ocorrer primeiro.
[C-1-2] O tamanho da tela NÃO PODE ser dimensionado para menos de 0,85 vezes a densidade nativa.
Para garantir uma boa usabilidade e tamanhos de fonte consistentes, é RECOMENDÁVEL que as seguintes opções de escalonamento de tela nativa sejam fornecidas (atendendo aos limites especificados acima):
Pequeno: 0,85x
Padrão: 1x (escala de exibição nativa)
Grande: 1,15x
Maior: 1,3x
Maior: 1,45x

7.1.2. Métricas de exibição

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

[C-1-1] É OBRIGATÓRIO informar os valores corretos para todas as métricas de exibição compatíveis com o Android definidas na API android.util.DisplayMetrics.

Se as implementações de dispositivos não incluem uma tela ou saída de vídeo incorporada, elas:

[C-2-1] É PRECISO informar os valores corretos da tela compatível com Android, conforme definido na API android.util.DisplayMetrics para o view.Display padrão emulado.

7.1.3. Orientação da tela

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO informar quais orientações de tela são compatíveis (android.hardware.screen.portrait e/ou android.hardware.screen.landscape) e é OBRIGATÓRIO informar pelo menos uma orientação compatível. Por exemplo, um dispositivo com uma tela de paisagem de orientação fixa, como uma televisão ou um laptop, DEVE informar apenas android.hardware.screen.landscape.
[C-0-2] É OBRIGATÓRIO informar o valor correto da orientação atual do dispositivo sempre que ele for consultado pela android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.

Se as implementações do dispositivo oferecerem suporte às duas orientações da tela, elas:

[C-1-1] É PRECISO oferecer suporte à orientação dinâmica por aplicativos para orientação de tela retrato ou paisagem. Ou seja, o dispositivo precisa respeitar a solicitação do aplicativo para uma orientação de tela específica.
[C-1-2] O tamanho ou a densidade da tela NÃO PODEM mudar quando a orientação é alterada.
PODE selecionar a orientação retrato ou paisagem como padrão.

7.1.4. Aceleração gráfica 2D e 3D

7.1.4.1 OpenGL ES

Implementações de dispositivos:

[C-0-1] É PRECISO identificar corretamente as versões do OpenGL ES com suporte (1.1, 2.0, 3.0, 3.1, 3.2) pelas APIs gerenciadas (como pelo método GLES10.getString()) e pelas APIs nativas.
[C-0-2] É PRECISO incluir o suporte a todas as APIs gerenciadas e nativas correspondentes para todas as versões do OpenGL ES identificadas.

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

[C-1-1] PRECISA oferecer suporte ao OpenGL ES 1.1 e 2.0, conforme definido e detalhado na documentação do SDK do Android.
[C-SR] É ALTAMENTE RECOMENDADO oferecer suporte ao OpenGL ES 3.1.
DEVE ter suporte ao OpenGL ES 3.2.

Se as implementações do dispositivo forem compatíveis com qualquer uma das versões do OpenGL ES, elas:

[C-2-1] É OBRIGATÓRIO informar, pelas APIs gerenciadas e nativas do OpenGL ES, quaisquer outras extensões do OpenGL ES implementadas. Por outro lado, NÃO é permitido informar strings de extensão que não sejam compatíveis.
[C-2-2] É PRECISO ter 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-SR] É ALTAMENTE RECOMENDADO oferecer suporte às extensões EGL_KHR_partial_update e OES_EGL_image_external.
DEVE informar com precisão, pelo método getString(), qualquer formato de compactação de textura compatível, que geralmente é específico do fornecedor.

Se as implementações do dispositivo declararem suporte ao OpenGL ES 3.0, 3.1 ou 3.2, elas:

[C-3-1] É OBRIGATÓRIO exportar os símbolos de função correspondentes para essas versões, além dos símbolos de função OpenGL ES 2.0 na biblioteca libGLESv2.so.
[SR] É ALTAMENTE RECOMENDADO oferecer suporte à extensão OES_EGL_image_external_essl3.

Se as implementações do dispositivo oferecem suporte ao OpenGL ES 3.2, elas:

[C-4-1] É PRECISO oferecer suporte ao pacote de extensões para Android do OpenGL ES na íntegra.

Se as implementações do dispositivo oferecerem suporte ao pacote de extensões para Android do OpenGL ES, elas:

[C-5-1] É OBRIGATÓRIO identificar o suporte usando a flag de recurso android.hardware.opengles.aep.

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

[C-6-1] É necessário ter suporte à extensão EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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

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

[SR] É ALTAMENTE RECOMENDADO incluir suporte ao Vulkan 1.1.

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

DEVE incluir suporte ao Vulkan 1.1.

Os testes dEQP do Vulkan são divididos em várias listas de teste, cada uma com uma data/versão associada. Eles estão na árvore de origem do Android em external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Um dispositivo que oferece suporte ao Vulkan em um nível informado por conta própria indica que ele pode passar nos testes dEQP em todas as listas de teste a partir desse nível.

Se as implementações do dispositivo incluem suporte ao Vulkan 1.0 ou mais recente, elas:

[C-1-1] DEVE informar o valor inteiro correto com as flags de recursos android.hardware.vulkan.level e android.hardware.vulkan.version.
[C-1-2] É PRECISO enumerar pelo menos um VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices() .
[C-1-3] É PRECISO implementar totalmente as APIs Vulkan 1.0 para cada VkPhysicalDevice enumerado.
[C-1-4] É PRECISO enumerar camadas, contidas em bibliotecas nativas nomeadas como libVkLayer*.so no diretório de biblioteca nativa do pacote de aplicativos, pelas APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
[C-1-5] NÃO É PERMITIDO enumerar camadas fornecidas por bibliotecas fora do pacote do aplicativo ou fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o atributo android:debuggable definido como true.
[C-1-6] É OBR informar todas as strings de extensão com suporte pelas APIs nativas do Vulkan e, inversamente, NÃO informar strings de extensão sem suporte.
[C-1-7] É PRECISO oferecer suporte às extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
[C-1-8] É PRECISO informar a versão máxima dos testes dEQP do Vulkan com suporte pela flag de recurso android.software.vulkan.deqp.level.
[C-1-9] É PRECISO oferecer suporte à versão 132317953 (de 1º de março de 2019) conforme informado na flag de recurso android.software.vulkan.deqp.level.
[C-1-10] É PRECISO passar em todos os testes dEQP do Vulkan nas listas de teste entre a versão 132317953 e a versão especificada na flag de recurso android.software.vulkan.deqp.level.
[C-SR] É ALTAMENTE RECOMENDADO oferecer suporte às extensões VK_KHR_driver_properties e VK_GOOGLE_display_timing.

Se as implementações do dispositivo não incluírem suporte ao Vulkan 1.0, elas:

[C-2-1] NÃO declarar nenhuma das flags de recursos do Vulkan (por exemplo, android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] NÃO É PERMITIDO enumerar nenhum VkPhysicalDevice para a vkEnumeratePhysicalDevices() da API nativa do Vulkan.

Se as implementações do dispositivo incluírem suporte ao Vulkan 1.1 e declararem qualquer uma das flags de recursos do Vulkan, elas:

[C-3-1] É PRECISO expor suporte para os tipos de semântica e de manipulação externos SYNC_FD e a extensão VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

[C-0-1] As implementações de dispositivos PRECISAM oferecer suporte ao Android RenderScript, conforme detalhado na documentação do SDK do Android.

7.1.4.4 Aceleração gráfica 2D

O Android inclui um mecanismo para que os aplicativos declarem que querem ativar a aceleração de hardware para gráficos 2D no nível do aplicativo, da atividade, da janela ou da visualização usando uma tag de manifesto android:hardwareAccelerated ou chamadas diretas de API.

Implementações de dispositivos:

[C-0-1] PRECISA ativar a aceleração de hardware por padrão e PRECISA desativar a aceleração de hardware se o desenvolvedor solicitar isso definindo android:hardwareAccelerated="false" ou desativando a aceleração de hardware diretamente pelas APIs View do Android.
[C-0-2] PRECISA apresentar um comportamento consistente com a documentação do SDK do Android sobre aceleração de hardware.

O Android inclui um objeto TextureView que permite que os desenvolvedores integrem diretamente texturas OpenGL ES aceleradas por hardware como destinos de renderização em uma hierarquia de interface.

Implementações de dispositivos:

[C-0-3] PRECISA oferecer suporte à API TextureView e PRECISA apresentar um comportamento consistente com a implementação upstream do Android.

7.1.4.5 Telas de ampla gama

Se as implementações de dispositivos declararem suporte a telas de ampla gama de cores usando Configuration.isScreenWideColorGamut() , elas:

[C-1-1] É PRECISO ter uma tela com cores calibradas.
[C-1-2] É OBRIGATÓRIO ter uma tela com uma gama que cubra a gama de cores sRGB totalmente no espaço CIE 1931 xyY.
[C-1-3] É OBRIGATÓRIO ter uma tela com uma gama de pelo menos 90% de DCI-P3 no espaço CIE 1931 xyY.
[C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.1 ou 3.2 e informar corretamente.
[C-1-5] É PRECISO anunciar suporte para as extensões EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear e EGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR] É ALTAMENTE RECOMENDADO oferecer suporte a GL_EXT_sRGB.

Por outro lado, se as implementações de dispositivos não oferecerem suporte a telas de ampla gama de cores, elas:

[C-2-1] DEVE abranger 100% ou mais de sRGB no espaço CIE 1931 xyY, embora a gama de cores da tela seja indefinida.

7.1.5. Modo de compatibilidade de aplicativos legados

O Android especifica um "modo de compatibilidade" em que o framework opera em um modo equivalente ao tamanho de tela "normal" (largura de 320 dp) para beneficiar aplicativos legados que não foram desenvolvidos para versões antigas do Android que antecedem a independência do tamanho da tela.

7.1.6. Tecnologia da tela

A plataforma Android inclui APIs que permitem que os aplicativos renderizem gráficos avançados em uma tela compatível com o Android. Os dispositivos precisam oferecer suporte a todas essas APIs, conforme definido pelo SDK do Android, a menos que seja permitido especificamente neste documento.

Todas as telas compatíveis com Android de uma implementação de dispositivo:

[C-0-1] PRECISA ser capaz de renderizar gráficos coloridos de 16 bits.
DEVE oferecer suporte a telas com gráficos coloridos de 24 bits.
[C-0-2] PRECISA ser capaz de renderizar animações.
[C-0-3] PRECISA ter uma proporção de pixels (PAR) entre 0,9 e 1,15. Ou seja, a proporção de pixels PRECISA ser próxima de um quadrado (1,0) com uma tolerância de 10 a 15%.

7.1.7. Telas secundárias

O Android inclui suporte a telas secundárias compatíveis com o Android para ativar recursos de compartilhamento de mídia e APIs para desenvolvedores acessarem telas externas.

Se as implementações de dispositivos oferecerem suporte a uma tela externa por uma conexão de tela adicional integrada, com ou sem fio, elas:

[C-1-1] É PRECISO implementar o serviço de sistema e a API DisplayManager conforme descrito na documentação do SDK do Android.

7.2. Dispositivos de entrada

Implementações de dispositivos:

[C-0-1] É PRECISO incluir um mecanismo de entrada, como uma tela tátil ou navegação sem toque, para navegar entre os elementos da interface.

7.2.1. Teclado

Se as implementações de dispositivos incluírem suporte a aplicativos de Editor de método de entrada (IME) de terceiros, elas:

[C-1-1] É PRECISO declarar a flag de recurso android.software.input_methods.
[C-1-2] É PRECISO implementar totalmente 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.keyboard (QWERTY ou 12 teclas). * DEVE incluir outras implementações de teclado virtual. * PODE incluir um teclado de hardware.

7.2.2. Navegação sem toque

O Android inclui suporte para botão direcional, trackball e roda como mecanismos de navegação sem toque.

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO informar o valor correto para android.content.res.Configuration.navigation.

Se as implementações de dispositivos não tiverem navegações sem toque, elas:

[C-1-1] É OBRIGATÓRIO fornecer um mecanismo de interface do usuário alternativo razoável para a seleção e edição de texto, compatível com mecanismos de gerenciamento de entrada. A implementação de código aberto upstream do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação não por toque.

7.2.3. Teclas de navegação

As funções Início, Recentes e Voltar, normalmente fornecidas por uma interação com um botão físico dedicado ou uma parte distinta da tela touchscreen, são essenciais para o paradigma de navegação do Android e, portanto, para implementações de dispositivos:

[C-0-1] É necessário fornecer uma capacidade do usuário para iniciar aplicativos instalados que tenham uma atividade com o <intent-filter> definido com ACTION=MAIN e CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER para implementações de dispositivos de TV. A função "Início" DEVE ser o mecanismo para essa affordance do usuário.
DEVE fornecer botões para a função "Recentes" e "Voltar".

Se as funções "Início", "Recentes" ou "Voltar" forem fornecidas, elas:

[C-1-1] PRECISA ser acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando qualquer uma delas for acessível.
[C-1-2] É PRECISO indicar claramente qual ação única aciona cada função. Exemplos de indicações são um ícone visível impresso no botão, um ícone de software mostrado na parte da barra de navegação da tela ou um fluxo de demonstração guiado passo a passo durante a experiência de configuração inicial.

Implementações de dispositivos:

[SR] É ALTAMENTE RECOMENDADO não fornecer o mecanismo de entrada para a função de menu, já que ela foi descontinuada em favor da barra de ações desde o Android 4.0.

Se as implementações do dispositivo oferecerem a função Menu, elas:

[C-2-1] PRECISA mostrar o botão de menu flutuante de ações 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 MODIFIQUE a posição do pop-up de overflow de ação exibido ao selecionar o botão de overflow na barra de ações, mas PODE renderizar o pop-up de overflow de ação em uma posição modificada na tela quando ele é exibido ao selecionar a função de menu.

Se as implementações do dispositivo não fornecerem a função Menu, elas:

[C-3-1] É PRECISO disponibilizar a função de menu para os aplicativos quando targetSdkVersion for menor que 10, seja por um botão físico, uma tecla de software ou gestos. Essa função de menu precisa ser acessível, a menos que esteja oculta com outras funções de navegação.

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

[C-4-1] A função Assist precisa ser acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando outras teclas de navegação estiverem acessíveis.
[SR] É ALTAMENTE RECOMENDADO usar o toque longo na função HOME como essa interação designada.

Se as implementações do dispositivo usarem uma parte distinta da tela para mostrar as teclas de navegação, elas:

[C-5-1] As teclas de navegação PRECISAM usar uma parte distinta da tela, que não está disponível para aplicativos, e NÃO PODEM obscurecer ou interferir de outra forma na parte da tela disponível para aplicativos.
[C-5-2] PRECISA disponibilizar uma parte da tela para aplicativos que atendam aos requisitos definidos na seção 7.1.1.
[C-5-3] É OBRIGATÓRIO respeitar as flags definidas pelo app pelo método da API View.setSystemUiVisibility(), para que essa parte distinta da tela (também conhecida como barra de navegação) seja oculta corretamente, conforme documentado no SDK.

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

[C-6-1] O WindowInsets#getMandatorySystemGestureInsets() SÓ pode ser usado para informar a área de reconhecimento de gestos da tela inicial.
[C-6-2] Os gestos que começam em um retângulo de exclusão fornecido pelo aplicativo em primeiro plano por meio de View#setSystemGestureExclusionRects(), mas fora de WindowInsets#getMandatorySystemGestureInsets(), NÃO PODEM ser interceptados para a função de navegação, desde que o retângulo de exclusão seja permitido dentro do limite máximo de exclusão especificado na documentação de View#setSystemGestureExclusionRects().
[C-6-3] É OBRIGATÓRIO enviar ao app em primeiro plano um evento MotionEvent.ACTION_CANCEL quando os toques começarem a ser interceptados para um gesto do sistema, se o app em primeiro plano tiver recebido anteriormente um evento MotionEvent.ACTION_DOWN.
[C-6-4] É PRECISO fornecer uma característica de uso para o usuário mudar para uma navegação na tela com base em botões (por exemplo, nas Configurações).
DEVE fornecer a função "Home" como um deslizar para cima da borda inferior da orientação atual da tela.
A função "Recentes" DEVE ser exibida como um gesto de deslizar para cima e segurar antes da liberação, na mesma área do gesto de "Início".
Os gestos que começam dentro de WindowInsets#getMandatorySystemGestureInsets() NÃO devem ser afetados por retângulos de exclusão fornecidos pelo aplicativo em primeiro plano por meio de View#setSystemGestureExclusionRects().

Se uma função de navegação for fornecida em qualquer lugar nas bordas esquerda e direita da orientação atual da tela:

[C-7-1] A função de navegação PRECISA ser "Voltar" e ser fornecida como um deslizar das bordas esquerda e direita da orientação atual da tela.
[C-7-2] Se painéis do sistema deslizáveis personalizados forem fornecidos nas bordas esquerda ou direita, eles PRECISAM ser colocados na parte superior de um terço da tela com uma indicação visual clara e persistente de que arrastar para dentro invocaria os painéis mencionados, e não "Voltar". Um painel do sistema PODE ser configurado por um usuário para que ele fique abaixo de 1/3 da borda da tela, mas ele NÃO PODE ocupar mais de 1/3 da borda.
[C-7-3] Quando o app em primeiro plano tem as flags View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY definidas, a deslizar das bordas PRECISA se comportar como implementado no AOSP, que está documentado no SDK.
[C-7-4] Quando o app em primeiro plano tem as flags View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY definidas, os painéis do sistema deslizáveis personalizados precisam estar ocultos até que o usuário abra as barras do sistema (ou seja, a barra de navegação e a de status) conforme implementado no AOSP.

7.2.4. Entrada por touchscreen

O Android oferece suporte a vários sistemas de entrada de ponteiro, como telas e trackpads touch, além de dispositivos de entrada touch falsos. As implementações de dispositivos com tela touchscreen são associadas a uma tela de modo que o usuário tem a impressão de manipular itens diretamente na tela. Como o usuário toca diretamente na tela, o sistema não exige recursos adicionais para indicar os objetos que estão sendo manipulados.

Implementações de dispositivos:

DEVE ter um sistema de entrada de ponteiro de algum tipo (semelhante a um mouse ou por toque).
DEVE oferecer suporte a ponteiros rastreados de forma totalmente independente.

Se as implementações do dispositivo incluírem uma tela touchscreen (single-touch ou melhor) em uma tela principal compatível com o Android, elas:

[C-1-1] É OBRIGATÓRIO informar TOUCHSCREEN_FINGER para o campo da API Configuration.touchscreen.
[C-1-2] É OBRIGATÓRIO informar os flags de recursos android.hardware.touchscreen e android.hardware.faketouch.

Se as implementações de dispositivos incluírem uma tela touchscreen que pode rastrear mais de um toque em uma tela principal compatível com Android, elas:

[C-2-1] É OBRIGATÓRIO informar as flags de recursos adequadas android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand correspondentes ao tipo de tela touchscreen específica no dispositivo.

Se as implementações do dispositivo dependerem de um dispositivo de entrada externo, como mouse ou trackball (ou seja, não tocar diretamente na tela) para entrada em uma tela principal compatível com Android e atender aos requisitos de toque falso na seção 7.2.5, elas:

[C-3-1] NÃO DEVE informar nenhuma flag de recurso que comece com android.hardware.touchscreen.
[C-3-2] É OBRIGATÓRIO informar apenas android.hardware.faketouch.
[C-3-3] É OBRIGATÓRIO informar TOUCHSCREEN_NOTOUCH para o campo da API Configuration.touchscreen.

7.2.5. Entrada por toque falsa

A interface de toque simulada fornece um sistema de entrada do usuário que aproxima um subconjunto de recursos de tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela se aproxima do toque, mas exige que o usuário primeiro aponte ou foque e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse aéreo com giroscópio, ponteiro com giroscópio, joystick e trackpad multitoque, podem oferecer suporte a interações de toque falsas. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada não por toque (baseado em ponteiro) de alta fidelidade, como um mouse ou trackpad que pode emular adequadamente a entrada por toque (incluindo suporte a gestos básicos) e indica que o dispositivo oferece suporte a um subconjunto emulado de recursos da tela touch.

Se as implementações de dispositivos não incluem uma tela touchscreen, mas incluem 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] É OBRIGATÓRIO informar as posições absolutas X e Y da tela do local do ponteiro e exibir um ponteiro visual na tela.
[C-1-2] É OBRIGATÓRIO informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre no ponteiro descendo ou subindo na tela.
[C-1-3] É PRECISO oferecer suporte ao ponteiro para baixo e para cima em um objeto na tela, o que permite que os usuários simulem o toque em um objeto na tela.
[C-1-4] É PRECISO oferecer suporte ao ponteiro para baixo, ponteiro para cima, ponteiro para baixo e ponteiro para cima no mesmo local em um objeto na tela dentro de um limite de tempo, o que permite que os usuários emulem o toque duplo em um objeto na tela.
[C-1-5] É PRECISO oferecer suporte ao ponteiro para baixo em um ponto arbitrário na tela, movimento do ponteiro para qualquer outro ponto arbitrário na tela, seguido por um ponteiro para cima, o que permite que os usuários emulem um arrasto por toque.
[C-1-6] É PRECISO oferecer suporte ao ponteiro para baixo e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, o ponteiro para cima na tela, o que permite que os usuários joguem um objeto na tela.

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

[C-2-1] É PRECISO declarar suporte para android.hardware.faketouch.
[C-2-2] É PRECISO oferecer suporte a 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] É PRECISO declarar suporte para android.hardware.faketouch.
[C-3-2] É NECESSÁRIO oferecer suporte a rastreamento distinto de 5 (rastreamento de uma mão de dedos) ou mais entradas de ponteiro de forma totalmente independente.

7.2.6. Suporte a controles de jogos

7.2.6.1. Mapeamentos de botões

Implementações de dispositivos:

[C-1-1] É PRECISO que o recurso mapeie eventos HID para as constantes InputEvent correspondentes, conforme listado nas tabelas abaixo. A implementação upstream do Android atende a esse requisito.

Se as implementações de dispositivos incorporarem um controlador ou forem enviadas com um controlador separado na caixa que forneça meios para inserir todos os eventos listados nas tabelas abaixo, elas:

[C-2-1] É PRECISO declarar a flag de recurso android.hardware.gamepad

Botão	Uso do HID²	Botão do Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
S¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Botão direcional para cima¹ Botão direcional para baixo¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad para a esquerda1 D-pad para a direita¹	0x01 0x0039³	AXIS_HAT_X⁴
Botão de ombro esquerdo¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Botão de ombro direito¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clique no botão esquerdo¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clique no botão direito¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Início¹	0x0c 0x0223	KEYCODE_HOME (3)
Voltar¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Os usos de HID acima precisam ser declarados em uma CA de gamepad (0x01 0x0005).

3 Esse uso precisa ter um mínimo lógico de 0, um máximo lógico de 7, um mínimo físico de 0, um máximo físico de 315, unidades em graus e um tamanho de relatório de 4. O valor lógico é definido como a rotação no sentido horário para longe do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e esquerda pressionadas.

4 MotionEvent

Controles analógicos¹	Uso de HID	Botão do Android
Gatilho esquerdo	0x02 0x00C5	AXIS_LTRIGGER
Gatilhos direito	0x02 0x00C4	AXIS_RTRIGGER
Joystick esquerdo	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick direito	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

Consulte a Seção 2.3.1 para ver os requisitos específicos do dispositivo.

7.3. Sensores

Se as implementações de dispositivo incluem um tipo de sensor específico que tem uma API correspondente para desenvolvedores terceirizados, a implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android e na documentação do Android Open Source sobre sensores.

Implementações de dispositivos:

[C-0-1] É PRECISO informar com precisão a presença ou ausência de sensores por classe android.content.pm.PackageManager.
[C-0-2] PRECISA retornar uma lista precisa dos sensores compatíveis usando SensorManager.getSensorList() e métodos semelhantes.
[C-0-3] PRECISA se comportar de maneira razoável para todas as outras APIs de sensor (por exemplo, retornando true ou false conforme apropriado quando os aplicativos tentam registrar listeners, não chamando listeners de sensor quando os sensores correspondentes não estão presentes etc.).

Se as implementações de dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, elas:

[C-1-1] É OBRIGATÓRIO informar todas as medições do sensor usando os valores relevantes do Sistema Internacional de Unidades (métrico) para cada tipo de sensor, conforme definido na documentação do SDK do Android.
[C-1-2] É OBRIGATÓRIO informar dados do sensor com uma latência máxima de 100 milissegundos + 2 * sample_time no caso de um fluxo de sensor com uma latência máxima solicitada de 0 ms quando o processador do aplicativo está ativo. Esse atraso não inclui atrasos de filtragem.
[C-1-3] É OBRIGATÓRIO informar a primeira amostra do sensor em 400 milissegundos + 2 * sample_time do sensor sendo ativado. É aceitável que essa amostra tenha uma precisão de 0.
[C-1-4] Para que qualquer API indicada pela documentação do SDK do Android seja um sensor contínuo, as implementações de dispositivos precisam fornecer continuamente amostras de dados periódicos que precisam ter um jitter abaixo de 3%, em que o jitter é definido como a variação padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.
[C-1-5] É PRECISO garantir que o stream de eventos do sensor NÃO impeça a CPU do dispositivo de entrar em um estado de suspensão ou de sair dele.
[C-1-6] É OBRIGATÓRIO informar o horário do evento em nanossegundos, conforme definido na documentação do SDK do Android, representando o horário em que o evento ocorreu e sincronizado com o relógio SystemClock.elapsedRealtimeNano().
[C-SR] É ALTAMENTE RECOMENDADO que o erro de sincronização de carimbo de data/hora seja inferior a 100 milissegundos e DEVE ser inferior a 1 milissegundo.
Quando vários sensores são ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia informado pelo sensor individual.

A lista acima não é abrangente. O comportamento documentado do SDK do Android e da documentação de código aberto do Android sobre sensores é considerado oficial.

Se as implementações de dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, elas:

[C-1-6] É OBRIGATÓRIO definir uma resolução diferente de zero para todos os sensores e informar o valor pelo método da API Sensor.getResolution().

Alguns tipos de sensores são compostos, ou seja, podem ser derivados de dados fornecidos por um ou mais outros sensores. Por exemplo, o sensor de orientação e o sensor de aceleração linear.

Implementações de dispositivos:

IMPLEMENTAR esses tipos de sensores, quando eles incluem os sensores físicos necessários, conforme descrito em tipos de sensores.

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

[C-2-1] É PRECISO implementar o sensor conforme descrito na documentação do Android Open Source sobre sensores compostos.

Se as implementações de dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados e o sensor informar apenas um valor, as implementações de dispositivo:

[C-3-1] É OBRIGATÓRIO definir a resolução como 1 para o sensor e informar o valor pelo método da API Sensor.getResolution().

Se as implementações do dispositivo incluírem um tipo de sensor específico que ofereça suporte a SensorAdditionalInfo#TYPE_VEC3_CALIBRATION e o sensor for exposto a desenvolvedores terceirizados, eles:

[C-4-1] NÃO deve incluir parâmetros de calibração fixos e determinados pela fábrica nos dados fornecidos.

Se as implementações do dispositivo incluem uma combinação de acelerômetro de três eixos, um sensor de giroscópio de três eixos ou um sensor de magnetômetro, elas são:

[C-SR] ALTAMENTE 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 possíveis estados de transformação do dispositivo.

7.3.1. Acelerômetro

Implementações de dispositivos:

[C-SR] É ALTAMENTE RECOMENDADO incluir um acelerômetro de três eixos.

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

[C-1-1] É PRECISO que o sistema consiga informar eventos com frequência de pelo menos 50 Hz.
[C-1-2] É PRECISO implementar e informar o sensor TYPE_ACCELEROMETER.
[C-1-3] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor Android, conforme detalhado nas APIs do Android.
[C-1-4] É PRECISO medir a queda livre até quatro vezes a gravidade(4g) ou mais em qualquer eixo.
[C-1-5] PRECISA ter uma resolução de pelo menos 12 bits.
[C-1-6] É OBRIGATÓRIO ter uma variação padrão não superior a 0,05 m/s^, em que a variação padrão precisa ser calculada por eixo em amostras coletadas durante um período de pelo menos 3 segundos na taxa de amostragem mais rápida.
[SR] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
[SR] RECOMENDA-SE FORTEMENTE implementar e informar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. É FORTEMENTE RECOMENDADO que os dispositivos Android atendam a esse requisito para que possam fazer upgrade para a versão futura da plataforma, quando isso se tornar OBRIGATÓRIO.
DEVE implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER conforme descrito no documento do SDK do Android.
DEVE informar eventos de até 200 Hz.
DEVE ter uma resolução de pelo menos 16 bits.
DEVEM ser calibrados durante o uso se as características mudarem ao longo do ciclo de vida e forem compensadas, e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
DEVE ser compensada pela temperatura.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos e qualquer um dos sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER forem implementados:

[C-2-1] A soma do consumo de energia PRECISA ser sempre menor que 4 mW.
Cada um precisa estar abaixo de 2 mW e 0,5 mW quando o dispositivo está em uma condição dinâmica ou estática.

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

[C-3-1] É PRECISO implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
[C-SR] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

Se as implementações do dispositivo incluem um acelerômetro de três eixos, um sensor de giroscópio de três eixos e um sensor de magnetômetro, elas:

[C-4-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

7.3.2. Magnetômetro

Implementações de dispositivos:

[C-SR] É ALTAMENTE RECOMENDADO incluir um magnetômetro de três eixos (bússola).

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

[C-1-1] É PRECISO implementar o sensor TYPE_MAGNETIC_FIELD.
[C-1-2] PRECISA ser capaz de informar eventos com frequência de pelo menos 10 Hz e DEVE informar eventos com frequência de pelo menos 50 Hz.
[C-1-3] É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor Android, conforme detalhado nas APIs do Android.
[C-1-4] É PRECISO medir entre -900 µT e +900 µT em cada eixo antes da saturação.
[C-1-5] É PRECISO ter um valor de deslocamento de ferro rígido menor que 700 µT e DEVE ter um valor abaixo de 200 µT, colocando o magnetômetro longe de campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímã).
[C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 µT.
[C-1-7] É PRECISO oferecer suporte à calibração on-line e à compensação do viés de hardware e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
[C-1-8] A compensação de ferro macio PRECISA ser aplicada. A calibração pode ser feita durante o uso ou durante a produção do dispositivo.
[C-1-9] DEVE ter um desvio padrão, calculado por eixo em amostras coletadas por um período de pelo menos 3 segundos na taxa de amostragem mais rápida, não maior que 1,5 µT; DEVE ter um desvio padrão não maior que 0,5 µT.
[C-SR] É ALTAMENTE RECOMENDADO implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se as implementações do dispositivo 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] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

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

PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Se as implementações do dispositivo incluem 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 para o modo de lote a 10 Hz.

7.3.3. GPS

Implementações de dispositivos:

[C-SR] É ALTAMENTE RECOMENDADO incluir um receptor GPS/GNSS.

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

[C-1-1] É PRECISO oferecer suporte a saídas de localização com uma taxa de pelo menos 1 Hz quando solicitado por LocationManager#requestLocationUpdate.
[C-1-2] É PRECISO determinar o local em condições de céu aberto (sinais fortes, multicaminho desprezível, HDOP < 2) em até 10 segundos (tempo rápido para a primeira correção), quando conectado a uma conexão de Internet de 0,5 Mbps ou mais rápida. Esse requisito geralmente é atendido pelo 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, localização de referência e efemérides/relógio do satélite.
- [C-1-6] Depois de fazer esse cálculo de localização, as implementações do dispositivo PRECISAM determinar a localização, em céu aberto, em até 5 segundos, quando as solicitações de localização forem reiniciadas, até uma hora após o cálculo inicial de localização, mesmo quando a solicitação subsequente for feita sem uma conexão de dados e/ou após um ciclo de energia.
Em condições de céu aberto, depois de determinar o local, enquanto estiver parado ou se movendo com menos de 1 metro por segundo ao quadrado de aceleração:
- [C-1-3] É PRECISO determinar a localização em até 20 metros e a velocidade em até 0, 5 metro por segundo, pelo menos 95% do tempo.
- [C-1-4] É necessário rastrear e informar simultaneamente pelo menos 8 satélites de uma constelação por meio de GnssStatus.Callback.
- 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] É ALTAMENTE RECOMENDADO continuar a fornecer saídas de localização normais do GPS/GNSS usando a API do provedor de localização do GNSS durante uma ligação telefônica de emergência.
- [C-SR] É ALTAMENTE RECOMENDADO informar as medições do GNSS de todas as constelações rastreadas (conforme informado nas mensagens GnssStatus), com exceção do SBAS.
- [C-SR] É ALTAMENTE RECOMENDADO informar a AGC e a frequência da medição do GNSS.
- [C-SR] É ALTAMENTE RECOMENDADO informar todas as estimativas de precisão (incluindo a direção, a velocidade e a vertical) como parte de cada local de GPS/GNSS.
- [C-SR] É ALTAMENTE RECOMENDADO informar as medições do GNSS assim que elas forem encontradas, mesmo que um local calculado pelo GPS/GNSS ainda não tenha sido informado.
- [C-SR] É ALTAMENTE RECOMENDADO informar as pseudodistâncias e as taxas de pseudodistância do GNSS que, em condições de céu aberto após a determinação do local, enquanto estão parados ou se movem com menos de 0, 2 metros por segundo ao quadrado de aceleração, são suficientes para calcular a posição em até 20 metros e a velocidade em até 0, 2 metros por segundo, pelo menos 95% do tempo.

7.3.4. Giroscópio

Implementações de dispositivos:

[C-SR] É ALTAMENTE RECOMENDADO incluir um sensor de giroscópio.

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

[C-1-1] É PRECISO que o sistema consiga informar eventos com frequência de pelo menos 50 Hz.
[C-1-2] É OBRIGATÓRIO implementar o sensor TYPE_GYROSCOPE e é ALTAMENTE RECOMENDÁVEL implementar o sensor TYPE_GYROSCOPE_UNCALIBRATED.
[C-1-4] PRECISA ter uma resolução de 12 bits ou mais e DEVE ter uma resolução de 16 bits ou mais.
[C-1-5] É PRECISO compensar a temperatura.
[C-1-6] DEVE ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
[C-1-7] A variância PRECISA ser menor que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar com a taxa de amostragem, mas PRECISA ser limitada por esse valor. Em outras palavras, se você medir a variação do giroscópio com uma taxa de amostragem de 1 Hz, ela NÃO PODE ser maior que 1e-7 rad^2/s^2.
[SR] É ALTAMENTE RECOMENDÁVEL que o erro de calibração seja menor que 0,01 rad/s quando o dispositivo estiver parado à temperatura ambiente.
DEVE informar eventos de até 200 Hz.

Se as implementações do dispositivo incluem um giroscópio de três eixos, um sensor de acelerômetro e um sensor de magnetômetro, elas:

[C-2-1] É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR.

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

[C-3-1] É PRECISO implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
[C-SR] É ALTAMENTE RECOMENDADO implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

Implementações de dispositivos:

[C-SR] É ALTAMENTE RECOMENDADO incluir um barômetro (sensor de pressão do ar ambiente).

Se as implementações do dispositivo incluírem um barômetro, elas:

[C-1-1] É PRECISO implementar e informar o sensor TYPE_PRESSURE.
[C-1-2] É PRECISO enviar eventos a 5 Hz ou mais.
[C-1-3] É PRECISO compensar a temperatura.
[SR] É ALTAMENTE RECOMENDADO que você possa informar medições de pressão no intervalo de 300 a 1.100 hPa.
Deve ter uma precisão absoluta de 1hPa.
DEVE ter uma precisão relativa de 0,12 hPa em um intervalo de 20 hPa (o que equivale a uma precisão de cerca de 1 m em uma mudança de cerca de 200 m no nível do mar).

7.3.6. Termômetro

Se as implementações do dispositivo incluem um termômetro ambiente (sensor de temperatura), elas:

[C-1-1] É PRECISO definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura ambiente, e o sensor PRECISA medir a temperatura ambiente (sala/cabine do veículo) de onde o usuário está interagindo com o dispositivo em graus Celsius.

Se as implementações do dispositivo incluírem um sensor de termômetro que mede uma temperatura diferente da temperatura ambiente, como a temperatura da CPU, elas:

[C-2-1] NÃO DEFINIR SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura.

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, elas:

[C-1-1] DEVE medir a proximidade de um objeto na mesma direção da tela. Ou seja, o sensor de proximidade PRECISA ser orientado para detectar objetos próximos à tela, já que a intenção principal desse tipo de sensor é detectar um telefone em uso pelo usuário. Se as implementações do dispositivo incluírem um sensor de proximidade com qualquer outra orientação, ele NÃO PODE ser acessível por essa API.
[C-1-2] PRECISA ter precisão de 1 bit ou mais.

7.3.9. Sensores de alta fidelidade

Se as implementações de dispositivos incluírem um conjunto de sensores de maior qualidade, conforme definido nesta seção, e os disponibilizarem para apps de terceiros, elas:

[C-1-1] É PRECISO identificar o capability usando a flag de recurso android.hardware.sensor.hifi_sensors.

Se as implementações do dispositivo declararem android.hardware.sensor.hifi_sensors, elas:

[C-2-1] É PRECISO ter um sensor TYPE_ACCELEROMETER que:
- PRECISA ter um intervalo de medição entre pelo menos -8g e +8g, e é ALTAMENTE RECOMENDADO ter um intervalo de medição entre pelo menos -16g e +16g.
- PRECISA ter uma resolução de medição de pelo menos 2048 LSB/g.
- PRECISA ter uma frequência de medição mínima de 12,5 Hz ou inferior.
- PRECISA ter uma frequência de medição máxima de 400 Hz ou mais; DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
- O ruído de medição não pode exceder 400 μg/√Hz.
- É PRECISO implementar um formulário de não ativação desse sensor com um recurso de buffer de pelo menos 3.000 eventos do sensor.
- O consumo de energia em lote precisa ser de no máximo 3 mW.
- [C-SR] É ALTAMENTE RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
- DEVE ter uma caminhada aleatória de aceleração menor que 30 μg √Hz testada à temperatura ambiente.
- DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 1 mg/°C.
- DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,5% e uma mudança de sensibilidade em relação à temperatura de ≤ 0,03%/C°.
- DEVE ter uma sensibilidade no eixo transversal de < 2,5 % e uma variação de sensibilidade no eixo transversal de < 0,2% na faixa de temperatura de operação do dispositivo.
[C-2-2] É PRECISO ter um TYPE_ACCELEROMETER_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_ACCELEROMETER.
[C-2-3] É PRECISO ter um sensor TYPE_GYROSCOPE que:
- PRECISA ter um intervalo de medição entre pelo menos -1000 e +1000 dps.
- PRECISA ter uma resolução de medição de pelo menos 16 LSB/dps.
- PRECISA ter uma frequência de medição mínima de 12,5 Hz ou inferior.
- PRECISA ter uma frequência de medição máxima de 400 Hz ou mais; DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
- Deve ter um ruído de medição não superior a 0,014°/s/√Hz.
- [C-SR] É ALTAMENTE RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
- DEVE ter uma taxa de caminhada aleatória menor que 0,001 °/s √Hz testada à temperatura ambiente.
- DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 0,05 °/ s / °C.
- DEVE ter uma mudança de sensibilidade em relação à temperatura de ≤ 0,02% / °C.
- DEVE ter uma não linearidade de linha de ajuste ideal de ≤ 0,2%.
- DEVE ter uma densidade de ruído de ≤ 0,007 °/s/√Hz.
- DEVE ter um erro de calibração menor que 0,002 rad/s na faixa de temperatura de 10 a 40 ℃ quando o dispositivo estiver parado.
- DEVE ter uma sensibilidade g menor que 0,1°/s/g.
- DEVE ter uma sensibilidade no eixo transversal de < 4,0 % e uma variação de sensibilidade no eixo transversal de < 0,3% no intervalo de temperatura de operação do dispositivo.
[C-2-4] É PRECISO ter um TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_GYROSCOPE.
[C-2-5] É PRECISO ter um sensor TYPE_GEOMAGNETIC_FIELD que:
- PRECISA ter um intervalo de medição entre pelo menos -900 e +900 μT.
- É PRECISO ter uma resolução de medição de pelo menos 5 LSB/uT.
- PRECISA ter uma frequência de medição mínima de 5 Hz ou menor.
- PRECISA ter uma frequência de medição máxima de 50 Hz ou mais.
- Deve ter um ruído de medição não superior a 0,5 uT.
[C-2-6] É PRECISO ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_GEOMAGNETIC_FIELD e, além disso:
- É PRECISO implementar um formulário sem ativação desse sensor com capacidade de buffer de pelo menos 600 eventos do sensor.
- [C-SR] É ALTAMENTE RECOMENDADO ter um espectro de ruído branco de 1 Hz a pelo menos 10 Hz quando a taxa de relatório for de 50 Hz ou mais.
[C-2-7] É OBRIGATÓRIO ter um sensor TYPE_PRESSURE que:
- PRECISA ter um intervalo de medição entre pelo menos 300 e 1.100 hPa.
- PRECISA ter uma resolução de medição de pelo menos 80 LSB/hPa.
- Deve ter uma frequência de medição mínima de 1 Hz ou inferior.
- PRECISA ter uma frequência de medição máxima de 10 Hz ou mais.
- O ruído de medição não pode exceder 2 Pa/√Hz.
- É PRECISO implementar um formulário sem ativação desse sensor com um recurso de buffer de pelo menos 300 eventos do sensor.
- O consumo de energia em lote precisa ser de no máximo 2 mW.
[C-2-8] É PRECISO ter um sensor TYPE_GAME_ROTATION_VECTOR.
[C-2-9] É PRECISO ter um sensor TYPE_SIGNIFICANT_MOTION que:
- O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
[C-2-10] É PRECISO ter um sensor TYPE_STEP_DETECTOR que:
- É PRECISO implementar um formulário sem ativação desse sensor com capacidade de buffer de pelo menos 100 eventos do sensor.
- O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
- O consumo de energia em lote precisa ser de no máximo 4 mW.
[C-2-11] É PRECISO ter um sensor TYPE_STEP_COUNTER que:
- O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
[C-2-12] É PRECISO ter um sensor TILT_DETECTOR que:
- O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
[C-2-13] O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro, pelo giroscópio e pelo magnetômetro PRECISA estar a 2, 5 milissegundos um do outro. O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro e pelo giroscópio DEVE estar a 0,25 milissegundos um do outro.
[C-2-14] É OBRIGATÓRIO ter carimbos de data/hora de eventos do sensor de giroscópio na mesma base de tempo que o subsistema da câmera e com um erro de até 1 milissegundo.
[C-2-15] É OBRIGATÓRIO enviar amostras para os aplicativos em até 5 milissegundos a partir do momento em que os dados estão disponíveis em qualquer um dos sensores físicos acima para o aplicativo.
[C-2-16] NÃO PODE ter um consumo de energia maior que 0,5 mW quando o dispositivo está estático e 2,0 mW quando o dispositivo está em movimento quando qualquer combinação dos seguintes sensores está ativada:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] PODE ter um sensor TYPE_PROXIMITY, mas, se estiver presente, PRECISA ter um recurso de buffer mínimo de 100 eventos do sensor.

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 consumida por toda a cadeia de sensores, incluindo o sensor, qualquer circuito de suporte, qualquer sistema de processamento de sensores dedicado etc.

Se as implementações de dispositivos incluem suporte a sensores diretos, elas:

[C-3-1] É OBRIGATÓRIO declarar corretamente o suporte a tipos de canal direto e ao nível de taxas de relatório direto usando as APIs isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
[C-3-2] É PRECISO oferecer suporte a pelo menos um dos dois tipos de canal direto do sensor para todos os sensores que declaram suporte ao canal direto do sensor.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
DEVE oferecer suporte à geração de relatórios de eventos pelo canal direto do sensor para o sensor principal (variante sem ativação) dos seguintes tipos:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensores biométricos

Para mais informações sobre como medir a segurança do desbloqueio biométrico, consulte a documentação sobre como medir a segurança biométrica.

Se as implementações do dispositivo incluem uma tela de bloqueio segura, elas:

DEVE incluir um sensor biométrico

Os sensores biométricos podem ser classificados como Classe 3 (antes Forte), Classe 2 (antes Fraco) ou Classe 1 (antes Conveniente) com base nas taxas de falsificação e aceitação de impostores e na segurança do pipeline biométrico. Essa classificação determina os recursos que o sensor biométrico tem para interagir com a plataforma e com aplicativos de terceiros. Os sensores são classificados como Classe 1 por padrão e precisam atender a outros requisitos, conforme detalhado abaixo, para serem classificados como Classe 2 ou Classe 3. Os recursos biométricos de Classe 2 e Classe 3 recebem recursos adicionais, conforme detalhado abaixo.

Se as implementações de dispositivos disponibilizarem um sensor biométrico para apps de terceiros usando android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, elas:

[C-4-1] É OBRIGATÓRIO atender aos requisitos de biometria de Classe 3 ou Classe 2, conforme definido neste documento.
[C-4-2] DEVE reconhecer e honrar cada nome de parâmetro definido como uma constante na classe Authenticators e em todas as combinações dela. Por outro lado, NÃO HONRE nem reconheça constantes inteiras transmitidas aos métodos canAuthenticate(int) e setAllowedAuthenticators(int), exceto aquelas documentadas como constantes públicas em Authenticators e qualquer combinação delas.
[C-4-3] É PRECISO implementar a ação ACTION_BIOMETRIC_ENROLL em dispositivos com biometria de Classe 3 ou Classe 2. Essa ação PRECISA apresentar apenas os pontos de entrada de registro para biometria de Classe 3 ou Classe 2.

Se as implementações de dispositivos oferecerem suporte à biometria passiva, elas:

[C-5-1] POR PADRÃO, É OBRIGATÓRIO exigir uma etapa de confirmação extra (por exemplo, pressionar um botão).
[C-SR] É ALTAMENTE RECOMENDADO ter uma configuração que permita aos usuários substituir a preferência do aplicativo e sempre exigir a etapa de confirmação.
[C-SR] É ALTAMENTE RECOMENDADO que a ação de confirmação seja protegida para que um comprometimento do sistema operacional ou do kernel não possa ser falsificado. Por exemplo, isso significa que a ação de confirmação baseada em um botão físico é encaminhada por um pino de entrada/saída (GPIO) de uso geral somente de entrada de um elemento de segurança (SE) que não pode ser controlado por nenhum outro meio além de um botão físico.
[C-5-2] É necessário implementar um fluxo de autenticação implícito (sem etapa de confirmação) correspondente a setConfirmationRequired(boolean), que os aplicativos podem definir para usar nos fluxos de login.

Se as implementações do dispositivo tiverem vários sensores biométricos, elas:

[C-SR] É ALTAMENTE RECOMENDADO exigir que apenas um método biométrico seja confirmado por autenticação. Por exemplo, se os sensores de impressão digital e facial estiverem disponíveis no dispositivo, onAuthenticationSucceeded precisará ser enviado depois que qualquer um deles for confirmado.

Para que as implementações de dispositivos permitam o acesso a chaves do keystore de apps de terceiros, elas:

[C-6-1] DEVE atender aos requisitos da Classe 3, conforme definido nesta seção abaixo.
[C-6-2] É OBRIGATÓRIO apresentar apenas biometria de Classe 3 quando a autenticação requer BIOMETRIC_STRONG ou quando a autenticação é invocada com um CryptoObject.

Se as implementações de dispositivo quiserem tratar um sensor biométrico como Classe 1 (antes Conveniência), elas:

[C-1-1] É PRECISO ter uma taxa de aceitação falsa menor que 0,002%.
[C-1-2] É OBRIGATÓRIO divulgar que esse modo pode ser menos seguro que um PIN, padrão ou senha fortes e listar claramente os riscos de ativá-lo, se as taxas de aceitação de falsificação e de impostores forem superiores a 7%, conforme medido pelos Protocolos de teste de biometria do Android.
[C-1-3] É OBRIGATÓRIO limitar a taxa de tentativas por pelo menos 30 segundos após cinco tentativas falsas de verificação biométrica, em que uma tentativa falsa é aquela com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
[C-1-4] É PRECISO impedir a adição de novas biometrias sem primeiro estabelecer uma cadeia de confiança, fazendo com que o usuário confirme a credencial de dispositivo (PIN/padrão/senha) atual ou adicione uma nova (PIN/padrão/senha) protegida pelo TEE. A implementação do Projeto Android Open Source fornece o mecanismo no framework para fazer isso.
[C-1-5] É OBRIGATÓRIO remover completamente todos os dados biométricos identificáveis de um usuário quando a conta dele for removida (inclusive por redefinição de fábrica).
[C-1-6] É PRECISO honrar a flag individual para essa biometria (ou seja, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT , DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] É OBRIGATÓRIO solicitar ao usuário a autenticação primária recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 24 horas ou menos para novos dispositivos lançados com o Android versão 10 e uma vez a cada 72 horas ou menos para dispositivos que estão sendo atualizados de uma versão anterior do Android.
[C-1-8] É OBRIGATÓRIO solicitar ao usuário a autenticação primária recomendada (por exemplo, PIN, padrão, senha) após uma das seguintes ações:
- um período de inatividade de 4 horas OU
- Três tentativas de autenticação biométrica com falha.
- O período de inatividade e a contagem de falhas de autenticação são redefinidos após qualquer confirmação bem-sucedida das credenciais do dispositivo.
O upgrade de dispositivos de uma versão anterior do Android pode ser isento da C-1-8. * [C-SR] É ALTAMENTE RECOMENDADO usar a lógica no framework fornecido pelo Android Open Source Project para aplicar restrições especificadas em [C-1-7] e [C-1-8] para novos dispositivos. * [C-SR] É ALTAMENTE RECOMENDADO ter uma taxa de rejeição falsa inferior a 10%, conforme medido no dispositivo. * [C-SR] É ALTAMENTE RECOMENDADO ter uma latência abaixo de 1 segundo, medida desde a detecção da biometria até o desbloqueio da tela, para cada biometria registrada.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 2 (antes Fraco), elas:

[C-2-1] É PRECISO atender a todos os requisitos da Classe 1 acima.
[C-2-2] É OBRIGATÓRIO ter uma taxa de aceitação de falsificação e impostor não superior a 20%, conforme medido pelos protocolos de teste de biometria do Android.
[C-2-3] É OBRIGATÓRIO realizar a correspondência biométrica em um ambiente de execução isolado fora do espaço do usuário ou do kernel do Android, como o ambiente de execução confiável (TEE) ou em um chip com um canal seguro para o ambiente de execução isolado.
[C-2-4] É OBRIGATÓRIO que todos os dados identificáveis sejam criptografados e autenticados criptograficamente, de modo que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação no site do Projeto Android Open Source.
[C-2-5] Para biometrias baseadas em câmera, enquanto a autenticação ou o registro biométrico estiver ocorrendo:
- DEVEM operar a câmera em um modo que impeça que os frames sejam lidos ou alterados fora do ambiente de execução isolado ou um chip com um canal seguro para o ambiente de execução isolado.
- Para soluções de câmera RGB única, os frames da câmera PODEM ser lidos fora do ambiente de execução isolado para oferecer suporte a operações como a visualização para registro, mas ELES NÃO PODEM ser alterados.
[C-2-6] NÃO É PERMITIDO ativar aplicativos de terceiros para distinguir entre registros biométricos individuais.
[C-2-7] NÃO É PERMITIDO permitir acesso não criptografado a dados biométricos identificáveis ou a dados derivados deles (como incorporações) ao processador de aplicativos fora do contexto do TEE.
[C-2-8] É PRECISO ter um pipeline de processamento seguro para que um comprometimento do sistema operacional ou do kernel não permita que dados sejam injetados diretamente para autenticar falsamente como o usuário.

Se as implementações do dispositivo já foram lançadas em uma versão anterior do Android e não puderem atender ao requisito C-2-8 com uma atualização do software do sistema, elas PODEM ser isentas do requisito.
[C-SR] É ALTAMENTE RECOMENDADO incluir a detecção de vida para todas as modalidades biométricas e a detecção de atenção para biometria facial.

Se as implementações de dispositivo quiserem tratar um sensor biométrico como Classe 3 (antes Forte), elas:

[C-3-1] É PRECISO atender a todos os requisitos da Classe 2 acima, exceto [C-1-7] e [C-1-8]. O upgrade de dispositivos de uma versão anterior do Android não está isento da C-2-7.
[C-3-2] É PRECISO ter uma implementação de keystore protegida por hardware.
[C-3-3] É OBRIGATÓRIO ter uma taxa de aceitação de falsificação e impostor não superior a 7%, conforme medido pelos protocolos de teste de biometria do Android.
[C-3-4] É OBRIGATÓRIO solicitar ao usuário a autenticação primária recomendada (por exemplo, PIN, padrão, senha) a cada 72 horas ou menos.

7.3.12. Sensor de pose

Implementações de dispositivos:

PODE oferecer suporte ao sensor de pose com seis graus de liberdade.

Se as implementações de dispositivos oferecerem suporte ao sensor de pose com seis graus de liberdade, elas:

[C-1-1] É PRECISO implementar e informar o sensor TYPE_POSE_6DOF.
[C-1-2] PRECISA ser mais preciso do que o vetor de rotação sozinho.

7.3.13. Sensor de ângulo de dobradiça

Se as implementações do dispositivo oferecerem suporte a um sensor de ângulo de articulação, elas:

[C-1-1] É OBRIGATÓRIO implementar e informar TYPE_HINGLE_ANGLE.
[C-1-2] PRECISA oferecer suporte a pelo menos duas leituras entre 0 e 360 graus (incluindo 0 e 360 graus).
[C-1-3] É PRECISO retornar um sensor de ativação para getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4. Conectividade de dados

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android e neste documento, se refere especificamente ao hardware relacionado a fazer chamadas de voz e enviar mensagens SMS por uma rede GSM ou CDMA. Embora essas ligações de voz possam ou não ser comutadas por pacotes, elas são consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade e as APIs de "telefonia" do Android se referem especificamente a chamadas de voz e SMS. Por exemplo, implementações de dispositivos que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas dispositivos de telefonia, mesmo que usem uma rede celular para conectividade de dados.

O Android PODE ser usado em dispositivos que não incluem hardware de telefonia. Ou seja, o Android é compatível com dispositivos que não são smartphones.

Se as implementações de dispositivos incluírem telefonia GSM ou CDMA, elas:

[C-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.telephony e outras flags de subrecurso de acordo com a tecnologia.
[C-1-2] É PRECISO implementar suporte total à API para essa tecnologia.

Se as implementações de dispositivos não incluírem hardware de telefonia, elas:

[C-2-1] É OBRIGATÓRIO implementar as APIs completas como no-ops.

Se as implementações de dispositivos oferecerem suporte a eUICCs ou eSIMs/cartões SIM integrados e incluírem um mecanismo reservado para disponibilizar a funcionalidade de eSIM para desenvolvedores de terceiros, eles:

[C-3-1] É PRECISO fornecer uma implementação completa do EuiccManager API.

7.4.1.1. Compatibilidade com o bloqueio de números

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

[C-1-1] É PRECISO incluir suporte ao bloqueio de números
[C-1-2] É PRECISO implementar totalmente BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.
[C-1-3] É OBRIGATÓRIO bloquear todas as ligações e mensagens de um número de telefone em "BlockedNumberProvider" sem nenhuma interação com apps. A única exceção é quando o bloqueio de número é temporariamente suspenso, conforme descrito na documentação do SDK.
[C-1-4] NÃO É PERMITIDO gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada.
[C-1-5] NÃO DEVE gravar no provedor de telefonia para uma mensagem bloqueada.
[C-1-6] É PRECISO implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada pelo método TelecomManager.createManageBlockedNumbersIntent().
[C-1-7] NÃO DEVE permitir que usuários secundários visualizem ou editem os números bloqueados no dispositivo, já que a plataforma Android assume que o usuário principal tem controle total dos serviços de telefonia, uma única instância, no dispositivo. Toda a interface relacionada ao bloqueio PRECISA ser oculta para usuários secundários, e a lista de bloqueados PRECISA ser respeitada.
DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.

7.4.1.2. API Telecom

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

[C-1-1] É PRECISO oferecer suporte às APIs ConnectionService descritas no SDK.
[C-1-2] É PRECISO mostrar uma nova chamada recebida e oferecer ao usuário a possibilidade de aceitar ou rejeitar a chamada recebida quando o usuário estiver em uma chamada em andamento feita por um app de terceiros que não oferece suporte ao recurso de retenção especificado por CAPABILITY_SUPPORT_HOLD.
[C-1-3] É PRECISO ter um aplicativo que implemente o InCallService.
[C-SR] É ALTAMENTE RECOMENDADO notificar o usuário de que atender uma chamada recebida encerrará uma chamada em andamento.

A implementação do AOSP atende a esses requisitos com uma notificação de alerta que indica ao usuário que atender uma chamada recebida fará com que a outra seja encerrada.
[C-SR] É ALTAMENTE RECOMENDADO pré-carregar o app de discagem padrão que mostra uma entrada de registro de chamadas e o nome de um app de terceiros no registro de chamadas quando o app de terceiros define a chave de extras EXTRA_LOG_SELF_MANAGED_CALLS no PhoneAccount como true.
[C-SR] É ALTAMENTE RECOMENDADO processar os eventos KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK dos fones de ouvido de áudio para as APIs android.telecom, conforme abaixo:
- Chamar Connection.onDisconnect() quando um toque curto do evento de tecla for detectado durante uma chamada em andamento.
- Chamar Connection.onAnswer() quando um toque curto do evento de tecla for detectado durante uma chamada recebida.
- Chamar Connection.onReject() quando um toque longo do evento de tecla for detectado durante uma ligação recebida.
- Alternar o status de silêncio do CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementações de dispositivos:

DEVE incluir suporte a uma ou mais formas de 802.11.

Se as implementações de dispositivos incluírem suporte a 802.11 e exporem a funcionalidade a um aplicativo de terceiros, elas:

[C-1-1] É PRECISO implementar a API correspondente do Android.
[C-1-2] É OBRIGATÓRIO informar a flag de recurso de hardware android.hardware.wifi.
[C-1-3] É OBRIGATÓRIO implementar a API multicast conforme descrito na documentação do SDK.
[C-1-4] É PRECISO oferecer suporte a DNS multicast (mDNS) e NÃO filtrar pacotes mDNS (224.0.0.251) em qualquer momento da operação, incluindo:
- Mesmo quando a tela não está ativa.
- Para implementações de dispositivos Android TV, mesmo em estados de energia em espera.
[C-1-5] NÃO é permitido tratar a chamada do método da API WifiManager.enableNetwork() como uma indicação suficiente para alternar o Network ativo atualmente, que é usado por padrão para o tráfego do aplicativo e é retornado pelos métodos da API ConnectivityManager, como getActiveNetwork e registerDefaultNetworkCallback. Em outras palavras, eles só poderão desativar o acesso à Internet fornecido por qualquer outro provedor de rede (por exemplo, dados móveis) se validarem que a rede Wi-Fi está fornecendo acesso à Internet.
[C-1-6] É ALTAMENTE RECOMENDADO que, quando o método da API ConnectivityManager.reportNetworkConnectivity() for chamado, reavalie o acesso à Internet no Network e, quando a avaliação determinar que o Network atual não oferece mais acesso à Internet, mude para qualquer outra rede disponível (por exemplo, dados móveis) que ofereça acesso à Internet.
[C-SR] É ALTAMENTE RECOMENDADO randomizar o endereço MAC de origem e o número de sequência dos frames de solicitação de sondagem, uma vez no início de cada verificação, enquanto a STA está desconectada.
- Cada grupo de frames de solicitação de sondagem que compõem uma verificação deve usar um endereço MAC consistente (NÃO DEVE ser aleatório no meio de uma verificação).
- O número de sequência da solicitação de sondagem precisa ser iterado normalmente (sequencialmente) entre as solicitações de sondagem em uma verificação.
- O número de sequência da solicitação de sondagem precisa ser aleatório entre a última solicitação de sondagem de uma varredura e a primeira solicitação de sondagem da próxima varredura.
[C-SR] É ALTAMENTE RECOMENDADO, enquanto a STA estiver desconectada, permitir apenas os seguintes elementos nos frames de solicitação de sondagem:
- Conjunto de parâmetros SSID (0)
- Conjunto de parâmetros do DS (3)

Se as implementações de dispositivos incluírem suporte ao modo de economia de energia do Wi-Fi, conforme definido no padrão IEEE 802.11, elas:

[C-3-1] É OBRIGATÓRIO desativar o modo de economia de energia do Wi-Fi sempre que um app adquirir o 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 o dispositivo está no modo de bloqueio de latência baixa do Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) PRECISA ser menor do que a latência durante o modo de bloqueio de alto desempenho do Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
[C-SR] É ALTAMENTE RECOMENDADO minimizar a latência de ida e volta do Wi-Fi sempre que uma trava de baixa latência (WIFI_MODE_FULL_LOW_LATENCY) for adquirida e entrar em vigor.

Se as implementações de dispositivos oferecem suporte ao Wi-Fi e usam essa tecnologia para a busca de local, elas:

[C-2-1] É OBRIGATÓRIO fornecer uma característica de uso do usuário para ativar/desativar a leitura de valor pelo método da API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementações de dispositivos:

DEVE incluir suporte para Wi-Fi Direct (Wi-Fi ponto a ponto).

Se as implementações de dispositivos incluem suporte para Wi-Fi Direct, elas:

[C-1-1] É PRECISO implementar a API correspondente do Android, conforme descrito na documentação do SDK.
[C-1-2] É OBRIGATÓRIO informar o recurso de hardware android.hardware.wifi.direct.
[C-1-3] PRECISA ter suporte à operação regular de Wi-Fi.
[C-1-4] É PRECISO oferecer suporte a operações Wi-Fi e Wi-Fi Direct simultaneamente.

7.4.2.2. Configuração de link direto com Wi-Fi em túnel

Implementações de dispositivos:

DEVE incluir suporte para a configuração de link direto com encapsulamento (TDLS, na sigla em inglês) do Wi-Fi, conforme descrito na documentação do SDK do Android.

Se as implementações de dispositivos incluírem suporte a TDLS e o TDLS for ativado pela API WiFiManager, elas:

[C-1-1] É PRECISO declarar suporte a TDLS por meio de WifiManager.isTdlsSupported.
Use TDLS apenas quando for possível E benéfico.
DEVE ter alguma heurística e NÃO usar TDLS quando o desempenho for pior do que passar pelo ponto de acesso Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementações de dispositivos:

DEVE incluir suporte a Wi-Fi Aware.

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

[C-1-1] É OBRIGATÓRIO implementar as APIs WifiAwareManager conforme descrito na documentação do SDK.
[C-1-2] É OBRIGATÓRIO declarar a flag de recurso android.hardware.wifi.aware.
[C-1-3] É PRECISO oferecer suporte a operações do Wi-Fi e do Wi-Fi Aware simultaneamente.
[C-1-4] É NECESSÁRIO randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de até 30 minutos e sempre que o Wi-Fi Aware estiver ativado, a menos que uma operação de medição do Aware esteja em andamento ou um caminho de dados do Aware esteja ativo. Não é esperado que a randomização ocorra enquanto o caminho de dados estiver ativo.

Se as implementações do dispositivo incluírem suporte ao Wi-Fi Aware e à localização do Wi-Fi, conforme descrito na Seção 7.4.2.5, e exporem essas funcionalidades a apps de terceiros, elas:

[C-2-1] É PRECISO implementar as APIs de descoberta com localização: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint do Wi-Fi

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

DEVE incluir suporte ao Wi-Fi Passpoint.

Se as implementações de dispositivos incluem suporte para Wi-Fi Passpoint, elas:

[C-1-2] É PRECISO implementar as APIs WifiManager relacionadas à Passpoint conforme descrito na documentação do SDK.
[C-1-3] É PRECISO oferecer suporte ao padrão IEEE 802.11u, especificamente relacionado à descoberta e seleção de rede, como o serviço de publicidade genérico (GAS, na sigla em inglês) e o protocolo de consulta de rede de acesso (ANQP, na sigla em inglês).

Por outro lado, se as implementações de dispositivos não incluem suporte ao Wi-Fi Passpoint:

[C-2-1] A implementação das APIs WifiManager relacionadas ao Passpoint PRECISA gerar uma UnsupportedOperationException.

7.4.2.5. Local do Wi-Fi (tempo de retorno do Wi-Fi - RTT)

Implementações de dispositivos:

DEVE incluir suporte para Local do Wi-Fi.

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

[C-1-1] É OBRIGATÓRIO implementar as APIs WifiRttManager conforme descrito na documentação do SDK.
[C-1-2] É OBRIGATÓRIO declarar a flag de recurso android.hardware.wifi.rtt.
[C-1-3] É PRECISO randomizar o endereço MAC de origem de cada burst de RTT que é executado enquanto a interface Wi-Fi em que o RTT está sendo executado não está associada a um ponto de acesso.

7.4.2.6. Descarregar o keepalive do Wi-Fi

Implementações de dispositivos:

DEVE incluir suporte para transferência de dados de keepalive do Wi-Fi.

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

[C-1-1] É PRECISO oferecer suporte à API SocketKeepAlive.
[C-1-2] É PRECISO ter suporte a pelo menos três slots de keepalive simultâneos por Wi-Fi e pelo menos um slot de keepalive por rede celular.

Se as implementações de dispositivos não incluírem suporte ao offload de keepalive do Wi-Fi, elas:

[C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocolo de provisionamento de dispositivo)

Implementações de dispositivos:

DEVE incluir suporte para Wi-Fi Easy Connect (DPP).

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

[C-1-1] O método WifiManager#isEasyConnectSupported() PRECISA retornar true.

7.4.3. Bluetooth

Se as implementações do dispositivo oferecem suporte ao perfil de áudio Bluetooth, elas:

DEVE oferecer suporte a codecs de áudio avançados e Bluetooth (por exemplo, LDAC).

Se as implementações do dispositivo oferecerem suporte a HFP, A2DP e AVRCP, elas:

DEVE oferecer suporte a pelo menos cinco dispositivos conectados.

Se as implementações do dispositivo declararem o recurso android.hardware.vr.high_performance, elas:

[C-1-1] É PRECISO ter suporte a Bluetooth 4.2 e à extensão de comprimento de dados do Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.

Se as implementações de dispositivos incluem suporte para Bluetooth e Bluetooth de baixa energia, elas:

[C-2-1] É OBRIGATÓRIO declarar os recursos relevantes da plataforma (android.hardware.bluetooth e android.hardware.bluetooth_le, respectivamente) e implementar as APIs da plataforma.
DEVE implementar perfis relevantes de Bluetooth, como A2DP, AVRCP, OBEX, HFP etc., conforme apropriado para o dispositivo.

Se as implementações de dispositivos incluem suporte para Bluetooth de baixa energia (BLE), elas:

[C-3-1] É OBRIGATÓRIO declarar o recurso de hardware android.hardware.bluetooth_le.
[C-3-2] É OBRIGATÓRIO ativar as APIs Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e em android.bluetooth.
[C-3-3] É PRECISO informar o valor correto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar se a lógica de filtragem para as classes da API ScanFilter está implementada.
[C-3-4] É OBRIGATÓRIO informar o valor correto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar se a publicidade de baixa energia é compatível.
[C-3-5] É OBRIGATÓRIO implementar um tempo limite de endereço particular solucionável (RPA) de no máximo 15 minutos e girar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo estiver usando ativamente o BLE para digitalização ou publicidade. Para evitar ataques de tempo, os intervalos de tempo limite também precisam ser aleatórios entre 5 e 15 minutos.
DEVE oferecer suporte ao descarregamento da lógica de filtragem para o chipset Bluetooth ao implementar a API ScanFilter.
DEVE oferecer suporte ao descarregamento da verificação em lote para o chipset Bluetooth.
DEVE oferecer suporte a vários anúncios com pelo menos quatro slots.

Se as implementações do dispositivo oferecem suporte ao Bluetooth LE e usam esse tipo de Bluetooth para a verificação de local, elas:

[C-4-1] É necessário fornecer uma característica de uso do usuário para ativar/desativar a leitura de valor pela BluetoothAdapter.isBleScanAlwaysAvailable() da API do sistema.

Se as implementações do dispositivo incluem suporte para Bluetooth LE e perfil de aparelhos auditivos, conforme descrito em Suporte a áudio de aparelho auditivo usando Bluetooth LE, elas:

[C-5-1] É PRECISO retornar true para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

7.4.4. Comunicação a curta distância (NFC)

Implementações de dispositivos:

DEVE incluir um transceptor e hardware relacionado para comunicações de campo próximo (NFC).
[C-0-1] É OBRIGATÓRIO implementar as APIs android.nfc.NdefMessage e android.nfc.NdefRecord, mesmo que elas não incluam suporte a NFC ou declarem o recurso android.hardware.nfc, porque as classes representam um formato de representação de dados independente de protocolo.

Se as implementações de dispositivos incluírem hardware NFC e planejam disponibilizá-lo para apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO informar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature().
DEVE ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões NFC:
[C-1-2] PRECISA ser capaz de atuar como leitor/gravador do NFC Forum (conforme definido pela especificação técnica do NFC Forum NFCForum-TS-DigitalProtocol-1.0) pelos seguintes padrões de NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Tipos de tag do NFC Forum 1, 2, 3, 4 e 5 (definidos pelo NFC Forum)
[SR] ALTAMENTE RECOMENDADO para ler e gravar mensagens NDEF e dados brutos usando os seguintes padrões de NFC. Embora os padrões de NFC sejam indicados como ALTAMENTE RECOMENDADOS, a definição de compatibilidade para uma versão futura está planejada para mudar para OBRIGATÓRIO. Esses padrões são opcionais nesta versão, mas serão obrigatórios em versões futuras. É altamente recomendável que os dispositivos novos e atuais que executam essa versão do Android atendam a esses requisitos agora para que possam fazer upgrade para as versões futuras da plataforma.
[C-1-13] É PRECISO pesquisar todas as tecnologias com suporte no modo de descoberta de NFC.
DEVE estar no modo de descoberta de NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.
DEVE ser capaz de ler o código de barras e o URL (se codificado) dos produtos de código de barras NFC Thinfilm.

Os links disponíveis publicamente não estão disponíveis para as especificações do JIS, ISO e NFC Forum citadas acima.

O Android inclui suporte para o modo de emulação de cartão host (HCE) do NFC.

Se as implementações do dispositivo incluírem um chipset de controlador NFC compatível com HCE (para NfcA e/ou NfcB) e oferecerem suporte ao roteamento de ID do aplicativo (AID, na sigla em inglês), elas:

[C-2-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.nfc.hce.
[C-2-2] É NECESSÁRIO oferecer suporte a APIs HCE de NFC, conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem um chipset de controlador NFC compatível com HCE para NfcF e implementarem o recurso para aplicativos de terceiros, elas:

[C-3-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.nfc.hcef.
[C-3-2] É OBRIGATÓRIO implementar as APIs de emulação de cartão NfcF conforme definido no SDK do Android.

Se as implementações do dispositivo incluírem suporte geral a NFC, conforme descrito nesta seção, e oferecerem suporte a tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) na função de leitor/gravador, elas:

[C-4-1] É OBRIGATÓRIO implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
[C-4-2] É OBRIGATÓRIO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). Esse não é um recurso padrão do Android e, como tal, não aparece como uma constante na classe android.content.pm.PackageManager.

7.4.5. Protocolos de rede e APIs

7.4.5.1. Capacidade mínima de rede

Implementações de dispositivos:

[C-0-1] É PRECISO incluir suporte a uma ou mais formas de rede de dados. Especificamente, as implementações de dispositivos precisam incluir suporte a pelo menos um padrão de dados com capacidade de 200 Kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
DEVE incluir suporte a pelo menos um padrão de dados sem fio comum, como 802.11 (Wi-Fi), quando um padrão de rede física (como Ethernet) é a conexão de dados principal.
PODE implementar mais de uma forma de conectividade de dados.

7.4.5.2. IPv6

Implementações de dispositivos:

[C-0-2] É PRECISO incluir uma pilha de rede IPv6 e oferecer suporte à comunicação IPv6 usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, bem como as APIs nativas, como soquetes AF_INET6.
[C-0-3] É OBRIGATÓRIO ativar o IPv6 por padrão.
É PRECISO garantir que a comunicação IPv6 seja tão confiável quanto o IPv4, por exemplo:
- [C-0-4] É PRECISO manter a conectividade IPv6 no modo de suspensão.
- [C-0-5] A limitação de taxa NÃO PODE fazer com que o dispositivo perca a conectividade IPv6 em qualquer rede compatível com IPv6 que use tempos de vida de RA de pelo menos 180 segundos.
[C-0-6] É OBRIGATÓRIO fornecer a aplicativos de terceiros conectividade direta de IPv6 à rede quando conectados a uma rede IPv6, sem qualquer forma de tradução de endereço ou porta que ocorra localmente no dispositivo. As APIs gerenciadas, como Socket#getLocalAddress ou Socket#getLocalPort, e as APIs NDK, como getsockname() ou IPV6_PKTINFO, precisam retornar o endereço IP e a porta que são usados para enviar e receber pacotes na rede e que são visíveis como o IP e a porta de origem para servidores da Internet (Web).

O nível necessário de suporte ao IPv6 depende do tipo de rede, conforme mostrado nos requisitos a seguir.

Se as implementações de dispositivos forem compatíveis com Wi-Fi, elas:

[C-1-1] É PRECISO oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.

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

[C-2-1] É PRECISO oferecer suporte à operação de pilha dupla e somente IPv6 na Ethernet.

Se as implementações de dispositivos oferecerem suporte a dados móveis, elas:

[C-3-1] É PRECISO oferecer suporte à operação IPv6 (somente IPv6 e possivelmente pilha dupla) em dispositivos móveis.

Se as implementações de dispositivos forem compatíveis com mais de um tipo de rede (por exemplo, Wi-Fi e dados da rede celular), eles:

[C-4-1] É necessário atender simultaneamente aos requisitos acima em cada rede quando o dispositivo estiver conectado a mais de um tipo de rede.

7.4.5.3. Portais passivos

Um portal cativo é uma rede que exige login para acessar a Internet.

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

[C-1-1] É OBRIGATÓRIO fornecer um aplicativo de portal captive para processar a intent ACTION_CAPTIVE_PORTAL_SIGN_IN e exibir a página de login do portal captive, enviando essa intent em uma chamada para a API System ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] É OBRIGATÓRIO detectar portais cativos e oferecer suporte ao login pelo aplicativo de portal cativo quando o dispositivo estiver conectado a qualquer tipo de rede, incluindo rede celular/móvel, Wi-Fi, Ethernet ou Bluetooth.
[C-1-3] É PRECISO oferecer suporte ao login em portais cativos usando DNS de texto sem criptografia quando o dispositivo estiver configurado para usar o modo estrito de DNS particular.
[C-1-4] É OBRIGATÓRIO usar o DNS criptografado conforme a documentação do SDK para android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive em todo o tráfego de rede que não se comunique explicitamente com o portal captive.
[C-1-5] É PRECISO garantir que, enquanto o usuário estiver fazendo login em um portal cativo, a rede padrão usada pelos aplicativos (retornada por ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback e usada por padrão pelas APIs de rede Java, como java.net.Socket e APIs nativas, como connect()) seja qualquer outra rede disponível que ofereça acesso à Internet, se disponível.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

[C-0-1] A configuração mestre de sincronização automática PRECISA estar ativada por padrão para que o método getMasterSyncAutomatically() retorne "true".

7.4.7. Economia de dados

Se as implementações de dispositivos incluírem uma conexão limitada, elas serão:

[SR] É ALTAMENTE RECOMENDADO fornecer o modo de economia de dados.

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

[C-1-1] É PRECISO oferecer suporte a todas as APIs na classe ConnectivityManager, conforme descrito na documentação do SDK.

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

[C-2-1] PRECISA retornar o valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] NÃO DEVE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Elementos de segurança

Se as implementações de dispositivos oferecerem suporte a elementos de segurança compatíveis com a API Open Mobile e os disponibilizarem para apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO enumerar os leitores de elementos seguros disponíveis pela API android.se.omapi.SEService.getReaders().
[C-1-2] É NECESSÁRIO declarar os flags de recursos corretos usando android.hardware.se.omapi.uicc para o dispositivo com elementos seguros baseados em UICC, android.hardware.se.omapi.ese para o dispositivo com elementos seguros baseados em eSE e android.hardware.se.omapi.sd para o dispositivo com elementos seguros baseados em SD.

7,5. Cameras

Se as implementações do dispositivo incluírem pelo menos uma câmera, elas:

[C-1-1] É OBRIGATÓRIO declarar a flag de recurso android.hardware.camera.any.
[C-1-2] É PRECISO que um aplicativo possa alocar simultaneamente três bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo sensor de câmera de maior resolução no dispositivo, enquanto a câmera está aberta para fins de visualização básica e captura de fotos.
[C-1-3] É necessário garantir que o app de câmera padrão pré-instalado que processa intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE seja responsável por remover a localização do usuário nos metadados da imagem antes de enviar para o app de recebimento quando ele não tiver ACCESS_FINE_LOCATION.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera localizada na lateral do dispositivo oposta à tela. Ou seja, ela captura imagens de cenas no lado oposto do dispositivo, como uma câmera tradicional.

Implementações de dispositivos:

DEVE incluir uma câmera traseira.

Se as implementações do dispositivo incluírem pelo menos uma câmera traseira, elas:

[C-1-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera e android.hardware.camera.any.
[C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
DEVE ter o foco automático de hardware ou de software implementado no driver da câmera (transparente para o software do aplicativo).
PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
PODE incluir um flash.

Se a câmera tiver um flash:

[C-2-1] A lâmpada do flash NÃO PODE estar acesa enquanto uma instância de android.hardware.Camera.PreviewCallback estiver registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha ativado explicitamente o flash ativando os atributos FLASH_MODE_AUTO ou FLASH_MODE_ON de um objeto Camera.Parameters. Essa restrição não se aplica ao app de câmera do sistema integrado do dispositivo, mas apenas a apps de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela, ou seja, uma câmera normalmente usada para capturar imagens do usuário, como em videoconferências e aplicativos semelhantes.

Implementações de dispositivos:

PODE incluir uma câmera frontal.

Se as implementações do dispositivo incluírem pelo menos uma câmera frontal, elas:

[C-1-1] É OBRIGATÓRIO informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
[C-1-2] PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
[C-1-3] NÃO use uma câmera frontal como padrão para a API Camera e NÃO configure a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera do dispositivo.
[C-1-4] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo quando o aplicativo atual solicitou explicitamente que a tela da câmera fosse girada por uma chamada ao método android.hardware.Camera.setDisplayOrientation(). Por outro lado, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo quando o aplicativo atual não solicita explicitamente que a tela da câmera seja girada por uma chamada ao método android.hardware.Camera.setDisplayOrientation().
[C-1-5] NÃO É PERMITIDO espelhar os streams de imagem estática ou vídeo capturados e retornados aos callbacks do aplicativo ou comprometidos com o armazenamento de mídia.
[C-1-6] A imagem mostrada pelo pós-visualização precisa ser espelhada da mesma forma que o fluxo de imagens da visualização da câmera.
PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

Se as implementações de dispositivo puderem ser giradas pelo usuário (como automaticamente por um acelerômetro ou manualmente pela entrada do usuário):

[C-2-1] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação atual do dispositivo.

7.5.3. Câmera externa

Implementações de dispositivos:

PODE incluir suporte a uma câmera externa que não está necessariamente sempre conectada.

Se as implementações do dispositivo incluem suporte para uma câmera externa, elas:

[C-1-1] É OBRIGATÓRIO declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
[C-1-2] É PRECISO oferecer suporte à classe de vídeo USB (UVC 1.0 ou mais recente) se a câmera externa se conectar pela porta host USB.
[C-1-3] É PRECISO passar nos testes de CTS da câmera com um dispositivo de câmera externa física conectado. Os detalhes dos testes do CTS da câmera estão disponíveis em source.android.com.
DEVE oferecer suporte a compactações de vídeo, como MJPEG, para permitir a transferência de streams não codificados de alta qualidade (ou seja, streams de imagem brutos ou compactados de forma independente).
PODE oferecer suporte a várias câmeras.
PODE oferecer suporte à codificação de vídeo baseada na câmera.

Se a codificação de vídeo baseada na câmera for compatível:

[C-2-1] Um fluxo simultâneo não codificado / MJPEG (resolução QVGA ou superior) PRECISA estar acessível à implementação do dispositivo.

7.5.4. Comportamento da API Camera

O Android inclui dois pacotes de API para acessar a câmera. A API android.hardware.camera2 mais recente expõe o controle de câmera de nível inferior ao app, incluindo fluxos de streaming/de fotos em sequência eficientes sem cópia e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, redução de ruído, nitidez e muito mais.

O pacote de API mais antigo, android.hardware.Camera, está marcado como descontinuado no Android 5.0, mas ainda está disponível para uso em apps. As implementações de dispositivos Android precisam garantir o suporte contínuo da API, conforme descrito nesta seção e no SDK do Android.

Todos os recursos comuns entre a classe android.hardware.Camera descontinuada e o pacote mais recente android.hardware.camera2 PRECISAM ter desempenho e qualidade equivalentes nas duas APIs. Por exemplo, com configurações equivalentes, a velocidade e a precisão do foco automático precisam ser idênticas, e a qualidade das imagens capturadas precisa ser a mesma. Os recursos que dependem da semântica diferente das duas APIs não precisam ter velocidade ou qualidade correspondentes, mas precisam ser o mais semelhantes possível.

As implementações de dispositivos precisam implementar os seguintes comportamentos para as APIs relacionadas à câmera, para todas as câmeras disponíveis. Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO usar android.hardware.PixelFormat.YCbCr_420_SP para dados de visualização fornecidos a callbacks de app quando um app nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] PRECISA estar no formato de codificação NV21 quando um aplicativo registra uma instância android.hardware.Camera.PreviewCallback e o sistema chama o método onPreviewFrame() e o formato de visualização é YCbCr_420_SP, os dados no byte[] são transmitidos para onPreviewFrame(). Ou seja, o NV21 PRECISA ser o padrão.
[C-0-3] É OBRIGATÓRIO ter suporte ao formato YV12 (conforme indicado pela constante android.graphics.ImageFormat.YV12) para visualizações de câmera frontal e traseira para android.hardware.Camera. O codificador de vídeo e a câmera de hardware podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA oferecer suporte à conversão para YV12.
[C-0-4] É PRECISO oferecer suporte aos formatos android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG como saídas pela API android.media.ImageReader para dispositivos android.hardware.camera2 que anunciam o recurso REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE em android.request.availableCapabilities.
[C-0-5] A API Camera completa incluída na documentação do SDK do Android ainda precisa ser implementada, mesmo que o dispositivo inclua foco automático de hardware ou outros recursos. Por exemplo, câmeras sem foco automático PRECISAM chamar qualquer instância registrada de android.hardware.Camera.AutoFocusCallback, mesmo que isso não tenha relevância para uma câmera sem foco automático. Isso se aplica a câmeras frontais. Por exemplo, embora a maioria das câmeras frontais não ofereça suporte ao foco automático, os callbacks da API ainda precisam ser "falsos", conforme descrito.
[C-0-6] É PRECISO reconhecer e honrar cada nome de parâmetro definido como uma constante na classe android.hardware.Camera.Parameters e na classe android.hardware.camera2.CaptureRequest. Por outro lado, as implementações de dispositivos NÃO PODEM reconhecer ou aceitar constantes de string transmitidas ao método android.hardware.Camera.setParameters(), exceto aquelas documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos precisam oferecer suporte a todos os parâmetros padrão da câmera, se o hardware permitir, e NÃO podem oferecer suporte a tipos personalizados de parâmetros da câmera. Por exemplo, implementações de dispositivos que oferecem suporte à captura de imagens usando técnicas de High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera Camera.SCENE_MODE_HDR.
[C-0-7] É OBRIGATÓRIO informar o nível adequado de suporte com a propriedade android.info.supportedHardwareLevel, conforme descrito no SDK do Android, e informar as flags de recursos do framework adequadas.
[C-0-8] PRECISA declarar os recursos de câmera individuais de android.hardware.camera2 pela propriedade android.request.availableCapabilities e declarar as flags de recursos adequadas. PRECISA definir a flag de recurso se algum dos dispositivos de câmera conectados oferecer suporte a ela.
[C-0-9] PRECISA transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada da foto for adicionada à loja de mídia.
[C-0-10] É OBRIGATÓRIO transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da imagem for adicionada à loja de mídia.
[C-0-11] É OBRIGATÓRIO que todas as câmeras sejam acessíveis pela API android.hardware.Camera descontinuada e pela API android.hardware.camera2.
[C-0-12] É OBRIGATÓRIO garantir que a aparência facial NÃO seja alterada, incluindo, mas não se limitando a, alterar a geometria facial, o tom de pele ou o suavização da pele facial para qualquer API android.hardware.camera2 ou android.hardware.Camera.
[C-SR] Para dispositivos com várias câmeras RGB voltadas para a mesma direção, é ALTAMENTE RECOMENDADO oferecer suporte a um dispositivo de câmera lógica que liste o recurso CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, 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 a apps de terceiros, elas:

[C-1-1] É OBRIGATÓRIO implementar essa API de câmera usando a API android.hardware.camera2.
PODE fornecer tags e/ou extensões do fornecedor à API android.hardware.camera2.

7.5.5. Orientação da câmera

Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, elas:

[C-1-1] PRECISA estar orientado de forma que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é segurado na orientação paisagem, as câmeras precisam capturar imagens na orientação paisagem. Isso se aplica independentemente da orientação natural do dispositivo, ou seja, se aplica a dispositivos com orientação principal de paisagem e retrato.

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos

Implementações de dispositivos:

[C-0-1] PRECISA incluir um gerenciador de download que os aplicativos PODEM usar para fazer o download de arquivos de dados e PRECISA ser capaz de fazer o download de arquivos individuais de pelo menos 100 MB para o local de "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 conhecido como "armazenamento externo compartilhado", "armazenamento compartilhado do aplicativo" ou pelo caminho Linux "/sdcard" em que ele é montado.
[C-0-2] PRECISA ser configurado com o armazenamento compartilhado montado por padrão, ou seja, "pronto para uso", independentemente de o armazenamento ser implementado em um componente de armazenamento interno ou em um meio de armazenamento removível (por exemplo, slot para cartão Secure Digital).
[C-0-3] É PRECISO montar o armazenamento compartilhado do aplicativo diretamente no caminho sdcard do Linux ou incluir um link simbólico do Linux de sdcard para o ponto de montagem real.
[C-0-4] É necessário ativar o armazenamento com escopo por padrão para todos os apps com o nível desejado da API 29 ou mais recente, exceto na seguinte situação:
- Quando o app solicitou android:requestLegacyExternalStorage="true" no manifesto.
[C-0-5] É OBRIGATÓRIO editar os metadados de localização, como tags EXIF do GPS, armazenados em arquivos de mídia quando esses arquivos são acessados por MediaStore, exceto quando o app de chamada tem a permissão ACCESS_MEDIA_LOCATION.

As implementações de dispositivos PODEM atender aos requisitos acima usando uma das seguintes opções:

Armazenamento removível acessível ao usuário, como um slot para cartão Secure Digital (SD).
Uma parte do armazenamento interno (não removível) conforme implementado no Android Open Source Project (AOSP).

Se as implementações de dispositivos usarem armazenamento removível para atender aos requisitos acima, elas:

[C-1-1] É OBRIGATÓRIO implementar uma interface do usuário pop-up ou aviso ao usuário quando não houver um meio de armazenamento inserido no slot.
[C-1-2] É OBRIGATÓRIO incluir um meio de armazenamento formatado em FAT (por exemplo, um cartão SD) ou mostrar na caixa e em outros materiais disponíveis no momento da compra que o meio de armazenamento precisa ser comprado separadamente.

Se as implementações do dispositivo usarem uma parte do armazenamento não removível para atender aos requisitos acima, elas:

DEVE usar a implementação do AOSP do armazenamento compartilhado do aplicativo interno.
PODE compartilhar o espaço de armazenamento com os dados privados do aplicativo.

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

[C-3-1] É PRECISO fornecer um mecanismo para acessar os dados no armazenamento compartilhado do aplicativo em um computador host.
EXPORÃO o conteúdo das duas rotas de armazenamento de forma transparente pelo serviço de verificação de mídia do Android e pelo android.provider.MediaStore.
PODE usar o armazenamento em massa USB, mas DEVE usar o protocolo de transferência de mídia para atender a esse requisito.

Se as implementações do dispositivo tiverem uma porta USB com o modo periférico USB e oferecerem suporte ao protocolo de transferência de mídia, elas:

PRECISA ser compatível com o host de MTP do Android de referência, 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 o dispositivo for móvel, ao contrário da televisão, as implementações do dispositivo serão:

[SR] É ALTAMENTE RECOMENDADO implementar o armazenamento adaptável em um local estável de longo prazo, já que a desconexão acidental pode causar perda/corrupção de dados.

Se a porta do dispositivo de armazenamento removível estiver em um local estável de longo prazo, como dentro do compartimento da bateria ou outra capa protetora, as implementações do dispositivo serão:

[SR] É ALTAMENTE RECOMENDADO implementar o armazenamento adotável.

7.7. USB

Se as implementações do dispositivo tiverem uma porta USB, elas:

DEVE oferecer suporte ao modo de periférico USB e ao modo de host USB.

7.7.1. Modo de periférico USB

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

[C-1-1] A porta PRECISA ser compatível com um host USB que tenha uma porta USB tipo A ou tipo C padrão.
[C-1-2] É OBRIGATÓRIO informar o valor correto de iSerialNumber no descritor de dispositivo padrão do USB por meio de android.os.Build.SERIAL.
[C-1-3] É NECESSÁRIO detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão do resistor do tipo C e DETECTAR MUDANÇAS NO ANÚNCIO se eles tiverem suporte para USB tipo C.
[SR] A porta DEVE usar o formato USB micro-B, micro-AB ou tipo C. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
[SR] A porta DEVE estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação de tela do software para todos os apps (incluindo a tela inicial), para que a tela seja renderizada corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
[SR] DEVE implementar suporte para consumir uma corrente de 1,5 A durante o chirp e o tráfego de HS, conforme especificado na especificação de carregamento de bateria USB, revisão 1.2. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
[SR] É ALTAMENTE RECOMENDADO não oferecer suporte a métodos de carregamento proprietários que modifiquem a tensão do Vbus além dos níveis padrão ou alterem os papéis de destino/fonte, já que isso pode resultar em problemas de interoperabilidade com os carregadores ou dispositivos que oferecem suporte aos métodos padrão de fornecimento de energia USB. Embora isso seja "FORTEMENTE RECOMENDADO", em versões futuras do Android, podemos exigir que todos os dispositivos tipo C ofereçam suporte à interoperabilidade total com carregadores tipo C padrão.
[SR] É ALTAMENTE RECOMENDADO oferecer suporte à entrega de energia para dados e troca de função de energia quando houver suporte para USB Type-C e modo host USB.
DEVE oferecer suporte ao fornecimento de energia para carregamento de alta tensão e suporte a modos alternativos, como saída de tela.
DEVE implementar a API e a especificação do acessório aberto Android (AOA, na sigla em inglês) conforme documentado na documentação do SDK do Android.

Se as implementações do dispositivo incluem uma porta USB e implementam a especificação AOA, elas:

[C-2-1] É PRECISO declarar suporte ao recurso de hardware android.hardware.usb.accessory.
[C-2-2] A classe de armazenamento em massa USB PRECISA incluir a string "android" no final da string iInterface da descrição da interface do armazenamento em massa USB.

7.7.2. Modo de host USB

Se as implementações de dispositivo incluírem uma porta USB com suporte ao modo de host, elas:

[C-1-1] É PRECISO implementar a API host USB do Android conforme documentado no SDK do Android e DECLARAR suporte ao recurso de hardware android.hardware.usb.host.
[C-1-2] É PRECISO implementar suporte para conectar periféricos USB padrão. Em outras palavras, é PRECISO:
- Ter uma porta do tipo C no dispositivo ou ser enviado com cabos que adaptam uma porta proprietária do dispositivo a uma porta USB-C padrão (dispositivo USB-C).
- Ter uma porta tipo A no dispositivo ou ser enviado com cabos que adaptam uma porta proprietária no dispositivo a uma porta USB tipo A padrão.
- Ter uma porta micro-AB no dispositivo, que DEVE ser enviada com um cabo que se adapta a uma porta tipo A padrão.
[C-1-3] NÃO PODE ser enviado com um adaptador que converte portas USB tipo A ou micro-AB em uma porta tipo C (soquete).
[C-SR] É ALTAMENTE RECOMENDÁVEL implementar a classe de áudio USB conforme documentado na documentação do SDK do Android.
DEVE oferecer suporte ao carregamento do dispositivo periférico USB conectado no modo host; anunciando uma corrente de fonte de pelo menos 1,5 A, conforme especificado na seção "Terminais" da Especificação de cabo e conector USB Type-C, revisão 1.2 para conectores USB Type-C ou usando a faixa de corrente de saída da porta de carregamento downstream(CDP), conforme especificado nas Especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
DEVEM implementar e oferecer suporte aos padrões USB Type-C.

Se as implementações do dispositivo incluem uma porta USB com suporte ao modo de host e à classe de áudio USB, elas:

[C-2-1] É PRECISO oferecer suporte à classe HID do USB.
[C-2-2] É PRECISO oferecer suporte à detecção e ao mapeamento dos seguintes campos de dados HID especificados nas tabelas de uso do USB HID e na solicitação de uso do comando de voz para as constantes KeyEvent conforme abaixo:
- Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
- Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
- Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Se as implementações do dispositivo incluírem uma porta USB com suporte ao modo host e ao Framework de acesso ao armazenamento (SAF, na sigla em inglês), elas:

[C-3-1] DEVE reconhecer todos os dispositivos MTP (protocolo de transferência de mídia) conectados remotamente e tornar o conteúdo deles acessível pelas intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

Se as implementações do dispositivo incluem uma porta USB com suporte ao modo host e ao USB Type-C, elas:

[C-4-1] É PRECISO implementar a funcionalidade da porta de dupla função, conforme definido pela especificação USB Type-C (seção 4.5.1.3.3).
[SR] É ALTAMENTE RECOMENDADO que ofereça suporte a DisplayPort, DEVE oferecer suporte a taxas de dados USB SuperSpeed e ALTAMENTE RECOMENDADO que ofereça suporte ao fornecimento de energia para dados e troca de função de energia.
[SR] É ALTAMENTE RECOMENDÁVEL que o modo de acessório do adaptador de áudio não seja compatível, conforme descrito no Apêndice A da Revisão 1.2 da especificação de cabo e conector USB Type-C.
PRECISA implementar o modelo Try.* mais adequado para o formato do dispositivo. Por exemplo, um dispositivo portátil PRECISA implementar o modelo Try.SNK.

7.8. Áudio

7.8.1. Microfone

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

[C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.microphone.
[C-1-2] É OBRIGATÓRIO atender aos requisitos de gravação de áudio na seção 5.4.
[C-1-3] É NECESSÁRIO atender aos requisitos de latência de áudio na seção 5.6.
[SR] É ALTAMENTE RECOMENDADO oferecer suporte à gravação de ultrassom, conforme descrito na seção 7.8.3.

Se as implementações do dispositivo omitirem um microfone, elas:

[C-2-1] NÃO DEVE informar a constante de recurso android.hardware.microphone.
[C-2-2] É PRECISO implementar a API de gravação de áudio pelo menos como no-ops, de acordo com a seção 7.

7.8.2. Saída de áudio

Se as implementações do dispositivo incluírem um alto-falante ou uma porta de saída de áudio/multimídia para um periférico de saída de áudio, como uma entrada de áudio de 3,5 mm com quatro condutores ou uma porta no modo host USB usando a classe de áudio USB, elas:

[C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.audio.output.
[C-1-2] É PRECISO atender aos requisitos de reprodução de áudio na seção 5.5.
[C-1-3] É NECESSÁRIO atender aos requisitos de latência de áudio na seção 5.6.
[SR] É ALTAMENTE RECOMENDADO oferecer suporte à reprodução próxima à ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos não incluírem um alto-falante ou uma porta de saída de áudio, elas:

[C-2-1] NÃO DEVE informar o recurso android.hardware.audio.output.
[C-2-2] É PRECISO implementar as APIs relacionadas à saída de áudio como no-ops, no mínimo.

Para os fins desta seção, uma "porta de saída" é uma interface física, como uma entrada de áudio de 3,5 mm, HDMI ou porta de modo host USB com classe de áudio USB. O suporte à saída de áudio por protocolos baseados em rádio, como Bluetooth, Wi-Fi ou rede celular, não se qualifica como inclusão de uma "porta de saída".

7.8.2.1. Portas de áudio analógico

Para ser compatível com fones de ouvido e outros acessórios de áudio que usam o plugue de áudio de 3,5 mm em todo o ecossistema do Android, se as implementações do dispositivo incluírem uma ou mais portas de áudio analógico, elas:

[C-SR] É ALTAMENTE RECOMENDADO incluir pelo menos uma das portas de áudio como uma entrada de áudio de 3,5 mm com 4 condutores.

Se as implementações do dispositivo tiverem um conector de áudio de 3,5 mm com quatro condutores, elas:

[C-1-1] É PRECISO oferecer suporte à reprodução de áudio em fones de ouvido estéreo e fones de ouvido estéreo com microfone.
[C-1-2] É PRECISO oferecer suporte a conectores de áudio TRRS com a ordem de pinagem CTIA.
[C-1-3] PRECISA oferecer suporte à detecção e ao mapeamento para os códigos de tecla dos três intervalos de impedância equivalente entre o microfone e os condutores de aterramento no plugue de áudio:
- 70 ohms ou menos: KEYCODE_HEADSETHOOK
- 210-290 ohms: KEYCODE_VOLUME_UP
- 360-680 ohms: KEYCODE_VOLUME_DOWN
[C-1-4] PRECISA acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que todos os contatos do plugue estiverem tocando os segmentos relevantes na tomada.
[C-1-5] É PRECISO que ele seja capaz de gerar pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohms.
[C-1-6] A tensão de polarização do microfone DEVE estar entre 1,8 V e 2,9 V.
[C-1-7] É OBRIGATÓRIO detectar e mapear para o código de tecla o seguinte intervalo de impedância equivalente entre o microfone e os condutores de aterramento no plugue de áudio:
- 110-180 ohms:KEYCODE_VOICE_ASSIST
[C-SR] É ALTAMENTE RECOMENDADO oferecer suporte a plugues de áudio com a ordem de pinagem OMTP.
[C-SR] É ALTAMENTE RECOMENDADO oferecer suporte à gravação de áudio de fones de ouvido estéreo com microfone.

Se as implementações do dispositivo tiverem uma entrada de áudio de 3,5 mm com quatro condutores e oferecerem suporte a um microfone, e transmitirem o android.intent.action.HEADSET_PLUG com o valor extra do microfone definido como 1, elas:

[C-2-1] É PRECISO oferecer suporte à detecção de microfone no acessório de áudio conectado.

7.8.2.2. Portas de áudio digital

Para ser compatível com fones de ouvido e outros acessórios de áudio que usam conectores USB-C e implementam (classe de áudio USB) em todo o ecossistema do Android, conforme definido na especificação de fones de ouvido USB do Android.

Consulte a seção 2.2.1 para ver os requisitos específicos do dispositivo.

7.8.3. Near-Ultrasound

O áudio próximo ao ultrassom é a faixa de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

É necessário informar corretamente o suporte ao recurso de áudio de 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 potência média do microfone na faixa de 18,5 kHz a 20 kHz PRECISA ser de no máximo 15 dB abaixo da resposta em 2 kHz.
[C-1-2] A relação sinal-ruído não ponderada do microfone de 18,5 kHz a 20 kHz para um tom de 19 kHz em -26 dBFS PRECISA ser maior que 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND for "true":

[C-2-1] A resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser pelo menos 40 dB abaixo da resposta em 2 kHz.

7.8.4. Integridade do sinal

Implementações de dispositivos: * DEVEM fornecer um caminho de sinal de áudio sem falhas para fluxos de entrada e saída em dispositivos portáteis, conforme definido por zero falhas medidas durante um teste de um minuto por caminho. Teste usando o "Automated Glitch Test" do [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester).

O teste requer um dongle de loopback de áudio, usado diretamente em uma entrada de 3,5 mm e/ou em combinação com um adaptador USB-C para 3,5 mm. Todas as portas de saída de áudio precisam ser testadas.

O OboeTester atualmente oferece suporte a caminhos AAudio. Portanto, as combinações a seguir devem ser testadas para verificar falhas usando o AAudio:

Modo de desempenho	Compartilhamento	Taxa de amostragem	Em Chans	Out Chans
LOW_LATENCY	EXCLUSIVO	NÃO ESPECIFICADO	1	2
LOW_LATENCY	EXCLUSIVO	NÃO ESPECIFICADO	2	1
LOW_LATENCY	COMPARTILHADO	NÃO ESPECIFICADO	1	2
LOW_LATENCY	COMPARTILHADO	NÃO ESPECIFICADO	2	1
NENHUMA	COMPARTILHADO	48000	1	2
NENHUMA	COMPARTILHADO	48000	2	1
NENHUMA	COMPARTILHADO	44100	1	2
NENHUMA	COMPARTILHADO	44100	2	1
NENHUMA	COMPARTILHADO	16000	1	2
NENHUMA	COMPARTILHADO	16000	2	1

Um stream confiável DEVE atender aos seguintes critérios de razão sinal-ruído (SNR, na sigla em inglês) e distorção harmônica total (THD, na sigla em inglês) para seno de 2000 Hz.

Transdutor	THD	SNR
alto-falante principal integrado, medido usando um microfone de referência externo	< 3,0%	>= 50 dB
microfone principal integrado, medido usando um alto-falante de referência externo	< 3,0%	>= 50 dB
entradas analógicas integradas de 3,5 mm, testadas usando o adaptador de loopback	Menos de 1%	>= 60 dB
Adaptadores USB fornecidos com o smartphone, testados com adaptador de loopback	< 1,0%	>= 60 dB

7.9. Realidade virtual

O Android inclui APIs e recursos para criar apps de "realidade virtual" (RV), incluindo experiências de RV de alta qualidade para dispositivos móveis. As implementações de dispositivos precisam implementar essas APIs e comportamentos corretamente, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android inclui suporte ao modo de RV, um recurso que processa a renderização estereoscópica de notificações e desativa componentes monoculares da interface do sistema enquanto um aplicativo de RV tem o foco do usuário.

7.9.2. Modo de realidade virtual: alto desempenho

Se as implementações do dispositivo oferecem suporte ao modo de RV, elas:

[C-1-1] É PRECISO ter pelo menos dois núcleos físicos.
[C-1-2] É PRECISO declarar o recurso android.hardware.vr.high_performance.
[C-1-3] É PRECISO oferecer suporte ao modo performance sustentada.
[C-1-4] É ALTAMENTE RECOMENDADO oferecer suporte ao OpenGL ES 3.2.
[C-1-5] É PRECISO oferecer suporte a android.hardware.vulkan.level 0.
DEVE ter suporte a android.hardware.vulkan.level 1 ou mais recente.
[C-1-6] É NECESSÁRIO implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace e expor as extensões na lista de extensões EGL disponíveis.
[C-1-8] É PRECISO implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures e expor as extensões na lista de extensões GL disponíveis.
[C-SR] É ALTAMENTE RECOMENDADO implementar GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture e expor as extensões na lista de extensões GL disponíveis.
[C-SR] É ALTAMENTE RECOMENDÁVEL oferecer suporte ao Vulkan 1.1.
[C-SR] É ALTAMENTE RECOMENDADO implementar VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing e VK_KHR_shared_presentable_image e os expor na lista de extensões Vulkan disponíveis.
[C-SR] É ALTAMENTE RECOMENDADO expor pelo menos uma família de filas do Vulkan em que flags contenha VK_QUEUE_GRAPHICS_BIT e VK_QUEUE_COMPUTE_BIT, e queueCount seja pelo menos 2.
[C-1-7] A GPU e a tela precisam sincronizar o acesso ao buffer frontal compartilhado para que a renderização alternada do olho do conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de rasgo visíveis.
[C-1-9] É PRECISO implementar suporte para as flags AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, conforme descrito no NDK.
[C-1-10] É NECESSÁRIO implementar suporte para 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] É ALTAMENTE RECOMENDADO oferecer suporte à alocação de AHardwareBuffers com mais de uma camada e sinalizações e formatos especificados em C-1-10.
[C-1-11] É PRECISO ter suporte à decodificação H.264 de pelo menos 3840 x 2160 a 30 fps, com compressão de uma média de 40 Mbps (equivalente a 4 instâncias de 1920 x 1080 a 30 fps-10 Mbps ou 2 instâncias de 1920 x 1080 a 60 fps-20 Mbps).
[C-1-12] É PRECISO ter suporte a HEVC e VP9, ser capaz de decodificar pelo menos 1920 x 1080 a 30 fps comprimidos a uma média de 10 Mbps e ser capaz de decodificar 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 instâncias de 1920 x 1080 a 30 fps-5 Mbps).
[C-1-13] É NECESSÁRIO oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
[C-1-14] É PRECISO ter uma tela integrada, e a resolução PRECISA ser de pelo menos 1920 x 1080.
[C-SR] É ALTAMENTE RECOMENDADO ter uma resolução de tela de pelo menos 2560 x 1440.
[C-1-15] A tela PRECISA ser atualizada a pelo menos 60 Hz no modo de RV.
[C-1-17] A tela PRECISA oferecer suporte a um modo de baixa persistência com persistência de ≤ 5 milissegundos, sendo que a persistência é definida como o tempo em que um pixel emite luz.
[C-1-18] É PRECISO ter suporte para Bluetooth 4.2 e extensão de comprimento de dados do Bluetooth LE seção 7.4.3.
[C-1-19] É PRECISO oferecer suporte e informar corretamente o tipo de canal direto para todos os seguintes tipos de sensores padrão:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR] É ALTAMENTE RECOMENDÁVEL oferecer suporte ao tipo de canal direto TYPE_HARDWARE_BUFFER para todos os tipos de canal direto listados acima.
[C-1-21] É OBRIGATÓRIO atender aos requisitos relacionados ao giroscópio, ao acelerômetro e ao magnetômetro para android.hardware.hifi_sensors, conforme especificado na seção 7.3.9.
[C-SR] É ALTAMENTE RECOMENDADO oferecer suporte ao recurso android.hardware.sensor.hifi_sensors.
[C-1-22] É OBRIGATÓRIO ter uma latência de movimento para fóton de ponta a ponta não superior a 28 milissegundos.
[C-SR] É ALTAMENTE RECOMENDADO ter uma latência de movimento para fóton de ponta a ponta não superior a 20 milissegundos.
[C-1-23] É OBRIGATÓRIO ter a proporção do primeiro frame, que é a proporção entre o brilho dos pixels no primeiro frame após uma transição de preto para branco e o brilho dos pixels brancos em estado estável, de pelo menos 85%.
[C-SR] É ALTAMENTE RECOMENDADO ter uma proporção de primeiro frame de pelo menos 90%.
PODE fornecer um núcleo exclusivo para o aplicativo em primeiro plano e PODE oferecer suporte à API Process.getExclusiveCores para retornar os números dos núcleos da CPU exclusivos do aplicativo em primeiro plano.

Se o núcleo exclusivo tiver suporte, ele:

[C-2-1] PRECISA não permitir que nenhum outro processo do espaço do usuário seja executado nele (exceto drivers de dispositivo usados pelo aplicativo), mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

7.10. Retorno tátil

Consulte a seção 2.2.1 para ver os requisitos específicos do dispositivo.

7.11. Classe de performance de mídia

A classe de desempenho de mídia da implementação do dispositivo pode ser obtida na API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Os requisitos para a classe de desempenho de mídia são definidos para cada versão do Android a partir da R (versão 30). O valor especial 0 indica que o dispositivo não tem uma classe de desempenho de mídia.

Se as implementações do dispositivo retornarem um valor diferente de zero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elas:

[C-1-1] PRECISA retornar pelo menos um valor de android.os.Build.VERSION_CODES.R.
[C-1-2] PRECISA ser uma implementação de dispositivo portátil.
[C-1-3] É PRECISO atender a todos os requisitos da "Classe de desempenho de mídia" descritos na seção 2.2.7.

Consulte a seção 2.2.7 para ver os requisitos específicos do dispositivo.

8. Desempenho e bateria

Alguns critérios mínimos de desempenho e potência são essenciais para a experiência do usuário e afetam as suposições de referência que os desenvolvedores teriam ao desenvolver um app.

8.1. Consistência na experiência do usuário

Uma interface do usuário suave pode ser fornecida ao usuário final se houver determinados requisitos mínimos para garantir uma taxa de frames e tempos de resposta consistentes para aplicativos e jogos. As implementações de dispositivos, dependendo do tipo, PODEM ter requisitos mensuráveis para a latência da interface do usuário e a alternância de tarefas, conforme descrito na seção 2.

8.2. Desempenho de acesso a E/S de arquivos

Fornecer uma base de referência comum para um desempenho consistente de acesso a arquivos no armazenamento de dados particular do aplicativo (partição /data) permite que os desenvolvedores de apps estabeleçam 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. Medido pela gravação de um arquivo de 256 MB usando um buffer de gravação de 10 MB.
Performance de gravação aleatória. Medido gravando um arquivo de 256 MB usando um buffer de gravação de 4 KB.
Desempenho de leitura sequencial. Medido lendo um arquivo de 256 MB usando um buffer de gravação de 10 MB.
Desempenho de leitura aleatória. Medido lendo um arquivo de 256 MB usando um buffer de gravação de 4 KB.

8.3. Modos de economia de energia

Se as implementações do dispositivo incluírem recursos para melhorar o gerenciamento de energia do dispositivo que estão incluídos no AOSP (por exemplo, App Standby Bucket, Soneca) ou estenderem os recursos que não aplicam restrições mais rígidas do que o App Standby Bucket raro, elas:

[C-1-1] NÃO se afaste da implementação do AOSP para os algoritmos de acionamento, manutenção e ativação e o uso das configurações globais do sistema dos modos de economia de energia do modo de espera do app e do Doze.
[C-1-2] NÃO se desvie da implementação do AOSP para o uso de configurações globais para gerenciar o limite de jobs, alarmes e rede para apps em cada bucket de suspensão do app.
[C-1-3] NÃO 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] É OBRIGATÓRIO implementar os Buckets de app em espera e a 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-SR] É ALTAMENTE RECOMENDADO fornecer ao usuário a capacidade de ativar e desativar o recurso de economia de bateria.
[C-SR] É ALTAMENTE RECOMENDADO fornecer ao usuário a capacidade de exibir todos os apps que estão isentos dos modos de suspensão e suspensão de energia do app.

Se as implementações do dispositivo estenderem os recursos de gerenciamento de energia incluídos no AOSP e essa extensão aplicar restrições mais rigorosas do que o bucket "Raro" do App em espera, consulte a seção 3.5.1.

Além dos modos de economia de energia, as implementações de dispositivos Android PODEM implementar qualquer um ou todos os quatro estados de energia em suspensão, conforme definido pela Interface Avançada de Energia e Configuração (ACPI).

Se as implementações de dispositivos implementarem os estados de energia S4 conforme definido pelo ACPI, elas:

[C-1-1] APENAS ENTRAR NESTE ESTADO APÓS O USUÁRIO REALIZAR UMA AÇÃO EXPRESSA PARA COLOCAR O DISPOSITIVO EM UM ESTADO INATIVO (POR EXEMPLO, FECHANDO UMA TAMPA QUE FAZ PARTE FÍSICAMENTE DO DISPOSITIVO OU DESLIGANDO UM VEÍCULO OU UMA TELEVISÃO) E ANTES DE REABILITAR O DISPOSITIVO (POR EXEMPLO, ABRA A TAMPA OU LIGUE O VEÍCULO OU A TELEVISÃO NOVAMENTE).

Se as implementações de dispositivos implementarem os estados de energia S3 conforme definido pelo ACPI, elas:

[C-2-1] PRECISA atender a C-1-1 acima ou PRECISA entrar no estado S3 somente quando os aplicativos de terceiros não precisarem dos recursos do sistema (por exemplo, tela, CPU).

Por outro lado, é PRECISO sair do estado S3 quando os aplicativos de terceiros precisam dos recursos do sistema, conforme descrito neste SDK.

Por exemplo, enquanto os aplicativos de terceiros solicitam que a tela permaneça ligada com FLAG_KEEP_SCREEN_ON ou que a CPU continue em execução com PARTIAL_WAKE_LOCK, o dispositivo NÃO PODE entrar no estado S3, a menos que, conforme descrito em C-1-1, o usuário tenha realizado uma ação explícita para colocar o dispositivo em um estado inativo. Por outro lado, quando uma tarefa implementada por apps de terceiros é acionada pelo JobScheduler ou quando o Firebase Cloud Messaging é entregue a apps de terceiros, o dispositivo PRECISA sair do estado S3, a menos que o usuário tenha colocado o dispositivo em um estado inativo. Esses não são exemplos abrangentes, e o AOSP implementa vários sinais de ativação que acionam um desbloqueio a partir desse estado.

8.4. Contabilidade de consumo de energia

Uma contabilidade e relatórios mais precisos do consumo de energia fornecem ao desenvolvedor do app os incentivos e as ferramentas para otimizar o padrão de uso de energia do aplicativo.

Implementações de dispositivos:

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

8.5. Desempenho consistente

A performance pode variar drasticamente em apps de longa duração de alto desempenho, seja por causa de outros apps em execução em segundo plano ou do estrangulamento da CPU devido a limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo for compatível, o aplicativo em primeiro plano possa solicitar que o sistema otimize a alocação dos recursos para lidar com essas flutuações.

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO informar o suporte ao modo performance sustentada com precisão pelo método da API PowerManager.isSustainedPerformanceModeSupported().
DEVE oferecer suporte ao modo performance sustentada.

Se as implementações de dispositivos informarem suporte ao modo performance sustentada, elas:

[C-1-1] É OBRIGATÓRIO fornecer ao aplicativo em primeiro plano um nível consistente de desempenho por pelo menos 30 minutos, quando o app solicitar.
[C-1-2] É PRECISO honrar a API Window.setSustainedPerformanceMode() e outras APIs relacionadas.

Se as implementações de dispositivos incluírem dois ou mais núcleos de CPU, elas:

DEVE fornecer pelo menos um núcleo exclusivo que possa ser reservado pelo aplicativo em primeiro plano.

Se as implementações de dispositivo oferecerem suporte à reserva de um núcleo exclusivo para o aplicativo em primeiro plano, elas:

[C-2-1] É OBRIGATÓRIO informar os números de ID das cores exclusivas que podem ser reservadas pelo aplicativo em primeiro plano pelo método da API Process.getExclusiveCores().
[C-2-2] NÃO DEVE permitir que nenhum processo do espaço do usuário, exceto os drivers de dispositivo usados pelo aplicativo, seja executado nas CPUs exclusivas, mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

Se as implementações do dispositivo não oferecerem suporte a um núcleo exclusivo, elas:

[C-3-1] PRECISA retornar uma lista vazia pelo método da API Process.getExclusiveCores().

9. Compatibilidade do modelo de segurança

Implementações de dispositivos:

[C-0-1] É PRECISO implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência sobre segurança e permissões nas APIs da documentação para desenvolvedores do Android.
[C-0-2] É PRECISO oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades. Especificamente, os dispositivos compatíveis precisam oferecer suporte aos mecanismos de segurança descritos nas subseções a seguir.

9.1. Permissões

Implementações de dispositivos:

[C-0-1] É PRECISO oferecer suporte ao modelo de permissões do Android, conforme definido na documentação para desenvolvedores do Android. Especificamente, eles precisam aplicar cada permissão definida conforme descrito na documentação do SDK. Nenhuma permissão pode ser omitida, alterada ou ignorada.
PODE adicionar outras permissões, desde que as novas strings de ID de permissão não estejam no namespace android.\*.
[C-0-2] As permissões com um protectionLevel de PROTECTION_FLAG_PRIVILEGED SOMENTE podem ser concedidas a apps pré-instalados nos caminhos privilegiados da imagem do sistema e no subconjunto das permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito lendo e respeitando as permissões permitidas para cada app dos arquivos no caminho etc/permissions/ e usando o caminho system/priv-app como o caminho privilegiado.

As permissões com nível de proteção perigoso são de execução. Os aplicativos com targetSdkVersion > 22 os solicitam no momento da execução.

Implementações de dispositivos:

[C-0-3] É OBRIGATÓRIO mostrar uma interface dedicada para que o usuário decida se concede as permissões de execução solicitadas e também fornecer uma interface para que o usuário gerencie as permissões de execução.
[C-0-4] É PRECISO ter uma e apenas uma implementação das duas interfaces do usuário.
[C-0-5] NÃO é permitido conceder nenhuma permissão de execução a apps pré-instalados, a menos que:
- O consentimento do usuário pode ser obtido antes que o aplicativo o use.
- As permissões de execução são associadas a um padrão de intent em que o aplicativo pré-instalado é definido como o gerenciador padrão.
[C-0-6] A permissão android.permission.RECOVER_KEYSTORE DEVE ser concedida apenas a apps do sistema que registram um agente de recuperação devidamente protegido. Um agente de recuperação com segurança adequada é definido como um agente de software no dispositivo que sincroniza com um armazenamento remoto fora do dispositivo, equipado com hardware seguro com proteção equivalente ou mais forte do que o descrito no Serviço de chaveiro do Google Cloud para evitar ataques de força bruta no fator de conhecimento da tela de bloqueio.

Implementações de dispositivos:

[C-0-7] É obrigatório obedecer às propriedades da permissão de localização do Android quando um app solicitar os dados de localização ou de atividade física usando a API padrão do Android ou um mecanismo proprietário. Esses dados incluem, entre outros:
- Local do dispositivo (por exemplo, latitude e longitude).
- Informações que podem ser usadas para determinar ou estimar a localização do dispositivo (por exemplo, SSID, BSSID, ID da célula ou localização da rede à qual o dispositivo está conectado).
- Atividade física do usuário ou classificação da atividade física.

Mais especificamente, as implementações de dispositivos:

[C-0-8] É OBRIGATÓRIO obter o consentimento do usuário para permitir que um app acesse os dados de local ou atividade física.
[C-0-9] É PRECISO conceder uma permissão de execução SOMENTE ao app que tem permissão suficiente, conforme descrito no SDK. Por exemplo, TelephonyManager#getServiceState exige android.permission.ACCESS_FINE_LOCATION.

As permissões podem ser marcadas como restritas, alterando o comportamento delas.

[C-0-10] As permissões marcadas com a flag hardRestricted NÃO PODEM ser concedidas a um app, a menos que:
- Um arquivo APK do app está na partição do sistema.
- O usuário atribui a um app uma função associada às permissões hardRestricted.
- O instalador concede o hardRestricted a um app.
- Um app recebe a hardRestricted em uma versão anterior do Android.
[C-0-11] Os apps que têm uma permissão softRestricted precisam receber apenas acesso limitado e não podem receber acesso total até que sejam incluídos na lista de permissões permitidas, conforme descrito no SDK, em que o acesso total e limitado é definido para cada permissão softRestricted (por exemplo, READ_EXTERNAL_STORAGE).

Se as implementações de dispositivos oferecerem uma capacidade de uso para que o usuário escolha quais apps podem ser exibidos sobre outros com uma atividade que processa a intent ACTION_MANAGE_OVERLAY_PERMISSION, elas:

[C-2-1] É OBRIGATÓRIO garantir que todas as atividades com filtros de intent para a intent ACTION_MANAGE_OVERLAY_PERMISSION tenham a mesma tela de IU, independentemente do app inicial ou das informações fornecidas.

9.2. Isolamento de UID e processo

Implementações de dispositivos:

[C-0-1] PRECISA oferecer suporte ao modelo de sandbox de aplicativos Android, em que cada aplicativo é executado como um UID no estilo Unix exclusivo e em um processo separado.
[C-0-2] É PRECISO oferecer suporte à execução de vários aplicativos como o mesmo ID de usuário do Linux, desde que os aplicativos sejam assinados e criados corretamente, conforme definido na Referência de segurança e permissões.

9.3. Permissões do sistema de arquivos

Implementações de dispositivos:

[C-0-1] 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 de permissões do Android, mesmo que incluam ambientes de execução que executam aplicativos usando algum outro software ou tecnologia que não seja o formato executável Dalvik ou o código nativo. Resumindo:

[C-0-1] Os ambientes de execução alternativos precisam ser aplicativos Android e obedecer ao modelo de segurança padrão do Android, conforme descrito em outro lugar na seção 9.
[C-0-2] Os runtimes alternativos NÃO PODEM receber acesso a recursos protegidos por permissões não solicitadas no arquivo AndroidManifest.xml do runtime pelo mecanismo <uses-permission>.
[C-0-3] Os ambientes de execução alternativos NÃO PODEM permitir que os aplicativos usem recursos protegidos por permissões do Android restritos a aplicativos do sistema.
[C-0-4] Os ambientes de execução alternativos PRECISAM obedecer ao modelo de sandbox do Android, e os aplicativos instalados que usam um ambiente de execução alternativo NÃO PODEM reutilizar o sandbox de nenhum outro app instalado no dispositivo, exceto pelos mecanismos padrão do Android de ID de usuário compartilhado e certificado de assinatura.
[C-0-5] Os ambientes de execução alternativos NÃO PODEM ser iniciados com, conceder ou receber acesso aos sandboxes correspondentes a outros aplicativos Android.
[C-0-6] As runtimes alternativas NÃO PODEM ser iniciadas, concedidas ou conceder a outros aplicativos qualquer privilégio do superusuário (raiz) ou de qualquer outro ID de usuário.
[C-0-7] Quando os arquivos .apk de ambientes de execução alternativos são incluídos na imagem do sistema de implementações de dispositivos, eles PRECISAM ser assinados com uma chave diferente da usada para assinar outros aplicativos incluídos nas implementações de dispositivos.
[C-0-8] Ao instalar aplicativos, os ambientes de execução alternativos PRECISAM receber o consentimento do usuário para as permissões do Android usadas pelo aplicativo.
[C-0-9] Quando um app precisa usar um recurso do dispositivo que tem uma permissão correspondente do Android (como câmera, GPS etc.), o ambiente de execução alternativo PRECISA informar ao usuário que o app poderá acessar esse recurso.
[C-0-10] Quando o ambiente de execução não registra os recursos do aplicativo dessa maneira, ele PRECISA listar todas as permissões mantidas pelo próprio ambiente de execução ao instalar qualquer aplicativo que use esse ambiente.
Os ambientes de execução alternativos PRECISAM instalar apps pelo PackageManager em sandboxes do Android separados (IDs de usuário do Linux etc.).
Os ambientes de execução alternativos podem fornecer um único sandbox do Android compartilhado por todos os aplicativos que usam o ambiente de execução alternativo.

9.5. Suporte a vários usuários

O Android inclui suporte para vários usuários e oferece suporte para isolamento total do usuário.

As implementações de dispositivos PODEM, mas NÃO devem, ativar o modo multiusuário se usarem mídia removível para o armazenamento externo principal.

Se as implementações de dispositivos incluírem vários usuários, eles:

[C-1-1] É PRECISO atender aos seguintes requisitos relacionados ao suporte multiusuário.
[C-1-2] PRECISA implementar, para cada usuário, um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência sobre segurança e permissões nas APIs.
[C-1-3] É OBRIGATÓRIO ter diretórios de armazenamento de aplicativos compartilhados (também conhecidos como /sdcard) separados e isolados para cada instância de usuário.
[C-1-4] É PRECISO garantir que os aplicativos de propriedade de um determinado usuário e executados em nome dele não possam listar, ler ou gravar nos arquivos de propriedade de qualquer outro usuário, mesmo que os dados de ambos estejam armazenados no mesmo volume ou sistema de arquivos.
[C-1-5] É NECESSÁRIO criptografar o conteúdo do cartão SD quando o modo multiusuário estiver ativado usando uma chave armazenada apenas em mídia não removível acessível apenas ao sistema, se as implementações do dispositivo usarem mídia removível para as APIs de armazenamento externo. Como isso torna a mídia ilegível para um PC host, as implementações de dispositivos precisam mudar para MTP ou um sistema semelhante para fornecer aos PCs host acesso aos dados do usuário atual.

9.6. Aviso de SMS premium

O Android inclui suporte para avisar os usuários sobre qualquer mensagem SMS premium enviada. SMS premium são mensagens de texto enviadas para um serviço registrado com uma operadora que pode gerar cobranças para o usuário.

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

[C-1-1] É OBRIGATÓRIO avisar os usuários antes de enviar uma mensagem SMS para números identificados por expressões regulares definidas no arquivo /data/misc/sms/codes.xml do dispositivo. O Android Open Source Project upstream oferece uma implementação que atende a esse requisito.

9.7. Recursos de segurança

As implementações de dispositivos precisam garantir a conformidade com os recursos de segurança no kernel e na plataforma, conforme descrito abaixo.

O Sandbox do Android inclui recursos que usam o sistema de controle de acesso obrigatório (MAC) do Security-Enhanced Linux (SELinux), o sandbox do seccomp e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:

[C-0-1] É PRECISO manter a compatibilidade com aplicativos existentes, mesmo quando o SELinux ou outros recursos de segurança são implementados abaixo do framework do Android.
[C-0-2] NÃO PODE ter uma interface do usuário visível quando uma violação de segurança é detectada e bloqueada pelo recurso de segurança implementado abaixo do framework do Android, mas PODE ter uma interface do usuário visível quando ocorre uma violação de segurança não bloqueada que resulta em uma exploração bem-sucedida.
[C-0-3] O SELinux ou qualquer outro recurso de segurança implementado abaixo do framework do Android NÃO PODE ser configurado pelo usuário ou desenvolvedor do app.
[C-0-4] NÃO É PERMITIDO que um aplicativo que possa afetar outro por meio de uma API (como a API Device Administration) configure uma política que quebre a compatibilidade.
[C-0-5] É PRECISO dividir o framework de mídia em vários processos para que seja possível conceder acesso mais restrito a cada processo, conforme descrito no site do Projeto Android Open Source.
[C-0-6] É OBRIGATÓRIO implementar um mecanismo de sandbox de aplicativo de kernel que permita a filtragem de chamadas do sistema usando uma política configurável de programas multithread. O Android Open Source Project upstream atende a esse requisito ativando o seccomp-BPF com sincronização de threadgroup (TSYNC), conforme descrito na seção "Configuração do kernel" do source.android.com.

Os recursos de integridade do kernel e de autoproteção são essenciais para a segurança do Android. Implementações de dispositivos:

[C-0-7] É PRECISO implementar mecanismos de proteção contra buffer excedente de pilha do kernel. Exemplos desses mecanismos são CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] É PRECISO implementar proteções rígidas de memória do kernel em que o código executável é somente leitura, os dados somente leitura não são executáveis nem graváveis e os dados graváveis não são executáveis (por exemplo, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
[C-0-9] É PRECISO implementar a verificação de limites de tamanho de objeto estático e dinâmico de cópias entre o espaço do usuário e o espaço do kernel (por exemplo, CONFIG_HARDENED_USERCOPY) em dispositivos originalmente enviados com o nível 28 da API ou mais recente.
[C-0-10] NÃO EXECUTAR a memória do espaço do usuário ao executar no modo do kernel (por exemplo, PXN de hardware ou emulado por CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente enviados com o nível 28 da API ou mais recente.
[C-0-11] NÃO É PERMITIDO ler ou gravar a memória do espaço do usuário no kernel fora das APIs de acesso de cópia de usuário normais (por exemplo, PAN de hardware ou emulado por CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente enviados com o nível 28 da API ou mais recente.
[C-0-12] É PRECISO implementar o isolamento da tabela de páginas do kernel se o hardware for vulnerável ao CVE-2017-5754 em todos os dispositivos enviados originalmente com o nível 28 da API ou mais recente (por exemplo, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] É PRECISO implementar o aumento da proteção da previsão de ramificação se o hardware for vulnerável ao CVE-2017-5715 em todos os dispositivos originalmente enviados com o nível 28 da API ou mais recente (por exemplo, CONFIG_HARDEN_BRANCH_PREDICTOR).
[SR] É ALTAMENTE RECOMENDADO manter os dados do kernel, que são gravados apenas durante a inicialização, marcados como somente leitura após a inicialização (por exemplo, __ro_after_init).
[C-SR] É ALTAMENTE RECOMENDADO randomizar o layout do código e da memória do kernel e evitar exposições que comprometam a randomização (por exemplo, CONFIG_RANDOMIZE_BASE com entropia do carregador de inicialização pelo /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).
[C-SR] É ALTAMENTE RECOMENDADO ativar a integridade do fluxo de controle (CFI, na sigla em inglês) no kernel para fornecer proteção extra contra ataques de reutilização de código (por exemplo, CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).
[C-SR] É ALTAMENTE RECOMENDADO não desativar a integridade do fluxo de controle (CFI), a pilha de chamadas de sombra (SCS, na sigla em inglês) ou a limpeza de estouro de inteiros (IntSan) nos componentes em que ela está ativada.
[C-SR] É ALTAMENTE RECOMENDADO ativar a CFI, a SCS e a IntSan para qualquer outro componente do espaço do usuário sensível à segurança, conforme explicado em CFI e IntSan.
[C-SR] É ALTAMENTE RECOMENDADO ativar a inicialização da pilha no kernel para evitar o uso de variáveis locais não inicializadas (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). Além disso, as implementações de dispositivos NÃO devem assumir o valor usado pelo compilador para inicializar os locais.
[C-SR] É ALTAMENTE RECOMENDADO ativar a inicialização do heap no kernel para evitar usos de alocações de heap não inicializadas (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e ELAS NÃO PODEM assumir o valor usado pelo kernel para inicializar essas alocações.

Se as implementações do dispositivo usarem um kernel do Linux, elas:

[C-1-1] É PRECISO implementar o SELinux.
[C-1-2] É PRECISO definir o SELinux como o modo de restrição global.
[C-1-3] É PRECISO configurar todos os domínios no modo de aplicação. Nenhum domínio no modo permissivo é permitido, incluindo domínios específicos de um dispositivo/fabricante.
[C-1-4] NÃO é permitido modificar, omitir ou substituir as regras neverallow presentes na pasta system/sepolicy fornecida no upstream do Android Open Source Project (AOSP), e a política PRECISA ser compilada com todas as regras neverallow presentes, tanto para domínios AOSP SELinux quanto para domínios específicos de dispositivo/fornecedor.
[C-1-5] É OBRIGATÓRIO executar aplicativos de terceiros com o nível 28 da API ou mais recente em sandboxes SELinux por aplicativo com restrições SELinux por app no diretório de dados particular de cada aplicativo.
DEVE manter a política SELinux padrão fornecida na pasta system/sepolicy do Projeto Android Open Source upstream e adicionar apenas a essa política para a própria configuração específica do dispositivo.

Se as implementações do dispositivo já foram lançadas em uma versão anterior do Android e não puderem atender aos requisitos [C-1-1] e [C-1-5] com uma atualização do software do sistema, elas PODEM ser isentas desses requisitos.

Se as implementações do dispositivo usarem um kernel diferente do Linux, elas:

[C-2-1] É OBRIGATÓRIO usar um sistema de controle de acesso obrigatório equivalente ao SELinux.

O Android tem vários recursos de defesa em profundidade que são essenciais para a segurança do dispositivo.

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] É OBRIGATÓRIO manter um período de retenção razoável desse histórico de usuário.
[SR] É ALTAMENTE RECOMENDADO manter o período de retenção de 14 dias conforme configurado por padrão na implementação do AOSP.

O Android armazena os eventos do sistema usando os identificadores StatsLog e gerencia esse histórico usando a StatsManager e a API System IncidentManager.

Implementações de dispositivos:

[C-0-2] SOMENTE os campos marcados com DEST_AUTOMATIC precisam ser incluídos no relatório de incidente criado pela classe IncidentManager da API do sistema.
[C-0-3] Não é permitido usar os identificadores de eventos do sistema para registrar qualquer outro evento que não seja o descrito nos documentos do SDK StatsLog. Se outros eventos do sistema forem registrados, eles poderão usar um identificador de átomo diferente no intervalo entre 100.000 e 200.000.

9.8.2. Gravações

Implementações de dispositivos:

[C-0-1] NÃO É PERMITIDO pré-carregar ou distribuir componentes de software prontos para uso que enviam informações particulares do usuário (por exemplo, teclas pressionadas, texto exibido na tela, bugreport) do dispositivo sem o consentimento do usuário ou limpar notificações em andamento.
[C-0-2] É PRECISO mostrar e receber o consentimento explícito do usuário para permitir que qualquer informação confidencial mostrada na tela do usuário seja capturada sempre que a transmissão ou gravação de tela for ativada por MediaProjection ou APIs proprietárias. NÃO PODE permitir que os usuários desativem a exibição futura do consentimento do usuário.
[C-0-3] É OBRIGATÓRIO ter uma notificação contínua para o usuário enquanto a transmissão ou gravação de tela estiver ativada. O AOSP atende a esse requisito mostrando um ícone de notificação em andamento na barra de status.

Se as implementações do dispositivo incluírem uma funcionalidade no sistema que capture o conteúdo exibido na tela e/ou grave o fluxo de áudio reproduzido no dispositivo, que não seja pela API System ContentCaptureService ou por outros meios proprietários descritos na Seção 9.8.6 Captura de conteúdo, elas:

[C-1-1] É OBRIGATÓRIO ter uma notificação em andamento para o usuário sempre que esse recurso estiver ativado e capturar/gravar ativamente.

Se as implementações de dispositivo incluírem um componente ativado de fábrica, capaz de gravar áudio ambiente e/ou gravar o áudio reproduzido no dispositivo para inferir informações úteis sobre o contexto do usuário, elas:

[C-2-1] NÃO É PERMITIDO armazenar de forma permanente no armazenamento do dispositivo ou transmitir fora dele o áudio bruto gravado ou qualquer formato que possa ser convertido de volta para o áudio original ou um fac-símile semelhante, exceto com consentimento explícito do usuário.

9.8.3. Conectividade

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

[C-1-1] É OBRIGATÓRIO apresentar uma interface que peça o consentimento do usuário antes de permitir o acesso ao conteúdo do armazenamento compartilhado pela porta USB.

9.8.4. Tráfego de rede

Implementações de dispositivos:

[C-0-1] É PRECISO pré-instalar os mesmos certificados raiz para a loja de autoridade certificadora (AC) confiável do sistema como fornecidos no projeto upstream do Android Open Source.
[C-0-2] É OBRIGATÓRIO enviar com uma loja de AC raiz do usuário vazia.
[C-0-3] É OBRIGATÓRIO mostrar um aviso ao usuário indicando que o tráfego de rede pode ser monitorado quando uma AC raiz do usuário é adicionada.

Se o tráfego do dispositivo for roteado por uma VPN, as implementações do dispositivo:

[C-1-1] É OBRIGATÓRIO mostrar um aviso ao usuário indicando:
- Esse tráfego de rede pode ser monitorado.
- Esse tráfego de rede está sendo roteado pelo aplicativo VPN específico que fornece a VPN.

Se as implementações de dispositivos tiverem um mecanismo ativado por padrão que roteia o tráfego de dados de rede por um servidor proxy ou gateway de VPN (por exemplo, pré-carregar um serviço de VPN com android.permission.CONTROL_VPN concedido), elas:

[C-2-1] É OBRIGATÓRIO pedir o consentimento do usuário antes de ativar esse mecanismo, a menos que a VPN seja ativada pelo Device Policy Controller usando o DevicePolicyManager.setAlwaysOnVpnPackage(). Nesse caso , o usuário não precisa fornecer um consentimento separado, mas APENAS ser notificado.

Se as implementações de dispositivos implementarem uma capacidade do usuário para ativar a função "VPN sempre ativa" de um app de VPN de terceiros, elas:

[C-3-1] É PRECISO desativar essa ação do usuário para apps que não oferecem suporte ao serviço de VPN sempre ativa no arquivo AndroidManifest.xml, definindo o atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON como false.

9.8.5. Identificadores de dispositivo

Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO impedir o acesso ao número de série do dispositivo e, quando aplicável, ao IMEI/MEID, ao número de série do SIM e à Identidade Internacional de Assinante de Celular (IMSI) de um app, a menos que ele atenda a um dos seguintes requisitos:
- é um app de operadora assinado que é verificado pelos fabricantes de dispositivos.
- recebeu a permissão READ_PRIVILEGED_PHONE_STATE.
- tem privilégios de operadora, conforme definido em Privilégios da operadora UICC.
- é um proprietário do dispositivo ou do perfil que recebeu a permissão READ_PHONE_STATE.
- (Somente para número de série do SIM/ICCID) tem a exigência das regulamentações locais de que o app detecte mudanças na identidade do assinante.

9.8.6. Captura de conteúdo

O Android, pela API System ContentCaptureService ou por outros meios proprietários, oferece suporte a um mecanismo para implementações de dispositivos capturarem as seguintes interações entre os apps e o usuário.

Textos e gráficos renderizados na tela, incluindo, entre outros, notificações e dados de assistência pela API AssistStructure.
Dados de mídia, como áudio ou vídeo, gravados ou reproduzidos pelo dispositivo.
Eventos de entrada (por exemplo, tecla, mouse, gesto, voz, vídeo e acessibilidade).
Qualquer outro evento que um aplicativo forneça ao sistema pela API Content Capture ou por uma API proprietária com capacidade semelhante.
Qualquer texto ou outros dados enviados pelo TextClassifier API ao System TextClassifier, ou seja, ao serviço do sistema para entender o significado do texto e gerar as próximas ações previstas com base no texto.

Se as implementações do dispositivo capturarem os dados acima, elas:

[C-1-1] PRECISA criptografar todos esses dados quando armazenados no dispositivo. Essa criptografia PODE ser realizada usando a criptografia baseada em arquivos do Android ou qualquer uma das cifras listadas como versão 26 ou mais recente da API, descritas no SDK Cipher.
[C-1-2] NÃO É PERMITIDO fazer backup de dados brutos ou criptografados usando métodos de backup do Android ou qualquer outro método de backup.
[C-1-3] SOMENTE os dados e o registro do dispositivo precisam ser enviados usando um mecanismo de preservação de privacidade. O mecanismo de preservação de privacidade é definido como "aqueles que permitem apenas a análise agregada e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais", para evitar que os dados por usuário sejam introspeccionáveis (por exemplo, implementados usando uma tecnologia de privacidade diferencial, como RAPPOR).
[C-1-4] NÃO PRECISA associar esses dados a nenhuma identidade do usuário (como Account) no dispositivo, exceto com o consentimento explícito do usuário sempre que os dados forem associados.
[C-1-5] NÃO COMPARTILHE esses dados com outros apps, exceto com o consentimento explícito do usuário sempre que forem compartilhados.
[C-1-6] É PRECISO fornecer ao usuário a capacidade de apagar os dados coletados pela ContentCaptureService ou pelo meio proprietário, caso eles sejam armazenados de qualquer forma no dispositivo.

Se as implementações de dispositivo incluírem um serviço que implementa a API System ContentCaptureService ou qualquer serviço reservado que capture os dados conforme descrito acima, elas:

[C-2-1] NÃO É PERMITIDO que os usuários substituam o serviço de captura de conteúdo por um aplicativo ou serviço instalável pelo usuário, e APENAS o serviço pré-instalado pode capturar esses dados.
[C-2-2] NÃO É PERMITIDO que nenhum app, exceto o mecanismo de serviço de captura de conteúdo pré-instalado, capture esses dados.
[C-2-3] É PRECISO fornecer ao usuário a capacidade de desativar o serviço de captura de conteúdo.
[C-2-4] NÃO É PERMITIDO omitir a capacidade do usuário de gerenciar as permissões do Android que são mantidas pelo serviço de captura de conteúdo e seguir o modelo de permissões do Android, conforme descrito na Seção 9.1. Permissão.
[C-SR] É ALTAMENTE RECOMENDADO manter os componentes do serviço de captura de conteúdo separados, por exemplo, não vinculando o serviço ou compartilhando IDs de processo de outros componentes do sistema, exceto:
- Telefonia, contatos, interface do sistema e mídia

9.8.7. Acesso à área de transferência

Implementações de dispositivos:

[C-0-1] NÃO DEVE retornar dados cortados na área de transferência (por exemplo, pela API ClipboardManager), a menos que o app seja o IME padrão ou o app em foco no momento.

9.8.8. Local

Implementações de dispositivos:

[C-0-1] NÃO ative/desative a configuração de localização do dispositivo e as configurações de verificação de Wi-Fi/Bluetooth sem o consentimento ou a iniciação explícita do usuário.
[C-0-2] É necessário oferecer ao usuário a capacidade de acessar informações relacionadas à localização, incluindo solicitações de localização recentes, permissões no nível do app e uso de verificação de Wi-Fi/Bluetooth para determinar a localização.
[C-0-3] É OBRIGATÓRIO garantir que o aplicativo que usa a API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] seja uma sessão de emergência iniciada pelo usuário (por exemplo, discar 911 ou enviar mensagem de texto para 911). No entanto, no setor automotivo, um veículo PODE iniciar uma sessão de emergência sem a interação ativa do usuário no caso de um acidente/colisão detectado (por exemplo, para atender aos requisitos do eCall).
[C-0-4] É PRECISO preservar a capacidade da API Emergency Location Bypass de ignorar as configurações de localização do dispositivo sem mudar as configurações.
[C-0-5] É necessário programar uma notificação que lembre o usuário depois que um app em segundo plano tiver acessado a localização dele usando a permissão [ACCESS_BACKGROUND_LOCATION].

9.8.9. Apps instalados

Por padrão, os apps Android destinados ao nível 30 da API ou mais recente não podem acessar detalhes sobre outros apps instalados. Consulte Visibilidade do pacote na documentação do SDK do Android.

Implementações de dispositivos:

[C-0-1] NÃO EXPORÃO detalhes sobre nenhum outro app instalado a qualquer app direcionado ao nível 30 da API ou mais recente, a menos que o app já consiga ver detalhes sobre o outro app instalado pelas APIs gerenciadas. Isso inclui, sem limitação, detalhes expostos por APIs personalizadas adicionadas pelo implementador do dispositivo ou acessíveis pelo sistema de arquivos.

9.8.10. Relatório de bug de conectividade

Se as implementações do dispositivo gerarem relatórios de bugs usando a API System BUGREPORT_MODE_TELEPHONY com o BugreportManager, elas:

[C-1-1] É OBRIGATÓRIO receber o consentimento do usuário sempre que a API System BUGREPORT_MODE_TELEPHONY for chamada para gerar um relatório e NÃO é permitido solicitar o consentimento do usuário para todas as solicitações futuras do aplicativo.
[C-1-2] É PRECISO mostrar e receber o consentimento explícito do usuário quando os relatórios começarem a ser gerados e NÃO é permitido retornar o relatório gerado ao app solicitante sem o consentimento explícito do usuário.
[C-1-3] É OBRIGATÓRIO gerar relatórios solicitados contendo pelo menos as seguintes informações:
- Dump de TelephonyDebugService
- Despejo de TelephonyRegistry
- Snapshot de estado do WifiService
- Despejo do ConnectivityService
- Um despejo da instância CarrierService do pacote de chamada (se vinculado)
- Buffer de registro de rádio
[C-1-4] NÃO inclua o seguinte nos relatórios gerados:
- Qualquer tipo de informação não relacionada à depuração de conectividade.
- Qualquer tipo de registro de tráfego de aplicativos instalados pelo usuário ou perfis detalhados de aplicativos/pacotes instalados pelo usuário (os UIDs são permitidos, mas os nomes de pacotes não).
PODE incluir informações adicionais que não estão associadas a nenhuma identidade do usuário. (por exemplo, registros de fornecedores).

Se as implementações do dispositivo incluírem informações adicionais (por exemplo, registros de fornecedores) no relatório de bugs e essas informações tiverem impacto na privacidade/segurança/bateria/armazenamento/memória, elas:

[C-SR] É ALTAMENTE RECOMENDADO que a configuração do desenvolvedor seja desativada por padrão. O AOSP atende a isso fornecendo a opção Enable verbose vendor logging nas configurações do desenvolvedor para incluir mais registros de fornecedores específicos do dispositivo nos relatórios de bugs.

9.8.11. Compartilhamento de blobs de dados

O Android, por meio do BlobStoreManager, permite que os apps contribuam com blobs de dados para que o sistema seja compartilhado com um conjunto selecionado de apps.

Se as implementações do dispositivo oferecerem suporte a blobs de dados compartilhados, conforme descrito na documentação do SDK, elas:

[C-1-1] NÃO PODE compartilhar blobs de dados pertencentes a apps além do que eles pretendiam permitir (ou seja, o escopo de acesso padrão e os outros modos de acesso que podem ser especificados usando BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() ou BlobStoreManager.session#allowPublicAccess(). A implementação de referência do AOSP atende a esses requisitos.
[C-1-2] NÃO É PERMITIDO enviar do dispositivo ou compartilhar com outros apps os hashes seguros de blobs de dados (que são usados para controlar o acesso).

9,9. Criptografia de armazenamento de dados

Todos os dispositivos precisam atender aos requisitos da seção 9.9.1. Os dispositivos lançados em um nível da API anterior ao deste documento estão isentos dos requisitos das seções 9.9.2 e 9.9.3. Em vez disso, eles precisam atender aos requisitos da seção 9.9 do documento de definição de compatibilidade do Android correspondente ao nível da API em que o dispositivo foi lançado.

9.9.1. Inicialização direta

Implementações de dispositivos:

[C-0-1] É PRECISO implementar as APIs do modo de inicialização direta, mesmo que elas não ofereçam suporte à criptografia de armazenamento.
[C-0-2] As intents ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED ainda precisam ser transmitidas para sinalizar aos aplicativos com suporte à inicialização direta que os locais de armazenamento criptografados por dispositivo (DE, na sigla em inglês) e por credencial (CE, na sigla em inglês) 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) e a partição de armazenamento compartilhada do aplicativo (partição /sdcard) se ela for uma parte permanente e não removível do dispositivo.
[C-0-2] É OBRIGATÓRIO ativar a criptografia de armazenamento de dados por padrão quando o usuário concluir a experiência de configuração inicial.
[C-0-3] É NECESSÁRIO 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) e Criptografia de metadados, conforme descrito na seção 9.9.3.1.
- Criptografia no nível do bloco por usuário, conforme descrito na seção 9.9.3.2.

9.9.3. Métodos de criptografia

Se as implementações do dispositivo forem criptografadas, elas:

[C-1-1] É OBRIGATÓRIO inicializar sem pedir credenciais ao usuário e permitir que apps compatíveis com a inicialização direta acessem o armazenamento criptografado do dispositivo (DE) depois que a mensagem ACTION_LOCKED_BOOT_COMPLETED for transmitida.
[C-1-2] SOMENTE PERMITIR O ACESSO AO ARMAZENAMENTO CRIPTOGRÁFICO DE CREDENCIAIS (CE, NA SIGLA EM INGLÊS) DEPOIS QUE O USUÁRIO DESBLOQUEIE O DISPOSITIVO FORNECENDO AS CREDENCIAIS (POR EXEMPLO, SENHA, PIN, PADRÃO OU IMPRESSÃO DIGITAL) E A MENSAGEM ACTION_USER_UNLOCKED FOR ENVIADA.
[C-1-13] NÃO ofereça nenhum método para desbloquear o armazenamento protegido por CE sem as credenciais fornecidas pelo usuário, uma chave de depósito registrada ou uma retomada na implementação de reinicialização que atenda aos requisitos da seção 9.9.4.
[C-1-4] É OBRIGATÓRIO usar a inicialização verificada.

9.9.3.1. Criptografia baseada em arquivos com criptografia de metadados

Se as implementações de dispositivos usarem a criptografia baseada em arquivos com a criptografia de metadados, elas:

[C-1-5] É NECESSÁRIO criptografar o conteúdo do arquivo e os metadados do sistema de arquivos usando AES-256-XTS ou Adiantum. AES-256-XTS se refere ao Padrão de criptografia avançada com um comprimento de chave de criptografia de 256 bits, operado no modo XTS. O comprimento total da chave é de 512 bits. Adiantum se refere a Adiantum-XChaCha12-AES, conforme especificado em https://github.com/google/adiantum. Os metadados do sistema de arquivos são dados como tamanhos de arquivo, propriedade, modos e atributos estendidos (xattrs).
[C-1-6] É PRECISO criptografar os nomes de arquivo usando AES-256-CBC-CTS ou Adiantum.
[C-1-12] Se o dispositivo tiver instruções do padrão avançado de criptografia (AES, na sigla em inglês), como extensões de criptografia ARMv8 em dispositivos baseados em ARM ou AES-NI em dispositivos baseados em x86, as opções baseadas em AES acima para nome de arquivo, conteúdo de arquivo e criptografia de metadados do sistema de arquivos PRECISAM ser usadas, e não o Adiantum.
[C-1-13] É OBRIGATÓRIO usar uma função de derivação de chaves criptograficamente forte e não reversível (por exemplo, HKDF-SHA512) para derivar as subchaves necessárias (por exemplo, chaves por arquivo) das chaves CE e DE. "Forte criptograficamente e irreversível" significa que a função de derivação de chaves tem uma força de segurança de pelo menos 256 bits e se comporta como uma família de funções pseudoaleatórias nas entradas.
[C-1-14] NÃO use as mesmas chaves ou subchaves de criptografia baseada em arquivos (FBE) para finalidades criptográficas diferentes (por exemplo, para criptografia e derivação de chaves ou para dois algoritmos de criptografia diferentes).
As chaves que protegem as áreas de armazenamento de CE e DE e os metadados do sistema de arquivos:
[C-1-7] PRECISA ser criptograficamente vinculado a um keystore protegido por hardware. Esse keystore PRECISA estar vinculado à inicialização verificada e à raiz de confiança do hardware do dispositivo.
[C-1-8] As chaves de CE precisam estar vinculadas às credenciais da tela de bloqueio de um usuário.
[C-1-9] As chaves de CE precisam estar vinculadas a uma senha padrão quando o usuário não especificou credenciais da tela de bloqueio.
[C-1-10] PRECISA ser único e distinto. Em outras palavras, nenhuma chave CE ou DE de um usuário corresponde a qualquer outra chave CE ou DE.
[C-1-11] É OBRIGATÓRIO usar as cifras, os comprimentos de chave e os modos com suporte obrigatório.
É NECESSÁRIO que os apps essenciais pré-instalados (por exemplo, Alarm, Phone, Messenger) sejam compatíveis com a inicialização direta.

O projeto upstream do Android Open Source oferece uma implementação preferencial da 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.

9.9.3.2. Criptografia no nível de bloco por usuário

Se as implementações de dispositivo usarem a criptografia no nível do bloco por usuário, elas:

[C-1-1] É OBRIGATÓRIO ativar o suporte a vários usuários, conforme descrito na seção 9.5.
[C-1-2] É OBRIGATÓRIO fornecer partições por usuário, usando partições brutas ou volumes lógicos.
[C-1-3] É OBRIGATÓRIO usar chaves de criptografia exclusivas e distintas por usuário para criptografar os dispositivos de bloco subjacentes.
[C-1-4] É OBRIGATÓRIO usar AES-256-XTS para criptografia em nível de bloco das partições do usuário.
As chaves que protegem os dispositivos criptografados no nível do bloco por usuário:
[C-1-5] PRECISA estar criptograficamente vinculado a um Keystore protegido por hardware. Esse keystore PRECISA estar vinculado à inicialização verificada e à raiz de confiança do hardware do dispositivo.
[C-1-6] PRECISA estar vinculado às credenciais da tela de bloqueio do usuário correspondente.

A criptografia em nível de bloco por usuário pode ser implementada usando o recurso "dm-crypt" do kernel do Linux em partições por usuário.

9.9.4. Retomar na reinicialização

A retomada na reinicialização permite desbloquear o armazenamento de CE de todos os apps, incluindo aqueles que ainda não oferecem suporte à inicialização direta, após uma reinicialização iniciada por uma OTA. Esse recurso permite que os usuários recebam notificações de apps instalados após a reinicialização.

Uma implementação de retomada na reinicialização precisa continuar garantindo que, quando um dispositivo cair nas mãos de um invasor, será extremamente difícil para ele recuperar os dados criptografados por CE do usuário, mesmo que o dispositivo esteja ligado, o armazenamento do CE esteja desbloqueado e o usuário tenha desbloqueado o dispositivo após receber uma OTA. Para a resistência a ataques internos, também presumimos que o invasor tenha acesso às chaves de assinatura criptográfica de transmissão.

Especificamente:

[C-0-1] O armazenamento de CE NÃO PODE ser legível, mesmo para o invasor que tem o dispositivo fisicamente e tem 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 o dispositivo receba uma OTA.
- Pode modificar a operação de qualquer hardware (AP, flash etc.), exceto conforme detalhado abaixo, mas essa modificação envolve um atraso de pelo menos uma hora e um ciclo de energia que destrói o conteúdo da RAM.
- Não é possível modificar a operação de hardware resistente a adulterações (por exemplo, Titan M).
- Não é possível ler a RAM do dispositivo em tempo real.
- Não é possível acessar a credencial do usuário (PIN, padrão, senha) ou fazer com que ela seja inserida.

Por exemplo, uma implementação de dispositivo que implementa e obedece a todas as descrições encontradas aqui será compatível com [C-0-1].

9.10. Integridade do dispositivo

Os requisitos a seguir garantem a transparência do status da integridade do dispositivo. Implementações de dispositivos:

[C-0-1] É OBRIGATÓRIO informar corretamente pelo método PersistentDataBlockManager.getFlashLockState() da API do sistema se o estado do carregador de inicialização permite a instalação da imagem do sistema. O estado FLASH_LOCK_UNKNOWN é reservado para implementações de dispositivos que estão sendo atualizadas de uma versão anterior do Android, em que esse novo método da API do sistema não existia.
[C-0-2] É PRECISO oferecer suporte à inicialização verificada para a integridade do dispositivo.

Se as implementações de dispositivos já foram lançadas sem suporte à inicialização verificada em uma versão anterior do Android e não puderem adicionar suporte a esse recurso com uma atualização do software do sistema, elas PODEM ser isentas do requisito.

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

[C-1-1] É PRECISO declarar a flag de recurso da plataforma android.software.verified_boot.
[C-1-2] É PRECISO realizar a verificação em cada sequência de inicialização.
[C-1-3] É OBRIGATÓRIO iniciar a verificação em uma chave de hardware imutável que seja a raiz de confiança e ir até a partição do sistema.
[C-1-4] É PRECISO implementar cada etapa de verificação para verificar a integridade e a autenticidade de todos os bytes na próxima etapa antes de executar o código na próxima etapa.
[C-1-5] É OBRIGATÓRIO usar algoritmos de verificação tão fortes quanto as recomendações atuais do NIST para algoritmos de hash (SHA-256) e tamanhos de chave pública (RSA-2048).
[C-1-6] NÃO DEVE permitir que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário consinta tentar a inicialização. Nesse caso, os dados de qualquer bloco de armazenamento não verificado NÃO PODEM ser usados.
[C-1-7] NÃO É PERMITIDO que partições verificadas no dispositivo sejam modificadas, a menos que o usuário tenha desbloqueado explicitamente o carregador de inicialização.
[C-SR] Se houver vários chips discretos no dispositivo (por exemplo, rádio, processador de imagens especializado), o processo de inicialização de cada um desses chips é ALTAMENTE RECOMENDADO para verificar cada etapa durante a inicialização.
[C-1-8] É OBRIGATÓRIO usar armazenamento inviolável para armazenar se o carregador de inicialização está desbloqueado. O armazenamento inviolável significa que o carregador de inicialização pode detectar se o armazenamento foi violado no Android.
[C-1-9] É PRECISO solicitar ao usuário, durante o uso do dispositivo, e exigir a confirmação física antes de permitir a transição do modo de carregador de inicialização bloqueado para o modo de carregador de inicialização desbloqueado.
[C-1-10] É PRECISO implementar a proteção de reversão para partições usadas pelo Android (por exemplo, inicialização, partições do sistema) e usar armazenamento inviolável para armazenar os metadados usados para determinar a versão mínima do SO permitida.
[C-SR] É ALTAMENTE RECOMENDADO verificar todos os arquivos APK de apps privilegiados com uma cadeia de confiança com base em partições protegidas pela Inicialização verificada.
[C-SR] É ALTAMENTE RECOMENDADO verificar todos os artefatos executáveis carregados por um app privilegiado de fora do arquivo APK (como código carregado dinamicamente ou código compilado) antes de executá-los ou ALTAMENTE RECOMENDADO não executá-los.
DEVE implementar a proteção de reversão para qualquer componente com firmware persistente (por exemplo, modem, câmera) e DEVE usar armazenamento inviolável para armazenar os metadados usados para determinar a versão mínima permitida.

Se as implementações de dispositivos já foram lançadas sem suporte a C-1-8 a C-1-10 em uma versão anterior do Android e não puderem adicionar suporte a esses requisitos com uma atualização de software do sistema, elas PODEM ser isentas dos requisitos.

O Android Open Source Project upstream oferece uma implementação preferencial desse recurso no repositório external/avb/, que pode ser integrado ao carregador de inicialização usado para carregar o Android.

Implementações de dispositivos:

[C-0-3] É necessário oferecer suporte à verificação criptográfica do conteúdo do arquivo em relação a uma chave confiável sem ler o arquivo inteiro.
[C-0-4] NÃO É PERMITIDO que as solicitações de leitura em um arquivo protegido sejam bem-sucedidas quando o conteúdo lido não for verificado em uma chave confiável.

Se as implementações do dispositivo já foram lançadas sem a capacidade de verificar o conteúdo do arquivo em relação a uma chave confiável em uma versão anterior do Android e não puderem adicionar suporte a esse recurso com uma atualização de software do sistema, elas PODEM ser isentas do requisito. O projeto upstream do Android Open Source oferece uma implementação preferencial desse recurso com base no recurso fs-verity do kernel do Linux.

Implementações de dispositivos:

[C-R] É RECOMENDADO oferecer suporte à API Confirmação protegida pelo Android.

Se as implementações do dispositivo oferecem suporte à API Confirmação protegida pelo Android, elas:

[C-3-1] É OBRIGATÓRIO informar true para a API ConfirmationPrompt.isSupported().
[C-3-2] É NECESSÁRIO garantir que o código executado no SO Android, incluindo o kernel, malicioso ou não, não gere uma resposta positiva sem a interação do usuário.
[C-3-3] É OBRIGATÓRIO garantir que o usuário tenha podido analisar e aprovar a mensagem solicitada, mesmo que o SO Android, incluindo o kernel, esteja comprometido.

9.11. Chaves e credenciais

O sistema Android Keystore permite que os desenvolvedores de apps armazenem chaves criptográficas em um contêiner e as usem em operações criptográficas pela API KeyChain ou pela API Keystore. Implementações de dispositivos:

[C-0-1] DEVE permitir que pelo menos 8.192 chaves sejam importadas ou geradas.
[C-0-2] A autenticação da tela de bloqueio PRECISA limitar a taxa de tentativas e PRECISA ter um algoritmo de espera exponencial. Após 150 tentativas, o atraso precisa ser de pelo menos 24 horas por tentativa.
NÃO deve limitar o número de chaves que podem ser geradas

Quando a implementação do dispositivo oferece suporte a uma tela de bloqueio segura, ela:

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

[C-1-5] É OBRIGATÓRIO permitir que o usuário escolha o tempo limite de suspensão para a transição do estado desbloqueado para o bloqueado, com um tempo limite mínimo permitido de até 15 segundos. Dispositivos automotivos, que bloqueiam a tela sempre que a unidade principal é desligada ou o usuário é trocado, PODEM NÃO ter a configuração de tempo limite de suspensão.

9.11.1. Tela de bloqueio e autenticação seguras

A implementação do AOSP segue um modelo de autenticação em camadas em que uma autenticação primária baseada em fábrica de conhecimento pode ser apoiada por uma biometria secundária forte ou por modalidades terciárias mais fracas.

Implementações de dispositivos:

[C-SR] É ALTAMENTE RECOMENDADO definir apenas um dos seguintes como o método de autenticação principal:
- Um PIN numérico
- Uma senha alfanumérica
- Um padrão de deslizar em uma grade de exatamente 3 x 3 pontos

Os métodos de autenticação acima são referidos como os métodos de autenticação principais recomendados neste documento.

Se as implementações de 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 a autenticação do usuário para o uso de chaves.

Se as implementações de dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio com base em um segredo conhecido e usarem um novo método de autenticação para ser tratado como uma maneira segura de bloquear a tela:

[C-3-1] A entropia do 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 de autenticação principais recomendados (por exemplo, PIN, padrão, senha) implementados e fornecidos no AOSP.
[C-3-4] O novo método de autenticação PRECISA ser desativado quando o aplicativo do controlador de política de dispositivo (DPC, na sigla em inglês) tiver definido a política de qualidade da senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_SOMETHING.
[C-3-5] Os novos métodos de autenticação PRECISAM usar os métodos principais recomendados (por exemplo, PIN, padrão, senha) a cada 72 horas ou menos OU informar claramente ao usuário que alguns dados não serão armazenados em backup 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 em biometria para ser tratado como uma maneira segura de bloquear a tela, o novo método:

[C-4-1] É PRECISO atender a todos os requisitos descritos na seção 7.3.10 para a Classe 1 (anteriormente conveniência).
[C-4-2] É OBRIGATÓRIO ter um mecanismo de fallback para usar um dos métodos de autenticação principal recomendados, que é baseado em um secret conhecido.
[C-4-3] PRECISA ser desativado e permitir apenas que a autenticação primária recomendada desbloqueie a tela quando o aplicativo do controlador de políticas do dispositivo (DPC) tiver definido a política de recurso de bloqueio de tela chamando o método DevicePolicyManager.setKeyguardDisabledFeatures() , com qualquer uma das flags biométricas associadas (por exemplo, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Se os métodos de autenticação biométrica não atenderem aos requisitos da Classe 3 (anteriormente Forte), conforme descrito na seção 7.3.10:

[C-5-1] Os métodos PRECISAM ser desativados se o aplicativo do controlador de política de dispositivo (DPC) tiver definido a política de qualidade da senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] O usuário PRECISA ser desafiado para a autenticação primária 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 de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio e um novo método de autenticação for baseado em um token físico ou no local:

[C-6-1] Eles PRECISAM ter um mecanismo de fallback para usar um dos métodos de autenticação principal recomendados, que é baseado em um segredo conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
[C-6-2] O novo método PRECISA ser desativado e permitir apenas um dos métodos de autenticação primários recomendados para desbloquear a tela quando o aplicativo do controlador de políticas do dispositivo (DPC) tiver definido a política com o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_UNSPECIFIED.
[C-6-3] O usuário PRECISA ser desafiado com um dos métodos de autenticação principal recomendados (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada quatro horas ou menos.
[C-6-4] O novo método NÃO PODE ser tratado como uma tela de bloqueio segura e DEVE seguir as restrições listadas em C-8 abaixo.

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

[C-7-1] É OBRIGATÓRIO ter uma indicação clara no menu de configurações e na tela de bloqueio quando o bloqueio do dispositivo for adiado ou puder ser desbloqueado por agentes de confiança. Por exemplo, o AOSP atende a esse requisito mostrando uma descrição de texto para "Configuração de bloqueio automático" e "O botão liga/desliga bloqueia instantaneamente" no menu de configurações e um ícone distinguível na tela de bloqueio.
[C-7-2] É NECESSÁRIO respeitar e implementar totalmente todas as APIs de agente de confiança na classe DevicePolicyManager, como a constante KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] A função TrustAgentService.addEscrowToken() NÃO PODE ser implementada totalmente em um dispositivo usado como dispositivo pessoal principal (por exemplo, portátil), mas PODE ser implementada totalmente em implementações de dispositivo que são normalmente compartilhadas (por exemplo, Android TV ou dispositivo automotivo).
[C-7-4] É OBRIGATÓRIO criptografar todos os tokens armazenados adicionados por TrustAgentService.addEscrowToken().
[C-7-5] A chave de criptografia ou o token de depósito em garantia NÃO PODEM ser armazenados no mesmo dispositivo em que a chave é usada. Por exemplo, é permitido que uma chave armazenada em um smartphone desbloqueie uma conta de usuário em uma TV. Para dispositivos automotivos, não é permitido armazenar o token de depósito em garantia em nenhuma parte do veículo.
[C-7-6] É OBRIGATÓRIO informar o usuário sobre as implicações de segurança antes de ativar o token de depósito para descriptografar o armazenamento de dados.
[C-7-7] É OBRIGATÓRIO ter um mecanismo de fallback para usar um dos métodos de autenticação principais recomendados.
[C-7-8] O usuário PRECISA ser desafiado para um dos métodos de autenticação principal recomendados (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 72 horas ou menos, a menos que a segurança do usuário (por exemplo, distração do motorista) seja uma preocupação.
[C-7-9] O usuário PRECISA ser desafiado para um dos métodos de autenticação principal recomendados (por exemplo, PIN, padrão, senha), conforme descrito em [C-1-7] e [C-1-8] na seção 7.3.10, a menos que a segurança do usuário (por exemplo, distração do motorista) seja uma preocupação.
[C-7-10] NÃO pode ser tratado como uma tela de bloqueio segura e DEVE seguir as restrições listadas em C-8 abaixo.
[C-7-11] Os TrustAgents em dispositivos pessoais principais (por exemplo, portáteis) NÃO PODEM desbloquear o dispositivo.Eles só podem ser usados para manter um dispositivo já desbloqueado nesse estado por até quatro horas. A implementação padrão do TrustManagerService no AOSP atende a esse requisito.
[C-7-12] É OBRIGATÓRIO usar um canal de comunicação com criptografia (por exemplo, UKEY2) para transmitir o token de depósito em garantia do dispositivo de armazenamento para o dispositivo de destino.

Se as implementações de dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio que não é uma tela de bloqueio segura, conforme descrito acima, e usarem um novo método de autenticação para desbloquear o protetor de tela:

[C-8-1] O novo método PRECISA ser desativado quando o aplicativo do controlador de política de dispositivo (DPC, na sigla em inglês) tiver definido a política de qualidade da senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_UNSPECIFIED.
[C-8-2] Não é necessário redefinir os timers de expiração da senha definidos por DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] Elas NÃO PODEM expor uma API para uso por apps de terceiros para mudar o estado de bloqueio.

9.11.2. StrongBox

O sistema Android Keystore permite que os desenvolvedores de apps armazenem chaves criptográficas em um processador seguro dedicado, além do ambiente de execução isolado descrito acima. Esse processador seguro dedicado é chamado de "StrongBox". Os requisitos C-1-3 a C-1-11 abaixo definem os requisitos que um dispositivo precisa atender para se qualificar como StrongBox.

Implementações de dispositivos que têm um processador seguro dedicado:

[C-SR] É ALTAMENTE RECOMENDADO oferecer suporte ao StrongBox. O StrongBox provavelmente se tornará um requisito em uma versão futura.

Se as implementações do dispositivo oferecem suporte ao StrongBox, elas:

[C-1-1] É PRECISO declarar FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] É NECESSÁRIO fornecer hardware seguro dedicado que seja usado para fazer backup do keystore e proteger a autenticação do usuário. O hardware seguro dedicado também pode ser usado para outras finalidades.
[C-1-3] É PRECISO ter uma CPU discreta que não compartilhe cache, DRAM, coprocessadores ou outros recursos principais com o processador do aplicativo (AP).
[C-1-4] É PRECISO garantir que todos os periféricos compartilhados com o AP não possam alterar o processamento do StrongBox de nenhuma forma nem extrair informações dele. O AP PODE desativar ou bloquear o acesso ao StrongBox.
[C-1-5] É PRECISO ter um relógio interno com precisão razoável (+-10%) que seja imune à manipulação pelo AP.
[C-1-6] É PRECISO ter um gerador de números aleatórios real que produz saída uniformemente distribuída e imprevisível.
[C-1-7] É PRECISO ter resistência a adulteração, incluindo resistência contra penetração física e falhas.
[C-1-8] É PRECISO ter resistência a canais secundários, incluindo resistência a vazamento de informações por canais secundários de energia, temporização, radiação eletromagnética e radiação térmica.
[C-1-9] É OBRIGATÓRIO ter armazenamento seguro que garanta a confidencialidade, a integridade, a autenticidade, a consistência e a atualidade do conteúdo. O armazenamento NÃO PODE ser lido ou alterado, exceto conforme permitido pelas APIs StrongBox.
Para validar a conformidade com [C-1-3] a [C-1-9], as implementações de dispositivos:
- [C-1-10] É OBRIGATÓRIO incluir o hardware certificado de acordo com o perfil de proteção de cartão inteligente 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 de critérios comuns de potencial de ataque a cartões inteligentes.
- [C-1-11] É OBRIGATÓRIO incluir o firmware 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 de critérios comuns de potencial de ataque a smartcards.
- [C-SR] É ALTAMENTE RECOMENDADO incluir o hardware que é avaliado usando um alvo de segurança, nível de garantia de avaliação (EAL) 5, aumentado por AVA_VAN.5. A certificação EAL 5 provavelmente se tornará um requisito em uma versão futura.
[C-SR] são ALTAMENTE RECOMENDADOS para fornecer resistência a ataques internos (IAR, na sigla em inglês), o que significa que uma pessoa com acesso às chaves de assinatura do firmware não pode produzir firmware que cause vazamentos de segredos do StrongBox, para contornar os requisitos de segurança funcional ou permitir o acesso a dados sensíveis do usuário. A maneira recomendada de implementar o IAR é permitir atualizações de firmware somente quando a senha do usuário principal for fornecida pelo HAL IAuthSecret.

9.11.3. Credencial de identidade

O sistema de credencial de identidade é definido e alcançado pela implementação de todas as APIs no pacote android.security.identity.*. Essas APIs permitem que os desenvolvedores de apps armazenem e extraiam documentos de identidade do usuário. Implementações de dispositivos:

[C-SR] são ALTAMENTE RECOMENDADAS para implementar o sistema de credencial de identidade.

Se as implementações de dispositivos implementarem o sistema de credenciais de identidade, elas:

[C-0-1] PRECISA retornar um valor não nulo para o método IdentityCredentialStore#getInstance().
[C-0-2] É PRECISO implementar o sistema de credencial de identidade (por exemplo, as APIs android.security.identity.*) com código que se comunique com um aplicativo confiável em uma área isolada do código executado no kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o kernel ou o código do espaço do usuário pode acessar o estado interno do ambiente isolado, incluindo o DMA.
[C-0-3] As operações criptográficas necessárias para implementar o sistema de credencial de identidade (por exemplo, as APIs android.security.identity.*) PRECISAM ser realizadas inteiramente no aplicativo confiável, e o material de chave privada NUNCA PODE sair do ambiente de execução isolado, a menos que seja especificamente exigido por APIs de nível mais alto (por exemplo, o método createEphemeralKeyPair()).
[C-0-4] O aplicativo confiável PRECISA ser implementado de forma que as propriedades de segurança não sejam afetadas (por exemplo, os dados de credenciais não são liberados a menos que as condições de controle de acesso sejam atendidas, os MACs não podem ser produzidos para dados arbitrários), mesmo que o Android esteja com comportamento incorreto ou comprometido.

9.12. Exclusão de dados

Todas as implementações de dispositivos:

[C-0-1] É PRECISO oferecer aos usuários um mecanismo para realizar uma "Redefinição para a configuração original".
[C-0-2] É OBRIGATÓRIO excluir todos os dados no sistema de arquivos userdata.
[C-0-3] É OBRIGATÓRIO excluir os dados de modo a atender aos padrões relevantes do setor, como o NIST SP800-88.
[C-0-4] É PRECISO acionar o processo "Redefinição de dados de fábrica" acima quando a API DevicePolicyManager.wipeData() for chamada pelo app de controle de política do dispositivo do usuário principal.
PODE fornecer uma opção de eliminação rápida de dados que realiza apenas uma exclusão lógica de dados.

9.13. Modo de inicialização segura

O Android oferece o modo de inicialização segura, que permite que os usuários inicializem em um modo em que apenas os apps do sistema pré-instalados podem ser executados e todos os apps de terceiros são desativados. Esse modo, conhecido como "Modo de inicialização segura", permite que o usuário desinstale apps de terceiros potencialmente nocivos.

As implementações de dispositivos são:

[SR] É ALTAMENTE RECOMENDADO implementar o modo de inicialização segura.

Se as implementações de dispositivo implementarem o modo de inicialização segura, elas:

[C-1-1] É PRECISO fornecer ao usuário uma opção para entrar no modo de inicialização segura de forma ininterruptível de apps de terceiros instalados no dispositivo, exceto quando o app de terceiros é um controlador de política de dispositivo e definiu a flag UserManager.DISALLOW_SAFE_BOOT como verdadeira.
[C-1-2] É PRECISO permitir que o usuário desinstale apps de terceiros no modo de segurança.
DEVEM fornecer ao usuário a opção de entrar no modo de inicialização segura pelo menu de inicialização usando um fluxo de trabalho diferente do de uma inicialização normal.

9.14. Isolamento do sistema de veículos automotivos

Espera-se que os dispositivos Android Automotive troquem dados com subsistemas críticos do veículo usando o HAL do veículo para enviar e receber mensagens pelas redes do veículo, como o barramento CAN.

A troca de dados pode ser protegida com a implementação de recursos de segurança abaixo das camadas do framework do Android para evitar interações maliciosas ou não intencionais com esses subsistemas.

9.15. Planos de assinatura

"Planos de assinatura" se referem aos detalhes do plano de relacionamento de faturamento fornecidos por uma operadora de celular pelo SubscriptionManager.setSubscriptionPlans().

Todas as implementações de dispositivos:

[C-0-1] DEVE retornar planos de assinatura apenas para o app da operadora móvel que os forneceu originalmente.
[C-0-2] NÃO É PERMITIDO fazer backup ou fazer upload de planos de assinatura remotamente.
[C-0-3] SOMENTE é permitido permitir substituições, como SubscriptionManager.setSubscriptionOverrideCongested(), do app da operadora de celular que oferece planos de assinatura válidos.

9.16. Migração de dados de aplicativos

Se as implementações de dispositivo incluírem um recurso para migrar dados de um dispositivo para outro e não limitarem os dados do aplicativo que são copiados para o que é configurado pelo desenvolvedor do aplicativo no manifesto pelo atributo android:fullBackupContent, elas:

[C-1-1] NÃO PODE iniciar transferências de dados de aplicativos de dispositivos em que o usuário não definiu uma autenticação primária, conforme descrito em 9.11.1 Tela de bloqueio segura e autenticação.
[C-1-2] É OBRIGATÓRIO confirmar com segurança a autenticação principal no dispositivo de origem e confirmar com a intenção do usuário de copiar os dados no dispositivo de origem antes de transferir qualquer dado.
[C-1-3] É PRECISO usar a confirmação de chave de segurança para garantir que o dispositivo de origem e o dispositivo de destino na migração de dispositivo para dispositivo sejam dispositivos Android legítimos e tenham um carregador de inicialização bloqueado.
[C-1-4] SOMENTE migrar dados do aplicativo para o mesmo aplicativo no dispositivo de destino, com o mesmo nome de pacote E certificado de assinatura.
[C-1-5] É PRECISO mostrar uma indicação de que os dados foram migrados do dispositivo de origem por uma migração de dados de dispositivo para dispositivo no menu de configurações. O usuário NÃO PODE remover essa indicação.

10. Teste de compatibilidade de software

As implementações de dispositivos precisam passar em todos os testes descritos nesta seção. No entanto, nenhum pacote de teste de software é totalmente abrangente. Por esse motivo, É ALTAMENTE RECOMENDADO que os implementadores de dispositivos façam o menor número possível de mudanças na implementação de referência e preferida do Android disponível no Projeto Android Open Source. Isso vai minimizar o risco de introduzir bugs que criam incompatibilidades que exigem retrabalho e possíveis atualizações do dispositivo.

10.1. Conjunto de teste de compatibilidade

Implementações de dispositivos:

[C-0-1] É PRECISO passar no Conjunto de teste de compatibilidade do Android (CTS) disponível no Projeto Android Open Source, usando o software de envio final no dispositivo.
[C-0-2] É PRECISO garantir a compatibilidade em casos de ambiguidade no CTS e para qualquer nova implementação de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. A versão do CTS será independente dessa definição de compatibilidade, e várias revisões do CTS poderão ser lançadas para o Android 11.

Implementações de dispositivos:

[C-0-3] É NECESSÁRIO passar na versão mais recente do CTS disponível 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 Compatibility Test Suite e é executado por um operador humano para testar funcionalidades que não podem ser testadas por um sistema automatizado, como o funcionamento correto de uma câmera e sensores.

Implementações de dispositivos:

[C-0-1] É PRECISO executar corretamente todos os casos aplicáveis no verificador do CTS.

O Verificador do CTS tem testes para muitos tipos de hardware, incluindo alguns opcionais.

Implementações de dispositivos:

[C-0-2] É PRECISO passar em todos os testes de hardware que eles têm. Por exemplo, se um dispositivo tiver um acelerômetro, ele PRECISA executar corretamente o caso de teste do acelerômetro no Verificador do CTS.

Os casos de teste para recursos indicados como opcionais neste documento de definição de compatibilidade PODEM ser pulados ou omitidos.

[C-0-2] Todos os dispositivos e builds precisam executar corretamente o Verificador CTS, conforme observado acima. No entanto, como muitos builds são muito semelhantes, não é esperado que os implementadores de dispositivos executem explicitamente o Verificador do CTS em builds que diferem apenas de maneiras triviais. Especificamente, implementações de dispositivos que diferem de uma implementação que passou pelo Verificador do CTS apenas pelo conjunto de localidades, branding etc. incluídos PODEM omitir o teste do Verificador do CTS.

11. Software atualizável

[C-0-1] As implementações de dispositivos precisam incluir um mecanismo para substituir todo o software do sistema. O mecanismo não precisa realizar upgrades "ao vivo", ou seja, pode ser necessário reiniciar o dispositivo. Qualquer método pode ser usado, desde que substitua todo o software pré-instalado no dispositivo. Por exemplo, qualquer uma das seguintes abordagens atende a esse requisito:
- Downloads "over-the-air (OTA)" com atualização off-line por reinicialização.
- Atualizações "conectadas" por USB de um PC host.
- Atualizações "off-line" com uma reinicialização e atualização de um arquivo no armazenamento removível.
[C-0-2] O mecanismo de atualização usado PRECISA oferecer suporte a atualizações sem apagar os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados privados e compartilhados do app. O software upstream do Android inclui um mecanismo de atualização que atende a esse requisito.
[C-0-3] A atualização inteira PRECISA ser assinada, e o mecanismo de atualização no dispositivo PRECISA verificar a atualização e a assinatura em relação a uma chave pública armazenada no dispositivo.
[C-SR] O mecanismo de assinatura é ALTAMENTE RECOMENDADO para gerar hash da atualização com SHA-256 e validar o hash com a chave pública usando ECDSA NIST P-256.

Se as implementações do dispositivo incluem suporte a uma conexão de dados não tarifadas, como o perfil 802.11 ou Bluetooth PAN (rede de área pessoal), elas:

[C-1-1] É PRECISO oferecer suporte a downloads OTA com atualização off-line por reinicialização.

Para implementações de dispositivos lançadas com o Android 6.0 e versões mais recentes, o mecanismo de atualização PRECISA oferecer suporte à verificação de que a imagem do sistema é binária idêntica ao resultado esperado após uma atualização OTA. A implementação OTA baseada em blocos no Android Open Source Project upstream, adicionada desde o Android 5.1, atende a esse requisito.

Além disso, as implementações de dispositivos precisam oferecer suporte a atualizações A/B do sistema. O AOSP implementa esse recurso usando o HAL de controle de inicialização.

Se um erro for encontrado em uma implementação de dispositivo após o lançamento, mas dentro de um período razoável de vida útil do produto determinado em consulta com a equipe de compatibilidade do Android para afetar a compatibilidade de apps de terceiros, faça o seguinte:

[C-2-1] O implementador do dispositivo PRECISA corrigir o erro com uma atualização de software disponível que possa ser aplicada de acordo com o mecanismo descrito.

O Android inclui recursos que permitem ao app proprietário do dispositivo (se presente) controlar a instalação de atualizações do sistema. Se o subsistema de atualização do sistema para dispositivos informar android.software.device_admin, ele:

[C-3-1] PRECISA implementar o comportamento descrito na classe SystemUpdatePolicy.

12. Registro de alterações do documento

Para um resumo das mudanças na definição de compatibilidade nesta versão:

Documentar o registro de alterações

Confira um resumo das mudanças nas seções de pessoas:

12.1. Dicas para visualizar o registro de alterações

As mudanças são marcadas da seguinte maneira:

CDD
Mudanças substanciais nos requisitos de compatibilidade.
Documentos
Mudanças cosméticas ou relacionadas ao build.

Para uma melhor visualização, anexe os parâmetros de URL pretty=full e no-merges aos URLs do registro de alterações.

13. Entre em contato

Você pode participar do fórum de compatibilidade com o Android e pedir esclarecimentos ou mencionar problemas que você acha que o documento não aborda.