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 "PRECISA", "NÃO PODE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVE", "DEVE", "NÃO DEVE", "RECOMENDADO", "PODE" e "OPCIONAL" está de acordo com o padrão IETF definido no RFC2119.

Conforme usado neste documento, um "implementador de dispositivo" ou "implementador" é uma pessoa ou organização que desenvolve uma solução de hardware/software executando o Android 11. Uma "implementação de dispositivo" ou "implementação" é a solução de hardware/software tão 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, é responsabilidade do implementador do dispositivo garantir a compatibilidade com as implementações atuais.

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

Muitos dos recursos vinculados neste documento são derivados direta ou indiretamente do SDK do Android e serão funcionalmente idênticos às informações na documentação desse SDK. Nos casos em que essa definição ou o conjunto de teste de compatibilidade discorda da documentação do SDK, ela é considerada oficial. Quaisquer detalhes técnicos fornecidos nos recursos vinculados ao longo deste documento são considerados parte desta Definição de Compatibilidade para inclusão.

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 específico de dispositivo. Cada subseção da Seção 2 é dedicada a um tipo específico de dispositivo.

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

1.1.2. ID do requisito

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

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

Cada ID é definido conforme abaixo:

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

1.1.3 ID do requisito na seção 2

O ID do requisito na Seção 2 começa com o ID da seção correspondente, seguido pelo ID descrito acima.

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

2. Tipos de dispositivos

Embora o Android Open Source Project forneça uma pilha de software que pode ser usada para uma variedade de tipos de dispositivos e formatos, há alguns tipos que têm um ecossistema de distribuição de aplicativos relativamente melhor estabelecido.

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

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

2.1 Configurações do dispositivo

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

2.2. Requisitos para dispositivos portáteis

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

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

• usar uma fonte de energia que ofereça mobilidade, como uma bateria;
• Ter uma tela diagonal física 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 portáteis Android.

2.2.1. Hardware

Implementações de dispositivos portáteis:

• [7.1.1.1/H-0-1] PRECISA ter pelo menos uma tela compatível com Android que atenda a todos os requisitos descritos neste documento.
• [7.1.1.3/H-SR] São RECOMENDADOS PARA oferecer aos usuários uma affordance para mudar o tamanho de exibição (densidade da tela).

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

• [7.1.1.1/H-1-1]* A tela lógica disponibilizada para aplicativos de terceiros PRECISA ter pelo menos 2 polegadas nas bordas curtas e 2,7 polegadas nas bordas maiores. Os dispositivos iniciados 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 da tela do 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 nas bordas curtas. Os dispositivos iniciados em um nível de API anterior ao deste documento estão isentos desse requisito.

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

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

Implementações de dispositivos portáteis:

• [7.1.4.6/H-0-1] PRECISA informar se o dispositivo oferece suporte à capacidade de criação de perfil da GPU usando uma propriedade do sistema graphics.gpu.profiler.support.

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

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

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

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

• [7.3,8/H] DEVEM incluir um sensor de proximidade.

Implementações de dispositivos portáteis:

• [7.3.11/H-SR] São RECOMENDADOS para oferecer suporte ao sensor de pose com 6 graus de liberdade.
• [7.4.3/H] DEVE incluir suporte a Bluetooth e Bluetooth LE.

Se as implementações de dispositivos portáteis incluírem uma conexão limitada, elas:

• [7.4.7/H-1-1] PRECISA 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 liste os recursos usando CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, elas:

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

Implementações de dispositivos portáteis:

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

Se as implementações de dispositivos portáteis declararem compatibilidade somente com ABI de 32 bits:

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

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

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

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

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

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

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

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

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

Observe que a "memória disponível para o kernel e o espaço do usuário" acima refere-se 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 sobre implementações de dispositivos.

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

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

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

• [7.6.1/H-10-1] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecido 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 PODE fornecer um armazenamento compartilhado de aplicativo menor que 1 GiB.
• [7.7.1/H] DEVE incluir uma porta USB compatível com o modo de periféricos.

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

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

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

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

Implementações de dispositivos portáteis:

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

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

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

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

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

Função	Mapeamentos	Contexto	Comportamento
A	Página de uso do HID: 0x0C Uso de HID: 0x0CD Chave do kernel: KEY_PLAYPAUSE Chave do Android: KEYCODE_MEDIA_PLAY_PAUSE	Controles de mídia	Entrada: pressione rapidamente Saída: reproduzir ou pausar
			Entrada: toque e mantenha pressionado . Saída: iniciar o comando de voz Envios: android.speech.action.VOICE_SEARCH_HANDS_FREE se o dispositivo estiver bloqueado ou a tela estiver desligada. Caso contrário, envia android.speech.RecognizerIntent.ACTION_WEB_SEARCH
		Chamada recebida	Entrada: pressione rapidamente Saída: aceitar chamada
			Entrada: toque e mantenha pressionado . Saída: rejeitar chamada
		Chamada em andamento	Entrada: pressione rapidamente Saída: fim da chamada
			Entrada: toque e mantenha pressionado . Saída: ativar ou desativar o som do microfone
B	Página de uso do HID: 0x0C Uso de HID: 0x0E9 Chave do kernel: KEY_VOLUMEUP Chave do Android: VOLUME_UP	Reprodução de mídia, ligação em andamento	Entrada: toque curto ou longo Saída: aumenta o volume do sistema ou do fone de ouvido
C	Página de uso do HID: 0x0C Uso de HID: 0x0EA Chave do kernel: KEY_VOLUMEDOWN Chave do Android: VOLUME_DOWN	Reprodução de mídia, ligação em andamento	Entrada: toque curto ou longo Saída: diminui o volume do sistema ou do fone de ouvido.
D	Página de uso do HID: 0x0C Uso 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] PRECISA acionar ACTION_HEADSET_PLUG na inserção de 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 o terminal de áudio USB do tipo 0x0302 é detectado, ele:

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

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

• [7.8.2.2/H-3-1] PRECISA transmitir a intent ACTION_HEADSET_PLUG com "microfone" o extra foi definido como 1.

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

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

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

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

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

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

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

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

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

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

• [7.10/H-SR]* É RECOMENDADO NÃO usar um atuador tátil de massa giratória excêntrica (ERM, na sigla em inglês) (vibrador).
• [7,10/H]* DEVE posicionar o atuador perto do local onde o dispositivo normalmente é segurado ou tocado pelas mãos.
• [7.10/H-SR]* São RECOMENDADOS !
• [7.10/H-SR]* É RECOMENDADO que você implemente todas as constantes públicas para o retorno tátil claro em android.os.VibrationEffect, ou seja, (EF_TICK, determinado_CLICK, app_HEAVY_CLICK e data_PRIMIT_CLICK) e todas as constantes públicas para haptics rich haptics em android.os.VibrationEffect e android.os.VibrationEffect.
• [7.10/H-SR]* É RECOMENDADO usar esses mapeamentos de constantes táteis vinculados.
• [7.10/H-SR]* É RECOMENDADO que você siga a avaliação de qualidade para as APIs createOneShot() e createWaveform().
• [7.10/H-SR]* São RECOMENDADOS ALTAMENTE para verificar os recursos de escalonabilidade de amplitude executando android.os.Vibrator.hasAmplitudeControl().

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

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

• [7,10/H]* DEVE mover o atuador tátil no eixo X da orientação retrato.

Se as implementações de dispositivos portáteis tiverem um atuador tátil, que é um atuador ressonante linear do eixo X, elas:

• [7,10/H-SR]* É RECOMENDADO que a frequência ressonante do LRA do eixo X fique abaixo de 200 Hz.

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

• [7,10/H-SR]* É RECOMENDADO que você realize uma avaliação de qualidade para constantes de retorno tátil.

2.2.2. Multimídia

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

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

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

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

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

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

2.2.3. Software

Implementações de dispositivos portáteis:

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

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

• [3.8.4/H-SR] É RECOMENDADO usar a tecla HOME e mantê-la pressionada como a interação designada para iniciar o app assistivo, conforme descrito na seção 7.2.3. PRECISA iniciar o app assistivo selecionado pelo usuário, ou seja , o app que implementa a VoiceInteractionService ou uma atividade que processa a intent ACTION_ASSIST.

Se as implementações de dispositivos portáteis oferecerem suporte ao conversation notifications e as agruparem em uma seção separada dos alertas e das notificações silenciosas que não sejam de conversa, elas:

• [3.8.4/H-1-1]* PRECISA mostrar notificações de conversas antes das outras, exceto as de serviço em primeiro plano e importance:high.

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

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

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

• [3.9/H-1-1] PRECISA implementar todas as políticas de administração de dispositivos definidas na documentação do SDK do Android.
• [3.9/H-1-2] PRECISA declarar o suporte de perfis gerenciados pela flag de recurso android.software.managed_users, exceto quando o dispositivo está configurado para informar a si mesmo como um dispositivo com pouca RAM ou para que ele aloque 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 dispositivos, elas:

• [3.8.16/H-1-1] PRECISA declarar a flag de recurso android.software.controls e defini-la como true.
• [3.8.16/H-1-2] PRECISA fornecer funcionalidade de usuário com a capacidade de adicionar, editar, selecionar e operar os controles de dispositivo favoritos do usuário usando os controles registrados pelos aplicativos de terceiros com as APIs ControlsProviderService e Control.
• [3.8.16/H-1-3] PRECISA fornecer acesso a essa funcionalidade do usuário em três interações a partir de uma tela de início padrão.
• [3.8.16/H-1-4] PRECISA renderizar com precisão nesta funcionalidade de usuário o nome e o ícone de cada app de terceiros que oferece controles pela API ControlsProviderService, além dos campos especificados fornecidos pelas APIs Control.

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

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

Implementações de dispositivos portáteis:

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

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

• [3.16/H-1-1] PRECISA ser compatível com o recurso de pareamento do dispositivo complementar.

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

• [7.2.3/H] A zona de reconhecimento de gestos para a função inicial PRECISA ter no máximo 32 dp de altura a partir da parte de baixo da tela.

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

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

2.2.4 Desempenho e potência

• [8.1/H-0-1] Latência de frame consistente. A latência de frame inconsistente ou um atraso na renderização de frames NÃO PODEM ocorrer com mais frequência do que 5 frames por segundo e DEVEM ser menores que 1 frames por segundo.
• [8.1/H-0-2] Latência da interface do usuário. As implementações de dispositivos PRECISAM garantir a experiência do usuário de baixa latência rolando uma lista de 10 mil entradas na lista, conforme definido pelo Conjunto de teste de compatibilidade (CTS) do Android, em menos de 36 segundos.
• [8.1/H-0-3] Troca de tarefas. Quando vários aplicativos tiverem sido iniciados, a reinicialização de um aplicativo já em execução após o lançamento PRECISA levar menos de um segundo.

Implementações de dispositivos portáteis:

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

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

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

Implementações de dispositivos portáteis:

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

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

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

2.2.5 Modelo de segurança

Implementações de dispositivos portáteis:

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

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

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

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior do Android, esse dispositivo está isento da exigência de ter um keystore apoiado por um ambiente de execução isolado e oferecer suporte ao atestado de chaves, a menos que ele declare o recurso android.hardware.fingerprint, que exige um keystore apoiado por um ambiente de execução isolado.

Quando as implementações de dispositivos portáteis são compatíveis com uma tela de bloqueio segura, elas:

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

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

• [9.5/H-2-1] PRECISA oferecer suporte a perfis restritos, um recurso que permite que os proprietários de dispositivos gerenciem outros usuários e os recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para outros usuários trabalharem, com a capacidade de gerenciar restrições mais específicas 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 PRECISA estar alinhado à implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários às chamadas de voz e SMS.

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

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

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

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

• Perfetto (link em inglês)
  • [6.1/H-0-2]* PRECISA expor um binário /system/bin/perfetto ao usuário do shell. O cmdline está em conformidade com a documentação do Perfeito.
  • [6.1/H-0-3]* O binário do perfetto PRECISA aceitar como entrada uma configuração protobuf que esteja em conformidade com o esquema definido na documentação do perfetto.
  • [6.1/H-0-4]* O binário do perfetto PRECISA gravar como saída um trace protobuf que esteja em conformidade com o 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 rastreado do perfetto PRECISA ser ativado por padrão (propriedade do sistema persist.traced.enable).

2.2.7 Classe de desempenho de mídia portátil

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

2.2.7.1 Mídia

Se as implementações de dispositivos portáteis retornarem android.os.Build.VERSION_CODES.R para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, ele poderá fazer o seguinte:

• [5.1/H-1-1] PRECISA anunciar o número máximo de hardwares decodificadores de vídeo sessões que podem ser executadas simultaneamente em qualquer combinação de codecs por meio do CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints() métodos.
• [5.1/H-1-2] PRECISA oferecer suporte a seis instâncias de sessões de decodificador de vídeo por hardware. (AVC ou HEVC) em qualquer combinação de codecs executada simultaneamente a 720p resolução a 30 fps.
• [5.1/H-1-3] PRECISA anunciar o número máximo de hardwares de codificador sessões que podem ser executadas simultaneamente em qualquer combinação de codecs por meio do CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] PRECISA oferecer suporte a seis instâncias de sessões de codificador de vídeo em hardware. (AVC ou HEVC) em qualquer combinação de codecs executada simultaneamente a 720p resolução a 30 fps.
• [5.1/H-1-5] PRECISA anunciar o número máximo de hardwares de codificador e decodificadores que podem ser executadas simultaneamente em qualquer combinação de codecs pelo CodecCapabilities.getMaxSupportedInstances() e VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] PRECISA oferecer suporte a seis instâncias de hardware de decodificador de vídeo e hardware. sessões do codificador de vídeo (AVC ou HEVC) em qualquer combinação de codec em execução ao mesmo tempo, a uma resolução de 720p a 30 fps.
• [5.1/H-1-7] PRECISA ter uma latência de inicialização de codec de 65 ms ou menos para um 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) durante o carregamento. Nesse caso, o carregamento é definido Sessão simultânea de transcodificação de vídeo de 1080p a 720p usando vídeo de hardware e codecs com a inicialização de gravação de áudio e vídeo de 1080p.
• [5.1/H-1-8] PRECISA ter uma latência de inicialização de codec de 50 ms ou menos para um Sessão de codificação de áudio com taxa de bits de 128 kbps ou menor para todos os codificadores de áudio quando em load.Load aqui é definido como um vídeo simultâneo de 1080p a 720p sessão de transcodificação usando codecs de vídeo de hardware junto com a inicialização de gravação de áudio e vídeo.
• [5.3/H-1-1] NÃO PODE eliminar mais de 1 frame em 10 segundos (ou seja, menos de 0,333% de queda do frame) para uma sessão de vídeo com 1080p e 30 fps sob carga. O carregamento é definido como um vídeo simultâneo de 1080p a 720p de transcodificação usando codecs de vídeo de hardware, além de Reprodução de áudio AAC a 128 kbps.
• [5.3/H-1-2] NÃO PODE cair mais de 1 frame em 10 segundos durante um vídeo. mudança da resolução em uma sessão de vídeo de 30 QPS sob carga. O carregamento é definido como um Sessão simultânea de transcodificação de vídeo de 1080p a 720p usando vídeo de hardware e uma reprodução de áudio AAC de 128 Kbps.
• [5.6/H-1-1] PRECISA ter uma latência de toque para tom inferior a 100 milissegundos usando o teste toque a tom do OboeTester ou o teste por toque 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, ele poderá fazer o seguinte:

• [7.5/H-1-1] PRECISA ter uma câmera traseira principal com resolução de no mínimo no mínimo 12 megapixels com suporte para captura de vídeo a 4k a 30 fps. O principal que é a traseira com o menor ID de câmera.
• [7.5/H-1-2] PRECISA ter uma câmera frontal principal com resolução de no mínimo no mínimo 4 megapixels com suporte para captura de vídeo a 1080p a 30 fps. O principal A câmera frontal é a frontal com o menor ID de câmera.
• [7.5/H-1-3] PRECISA oferecer suporte à propriedade android.info.supportedHardwareLevel como FULL ou melhor para o tipo primário e LIMITED ou melhor para o tipo frontal principal. câmera.
• [7.5/H-1-4] PRECISA ser compatível CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para as duas câmeras principais.
• [7.5/H-1-5] PRECISA ter latência de captura JPEG da Camera2 < 1.000 ms para Resolução de 1080p medida pelo PerformanceTest da câmera CTS em Condições de iluminação ITS (3.000K) para ambas as câmeras principais.
• [7.5/H-1-6] PRECISA ter latência de inicialização da câmera2 (abrir a câmera para a primeira visualização) frame) < 600 ms medidos pelo PerformanceTest da câmera CTS de acordo com o ITS. condições de iluminação (3.000K) 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, eles:

• [7.1.1.1/H-1-1] PRECISA ter uma resolução de tela de pelo menos 1080p.
• [7.1.1.3/H-1-1] PRECISA ter uma densidade de tela de pelo menos 400 dpi.
• [7.6.1/H-1-1] PRECISA 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, eles:

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

2.3. Requisitos para televisão

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

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

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

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

2.3.1 Hardware

Implementações de dispositivos de televisão:

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

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

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

Implementações de dispositivos de televisão:

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

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

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

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

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

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

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

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

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

Observe que a "memória disponível para o kernel e o espaço do usuário" acima refere-se 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 sobre implementações de dispositivos.

Implementações de dispositivos de televisão:

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

2.3.2 Multimídia

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

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

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

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

Implementações de dispositivos de televisão:

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

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

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

As implementações de dispositivos de televisão PRECISAM ser compatíveis com a decodificação MPEG-2, conforme detalhado na Seção 5.3.1, com frame rates e resoluções padrão de até e, inclusive:

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

As implementações de dispositivos de televisão PRECISAM ser compatíveis com a decodificação H.264, conforme detalhado na Seção 5.3.4, com frame rates e resoluções padrão de até e, inclusive:

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

Implementações de dispositivos de televisão com decodificadores de hardware H.265 PRECISAM oferecer suporte à decodificação H.265, conforme detalhado na Seção 5.3.5, com taxas de quadros e resoluções padrão de vídeo até e, inclusive:

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

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

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

As implementações de dispositivos de televisão PRECISAM ser compatíveis com a decodificação VP8, conforme detalhado na Seção 5.3.6, com taxas de quadros e resoluções padrão de vídeo, incluindo:

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

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

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

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

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

Implementações de dispositivos de televisão:

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

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

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

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

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

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

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

2.3.3 Software

Implementações de dispositivos de televisão:

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

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

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

Implementações de dispositivos de televisão:

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

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

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

Implementações de dispositivos de televisão:

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

2.3.4 Desempenho e potência

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

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

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

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

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

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

• [8.3/T-1-3] PRECISA oferecer recursos ao usuário para mostrar todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".

Implementações de dispositivos de televisão:

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

2.3.5 Modelo de segurança

Implementações de dispositivos de televisão:

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

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior do Android, esse dispositivo está isento da exigência de ter um keystore apoiado por um ambiente de execução isolado e oferecer suporte ao atestado de chaves, a menos que ele declare o recurso android.hardware.fingerprint, que exige um keystore apoiado por um ambiente de execução isolado.

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

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

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

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

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

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

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

Implementações de dispositivos de televisão:

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

2.4. Requisitos do relógio

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

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

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

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

2.4.1. Hardware

Implementações de dispositivos de smartwatches:

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

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

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

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

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

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

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

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

Implementações de dispositivos de smartwatches:

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

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

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

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

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

2.4.2. Multimídia

Nenhum requisito extra.

2.4.3. Software

Implementações de dispositivos de smartwatches:

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

Implementações de dispositivos de smartwatches:

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

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

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

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

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

• [3.11/W-0-1] PRECISA ser compatível com a instalação de mecanismos TTS de terceiros.

2.4.4 Desempenho e potência

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

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

Implementações de dispositivos de smartwatches:

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

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

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

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

2,5 Requisitos automotivos

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

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

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

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

2.5.1. Hardware

Implementações de dispositivos automotivos:

• [7.1.1.1/A-0-1] PRECISA ter uma tela com pelo menos 15 cm de tamanho diagonal.

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

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

• [7.2.3/A-0-2] PRECISA enviar os eventos de tocar normal e longo da função Voltar (KEYCODE_BACK) para o aplicativo em primeiro plano.
• [7.3/A-0-1] PRECISA implementar e informar GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED e PARKING_BRAKE_ON.
• [7.3/A-0-2] O valor da flag NIGHT_MODE PRECISA ser consistente com o modo dia/noite do painel e DEVE ser baseado na entrada do sensor de luz ambiente. O sensor de luz ambiente subjacente PODE ser o mesmo do Photometer.
• [7.3/A-0-3] PRECISA 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] PODERÁ reconhecer a Localização ao fundir GPS/GNSS com sensores adicionais. Se a localização não tiver sido detectada, é FORTEMENTE RECOMENDADO implementar e informar os tipos de Sensor correspondentes e/ou IDs de propriedade do veículo usados.
• [7.3/A-0-2] O Local solicitado por LocationManager#requestLocationUpdates() NÃO PODE ter correspondência com o mapa.

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

• [7.3.1/A-1-1] PRECISA relatar eventos com até uma frequência de pelo menos 100 Hz.
• [7.3.1/A-1-2] PRECISA estar em conformidade com o 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 relatar eventos com até uma frequência de pelo menos 100 Hz.
• [7.3.4/A-2-2] também PRECISA implementar o sensor TYPE_GYROSCOPE_UNCALIBRATED.
• [7.3.4/A-2-3] PRECISA ser capaz de medir mudanças de orientação até 250 graus por segundo.
• [7.3.4/A-SR] É RECOMENDADO que você configure o intervalo de medição do giroscópio como +/-250 dps para maximizar a resolução possível

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

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

Implementações de dispositivos automotivos:

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

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

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

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

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

Implementações de dispositivos automotivos:

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

Se as implementações de dispositivos automotivos incluírem uma câmera de visualização externa, no caso desse tipo de câmera, elas:

• [7.5/A-1-1] NÃO PODE ter câmeras de visualização externa acessíveis pelas APIs Android Camera, a menos que obedeçam aos requisitos principais da câmera.
• [7,5/A-SR] É ALTAMENTE RECOMENDADO para não girar nem espelhar a visualização da câmera na horizontal.
• [7.5.5/A-SR] É RECOMENDADO ALTAMENTE para estar na orientação de modo que a dimensão longa da câmera se alinhe com o horizonte.
• [7,5/A-SR] É MUITO 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 por hardware ou por software implementado no driver da câmera.

Implementações de dispositivos automotivos:

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

• [7.6.1/A] DEVE formatar a partição de dados para oferecer melhor desempenho e longevidade no armazenamento flash, por exemplo, usando o sistema de arquivos f2fs.

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

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

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

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

  • 280 dpi ou menos em telas pequenas/normais
  • Ldpi ou menor em telas muito grandes
  • Mdpi ou menor em telas grandes

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

  • xhdpi ou maior em telas pequenas/normais
  • hdpi ou maior em telas grandes
  • mdpi ou maior em telas muito grandes

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

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

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

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

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

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

  • 280 dpi ou menos em telas pequenas/normais
  • Ldpi ou menor em telas muito grandes
  • Mdpi ou menor em telas grandes

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

  • xhdpi ou maior em telas pequenas/normais
  • hdpi ou maior em telas grandes
  • mdpi ou maior em telas muito grandes

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

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

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

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

Observe que a "memória disponível para o kernel e o espaço do usuário" acima refere-se 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 sobre implementações de dispositivos.

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

2.5.2 Multimídia

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

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

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

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

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

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

As implementações de dispositivos automotivos são MUITO RECOMENDADAS para oferecer suporte à 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] PRECISA declarar o recurso android.hardware.type.automotive.

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

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

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

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

Implementações de dispositivos automotivos:

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

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

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

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

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

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

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

• [3.14/A-0-1] PRECISA incluir um framework de interface para oferecer suporte a apps de terceiros que usam as APIs de mídia, conforme descrito na seção 3.14.
• [3.14/A-0-2] PRECISA permitir que o usuário interaja com segurança com aplicativos de mídia enquanto dirige.
• [3.14/A-0-3] PRECISA oferecer suporte à ação da intent implícita CAR_INTENT_ACTION_MEDIA_TEMPLATE com o extra CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] PRECISA fornecer uma affordance para navegar até a atividade de preferência de um Aplicativo de mídia, mas PRECISA ativá-la apenas quando as Restrições de UX para carros não estiverem em vigor.
• [3.14/A-0-5] PRECISA exibir mensagens de erro definidas por aplicativos de mídia e PRECISA oferecer suporte aos extras opcionais ERROR_RESOLUTION_ACTION_LABEL e ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] PRECISA ser compatível com uma funcionalidade de pesquisa no app.
• [3.14/A-0-7] PRECISA respeitar as definições de CONTENT_STYLE_BROWSABLE_HINT e CONTENT_STYLE_PLAYABLE_HINT ao exibir a hierarquia MediaBrowser.

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

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

Implementações de dispositivos automotivos:

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

2.5.4 Desempenho e potência

Implementações de dispositivos automotivos:

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

2.5.5 Modelo de segurança

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

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

Implementações de dispositivos automotivos:

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

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior do Android, esse dispositivo está isento da exigência de ter um keystore apoiado por um ambiente de execução isolado e oferecer suporte ao atestado de chaves, a menos que ele declare o recurso android.hardware.fingerprint, que exige um keystore apoiado por um ambiente de execução isolado.

Implementações de dispositivos automotivos:

• [9.14/A-0-1] PRECISA bloquear as mensagens dos subsistemas dos veículos do framework do Android, por exemplo, adicionar os tipos e origens de mensagens permitidos a uma lista de permissões.
• [9.14/A-0-2] É NECESSÁRIO observar um monitoramento contra ataques de negação de serviço do framework do Android ou de apps de terceiros. Isso protege contra o uso de software malicioso que inunde a rede do veículo com tráfego, o que pode levar ao mau funcionamento de subsistemas do veículo.

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

Implementações de dispositivos automotivos:

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

2,6 Requisitos para tablets

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

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

As implementações de tablets têm requisitos semelhantes às implementações de dispositivos portáteis. As exceções são indicadas por um * nesta seção e indicadas 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 tablets incluírem um giroscópio de três eixos, elas:

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

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

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

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

Se as implementações de tablets incluírem uma porta USB compatível com o modo periférico, elas:

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

Modo de realidade virtual (Seção 7.9.1)

Alto desempenho da realidade virtual (Seção 7.9.2)

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

2.6.2. Modelo de segurança

Chaves e credenciais (Seção 9.11)

Consulte a Seção [9.11].

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

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

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

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

2.6.2. Software

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

3. Software

3.1. Compatibilidade com APIs gerenciadas

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

Implementações de dispositivos:

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

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

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

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

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

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

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

  No entanto, elas:

  • Caso não haja uma API oculta ou ela tenha sido implementada de maneira diferente na implementação do dispositivo, mova-a para a lista de bloqueio ou omita a API em todas as listas restritas (por exemplo, cinza-claro, cinza-escuro e preto).
  • MAI, se ainda não existir uma API oculta no AOSP, adicione 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 superfície da API gerenciada de um nível específico da API atualizando a versão da extensão para esse nível. A API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) vai retornar a versão da extensão do apiLevel fornecido, se houver extensões para esse nível de API.

Implementações de dispositivos Android:

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

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

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

3.1.2. Biblioteca do Android

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

• [C-0-1] NÃO PODE colocar a biblioteca org.apache.http.legacy no bootclasspath.
• [C-0-2] PRECISA adicionar a biblioteca org.apache.http.legacy ao caminho de classe do aplicativo somente quando ele atender a uma destas condições:
  • Segmenta a API de nível 28 ou anterior.
  • Declara no manifesto que precisa da biblioteca, definindo o atributo android:name de <uses-library> como org.apache.http.legacy.

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

3.2. Compatibilidade leve com APIs

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

3.2.1. Permissões

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

3.2.2. Parâmetros de build

As APIs do Android incluem várias constantes na classe android.os.Build destinadas a descrever o dispositivo atual.

• [C-0-1] Para fornecer valores consistentes e significativos em todas as implementações de dispositivos, a tabela abaixo inclui restrições adicionais sobre os formatos desses valores com os quais as implementações de dispositivos PRECISAM estar em conformidade.

Parâmetro	Detalhes
VERSÃO.LANÇAMENTO	A versão do sistema Android em execução no momento, em formato legível por humanos. Este 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 do aplicativo de terceiros. No 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 do aplicativo de terceiros. No Android 11, esse campo PRECISA ter o valor inteiro 11_INT.
VERSÃO.INCREMENTAL	Um valor escolhido pelo implementador do dispositivo, designando o build específico do sistema Android em execução no momento, em formato legível por humanos. Esse valor NÃO PODE ser reutilizado para builds diferentes disponibilizados aos usuários finais. Esse campo costuma ser usado para indicar qual número de build ou identificador de mudança de controle de origem foi usado para gerar o build. O valor desse campo PRECISA ser codificado como ASCII de 7 bits para impressão e corresponder à expressão regular "^[^ :\/~]+$".
TABULEIRO	Um valor escolhido pelo implementador do dispositivo que identifica o hardware interno específico usado pelo dispositivo, em formato legível por humanos. Esse campo pode ser usado para indicar a revisão específica da placa que fornece energia ao dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”.
MARCA	Um valor que reflete o nome da marca associada ao dispositivo, como conhecido pelos usuários finais. PRECISA estar em um formato legível por humanos e DEVE representar o fabricante do dispositivo ou a marca da empresa sob a qual o dispositivo é comercializado. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”.
ABIS_SUPORTE	O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
SUPORTE_32_ABIS_BIT	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.
SUPORTE_64_ABIS_BIT	É o nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com 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 contendo o nome de desenvolvimento ou o codinome que identifica a configuração dos recursos de hardware e o design industrial do dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”. O nome do dispositivo NÃO PODE ser alterado durante a vida útil do produto.
IMPRESSORA	Uma string que identifica exclusivamente este build. Ele DEVE ser legível por humanos. Ele PRECISA seguir este modelo: $(MARCA)/$(PRODUTO)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Exemplo: acme/meuproduto/ 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 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_-]+$”.
APRESENTADOR	Uma string que identifica de forma exclusiva o host em que o build foi criado, em formato legível. Não há requisitos para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
ID	Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão específica, em formato legível por humanos. Esse campo pode ser igual a android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficientemente significativo para que os usuários finais diferenciem versões de software. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9._-]+$”.
FABRICANTE	O nome comercial do fabricante de equipamento original (OEM) do produto. Não há requisitos para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia (""). Este campo NÃO PODE ser alterado durante a vida útil do produto.
MODEL	Um valor escolhido pelo implementador do dispositivo contendo o nome do dispositivo conhecido pelo usuário final. Esse DEVE ser o mesmo nome usado para divulgar e vender o dispositivo aos usuários finais. Não há requisitos para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia (""). Este campo NÃO PODE ser alterado durante a vida útil do produto.
PRODUTO	Um valor escolhido pelo implementador do dispositivo contendo o nome de desenvolvimento ou o codinome do produto específico (SKU) que PRECISA ser exclusivo na mesma marca. PRECISA ser legível, mas não se destina necessariamente à visualização dos 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_-]+$”. Este nome de produto NÃO PODE ser alterado durante a vida útil do produto.
SÉRIE	PRECISA retornar "UNKNOWN".
TAGS	Uma lista separada por vírgulas de tags escolhidas pelo implementador do dispositivo que distingue ainda mais o build. As tags PRECISAM ser codificadas como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-]+" e PRECISAM ter um dos valores correspondentes às três configurações típicas de assinatura da plataforma Android: "release-keys", "dev-keys" e "test-keys".
HORÁRIO	Um valor que representa o carimbo de data/hora de quando o build ocorreu.
MÁQUINA	Um valor escolhido pelo implementador do dispositivo especificando a configuração de tempo de execução do build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas do ambiente de execução do Android: user, userdebug ou eng.
USUÁRIO	Um nome ou ID do usuário (ou usuário automatizado) que gerou o build. Não há requisitos para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
VERSION.SECURITY_PATCH	Um valor que indica o nível do patch de segurança de uma versão. Ela PRECISA indicar que o build não está vulnerável a nenhum dos problemas descritos no boletim de segurança pública do Android. Ele PRECISA estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no Boletim de segurança pública do Android ou no Aviso de segurança do Android, por exemplo, "2015-11-01".
VERSÃO.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, informar uma string vazia ("").
BOOTLOADER	Um valor escolhido pelo implementador do dispositivo que identifica a versão interna específica do carregador de inicialização usada no dispositivo, em formato legível. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9._-]+$”.
getRadioVersion() (link em inglês)	PRECISA (ser ou retornar) um valor escolhido pelo implementador do dispositivo, identificando a versão interna específica do rádio/modem usada no dispositivo, em formato legível. Se um dispositivo não tiver nenhum rádio/modem interno, ele PRECISA retornar NULL. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9._-,]+$”.
getSerial() (em inglês)	PRECISA (ser ou devolver) um número de série do hardware, que PRECISA estar disponível e ser exclusivo em dispositivos com o mesmo MODEL e MANUFACTURER. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9._-,]+$”.

3.2.3. Compatibilidade de intents

3.2.3.1. Intents comuns de aplicativos

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

Implementações de dispositivos:

• [C-SR] É FORTEMENTE RECOMENDADO pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intent pública definidos pelos seguintes intents de aplicativo listados aqui e fornecer fulfillment, ou seja, atender à expectativa do desenvolvedor para essas intents de aplicativo comuns, conforme descrito no SDK.

Consulte a Seção 2 para saber mais sobre intents de aplicativos obrigatórias para cada tipo de dispositivo.

3.2.3.2. Resolução de intents

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

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

• [C-0-3] As implementações de dispositivos PRECISAM fornecer uma interface do usuário para que os usuários modifiquem a atividade padrão 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 app padrão autoritativo para determinados tipos de intents de URI da Web. Quando essas declarações autoritativas são definidas nos padrões de filtro de intent de um app, as implementações do dispositivo:

• [C-0-4] PRECISA tentar validar os filtros de intent executando as etapas de validação definidas na especificação Digital Asset Links, conforme implementadas pelo Package Manager no Android Open Source Project.
• [C-0-5] PRECISA tentar validar os filtros de intent durante a instalação do aplicativo e definir todos os filtros de intent de URI validados com sucesso como gerenciadores de app padrão para os URIs.
• PODEM definir filtros de intent de URI específicos como gerenciadores de aplicativos padrão para seus URIs, se eles forem verificados, mas outros filtros candidatos de URI falharem na verificação. Se uma implementação de dispositivo fizer isso, ela PRECISA fornecer ao usuário substituições apropriadas por padrão de URI no menu de configurações.
• PRECISA fornecer ao usuário controles de links do app por app nas configurações, da seguinte maneira:
  • [C-0-6] O usuário PRECISA ser capaz de substituir de forma holística o comportamento dos links de app padrão para que um app seja: sempre aberto, sempre perguntar ou nunca abrir, o que precisa ser aplicado a todos os filtros de intent de URI candidatos igualmente.
  • [C-0-7] O usuário PRECISA ver uma lista de filtros de intent de URI candidatos.
  • A implementação do dispositivo PODE fornecer ao usuário a capacidade de substituir filtros de intent de URI candidatos específicos que foram verificados com base em filtros por intent.
  • [C-0-8] A implementação do dispositivo PRECISA oferecer aos usuários a capacidade de visualizar e substituir filtros de intent de URI candidatos específicos se a implementação do dispositivo permitir que alguns filtros de intent de URI candidatos sejam aprovados na verificação, enquanto outros possam falhar.

3.2.3.3. Namespaces de intents

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

3.2.3.4. Intents de transmissão

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

Implementações de dispositivos:

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

3.2.3.5. Intents de aplicativos condicionais

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

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

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

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

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

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

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

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

• [C-2-3] PRECISA respeitar a intent android.telecom.action.CHANGE_PHONE_ACCOUNTS para que o usuário possa configurar a ConnectionServices associada ao PhoneAccounts, além de uma PhoneAccount padrão que o provedor de serviços de telecomunicações usará para realizar chamadas. A implementação do AOSP atende a esse requisito incluindo uma "opção para chamadas de contas". em "Chamadas", no menu de configurações.

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

• [C-2-5] PRECISA oferecer recursos para o usuário escolher um app com o papel android.app.role.CALL_REDIRECTION.
• [C-2-6] PRECISA respeitar as intents android.intent.action.SENDTO e android.intent.action.VIEW e fornecer uma atividade para enviar/exibir mensagens SMS.
• [C-SR] É altamente recomendável respeitar android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_Button, android.intent.action.VIEW e Intents android.intent.action.DIAL com um aplicativo discador pré-carregado que pode processar essas intents e fornecer fulfillment conforme descrito no SDK.

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

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

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

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

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

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

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

• [C-5-1] PRECISA respeitar a intent ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ e mostrar uma atividade do sistema para permitir que o usuário ative o Bluetooth.
• [C-5-2] PRECISA respeitar a intent ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ e mostrar uma atividade do sistema que solicita o modo detectável.

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

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

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

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

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

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

Se as implementações de dispositivos forem compatíveis com o Wi-Fi Easy Connect e exporem a funcionalidade a apps de terceiros, elas:

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

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

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

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

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

• [C-12-1] PRECISA respeitar as intents android.media.action.STILL_IMAGE_CAMERA e android.media.action.STILL_IMAGE_CAMERA_SECURE e iniciar a câmera em modo de imagem estática, conforme descrito no SDK.
• [C-12-2] PRECISA respeitar a intent android.media.action.VIDEO_CAMERA para iniciar a câmera no modo de vídeo, conforme descrito no SDK.
• [C-12-3] PRECISA permitir que apenas apps 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] PRECISA respeitar a intent android.app.action.ADD_DEVICE_ADMIN de invocar uma interface para levar o usuário ao adicionar o administrador do dispositivo ao sistema (ou permitir que ele a rejeite).

• [C-13-2] PRECISA respeitar 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_MANAGE1.SET_PROFILE1}{PARENT_PASSWORD1},{PARENT_PASSWORD1} android.app.action.START_ENCRYPTION e ter uma atividade para fornecer o fulfillment para essas intents, conforme descrito aqui no SDK.

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

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

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

• Os [C-SR] são FORTEMENTE RECOMENDADOS fornecem 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_CONFIG para apps que declaram a permissão android.permission.PACKAGE_USAGE_STATS.

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

• [C-15-1] ainda PRECISA ter uma atividade que processe o padrão de intent android.settings.ACTION_USAGE_ACCESS_CONFIG, mas PRECISA implementá-la como ambiente autônomo, ou seja, para ter um comportamento equivalente ao de um usuário recusado para acesso.

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

• [C-SR] É altamente recomendável para respeitar android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA e As intents android.speech.tts.engine.GET_SAMPLE_TEXT têm uma atividade para fornecer o fulfillment para essas intents, conforme descrito neste link do SDK.

O Android oferece suporte a protetores de tela interativos, anteriormente chamados de Dreams. Os Protetores de tela permitem que os usuários interajam com os aplicativos quando um dispositivo conectado a uma fonte de energia estiver inativo ou ancorado em uma dock de mesa. Implementações dos dispositivos:

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

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

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

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

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

• [C-3-1] Somente o proprietário da tela, do sistema e das atividades que já estão nela PRECISA ser capaz de iniciá-la. Todos podem abrir uma tela que tenha a flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilidade com API nativa

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

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

3.3.1. Interfaces binárias do aplicativo

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

Implementações de dispositivos:

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

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

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

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

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

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

• [C-0-9] É NECESSÁRIO listar outras bibliotecas não AOSP expostas diretamente a apps de terceiros em /vendor/etc/public.libraries.txt.
• [C-0-10] NÃO PODE expor outras bibliotecas nativas, implementadas e fornecidas no AOSP como bibliotecas do sistema, a apps de terceiros com nível de API 24 ou mais recente, porque elas são reservadas.
• [C-0-11] PRECISA exportar todos os símbolos de função do OpenGL ES 3.1 e do Android Extension Pack, conforme definido no NDK, pela biblioteca libGLESv3.so. Embora todos os símbolos PRECISAM estar presentes, a seção 7.1.4.1 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
• [C-0-12] É NECESSÁRIO exportar os símbolos de função para os símbolos de função principais do Vulkan 1.0, além das extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2, usando a biblioteca libvulkan.so. Embora todos os símbolos PRECISAM estar presentes, a seção 7.1.4.2 descreve com mais detalhes os requisitos para quando se espera a implementação completa de cada função correspondente.
• DEVE ser criado usando o código-fonte e os arquivos principais disponíveis no Android Open Source Project

Versões futuras do Android podem introduzir a compatibilidade com outras ABIs.

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

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

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

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

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

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

• [C-2-2] PRECISA sempre manter as operações a seguir disponíveis, mesmo quando a ABI está implementada em uma arquitetura ARMv8, seja pelo suporte nativo à CPU ou pela emulação de software:

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

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

3,4 Compatibilidade com a Web

3.4.1. Compatibilidade com WebView

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

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

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

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

  • O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
  • A string $(MODEL) PODE estar vazia, mas se não estiver, ela PRECISA ter o mesmo valor que android.os.Build.MODEL.
  • "Versão/$(BUILD)" PODE ser omitido, mas se estiver presente, a string $(BUILD) PRECISA ser igual ao valor de android.os.Build.ID.
  • O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium no Android Open Source Project.
  • As implementações de dispositivos podem omitir dispositivos móveis na string do user agent.

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

• [C-1-3] PRECISA renderizar o conteúdo fornecido ou o conteúdo do URL remoto em um processo diferente do aplicativo que instancia a WebView. Especificamente, o processo de renderizador separado PRECISA ter privilégio mínimo, ser executado como um ID de usuário separado, não ter acesso ao diretório de dados do app nem acesso direto à rede e só ter acesso aos serviços mínimos exigidos do sistema pelo binder. A implementação do WebView do AOSP atende a esse requisito.

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

3.4.2. Compatibilidade de navegadores

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

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

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

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

3,5 Compatibilidade comportamental de API

Implementações de dispositivos:

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

O comportamento de cada um dos tipos de API (gerenciado, flexível, nativo e Web) precisa ser consistente com a implementação preferida do Android Open Source Project upstream. Algumas áreas específicas de compatibilidade são:

• [C-0-1] Os dispositivos NÃO PODEM mudar o comportamento ou a semântica de uma intent padrão.
• [C-0-2] Os dispositivos NÃO PODEM alterar a semântica do ciclo de vida ou do ciclo de vida de um tipo específico de componente do sistema (como Service, Activity, ContentProvider etc.).
• [C-0-3] Os dispositivos NÃO PODEM mudar a semântica de uma permissão padrão.
• Os dispositivos NÃO PODEM alterar as limitações aplicadas a aplicativos em segundo plano. Mais especificamente, para aplicativos em segundo plano:
  • [C-0-4] eles PRECISAM parar de executar callbacks registrados pelo app para receber saídas de GnssMeasurement e GnssNavigationMessage.
  • [C-0-5] eles PRECISAM limitar a frequência de atualizações fornecidas ao app pela classe de API LocationManager ou pelo método WifiManager.startScan().
  • [C-0-6] Se o app for destinado ao nível 25 da API ou mais recente, eles NÃO PODEM permitir o registro de broadcast receivers para as transmissões implícitas de intents padrão do Android no manifesto do app, a menos que a intent de transmissão exija uma permissão "signature" ou "signatureOrSystem" protectionLevel ou esteja na lista de isenções.
  • [C-0-7] Se o app for direcionado ao nível 25 da API ou mais recente, ele PRECISA interromper os serviços em segundo plano, como se tivesse chamado o método stopSelf(), a menos que o app fosse colocado em uma lista de permissões temporária para processar uma tarefa visível para o usuário.
  • [C-0-8] Se o app for direcionado ao nível 25 da API ou mais recente, ele PRECISA liberar os wakelocks que o app reté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 indicada e com os nomes (como retornado por Provider.getName()) e classes, a menos que o app tenha modificado a lista usando insertProviderAt() ou removeProvider(). Os dispositivos PODEM retornar provedores adicionais após a lista especificada abaixo.
  1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL: com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider: sun.security.provider.CertPathProvider
  4. Alternativa AndroidKeyStoreBC: android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE: com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore: android.security.keystore.AndroidKeyStoreProvider

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

3.5.1. Restrição de aplicativo

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

• [C-1-1] PRECISA oferecer funcionalidade do usuário em que ele possa conferir a lista de apps restritos.
• [C-1-2] PRECISA oferecer recursos ao usuário para ativar / desativar as restrições em cada app.
• [C-1-3] não pode aplicar restrições automaticamente sem evidência de mau comportamento de integridade do sistema, mas PODE aplicar as restrições em apps após a detecção de um comportamento inadequado de integridade do sistema, como wakelocks travados, serviços de longa duração 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 são puramente relacionados à integridade do sistema, como a falta de popularidade do app no mercado, NÃO PODEM ser usados como critério.
• [C-1-4] Não deve aplicar restrições de apps automaticamente quando um usuário desativou essas restrições manualmente e PODE sugerir que o usuário aplique restrições de apps.
• [C-1-5] PRECISA informar os usuários se restrições forem aplicadas automaticamente a um app. Essas informações DEVEM ser fornecidas dentro de 24 horas a partir da aplicação das restrições.
• [C-1-6] PRECISA retornar true para ActivityManager.isBackgroundRestricted() quando o app restrito chamar essa API.
• [C-1-7] NÃO PODE restringir o app em primeiro plano que é explicitamente usado pelo usuário.
• [C-1-8] É NECESSÁRIO suspender as restrições em um app que se torna o principal app em primeiro plano quando o usuário começa a usar explicitamente o app que era restrito.

3,6 Namespaces da API

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

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

Ou seja, eles:

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

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

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

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

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

Se um implementador de dispositivo propõe melhorar um dos namespaces de pacote acima (por exemplo, adicionando uma nova funcionalidade útil a uma API existente), ele DEVIA acessar source.android.com e iniciar o processo para contribuir com alterações e código, de acordo com as informações nesse site.

Observe que as restrições acima correspondem às convenções padrão para nomear APIs na linguagem de programação Java. nesta seção, tem como objetivo reforçar essas convenções e torná-las vinculativas por meio da inclusão nesta Definição de Compatibilidade.

3,7 Compatibilidade de ambiente de execução

Implementações de dispositivos:

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

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

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

• DEVE fazer testes de fuzz em vários modos de execução e arquiteturas-alvo 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)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
pequeno/normal	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
grande	120 dpi (ldpi)	32MB
	140 dpi (140dpi)	48MB
	160 dpi (mdpi)
	180 dpi (180dpi)	80MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512 MB
extra grande	120 dpi (ldpi)	48MB
	140 dpi (140dpi)	80MB
	160 dpi (mdpi)
	180 dpi (180dpi)	96MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3,8. Compatibilidade da interface do usuário

3.8.1. Tela de início (tela inicial)

O Android inclui um aplicativo de inicialização (tela inicial) e suporte a aplicativos de terceiros para substituir o inicializador 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] PRECISA declarar o recurso da plataforma android.software.home_screen.
• [C-1-2] PRECISA retornar o objeto AdaptiveIconDrawable quando o aplicativo de terceiros usar a tag <adaptive-icon> para fornecer o ícone, e os métodos PackageManager para recuperar ícones são chamados.

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

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

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

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

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

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

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

• [C-5-1] PRECISA respeitar o método da API NotificationChannel.setShowBadge(). Em outras palavras, mostre uma funcionalidade visual associada ao ícone do app se o valor estiver definido como true e não mostre nenhum esquema de selo de ícone do app quando todos os canais de notificação tiverem definido o valor como false.
• PODE substituir os selos de ícone do app pelo esquema de selo reservado quando aplicativos de terceiros indicarem suporte ao esquema de selos reservado com o uso de APIs proprietárias. No entanto, DEVE usar os recursos e valores fornecidos pelas APIs de selos de notificação descritas no SDK , como as APIs 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 forem compatíveis com widgets de apps de terceiros, elas:

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

Se as implementações de dispositivos forem compatíveis com widgets de apps de terceiros e fixação de atalhos no app, elas:

• [C-2-1] PRECISA informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] PRECISA ter affordance do usuário antes de adicionar um atalho solicitado pelos apps com o método de 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 usuários atenção usando os componentes de hardware (por exemplo, som, vibração e luz) e recursos de software (por exemplo, aba de notificações, barra de sistema) do dispositivo.

3.8.3.1. Apresentação de notificações

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

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

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

Implementações de dispositivos:

• [C-SR] É MUITO RECOMENDADO para agrupar e mostrar conversation notifications antes de notificações que não sejam de conversa, com exceção das notificações de serviços em primeiro plano e importance:high em andamento.

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

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

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

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

Se as implementações de dispositivos forem compatíveis com notificações de alerta:

• [C-3-1] PRECISA usar a visualização e os recursos das notificações de alerta, conforme descrito na classe da API Notification.Builder quando elas forem apresentadas.
• [C-3-2] PRECISA 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 (após a ativação explícita do usuário) recebam uma cópia de todas as notificações conforme são postadas ou atualizadas.

Implementações de dispositivos:

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

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

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

3.8.3.3. Não perturbe

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

• [C-1-1] É NECESSÁRIO, para quando a implementação do dispositivo permitir que o usuário conceda ou negue apps de terceiros para acessar a configuração da política de Não perturbe, mostrar as Regras automáticas de Não perturbe criadas pelos apps junto com as regras predefinidas e criadas pelo usuário.
• [C-1-3] PRECISA respeitar os valores suppressedVisualEffects transmitidos pela NotificationManager.Policy. Se um app tiver definido qualquer uma das flags supPRESSED_EF_SCREEN_OFF ou supPRESSED_EF_SCREEN_ON, ela DEVE indicar ao usuário que os efeitos visuais foram suprimidos no menu de configurações de "DND".

3.8.4. Pesquisar

O Android inclui APIs que permitem aos desenvolvedores incorporar a pesquisa em seus aplicativos e expor os dados de seus aplicativos na pesquisa do sistema global. De modo geral, essa funcionalidade consiste em uma interface de usuário única em todo o sistema que permite aos usuários inserir consultas, exibir sugestões à medida que os usuários digitam e exibir resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para fornecer pesquisa nos próprios aplicativos e para fornecer resultados à interface de usuário de pesquisa global comum.

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

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

• [C-1-1] PRECISA implementar as APIs que permitem que aplicativos de terceiros adicionem sugestões à caixa de pesquisa quando ela é executada no modo de pesquisa global.

Se não estiverem instalados aplicativos de terceiros que usem a pesquisa global:

• O comportamento padrão DEVE ser exibir sugestões e resultados de mecanismos de pesquisa na 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 de dispositivos forem compatíveis com a ação de assistência, elas:

• [C-2-1] PRECISA indicar claramente para o usuário final quando o contexto é compartilhado, de uma destas formas:
  • Sempre que o app assistivo acessa o contexto, mostrando uma luz branca ao redor das bordas da tela que correspondem ou excedem a duração e o brilho da implementação do Android Open Source Project.
  • Para o app assistivo pré-instalado, fornecer uma funcionalidade do usuário a menos de duas navegações do menu de configurações padrão da entrada de texto por voz e do app assistente e compartilhar o contexto apenas quando o app assistivo for invocado explicitamente pelo usuário com uma entrada da tecla de navegação de hotword ou de assistência.
• [C-2-2] A interação designada para iniciar o app assistivo, conforme descrito na seção 7.2.3, PRECISA iniciar o app assistivo selecionado pelo usuário. Em outras palavras, o app que implementa VoiceInteractionService ou uma atividade que processa a intent ACTION_ASSIST.

3.8.5. Alertas e avisos

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

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

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

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

3.8.6. Temas

O Android fornece “temas” como um mecanismo para os aplicativos aplicarem estilos em toda uma atividade ou aplicativo.

O Android inclui um "Holo" e um "Material" família de temas como um conjunto de estilos definidos que os desenvolvedores de aplicativos podem usar se quiserem combinar com a aparência do tema Holo (link em inglês), conforme definido pelo SDK do Android.

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

• [C-1-1] NÃO PODE alterar nenhum dos atributos de tema Holo expostos a aplicativos.
• [C-1-2] PRECISA ser compatível com a família de temas "Material" e NÃO pode alterar nenhum dos atributos de tema do Material Design ou os recursos deles expostos a aplicativos.
• [C-1-3] PRECISA definir "sans-serif" família de fontes para Roboto versão 2.x para os idiomas com suporte da Roboto ou fornecer uma affordance de usuário para alterar a fonte usada para "sans-serif" família de fontes da Roboto versão 2.x para os idiomas compatíveis com a Roboto.

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

• As implementações de dispositivos podem modificar os atributos de tema padrão do dispositivo expostos a aplicativos.

O Android oferece suporte a um tema 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 permitir uma experiência consistente para o desenvolvedor nessa configuração, é importante que o estilo do ícone da barra de status seja mantido em diferentes implementações de dispositivos.

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

• [C-2-1] PRECISA usar branco para ícones de status do sistema (como intensidade do sinal e nível da bateria) e notificações emitidas pelo sistema, a menos que o ícone esteja indicando um status problemático ou se um aplicativo solicitar uma barra de status clara usando a sinalização 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 solicita uma barra de status clara.

3.8.7. Planos fundo interativos

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

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

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

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

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

3.8.8. Troca de atividades

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

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

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

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

3.8.9. Gerenciamento de entradas

O Android é compatível com o gerenciamento de entrada e com editores de método de entrada de terceiros.

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

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

3.8.10. Controle de mídia da tela de bloqueio

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

3.8.11. Protetores de tela (antigo Dreams)

Consulte a seção 3.2.3.5 para saber mais sobre a intenção das 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 do local, elas

• [C-1-2] PRECISA exibir o status atual do local no menu "Local", em "Configurações".
• [C-1-3] NÃO PODE exibir os modos de localização no menu "Local" em "Configurações".

3.8.13. Unicode e fonte

O Android inclui suporte para os caracteres de emoji definidos em Unicode 10.0.

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

• [C-1-1] PRECISA renderizar esses caracteres de emoji em um glifo de cor.
• [C-1-2] PRECISA incluir suporte para:
  • Fonte Roboto 2 com pesos diferentes: Sans Serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-light (link em inglês) para os idiomas disponíveis no dispositivo.
  • Cobertura completa em Unicode 7.0 de latim, grego e cirílico, incluindo os intervalos latinos estendidos A, B, C e D, e todos os glifos no bloco de símbolos de moeda do Unicode 7.0.
• DEVE oferecer suporte ao tom de pele e aos diversos emojis de família, conforme especificado no Relatório técnico do Unicode no 51.

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

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

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

Se as implementações de dispositivos forem compatíveis com o 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 dispositivos puderem mostrar várias atividades ao mesmo tempo, elas:

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

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

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

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

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

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

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

3.8.15. Recorte da tela

O Android é compatível com recortes de tela, conforme descrito no documento do SDK. A API DisplayCutout define uma área na borda da tela que pode não ser funcional para um aplicativo devido a um corte da tela ou uma tela curvada nas bordas.

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

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

3.8.16. Controles do dispositivo

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

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

3,9. Administração do dispositivo

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

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

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

3.9.1 Provisionamento de dispositivos

3.9.1.1 Provisionamento do proprietário do dispositivo

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

• [C-1-1] PRECISA ser compatível com a inscrição de um cliente Device Policy (DPC) como um app proprietário do dispositivo, conforme descrito abaixo:
  • Quando a implementação do dispositivo ainda não tem dados do usuário, ela:
    • [C-1-3] PRECISA informar true para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] PRECISA registrar o aplicativo DPC como o app Proprietário do dispositivo em resposta à ação da intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] PRECISA registrar o aplicativo DPC como o app Proprietário do dispositivo se o dispositivo declarar suporte a comunicações a curta distância (NFC, na sigla em inglês) usando a flag de recurso android.hardware.nfc e receber uma mensagem NFC contendo um registro com o tipo MIME MIME_TYPE_PROVISIONING_NFC.
  • Quando a implementação do dispositivo tem dados do usuário, ela:
    • [C-1-6] PRECISA informar false para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] NÃO PODE mais registrar aplicativos DPC como o aplicativo Proprietário do dispositivo.
• [C-1-2] PRECISA exigir alguma ação afirmativa antes ou durante o processo de provisionamento para permitir que o app seja definido como Proprietário do dispositivo. O consentimento pode ser por ação do usuário ou por algum meio programático, mas o aviso de divulgação apropriado (conforme mencionado no AOSP) PRECISA ser mostrado antes que o provisionamento do proprietário do dispositivo seja iniciado. Além disso, o mecanismo de consentimento do proprietário do dispositivo programático usado (pelas empresas) para o provisionamento do proprietário NÃO PODE interferir na experiência pronta para uso em empresas.
• [C-1-3] NÃO PODE codificar o consentimento nem impedir o uso de outros apps do proprietário do dispositivo.

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

• [C-2-1] PRECISA ter um processo para verificar se o app específico que está sendo promovido pertence a uma solução legítima de gerenciamento de dispositivos corporativos e já foi configurado na solução proprietária para ter os direitos equivalentes a um "Proprietário do dispositivo".
• [C-2-2] PRECISA mostrar a mesma divulgação de consentimento do proprietário do dispositivo AOSP que o fluxo iniciado pelo android.app.action.PROVISION_MANAGED_DEVICE antes de registrar o app de DPC como "Proprietário do dispositivo".
• PODE ter dados de 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 de dispositivo declararem android.software.managed_users, elas:

• [C-1-1] PRECISA implementar as APIs, permitindo que um aplicativo controlador de política de dispositivo (DPC, na sigla em inglês) se torne proprietário de um novo perfil gerenciado.

• [C-1-2] A experiência dos usuários do processo de provisionamento de perfil gerenciado (o fluxo iniciado por android.app.action.PROVISION_MANAGED_PROFILE) PRECISA estar alinhada à implementação do AOSP.

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

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

3.9.2 Suporte de perfil gerenciado

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

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

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

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

3.9.3 Suporte gerenciado ao usuário

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

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

3,10 Acessibilidade

O Android oferece uma camada de acessibilidade que ajuda usuários com deficiências a navegar nos dispositivos com mais facilidade. Além disso, o Android oferece APIs de plataforma que permitem que implementações de serviço de acessibilidade recebam callbacks para eventos do usuário e do sistema e gerem mecanismos alternativos de feedback, como conversão de texto em voz, retorno tátil e navegação por trackball/botão direcional.

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

• [C-1-1] PRECISA fornecer uma implementação do framework de acessibilidade do Android, conforme descrito na documentação do SDK das APIs de acessibilidade.
• [C-1-2] PRECISA gerar eventos de acessibilidade e entregar o AccessibilityEvent adequado para todas as implementações de AccessibilityService registradas, conforme documentado no SDK.
• [C-1-4] PRECISA adicionar um botão na barra de navegação do sistema para o usuário controlar o serviço de acessibilidade quando os serviços ativados declaram a AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Para implementações de dispositivos sem uma barra de navegação do sistema, esse requisito não é aplicável, mas elas DEVEM fornecer uma funcionalidade do usuário para controlar esses serviços de acessibilidade.

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

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

3,11. Conversão de texto em voz

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

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

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

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

• [C-2-1] PRECISA fornecer affordance do usuário para que ele possa selecionar um mecanismo de TTS para uso no nível do sistema.

3,12. TV Input Framework

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

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

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

3,13 Configurações rápidas

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

Se as implementações de dispositivos incluírem um componente de interface para Configurações rápidas e forem compatíveis com Configurações rápidas de terceiros, elas:

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

3,14 Interface de mídia

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

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

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

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

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

3,15 Instant Apps

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

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

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

• [C-1-1] PRECISA fornecer as seguintes affordances do usuário para interagir com os Instant Apps. O AOSP atende aos requisitos da interface, das configurações e da tela de início padrão do sistema.
• [C-1-2] PRECISA oferecer recursos de visualização e exclusão de apps instantâneos localmente armazenados em cache para cada pacote de app.
• [C-1-3] PRECISA fornecer uma notificação persistente para o usuário, que pode ser recolhida enquanto um app instantâneo estiver em execução em primeiro plano. Essa notificação PRECISA incluir que os Instant Apps não exigem instalação e oferecer recursos que direcionem o usuário para a tela de informações do aplicativo nas configurações. Para Apps instantâneos iniciados por intents da Web, conforme definido pelo uso de uma intent com ação definida como Intent.ACTION_VIEW e com um esquema "http" ou "https", uma funcionalidade de usuário adicional DEVE permitir que o usuário não inicie o app instantâneo e inicie o link associado com o navegador da Web configurado, caso um navegador esteja disponível no dispositivo.
• [C-1-4] PRECISA permitir que Apps instantâneos em execução sejam acessados pela função "Recentes" se ela estiver disponível no dispositivo.
• [C-1-5] PRECISA pré-carregar um ou mais aplicativos ou componentes de serviço com um gerenciador de intents para os intents listados aqui no SDK e tornar os intents visíveis para o Instant Apps.

3,16 Pareamento de dispositivo complementar

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

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

• [C-1-1] PRECISA declarar a flag de recurso FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] PRECISA garantir que as APIs no pacote android.companion estejam totalmente implementadas.
• [C-1-3] PRECISA fornecer recursos do usuário para que ele selecione/confirme que um dispositivo complementar está presente e operacional.

3.17. Apps pesados

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

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

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

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

3,18. Contatos

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

RawContacts estão "associados" ou "armazenado em" uma Account quando as colunas ACCOUNT_NAME e ACCOUNT_TYPE dos contatos brutos corresponderem 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] É MUITO RECOMENDADO não criar contas locais personalizadas.

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

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

4. Compatibilidade do empacotamento de aplicativos

Implementações de dispositivos:

• [C-0-1] PRECISA instalar e executar arquivos ".apk" do Android conforme gerado pela ferramenta "aapt" incluída no SDK oficial do Android.
• Como o requisito acima pode ser desafiador, as implementações de dispositivos são RECOMENDADAS para usar o sistema de gerenciamento de pacotes da implementação de referência do AOSP.

Implementações de dispositivos:

• [C-0-2] PRECISA 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 PODE estender os formatos de bytecode .apk, Manifesto do Android, Bytecode Dalvik ou RenderScript de forma a impedir que esses arquivos sejam instalados e executados corretamente em outros dispositivos compatíveis.

• [C-0-4] NÃO É POSSÍVEL permitir outros apps além do "instalador do registro" atual para que o pacote desinstale silenciosamente o app sem qualquer confirmação do usuário, conforme documentado no SDK para a permissão DELETE_PACKAGE. As únicas exceções são o app verificador de pacote do sistema que processa a intent PACKAGE_NEEDS_VERIFICATION e o app gerenciador de armazenamento que processa a intent ACTION_MANAGE_STORAGE.

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

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

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

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

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

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

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

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

• Se as implementações de dispositivos já tiverem sido lançadas em uma versão anterior do Android e não puderem atender aos requisitos [C-0-8] e [C-0-9] após uma atualização de software do sistema, elas PODEM ser isentas desses requisitos.

5. Compatibilidade multimídia

Implementações de dispositivos:

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

Implementações de dispositivos:

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

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

O Google e a Open Handset Alliance nem o Google declaram que esses codecs estão isentos de patentes de terceiros. Aqueles que pretendem usar esse código-fonte em produtos de hardware ou software são informados que as implementações deste código, inclusive em software de código aberto ou shareware, podem exigir licenças de patente dos respectivos detentores de patentes.

5.1. Codecs de mídia

5.1.1. Codificação de áudio

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

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

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

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

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

5.1.2. Decodificação de áudio

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

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

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

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

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

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

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

Se a norma ISO/IEC 23003-4 for compatível e os metadados ISO/IEC 23003-4 e ISO/IEC 14496-3 estiverem presentes em um bitstream decodificado:

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

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

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

5.1.3. Detalhes dos codecs de áudio

Formato/Codec	Detalhes	Tipos de arquivos/formatos de contêiner aceitos
Perfil AAC para MPEG-4 (AAC LC)	Suporte a conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS AAC bruto (.aac, ADIF não compatíveis) MPEG-TS (.ts, não pesquisável, somente decodificação) Matroska (.mkv, somente decodificação)
Perfil MPEG-4 HE AAC (AAC+)	Suporte a conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Perfil (AAC+ otimizado)	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	Compatibilidade com conteúdo mono/estéreo com taxas de amostragem padrão de 7,35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 a 12,2 kbps com amostragem a 8 kHz.	3GPP (.3gp)
AMR-WB	9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz, conforme definido em AMR-WB, Adaptive Multi-Rate - Codec de fala de banda larga	3GPP (.3gp)
FLAC	Para codificador e decodificador: pelo menos os modos mono e estéreo PRECISAM ser compatíveis. Taxas de amostragem de até 192 kHz PRECISAM ser compatíveis. As resoluções de 16 e 24 bits PRECISAM ser compatíveis. O processamento de dados de áudio FLAC de 24 bits PRECISA estar disponível com a configuração de áudio de ponto flutuante.	FLAC (.flac) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv, somente decodificação)
MP3	Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8 a 320 Kbps	MP3 (.mp3) MPEG-4 (.mp4, .m4a, somente decodificação) Matroska (.mkv, somente decodificação)
MIDI	MIDI tipos 0 e 1. DLS versões 1 e 2. XMF e XMF para celular. 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 ser compatível com PCM linear de 16 bits e flutuante de 16 bits. O extrator WAVE precisa ser compatível com PCM linear de 16, 24 e 32 bits e flutuante de 32 bits (taxas até o limite do hardware). As taxas de amostragem PRECISAM ser compatíveis entre 8 kHz e 192 kHz.	WAVE (.wav)
Opus	Decodificação: compatibilidade com conteúdo mono, estéreo, 5.0 e 5.1 com taxas de amostragem de 8.000, 12.000, 16.000, 24.000 e 48.000 Hz. Codificação: suporte a 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

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

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

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

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

• [C-1-1] PRECISA fornecer um codec de codificador HEVC acelerado por hardware compatível com o modo de controle de taxa de bits BITRATE_MODE_CQ, perfil HEVCProfileMainStill e tamanho de frame de 512 x 512 px.

5.1.5 Decodificação de imagem

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

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

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

Se as implementações de dispositivos oferecerem suporte à decodificação de vídeo HEVC, elas: * [C-1-1] PRECISA oferecer suporte à decodificação de imagens HEIF (HEIC).

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

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

5.1.6. Detalhes dos codecs de imagem

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

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

• [SR] FORTEMENTE RECOMENDADO para oferecer suporte ao formato de cores RGB888 para o modo de superfície de entrada.

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

5.1.7. Codecs de vídeo

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

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

• [C-1-1] Os codecs de vídeo PRECISAM oferecer suporte a tamanhos de buffer de bytes de saída e de entrada que acomodem os maiores frames compactados e descompactados possíveis, conforme determinado pelo padrão e pela configuração, mas também sem alocação excessiva.

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

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

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

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

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

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

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

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

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

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

5.1.8. Lista de codecs de vídeo

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

5.1.9. Segurança do codec de mídia

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

O Android é compatível com a OMX, uma API de aceleração multimídia multiplataforma, e com o Codec 2.0, uma API de aceleração multimídia de baixa sobrecarga.

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

• [C-1-1] PRECISA oferecer suporte a codecs de mídia via OMX ou as APIs Codec 2.0 (ou ambos), como no Android Open Source Project, e não desativar nem contornar as proteções de segurança. Especificamente, isso não significa que todos os codecs PRECISAM usar a API OMX ou o Codec 2.0. No entanto, o suporte para pelo menos uma dessas APIs PRECISA estar disponível e o suporte para as APIs disponíveis PRECISA incluir as proteções de segurança presentes.
• [C-SR] É MUITO RECOMENDADO incluir suporte para a API Codec 2.0.

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

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

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

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

5.1.10 Caracterização do codec de mídia

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

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

Especificamente, as seguintes:

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

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

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

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

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

5,2. Codificação de vídeo

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

• NÃO DEVE estar, em duas janelas deslizantes, mais de 15% acima da taxa de bits entre intervalos intraframe (I-frame).
• NÃO DEVE estar acima de 100% da taxa de bits em uma janela deslizante de um segundo.

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

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

Se as implementações de dispositivos forem compatíveis com qualquer um dos codificadores de vídeo H.264, VP8, VP9 ou HEVC e os disponibilizarem para aplicativos de terceiros, elas:

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

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

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

Se as implementações de dispositivos fornecerem codificadores de vídeo ou imagem com aceleração de hardware e oferecerem suporte a uma ou mais câmeras de hardware conectadas ou conectáveis expostas pelas APIs android.camera:

• [C-4-1] Todos os codificadores de vídeo e imagem acelerados por hardware PRECISAM ser compatíveis com a codificação de frames das câmeras de hardware.
• DEVE oferecer suporte à codificação de frames das câmeras de hardware em todos os codificadores de vídeo ou imagem.

5.2.1. H.263

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

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

5.2.2. H.264

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

• [C-1-1] PRECISA oferecer suporte ao perfil de referência de nível 3. No entanto, o suporte para ASO (Ordem Arbitrária de Frações), FMO (Ordem Flexível de Macrobloco) e RS (Slices Redundantes) é OPCIONAL. Além disso, para manter a compatibilidade com outros dispositivos Android, é RECOMENDADO que ASO, FMO e RS não são usados para o perfil de referência por codificadores.
• [C-1-2] PRECISA oferecer suporte aos perfis de codificação de vídeo SD (Definição padrão) na tabela a seguir.
• DEVE oferecer suporte ao nível 4 do perfil principal.
• DEVE oferecer suporte aos perfis de codificação de vídeo em HD (alta definição), conforme indicado na tabela a seguir.

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

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

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

Se as implementações de dispositivos alegarem oferecer suporte ao Perfil 2 ou ao Perfil 3 usando as APIs Media:

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

5.2.5. H.265

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

• [C-1-1] PRECISA oferecer suporte ao perfil principal de nível 3.
• DEVE oferecer suporte aos perfis de codificação em HD conforme indicado na tabela a seguir.
• [SR] é MUITO RECOMENDADO para oferecer suporte aos perfis de codificação em HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.

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

5,3 Decodificação de vídeo

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

• [C-1-1] PRECISA oferecer suporte ao perfil principal de nível 3.1 e ao perfil de referência. O suporte para ASO (Ordem Arbitrária de Frações), FMO (Ordem Flexível de Macrobloco) e RS (Slices Redundantes) é OPCIONAL.
• [C-1-2] PRECISA ser capaz de decodificar vídeos com os perfis SD (definição padrão) listados na tabela a seguir e codificados com o perfil de referência e o perfil principal de nível 3.1 (incluindo 720p30).
• DEVE ser capaz de decodificar vídeos com os perfis em HD (alta definição), conforme indicado na tabela a seguir.

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

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

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

5.3.5. H.265 (HEVC)

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

• [C-1-1] PRECISA oferecer suporte ao 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 de HD conforme indicado na tabela a seguir.
• [C-1-2] PRECISA oferecer suporte aos perfis de decodificação de HD, conforme indicado na tabela a seguir, se houver um decodificador de hardware.

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

• [C-2-1] As implementações de dispositivos PRECISAM ser compatíveis com pelo menos um dos perfis H.265 ou VP9 de perfis 720, 1080 e UHD.

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

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

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

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

• [C-3-1] As implementações de dispositivos PRECISAM ser compatíveis com pelo menos uma das decodificação VP9 ou H.265 dos perfis 720, 1080 e UHD.

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

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

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

Se as implementações de dispositivos alegam oferecer suporte a um perfil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) usando as APIs de mídia:

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

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

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

5,4. Gravação em áudio

Embora alguns dos requisitos descritos nesta seção estejam listados como DEVEEM desde o Android 4.3, a definição de compatibilidade para versões futuras está planejada para alterá-los para OBRIGATÓRIO. Os dispositivos Android novos e existentes são AVALIMENTE RECOMENDADOS para atender aos requisitos listados como DEVE. Caso contrário, eles não serão compatíveis com o Android quando forem atualizados para a versão futura.

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

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

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

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

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

• [C-1-3] PRECISA incluir um filtro anti-aliasing adequado quando as taxas de amostragem fornecidas acima forem capturadas com down-sample.

• DEVE permitir captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, o que significa as seguintes características:

  • Formato: PCM linear, 16 bits
  • Taxas de amostragem: 22.050, 48.000 Hz
  • Canais: estéreo
  • [C-1-4] PRECISA respeitar a API MicrophoneInfo e preencher corretamente as informações sobre os microfones disponíveis no dispositivo que podem ser acessados pelos aplicativos de terceiros pela API AudioManager.getMicrophones() e para os microfones ativos no momento, 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] PRECISA capturar sem aumento de amostragem em qualquer proporção maior que 16.000:22.050 ou 44.100:48.000.

• [C-2-2] PRECISA incluir um filtro anti-aliasing adequado para qualquer upamostragem ou redução da amostragem.

5.4.2. Captura para reconhecimento de voz

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

• [C-1-1] PRECISA capturar a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION em uma das taxas de amostragem, 44.100 e 48.000.
• [C-1-2] PRECISA, por padrão, desativar o processamento de áudio com redução de ruído ao gravar um stream de áudio da fonte AudioSource.VOICE_RECOGNITION.
• [C-1-3] PRECISA, por padrão, desativar qualquer controle automático de ganho ao gravar um stream de áudio da fonte AudioSource.VOICE_RECOGNITION.
• DEVE gravar o stream de áudio de reconhecimento de voz com características de amplitude versus frequência aproximadamente planas: 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 com nível de potência do som (SPL, na sigla em inglês) de 90 dB a 1.000 Hz gere RMS de 2.500 para amostras de 16 bits.
• DEVE gravar o stream de áudio de reconhecimento de voz para que os níveis de amplitude de PCM rastreiem linearmente as mudanças de SPL de entrada em pelo menos 30 dB, de -18 dB a +12 dB re 90 dB com SPL no microfone.
• DEVE gravar o stream de áudio do reconhecimento de voz com distorção harmônica total (THD) menor que 1% para 1 kHz a 90 dB com nível de entrada SPL no microfone.

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

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

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

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

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

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

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

5.4.4. Cancelador de eco acústico

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

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

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

• [C-SR] são STRONGLY_RECOMMENDED para declarar isso pelo método de 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 STRONGLY_RECOMMENDED para identificar exclusivamente cada implementação de tecnologia 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] PRECISA permitir o acesso simultâneo ao microfone por um serviço de acessibilidade que captura com AudioSource.VOICE_RECOGNITION e pelo menos um aplicativo capturando com AudioSource.
• [C-1-2] PRECISA permitir o acesso simultâneo ao microfone por um aplicativo pré-instalado com uma função do Assistente e pelo menos um aplicativo capturando com qualquer AudioSource, exceto AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
• [C-1-3] PRECISA silenciar a captura de áudio de qualquer outro aplicativo, exceto um serviço de acessibilidade, enquanto um aplicativo estiver capturando com AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. No entanto, quando um app está capturando via AudioSource.VOICE_COMMUNICATION, outro app pode capturar a ligação se ele for um app privilegiado (pré-instalado) com a permissão CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Se dois ou mais aplicativos estiverem capturando simultaneamente e se nenhum deles tiver uma IU na parte superior, aquele que iniciou a captura mais recentemente receberá o áudio.

5.4.6. Níveis de ganho do microfone

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

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

5,5. Reprodução de áudio

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

5.5.1. Reprodução de áudio bruto

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

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

  • Formatos de origem: PCM linear, 16 bits, 8 bits, flutuante
  • Canais: configurações mono, estéreo e multicanal válidas com até oito canais
  • Taxas de amostragem (em Hz):
    • 8000, 11025, 16000, 22050, 32000, 44100, 48000 com as configurações de canal listadas acima
    • 96.000 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 de efeitos de áudio para implementações de dispositivos.

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

• [C-1-1] PRECISA oferecer suporte às implementações EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controláveis pelas subclasses Equalizer e LoudnessEnhancer do AudioEffect.
• [C-1-2] PRECISA oferecer suporte à implementação da API do visualizador, controlável pela classe Visualizer.
• [C-1-3] PRECISA oferecer suporte à implementação de EFFECT_TYPE_DYNAMICS_PROCESSING 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] É FORTEMENTE RECOMENDADO para oferecer suporte a efeitos em ponto flutuante e multicanal.

5.5.3. Volume de saída de áudio

Implementações de dispositivos automotivos:

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

5,6. Latência de áudio

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

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

• latência de saída. É o intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e quando o som correspondente é apresentado ao ambiente em um transdutor ou sinal sai do dispositivo por uma porta e pode ser observado externamente.
• latência de saída a frio. A latência de saída para o primeiro frame, quando o sistema de saída de áudio esteve inativo e desligado antes da solicitação.
• latência de saída contínua. A latência de saída para os frames subsequentes, depois que o dispositivo está reproduzindo áudio.
• latência de entrada. É o intervalo entre o momento em que um som é apresentado pelo ambiente para o dispositivo em um transdutor ou sinal que entra no dispositivo por uma porta e quando um aplicativo lê o frame correspondente de dados codificados em PCM.
• entrada perdida. A parte inicial de um sinal de entrada que não pode ser usado ou está indisponível.
• latência de entrada a frio. A soma do tempo de entrada perdido e da latência de entrada para o primeiro frame, quando o sistema de entrada de áudio esteve inativo e desligado antes da solicitação.
• latência de entrada contínua. A latência de entrada para frames subsequentes, enquanto o dispositivo está capturando áudio.
• instabilidade na saída a frio. A variabilidade entre medições separadas de valores de latência de saída frio.
• instabilidade de entrada a frio. A variabilidade entre medições separadas de valores de latência de entrada a frio.
• 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 indicador e tempo para reduzir a diferença de fase entre os fluxos de entrada e saída.
• API OpenSL ES PCM da fila de buffer. O conjunto de APIs OpenSL ES relacionadas a PCM no Android NDK.
• API Native Audio da AAudio. O conjunto de APIs AAudio no Android NDK.
• Carimbo de data/hora. Um par que consiste em uma posição relativa de frame dentro de um stream e o tempo estimado quando 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 underrun de buffer para saída, um estouro de buffer para entrada ou qualquer outra fonte de ruído digital ou analógico.

Se as implementações de dispositivos 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 tem precisão de +/- 2 ms.
• [C-1-2] Latência de saída fria de 500 milissegundos ou menos.

Se as implementações de dispositivos declararem android.hardware.audio.output, elas serão FORTEMENTE RECOMENDADAS a atender ou exceder os seguintes requisitos:

• [C-SR] Latência de saída fria de 100 milissegundos ou menos. Dispositivos novos e existentes que executam essa versão do Android são MUITO RECOMENDADOS para atender a esses requisitos agora. Em uma versão futura da plataforma em 2021, vamos exigir uma latência de saída fria de 200 ms ou menos como OBRIGATÓRIO.
• [C-SR] Latência de saída contínua de 45 milissegundos ou menos.
• [C-SR] Minimize a instabilidade da 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 de dispositivos atenderem aos requisitos acima, após qualquer calibração inicial, ao usar a fila de buffer de PCM do OpenSL ES e as APIs de áudio nativas da AAudio, para latência de saída contínua e latência de saída a frio em pelo menos um dispositivo de saída de áudio compatível, elas serão:

• [C-SR] É MUITO RECOMENDADO que você informe áudio de baixa latência ao declarar a flag de recurso android.hardware.audio.low_latency.
• [C-SR] RECOMENDADO fortemente para atender aos requisitos de áudio de baixa latência pela API AAudio.
• [C-SR] MUITO RECOMENDADO para 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 de dispositivos não atenderem aos requisitos de áudio de baixa latência pela fila de buffer PCM do OpenSL ES e pelas APIs de áudio nativos da AAudio, elas:

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

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

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

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

• [C-SR] Latência de entrada a frio de 100 milissegundos ou menos. Dispositivos novos e existentes que executam essa versão do Android são MUITO RECOMENDADOS para atender a esses requisitos agora. Em uma versão futura da plataforma em 2021, vamos exigir uma latência de entrada fria de 200 ms ou menos como OBRIGATÓRIO.
• [C-SR] Latência de entrada contínua de 30 milissegundos ou menos.
• [C-SR] Latência de ida e volta contínua de 50 milissegundos ou menos.
• [C-SR] Minimize a instabilidade da entrada a frio.
• [C-SR] Limite o erro nos carimbos de data/hora de entrada, conforme retornado por AudioRecord.getTimestamp ou AAudioStream_getTimestamp, para +/- 1 ms.

5,7. Protocolos de rede

As implementações de dispositivos PRECISAM ser compatíveis com os 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 de dispositivos incluírem um decodificador de áudio ou vídeo, elas:

• [C-1-1] PRECISA oferecer suporte a todos os codecs e formatos de contêiner necessários na seção 5.1 sobre HTTP(S).

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

• [C-1-3] PRECISA oferecer suporte ao seguinte perfil de áudio e vídeo RTP e aos codecs relacionados na tabela de RTSP abaixo. Para conferir as exceções, consulte as notas de rodapé da tabela na seção 5.1.

Formatos de segmento de mídia

Formatos de segmentos	Referências	Compatibilidade necessária com o codec
Stream de transporte MPEG-2	ISO 13818 (link em inglês)	Codecs de vídeo: H264 AVC MPEG-4 SP MPEG-2 Consulte a seção 5.1.3 para detalhes sobre H264 AVC, MPEG2-4 SP, e MPEG-2. Codecs de áudio: AAC Consulte a seção 5.1.1 para saber mais detalhes sobre o AAC e as variantes dele.
AAC com enquadramento ADTS e tags ID3	ISO 13818-7 (link em inglês)	Consulte a seção 5.1.1 para saber detalhes sobre o AAC e as variantes dele.
WebVTT	WebVTT

RTSP (RTP, SDP)

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

5,8. Mídia segura

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

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

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

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

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

• [C-3-1] PRECISA oferecer suporte a HDCP 1.2 ou mais recente para todos os monitores externos conectados por uma porta com fio acessível ao usuário.

5,9. Interface digital para instrumentos musicais (MIDI)

Se as implementações de dispositivos relatarem compatibilidade com o recurso android.software.midi pela classe android.content.pm.PackageManager, elas:

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

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

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

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

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

5,10 Áudio profissional

Se as implementações de dispositivos relatarem compatibilidade com o recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager, elas:

• [C-1-1] PRECISA relatar a compatibilidade com o recurso android.hardware.audio.low_latency.
• [C-1-2] PRECISA ter latência de ida e volta contínua de áudio, 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] PRECISA incluir portas USB compatíveis com o modo host USB e o modo de periférico USB.
• [C-1-4] PRECISA relatar a compatibilidade com o recurso android.software.midi.
• [C-1-5] PRECISA atender aos requisitos de latência e áudio USB usando a API de fila de buffer de PCM do OpenSL ES e pelo menos um caminho da API de áudio nativo do AAudio.
• [SR] É RECOMENDADO para atender aos requisitos de latência e áudio USB usando a API de áudio nativo da AAudio no caminho MMAP.
• [C-1-6] PRECISA ter latência de saída de frio de 200 milissegundos ou menos.
• [C-1-7] PRECISA ter latência de entrada a frio de 200 milissegundos ou menos.
• [SR] É MUITO RECOMENDADO para fornecer um nível consistente de desempenho da CPU enquanto o áudio está ativo e a carga da CPU varia. Isso precisa ser testado usando a versão do app Android do ID de confirmação SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. O SynthMark usa um sintetizador de software executado em um framework de áudio simulado que mede o desempenho do sistema. O app SynthMark precisa ser executado com a opção "Automated Test" e ter os seguintes resultados:
  • Voicemark.90 >= 32 vozes
  • latênciamark.fix.little <= 15 ms
  • latênciamark.dynamic.little <= 50 ms

Consulte a documentação do SynthMark para ver uma explicação sobre as comparações.

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

Se as implementações de dispositivos atenderem a todos os requisitos acima, elas:

• [SR] É RECOMENDADO que você informe o suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager.

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

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

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

• [C-3-1] PRECISA implementar a classe de áudio USB.
• [C-3-2] PRECISA ter uma latência de ida e volta contínua de áudio de 20 milissegundos ou menos na porta do modo de 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] É FORTEMENTE RECOMENDADO oferecer suporte a E/S simultâneas de até oito canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usados com periféricos de áudio USB que também aceitam esses requisitos.

Se as implementações de dispositivos incluírem uma porta HDMI, elas:

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

5,11. Capturar para não processados

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

Se as implementações do dispositivo tiverem a intenção de oferecer suporte a fontes de áudio não processadas e disponibilizá-las para apps de terceiros, elas:

• [C-1-1] PRECISA informar o suporte pela propriedade PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED do android.media.AudioManager.

• [C-1-2] PRECISA exibir características de amplitude x frequência aproximadamente planas no intervalo de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz para cada microfone usado para gravar a fonte de áudio não processada.

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

• [C-1-4] PRECISA exibir níveis de amplitude na faixa de alta frequência: especificamente de ±30 dB de 7.000 Hz a 22 KHz, em comparação com a faixa média de cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-5] PRECISA definir a sensibilidade à entrada de áudio de modo que uma fonte de tom senoidal de 1.000 Hz, reproduzida a 94 dB, o nível de pressão sonora (SPL, na sigla em inglês) gere uma resposta com RMS de 520 para amostras de 16 bits (ou escala completa de -36 dB para fontes de áudio de ponto flutuante/precisão dupla) para cada microfone não processado usado para gravar o microfone não processado.

• [C-1-6] PRECISA ter uma proporção sinal-ruído (SNR, na sigla em inglês) de 60 dB ou mais para cada microfone usado para gravar a fonte de áudio não processada. (enquanto o SNR é medido como a diferença entre SPL de 94 dB e SPL equivalente de ruído próprio, com peso A).

• [C-1-7] PRECISA ter uma distorção harmônica total (THD) menor que 1% para 1 kHZ a um nível de entrada de SPL de 90 dB em cada microfone usado para gravar a fonte de áudio não processada.

• Não É NECESSÁRIO ter nenhum outro processamento de sinal no caminho (por exemplo, controle automático de ganho, filtro de alta frequência ou cancelamento de eco) no caminho além de um multiplicador para levar o nível para a faixa desejada. Resumindo:

• [C-1-8] Se, por qualquer motivo, o processamento de sinal estiver presente na arquitetura, ele PRECISA ser desativado e introduzir efetivamente nenhum atraso ou latência extra no caminho do sinal.
• [C-1-9] O multiplicador de nível, embora permitido estar no caminho, NÃO PODE introduzir atraso ou latência no caminho do sinal.

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

Se as implementações de dispositivos declararem android.hardware.microphone, mas não forem compatíveis com fontes de áudio não processadas, elas:

• [C-2-1] PRECISA retornar null para o método de API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) para indicar corretamente a falta de suporte.
• [SR] ainda é FORTEMENTE RECOMENDADO para atender ao maior número possível dos requisitos de caminho de indicador da origem de gravação não processada.

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

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

• [C-0-1] PRECISA ser compatível com as Ferramentas para desenvolvedores do Android fornecidas no SDK do Android.

• Android Debug Bridge (adb)

  • [C-0-2] PRECISA oferecer suporte ao adb, conforme documentado no SDK do Android e nos comandos do shell fornecidos no AOSP, que podem ser usados por desenvolvedores de apps, incluindo o dumpsys cmd stats
  • [C-0-11] PRECISA oferecer suporte ao comando shell cmd testharness. O upgrade de implementações de dispositivos de uma versão anterior do Android sem um bloco de dados persistente pode ser isento de C-0-11.
  • [C-0-3] NÃO PODE alterar o formato ou o conteúdo dos eventos do sistema do dispositivo (batterystats , discostats, impressões digitais, gráficosstats, netstats, notificação, procstats) registrados pelo comando dumpsys.
  • [C-0-10] É NECESSÁRIO registrar, sem omissão, e tornar os seguintes eventos acessíveis e disponíveis para o comando do shell cmd stats e a classe da API do sistema StatsManager.
    • ActivityForegroundStateChanged
    • Anomalia detectada
    • AppBreadcrumbReported
    • Ocorreram AppCrash
    • O AppStart ocorreu
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • CobrançaStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • Alarme de ativação ocorreu
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] PRECISA fazer com que o daemon do adb do lado do dispositivo fique inativo por padrão e PRECISA haver um mecanismo acessível ao usuário para ativar o Android Debug Bridge.
  • [C-0-5] PRECISA oferecer suporte ao adb seguro. O Android inclui compatibilidade com o adb seguro. O adb seguro permite o uso do adb em hosts autenticados conhecidos.
  • [C-0-6] PRECISA fornecer um mecanismo que permita a conexão do adb em uma máquina host. Especificamente:

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

  • [C-3-1] PRECISA implementar o adb via rede de área local (como Ethernet ou Wi-Fi).
  • [C-3-2] PRECISA fornecer drivers para o Windows 7, 8 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.

  Se as implementações de dispositivos oferecerem suporte a conexões adb com uma máquina host via Wi-Fi, elas:

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

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

  • [C-5-1] PRECISA ter o método AdbManager#isAdbWifiQrSupported() retornar true.

• Serviço de monitoramento de depuração Dalvik (ddms)

  • [C-0-7] PRECISA oferecer suporte a todos os recursos de ddms, conforme documentado no SDK do Android. Como o ddms usa o adb, o suporte para ddms PRECISA estar inativo por padrão, mas PRECISA ser compatível sempre que o usuário ativar o Android Debug Bridge, conforme descrito acima.
• Macaco
  • [C-0-8] PRECISA incluir o framework Monkey e disponibilizá-lo para uso dos aplicativos.
• SysTrace (em inglês)
  • [C-0-9] PRECISA oferecer suporte à ferramenta Systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão e deve haver um mecanismo acessível ao usuário para ativá-lo.
• Perfetto (link em inglês)
  • [C-SR] É MUITO RECOMENDADO expor um binário /system/bin/perfetto ao usuário do shell. O cmdline está em conformidade com a documentação do Perfeito.
  • [C-SR] O binário do perfetto é FORTEMENTE RECOMENDADO para aceitar como entrada uma configuração de protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (link em inglês).
  • [C-SR] O binário do perfetto é FORTEMENTE RECOMENDADO para escrever como saída um rastro protobuf que esteja em conformidade com o esquema definido na documentação do perfetto (link em inglês).
  • [C-SR] É RECOMENDADO que você forneça, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto (link em inglês).
• Baixa memória assassina
  • [C-0-10] PRECISA gravar um Atom LMK_KILL_OCCURRED_FIELD_NUMBER no registro do StatsD quando um app for encerrado pelo Low Memory Killer.
• Modo arcabouço de testes: se as implementações do dispositivo oferecerem suporte ao comando shell cmd testharness e executarem cmd testharness enable, elas:
  • [C-2-1] PRECISA retornar true para ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] PRECISA implementar o modo de arcabouço de testes, conforme descrito na documentação desse modo.

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

• [C-1-1] PRECISA fornecer uma affordance para o desenvolvedor do app ativar/desativar as camadas de depuração da GPU.
• [C-1-2] PRECISA, quando as camadas de depuração de GPU estiverem ativadas, enumerar as camadas em bibliotecas fornecidas por ferramentas externas (ou seja, que não fazem parte da plataforma ou do pacote do aplicativo) encontradas em aplicativos depuráveis. diretório base para aceitar os métodos de API vkEnumerateInstanceLayerProperties() e vkCreateInstance().

6.2. Opções do desenvolvedor

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

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

• [C-0-1] PRECISA respeitar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar as configurações relacionadas ao desenvolvimento de aplicativos. A implementação upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários as iniciem depois de pressionarem sete (7) vezes em Configurações > Sobre o dispositivo > Número da versão.
• [C-0-2] É NECESSÁRIO ocultar as Opções do desenvolvedor por padrão.
• [C-0-3] PRECISA oferecer 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. PRECISA fornecer um documento ou site visível publicamente que descreva como ativar as Opções do desenvolvedor. Este documento ou site PRECISA estar disponível para links nos documentos do SDK do Android.
• DEVE manter uma notificação visual contínua para o usuário quando as "Opções do desenvolvedor" estiverem ativadas e a segurança do usuário for uma preocupação.
• PODE limitar temporariamente o acesso ao menu "Opções do desenvolvedor" ocultando ou desativando visualmente o menu para evitar distrações em cenários em que a segurança do usuário seja preocupante.

7. Compatibilidade de hardware

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

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

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

• [C-0-2] As definições de classe completas (conforme documentado pelo SDK) para as APIs do componente PRECISAM ser apresentadas.
• [C-0-3] Os comportamentos da API PRECISAM ser implementados como ambiente autônomo de maneira razoável.
• [C-0-4] Os métodos da API PRECISAM retornar valores nulos quando permitido pela documentação do SDK.
• [C-0-5] Os métodos da API PRECISAM retornar implementações independentes de classes em que valores nulos não são permitidos pela documentação do SDK.
• [C-0-6] Os métodos da API NÃO PODEM gerar exceções não documentadas pela documentação do SDK.
• [C-0-7] As implementações de dispositivos PRECISAM relatar informações precisas de configuração de hardware de maneira consistente usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para a mesma impressão digital do build.

Um exemplo típico de cenário em que esses requisitos se aplicam é a API de telefonia. Mesmo em dispositivos não telefônicos, essas APIs precisam ser implementadas como um ambiente autônomo razoável.

7.1. Tela e gráficos

O Android inclui instalações que ajustam automaticamente os recursos de aplicativos e os layouts da interface de forma adequada para o dispositivo, a fim de garantir que aplicativos de terceiros funcionem bem em diversas configurações de hardware. Nas telas compatíveis com Android em que todos os apps de terceiros compatíveis com Android podem ser executados, as implementações de dispositivos PRECISAM implementar corretamente essas APIs e esses comportamentos, conforme detalhado nesta seção.

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

• tamanho diagonal físico. A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
• pontos por polegada (dpi). O número de pixels abrangidos por um intervalo linear horizontal ou vertical de 1”. Quando os valores de dpi estão listados, os dpi horizontal e vertical precisam estar dentro do intervalo.
• proporção. A proporção entre os pixels da dimensão maior e da 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, na sigla em inglês). A unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como: pixels = dps * (densidade/160).

7.1.1. Configuração da tela

7.1.1.1 Tamanho e forma da tela

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

Implementações de dispositivos:

• [C-0-1] PRECISA informar o tamanho correto do layout para a Configuration.screenLayout, conforme definido na documentação do SDK do Android. Especificamente, as implementações de dispositivos PRECISAM informar as dimensões corretas da tela em pixels de densidade independente (dp) lógica, conforme abaixo:

  • Dispositivos com o Configuration.uiMode definido como qualquer valor diferente de UI_MODE_TYPE_WATCH e que informam um tamanho de small para o Configuration.screenLayout PRECISAM ter pelo menos 426 dp x 320 dp.
  • Os dispositivos que informam um tamanho de normal para a Configuration.screenLayout PRECISAM ter pelo menos 480 dp x 320 dp.
  • Os dispositivos que informam um tamanho de large para a Configuration.screenLayout PRECISAM ter pelo menos 640 dp x 480 dp.
  • Os dispositivos que informam um tamanho de xlarge para a Configuration.screenLayout PRECISAM ter pelo menos 960 dp x 720 dp.

• [C-0-2] PRECISA respeitar as inscrições corretamente. afirmou o suporte a tamanhos de tela pelo atributo <supports-screens> no AndroidManifest.xml, conforme descrito na documentação do SDK do Android.

• PODE ter telas compatíveis com Android com cantos arredondados.

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

• [C-1-1] PRECISA garantir que pelo menos um dos requisitos a seguir seja atendido:
• O raio dos cantos arredondados será menor ou igual a 38 dp.

• Quando uma caixa de 15 dp por 15 dp está ancorada em cada canto da tela lógica, pelo menos um pixel de cada caixa fica visível na tela.

• DEVE incluir affordance do usuário para alternar para o modo de exibição com os cantos retangulares.

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

• [C-2-1] PRECISA implementar a versão estável mais recente disponível da API de extensões ou da API secundária a ser usada pela biblioteca do Window Manager Jetpack.

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

• [C-3-1] PRECISA informar a posição, os limites e o estado da articulação ou dobra pelas APIs de extensões ou arquivos secundários para o aplicativo.

Para ver detalhes sobre como implementar corretamente as APIs de arquivo secundário ou de extensão, consulte a documentação pública do Gerenciador de janelas do Jetpack.

7.1.1.2 Proporção da tela

Embora não haja restrições quanto à proporção da tela física para as telas compatíveis com 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 dispositivos 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 destas condições:

  • O app declarou que oferece suporte a uma proporção de tela maior usando o valor de metadados android.max_aspect.
  • O app declara que é redimensionável usando o atributo android:resizeableActivity.
  • O app é direcionado ao nível 24 da API ou mais recente e não declara um android:maxAspectRatio que restrinja a proporção permitida.

• [C-0-2] As implementações de dispositivos 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 ainda mais ao atender a uma destas condições:

  • O app declara que é redimensionável usando o atributo android:resizeableActivity.
  • O app declara um android:minAspectRatio que restringe a proporção permitida.

• [C-0-3] As implementações de dispositivos com Configuration.uiMode definido como UI_MODE_TYPE_WATCH PRECISAM ter um valor de proporção definido como 1,0 (1:1).

7.1.1.3 Densidade da tela

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

• [C-0-1] Por padrão, as implementações de dispositivos PRECISAM informar apenas uma das densidades de framework do Android listadas em DisplayMetrics pela API DENSITY_DEVICE_STABLE, e esse valor NÃO PODE mudar a qualquer momento. No entanto, o dispositivo PODE informar uma densidade arbitrária diferente de acordo com as alterações de configuração de exibição feitas pelo usuário (por exemplo, tamanho da tela) definidas após a primeira inicialização.

• As implementações de dispositivos DEVEM definir a densidade padrão do framework do Android que é numericamente mais próxima da densidade física da tela, a menos que a densidade lógica coloque o tamanho da tela informado abaixo do mínimo compatível. Se a densidade do framework padrão do Android que é numericamente mais próxima da densidade física resultar em um tamanho de tela menor que o menor tamanho de tela compatível compatível (320 dp de largura), as implementações de dispositivos DEVEM informar a próxima densidade de framework padrão do Android mais baixa.

Se houver uma affordance para mudar o tamanho de exibição do dispositivo:

• [C-1-1] O tamanho de exibição NÃO PODE ser dimensionado maior que 1,5 vez a densidade nativa nem produzir uma dimensão mínima efetiva menor que 320 dp (equivalente ao qualificador de recurso sw320dp), o que ocorrer primeiro.
• [C-1-2] O tamanho de exibição NÃO PODE ser dimensionado menor que 0,85 vezes a densidade nativa.
• Para garantir boa usabilidade e tamanhos de fonte consistentes, é RECOMENDADO que as seguintes opções de dimensionamento de exibição nativa sejam fornecidas (obedecendo aos limites especificados acima)
• Pequeno: 0,85x
• Padrão: 1x (escala de display nativa)
• Grande: 1,15x
• Maior: 1,3x
• Maior 1,45x

7.1.2. Métricas de display

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

• [C-1-1] É NECESSÁRIO informar os valores corretos para todas as métricas de display compatíveis com Android definidas na API android.util.DisplayMetrics.

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

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

7.1.3. Orientação da tela

Implementações de dispositivos:

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

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

• [C-1-1] PRECISA oferecer suporte à orientação dinâmica dos aplicativos nas orientações 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] NÃO PODE mudar o tamanho ou a densidade da tela informada ao mudar a orientação.
• PODE selecionar a orientação retrato ou paisagem como padrão.

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

OpenGL ES 7.1.4.1

Implementações de dispositivos:

• [C-0-1] PRECISA identificar corretamente as versões do OpenGL ES com suporte (1.1, 2.0, 3.0, 3.1, 3.2) usando as APIs gerenciadas (como o método GLES10.getString()) e as APIs nativas.
• [C-0-2] PRECISA incluir suporte para todas as APIs gerenciadas e nativas correspondentes para cada versão do OpenGL ES que elas identificaram com suporte.

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

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

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

• [C-2-1] PRECISA gerar relatórios pelas APIs gerenciadas e nativas do OpenGL ES sobre qualquer outra extensão do OpenGL ES implementada e NÃO PRECISA informar strings de extensão incompatíveis.
• [C-2-2] PRECISA oferecer suporte às extensões EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable e EGL_ANDROID_GLES_layers.
• [C-SR] É FORTEMENTE RECOMENDADO oferecer suporte às extensões EGL_KHR_partial_update e OES_EGL_image_external.
• DEVE gerar relatórios com precisão usando o método getString(), qualquer formato de compactação de textura compatível, que geralmente é específico do fornecedor.

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

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

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

• [C-4-1] PRECISA ser compatível com o pacote de extensão OpenGL ES para Android na íntegra.

Se as implementações de dispositivos oferecerem suporte integral ao Pacote de extensões para Android (link em inglês) do OpenGL ES, elas:

• [C-5-1] PRECISA identificar o suporte pela flag de recurso android.hardware.opengles.aep.

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

• [C-6-1] também PRECISA oferecer suporte à extensão EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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

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

• [SR] É FORTEMENTE RECOMENDADO a inclusão de suporte ao Vulkan 1.1.

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

• DEVE incluir suporte para Vulkan 1.1.

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

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

• [C-1-1] PRECISA informar o valor inteiro correto com as flags de recurso android.hardware.vulkan.level e android.hardware.vulkan.version.
• [C-1-2] PRECISA enumerar pelo menos um VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] PRECISA implementar totalmente as APIs do Vulkan 1.0 para cada VkPhysicalDevice enumerado.
• [C-1-4] PRECISA enumerar as camadas, contidas em bibliotecas nativas chamadas libVkLayer*.so, no diretório da biblioteca nativa do pacote do app, usando as APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
• [C-1-5] NÃO PODE enumerar as camadas fornecidas por bibliotecas fora do pacote do aplicativo nem fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o atributo android:debuggable definido como true.
• [C-1-6] PRECISA informar todas as strings de extensão compatíveis com as APIs nativas do Vulkan e, por outro lado, NÃO PODE reportar strings de extensão que não têm suporte correto.
• [C-1-7] PRECISA oferecer suporte às extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
• [C-1-8] PRECISA informar a versão máxima dos testes de dEQP do Vulkan compatíveis com a flag de recurso android.software.vulkan.deqp.level.
• [C-1-9] PRECISA ser compatível com a versão 132317953 (a partir de 1o de março de 2019), conforme informado na flag de recurso android.software.vulkan.deqp.level.
• [C-1-10] PRECISA passar em todos os testes de dEQP do Vulkan nas listas de teste entre a versão 132317953 e a versão especificada na flag de recurso android.software.vulkan.deqp.level.
• [C-SR] É FORTEMENTE RECOMENDADO para oferecer suporte às extensões VK_KHR_driver_properties e VK_GOOGLE_display_timing.

Se as implementações de dispositivos não incluírem suporte para o Vulkan 1.0, elas:

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

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

• [C-3-1] PRECISA expor o suporte ao semáforo externo e aos tipos de identificador SYNC_FD e à extensão VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] As implementações de dispositivos PRECISAM ser compatíveis com o Android RenderScript, conforme detalhado na documentação do SDK do Android.

7.1.4.4 Aceleração gráfica 2D

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

Implementações de dispositivos:

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

O Android inclui um objeto TextureView que permite aos desenvolvedores integrar diretamente texturas do 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 ter um comportamento consistente com a implementação upstream do Android.

Telas de ampla gama 7.1.4.5

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

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

Por outro lado, se as implementações de dispositivos não forem compatíveis com telas de ampla gama, elas:

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

7.1.5. Modo de compatibilidade de aplicativo legado

O Android especifica um "modo de compatibilidade" em que o framework opera de forma "normal" Modo de tamanho de tela equivalente (320 dp de largura) para usar aplicativos legados não desenvolvidos para versões antigas do Android que são anteriores à independência de tamanho de tela.

7.1.6. Tecnologia da tela

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

Todas as telas compatíveis com a implementação do dispositivo:

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

7.1.7. Telas secundárias

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

Se as implementações de dispositivos forem compatíveis com uma tela externa por uma conexão com fio, sem fio ou de tela adicional incorporada, elas:

• [C-1-1] PRECISA implementar o serviço do sistema e a API do DisplayManager, conforme descrito na documentação do SDK do Android.

7.2. Dispositivos de entrada

Implementações de dispositivos:

• [C-0-1] PRECISA incluir um mecanismo de entrada, como uma tela touchscreen ou navegação sem toque, para navegar entre os elementos da interface.

7.2.1. Teclado

Se as implementações de dispositivos incluírem suporte para aplicativos Editor de método de entrada (IME) de terceiros, elas:

• [C-1-1] PRECISA declarar a flag de recurso android.software.input_methods.
• [C-1-2] PRECISA implementar totalmente Input Management Framework
• [C-1-3] PRECISA ter um teclado de software pré-instalado.

Implementações do dispositivo: * [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.proporcionado (QWERTY ou 12 teclas). * DEVE incluir implementações adicionais de teclado de software. * PODE incluir um teclado físico.

7.2.2. Navegação sem toque

O Android oferece suporte a botões direcional, trackball e wheel como mecanismos para navegação sem toque.

Implementações de dispositivos:

• [C-0-1] PRECISA informar o valor correto para android.content.res.Configuration.navigation.

Se as implementações de dispositivos não tiverem navegações sem toque, elas:

• [C-1-1] PRECISA fornecer um mecanismo de interface do usuário alternativo razoável para a seleção e edição de texto, compatível com os Mecanismos de gerenciamento de entradas. A implementação upstream de código aberto do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação sem toque.

7.2.3. Teclas de navegação

As funções Home, Recents 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, as implementações de dispositivos:

• [C-0-1] PRECISA oferecer uma funcionalidade do usuário para iniciar apps instalados que tenham uma atividade com a <intent-filter> definida com ACTION=MAIN e CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER para implementações de dispositivos de televisão. A função Home DEVE ser o mecanismo para essa affordance do usuário.
• DEVE fornecer botões para as funções Recentes e Voltar.

Se as funções Home, Recents ou Back forem fornecidas, elas:

• [C-1-1] PRECISA ser acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou fazer gesto) quando qualquer uma delas estiver acessível.
• [C-1-2] PRECISA fornecer uma indicação clara de qual ação acionaria cada função. Um ícone visível impresso no botão, um ícone de software na parte da barra de navegação da tela ou um guia para o usuário em um fluxo de demonstração passo a passo durante a configuração inicial são exemplos dessa indicação.

Implementações de dispositivos:

• [SR] é MUITO RECOMENDADO não fornecer o mecanismo de entrada para a função de menu, já que ela foi descontinuada e substituída pela barra de ações desde o Android 4.0.

Se as implementações de dispositivos fornecerem a função de menu, elas:

• [C-2-1] PRECISA exibir o botão flutuante de ação sempre que o pop-up desse menu não estiver vazio e a barra de ações estiver visível.
• [C-2-2] NÃO É POSSÍVEL modificar a posição do pop-up de estouro de ação exibido ao selecionar o botão flutuante na barra de ações. No entanto, PODE renderizar o pop-up de ação flutuante em uma posição modificada na tela quando ele é exibido selecionando a função "Menu".

Se as implementações de dispositivos não fornecerem a função Menu, para compatibilidade com versões anteriores, elas:

• [C-3-1] PRECISA 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 deve ser acessível, a menos que esteja oculta com outras funções de navegação.

Se as implementações de dispositivos fornecerem a função Assistente, elas:

• [C-4-1] PRECISA tornar a função Assistente acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou fazer um gesto) quando outras teclas de navegação estiverem acessíveis.
• [SR] É RECOMENDADO usar a função "HOME" e mantê-la pressionada como essa interação designada.

Se as implementações do dispositivo usarem uma parte distinta da tela para exibir as teclas de navegação, elas:

• [C-5-1] As teclas de navegação PRECISAM usar uma parte distinta da tela, não disponível para aplicativos, e NÃO PODEM obscurecer ou interferir 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] PRECISA respeitar as flags definidas pelo app com o método View.setSystemUiVisibility() da API para que essa parte distinta da tela (também conhecida como a barra de navegação) fique ocultada, conforme documentado no SDK.

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() só pode ser usado para informar a área de reconhecimento de gestos do Google Home.
• [C-6-2] Gestos que começam em um retângulo de exclusão conforme fornecido pelo aplicativo em primeiro plano via View#setSystemGestureExclusionRects(), mas fora de WindowInsets#getMandatorySystemGestureInsets(), NÃO PODEM ser interceptados para a função de navegação, desde que o retângulo de exclusão seja permitido dentro do limite de exclusão máximo, conforme especificado na documentação de View#setSystemGestureExclusionRects().
• [C-6-3] PRECISA enviar ao app em primeiro plano um evento MotionEvent.ACTION_CANCEL quando os toques começarem a ser interceptados por um gesto do sistema, se o app em primeiro plano tiver recebido um evento MotionEvent.ACTION_DOWN.
• [C-6-4] PRECISA fornecer uma funcionalidade do usuário para alternar para uma navegação baseada em botões na tela (por exemplo, em "Configurações").
• DEVE fornecer a função de início ao deslizar para cima a partir da borda inferior da orientação atual da tela.
• DEVE fornecer a função "Recentes" deslizando para cima e pressionando antes de soltar, na mesma área que o gesto "Início".
• Os gestos que começam em WindowInsets#getMandatorySystemGestureInsets() NÃO DEVEM ser afetados por retângulos de exclusão fornecidos pelo aplicativo em primeiro plano via View#setSystemGestureExclusionRects().

Se uma função de navegação for fornecida de qualquer lugar das bordas esquerda e direita da orientação atual da tela:

• [C-7-1] A função de navegação PRECISA ser "Voltar" e fornecida como um gesto de deslizar das bordas esquerda e direita da orientação atual da tela.
• [C-7-2] Se os painéis do sistema deslizável personalizados forem fornecidos nas bordas esquerda ou direita, eles PRECISAM ser colocados no 1/3 da parte de cima da tela com uma indicação visual clara e persistente de que arrastar para dentro invocaria os painéis mencionados acima e, portanto, não com o botão "Voltar". Um painel do sistema PODE ser configurado por um usuário de modo que ele fique abaixo do 1/3 superior das bordas da tela, mas o painel do sistema NÃO PODE usar mais do que 1/3 das bordas.
• [C-7-3] Quando o app em primeiro plano tem as flags View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY definidas, o gesto de deslizar das bordas PRECISA se comportar como implementado no AOSP, o 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 de sistema deslizantes personalizados PRECISAM ficar ocultos até que o usuário exiba as barras de sistema (ou seja, a barra de navegação e de status), conforme implementado no AOSP.

7.2.4. Entrada por tela touch

O Android é compatível com diversos sistemas de entrada de ponteiro, como touchscreens, touchpads e dispositivos de entrada por toque falsos. As implementações de dispositivos baseadas em touchscreen são associadas a uma tela para que o usuário tenha a impressão de manipular diretamente os itens na tela. Como o usuário está diretamente tocando na tela, o sistema não requer affordances adicionais para indicar os objetos que estão sendo manipulados.

Implementações de dispositivos:

• DEVE ter um sistema de entrada de ponteiro de algum tipo (semelhante ao mouse ou ao toque).
• DEVE dar suporte a ponteiros totalmente rastreados de forma independente.

Se as implementações de dispositivos incluírem uma tela touchscreen (toque único ou melhor) em uma tela principal compatível com Android, elas:

• [C-1-1] É NECESSÁRIO informar TOUCHSCREEN_FINGER no campo da API Configuration.touchscreen.
• [C-1-2] É NECESSÁRIO informar as flags de recurso android.hardware.touchscreen e android.hardware.faketouch.

Se as implementações de dispositivos incluírem uma tela touchscreen que possa rastrear mais de um único toque em uma tela principal compatível com Android, elas:

• [C-2-1] PRECISA informar as flags de recurso apropriadas android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand correspondentes ao tipo de tela touchscreen específica do dispositivo.

Se as implementações de dispositivos dependerem de um dispositivo de entrada externo, como mouse ou trackball (ou seja, sem tocar diretamente na tela) para entrada em uma tela principal compatível com Android e atenderem aos requisitos de toque falso na seção 7.2.5, elas:

• [C-3-1] NÃO É POSSÍVEL reportar uma flag de recurso que comece com android.hardware.touchscreen.
• [C-3-2] PRECISA informar apenas android.hardware.faketouch.
• [C-3-3] É NECESSÁRIO informar TOUCHSCREEN_NOTOUCH no campo da API Configuration.touchscreen.

7.2.5. Entrada de toque falsa

A interface de toque simulada fornece um sistema de entrada do usuário que se aproxima de um subconjunto de recursos da tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela faz uma aproximação do toque, mas exige que o usuário aponte ou concentre-se primeiro e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse baseado em 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 de alta fidelidade sem toque (baseado no ponteiro), como um mouse ou trackpad que pode emular adequadamente a entrada baseada em toque (incluindo suporte básico a gestos) e indica que o dispositivo oferece suporte a um subconjunto emulado da funcionalidade de tela touchscreen.

Se as implementações de dispositivos não incluírem uma tela sensível ao toque, mas incluírem outro sistema de entrada de ponteiro que querem disponibilizar, elas:

• DEVE declarar suporte à flag de recurso android.hardware.faketouch.

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

• [C-1-1] PRECISA informar as posições absolutas da tela X e Y da localização do ponteiro e mostrar um ponteiro visual na tela.
• [C-1-2] PRECISA informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre no ponteiro que desce ou sobe na tela.
• [C-1-3] PRECISA oferecer suporte ao ponteiro para cima e para baixo em um objeto na tela, o que permite que os usuários emulem o toque em um objeto na tela.
• [C-1-4] PRECISA oferecer suporte ao ponteiro para baixo, para cima, para baixo e para cima no mesmo lugar em um objeto na tela dentro de um limite de tempo, o que permite que os usuários emulem toques duplos em um objeto na tela.
• [C-1-5] PRECISA oferecer suporte ao ponteiro para baixo em um ponto arbitrário na tela, o ponteiro se mover para qualquer outro ponto arbitrário na tela seguido por um ponteiro para cima, o que permite que os usuários simulem uma ação de arrastar por toque.
• [C-1-6] PRECISA oferecer suporte ao ponteiro para baixo e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, apontem para cima na tela, o que permite que os usuários arrastem um objeto na tela.

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

• [C-2-1] PRECISA declarar compatibilidade com android.hardware.faketouch.
• [C-2-2] PRECISA oferecer suporte ao rastreamento distinto de duas ou mais entradas de ponteiro independentes.

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

• [C-3-1] PRECISA declarar compatibilidade com android.hardware.faketouch.
• [C-3-2] PRECISA oferecer suporte ao rastreamento distinto de cinco (rastreamento de uma mão de dedos) ou mais entradas de ponteiro de forma totalmente independente.

7.2.6. Suporte a controles de jogos

7.2.6.1. Mapeamentos de botões

Implementações de dispositivos:

• [C-1-1] PRECISA ser capaz de mapear eventos HID para as constantes InputEvent correspondentes, conforme listado nas tabelas abaixo. A implementação upstream do Android atende a esse requisito.

Se as implementações de dispositivo incorporarem um controlador ou enviarem com um controlador separado na caixa, que forneça meios de inserir todos os eventos listados nas tabelas abaixo, elas:

• [C-2-1] PRECISA declarar a flag de recurso android.hardware.gamepad.

Botão	Uso de HID2	Botão do Android
R1	0x09 0x0001	KEYCODE_BOT_A (96)
B1	0x09 0x0002	KEYCODE_BOT_B (97)
X1	0x09 0x0004	KEYCODE_BOT_X (99)
A1	0x09 0x0005	KEYCODE_BOT_Y (100)
Botão direcional para cima1 Botão direcional para baixo1	0x01 0x00393	Eixo_HAT_Y4
Botão direcional esquerdo1 Botão direcional para a direita1	0x01 0x00393	Eixo_HAT_X4
Botão do ombro esquerdo1	0x09 0x0007	KEYCODE_Button_L1 (102)
Botão do ombro direito1	0x09 0x0008	KEYCODE_Button_R1 (103)
Clique com o botão esquerdo do mouse1	0x09 0x000E	KEYCODE_BOT_THUMBL (106)
Clique com o botão direito do mouse1	0x09 0x000F	KEYCODE_Button_THUMBR (107)
Página inicial1	0x0c 0x0223	KEYCODE_HOME (3)
Voltar1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Os usos de HID acima precisam ser declarados em uma CA de Gamepad (0x01 0x0005).

3 Este uso deve 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 na direção oposta do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima está sendo pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e para a esquerda estão sendo pressionadas.

4 MotionEvent

Controles analógicos1	Uso de HID	Botão do Android
Gatilho esquerdo	0x02 0x00C5	AXIS_LTRIGGER
Gatilho correto	0x02 0x00C4	EIXO_RTRIGGER
Joystick esquerdo	0x01 0x0030 0x01 0x0031	Eixo X Eixo_Y
Joystick direito	0x01 0x0032 0x01 0x0035	Eixo Z AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

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

7,3 Sensores

Se as implementações do dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, a implementação do dispositivo PRECISA implementar essa API, conforme descrito na documentação do SDK do Android e na documentação do Android Open Source sobre sensores.

Implementações de dispositivos:

• [C-0-1] PRECISA informar com precisão a presença ou ausência de sensores de acordo com a classe android.content.pm.PackageManager.
• [C-0-2] PRECISA retornar uma lista precisa de sensores com suporte usando SensorManager.getSensorList() e métodos semelhantes.
• [C-0-3] PRECISA se comportar de maneira razoável com todas as outras APIs de sensores. Por exemplo, retornar true ou false conforme apropriado quando os aplicativos tentarem registrar listeners, não chamar listeners quando os sensores correspondentes não estiverem presentes etc.

Se as implementações de dispositivos incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, elas:

• [C-1-1] PRECISA informar todas as medições do sensor usando os valores relevantes do Sistema Internacional de Unidades (métrica) para cada tipo de sensor, conforme definido na documentação do SDK do Android.
• [C-1-2] PRECISA informar os dados do sensor com latência máxima de 100 milissegundos + 2 * sample_time para o caso de um stream do sensor com latência máxima solicitada de 0 ms quando o processador do aplicativo estiver ativo. Esse atraso não inclui atrasos de filtragem.
• [C-1-3] PRECISA informar a primeira amostra do sensor em até 400 milissegundos + 2 * sample_time do sensor que está sendo ativado. É aceitável que essa amostra tenha uma precisão de 0.
• [C-1-4] Para que qualquer API indicada pela documentação do SDK do Android seja um sensor contínuo, as implementações de dispositivos PRECISAM fornecer continuamente amostras de dados periódicas que DEVEM ter uma instabilidade inferior a 3%. Nesse caso, a instabilidade é definida como o desvio padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.
• [C-1-5] PRECISA garantir que o fluxo de eventos do sensor NÃO possa impedir que a CPU do dispositivo entre em um estado de suspensão ou desperte desse estado.
• [C-1-6] PRECISA informar a hora do evento em nanossegundos, conforme definido na documentação do SDK do Android, representando a hora em que o evento aconteceu e sincronizado com o relógio SystemClock.elapsedRealtimeNano().
• [C-SR] É FORTEMENTE RECOMENDADO que tenham erros de sincronização de carimbo de data/hora abaixo de 100 milissegundos e DEVEM ter erros de sincronização de carimbo de data/hora abaixo de 1 milissegundo.
• Quando vários sensores estiverem ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia relatado de cada sensor individual.

A lista acima não é abrangente. o comportamento documentado do SDK do Android e da documentação de código aberto do Android em sensores é considerado oficial.

Se as implementações de dispositivos incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, elas:

• [C-1-6] PRECISA definir uma resolução diferente de zero para todos os sensores e informar o valor pelo método Sensor.getResolution() da API.

Alguns tipos de sensores são compostos, o que significa que podem ser derivados de dados fornecidos por um ou mais sensores. (Os exemplos incluem o sensor de orientação e o sensor de aceleração linear.)

Implementações de dispositivos:

• DEVE implementar esses tipos de sensores quando incluem os pré-requisitos de sensores físicos, conforme descrito nos tipos de sensor.

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

• [C-2-1] PRECISA implementar o sensor, conforme descrito na documentação do Android Open Source sobre sensores compostos.

Se as implementações do dispositivo incluem um tipo específico de sensor que tem uma API correspondente para desenvolvedores de terceiros e o sensor informa apenas um valor, as implementações do dispositivo:

• [C-3-1] PRECISA definir a resolução como 1 para o sensor e informar o valor pelo método da API Sensor.getResolution().

Se as implementações do dispositivo incluírem um tipo de sensor específico compatível com SensorAdditionalInfo#TYPE_VEC3_CALIBRATION e o sensor for exposto a desenvolvedores terceirizados, elas:

• [C-4-1] NÃO PODE incluir parâmetros de calibração fixos e determinados pela fábrica nos dados fornecidos.

Se as implementações do dispositivo incluírem uma combinação de acelerômetro de três eixos, sensor de giroscópio de três eixos ou sensor magnetômetro, elas serão:

• [C-SR] MUITO RECOMENDADO para garantir que o acelerômetro, o giroscópio e o magnetômetro tenham uma posição relativa fixa, de modo que, se o dispositivo for transformável (por exemplo, dobrável), os eixos do sensor permaneçam alinhados e consistentes com o sistema de coordenadas do sensor em todos os estados de transformação possíveis.

7.3.1. Acelerômetro

Implementações de dispositivos:

• [C-SR] É MUITO RECOMENDADO incluir um acelerômetro de três eixos.

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

• [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
• [C-1-2] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER.
• [C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android.
• [C-1-4] PRECISA ser capaz de medir a queda livre até quatro vezes a gravidade(4g) ou mais em qualquer eixo.
• [C-1-5] PRECISA ter uma resolução de pelo menos 12 bits.
• [C-1-6] PRECISA ter um desvio padrão não superior a 0,05 m/s^, em que o desvio padrão deve ser calculado por eixo, em amostras coletadas durante um período de pelo menos 3 segundos com a taxa de amostragem mais rápida.
• [SR] são altamente RECOMENDADOS para implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
• [SR] é MUITO RECOMENDADO para implementar e informar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. É MUITO RECOMENDADO que os dispositivos Android atendam a esse requisito para que possam fazer upgrade para a versão futura da plataforma, em que isso pode se tornar OBRIGATÓRIO.
• 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 relatar eventos de até pelo menos 200 Hz.
• DEVE ter uma resolução de pelo menos 16 bits.
• DEVE ser calibrado durante o uso se as características mudarem ao longo do ciclo de vida e compensadas, além de preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• DEVE ser compensado por temperatura.

Se as implementações 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 deles DEVE ter menos de 2 mW e 0,5 mW quando o dispositivo estiver em uma condição dinâmica ou estática.

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

• [C-3-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR] É MUITO RECOMENDADO a implementação do sensor composto TYPE_GAME_ROTATION_VECTOR.

Se as implementações de dispositivos incluírem um acelerômetro de três eixos, um sensor de giroscópio de três eixos e um sensor magnetômetro, elas:

• [C-4-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

7.3.2. Magnetômetro

Implementações de dispositivos:

• [C-SR] É MUITO RECOMENDADO incluir um magnetômetro de três eixos (bússola).

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

• [C-1-1] PRECISA implementar o sensor TYPE_MAGNETIC_FIELD.
• [C-1-2] PRECISA relatar eventos com uma frequência de pelo menos 10 Hz e DEVE relatar eventos de até 50 Hz.
• [C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android.
• [C-1-4] PRECISA ser capaz de medir entre -900 μT e +900 μT em cada eixo antes da saturação.
• [C-1-5] PRECISA ter um valor de compensação do ferro rígido menor que 700 μT e PRECISA ter um valor inferior a 200 μT. Para isso, o magnetômetro precisa ficar longe dos campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímãs).
• [C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 μT.
• [C-1-7] PRECISA oferecer suporte à calibragem on-line e à compensação da polarização de ferro rígido e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• [C-1-8] PRECISA ter a compensação de ferro suave aplicada. A calibração pode ser feita durante o uso ou durante a produção do dispositivo.
• [C-1-9] PRECISA ter um desvio padrão, calculado por eixo, em amostras coletadas durante um período de pelo menos 3 segundos e com a taxa de amostragem mais rápida, não superior a 1,5 μT; DEVE ter um desvio padrão menor ou igual a 0,5 μT.
• [C-SR] É MUITO RECOMENDADO a implementação do sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se as implementações de dispositivos incluírem um magnetômetro de três eixos, um sensor de acelerômetro e um sensor de giroscópio de três eixos, elas:

• [C-2-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

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

• PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

• [C-3-1] PRECISA consumir menos de 10 mW.
• DEVE consumir menos de 3 mW quando o sensor estiver registrado no modo de lote a 10 Hz.

7.3.3. GPS

Implementações de dispositivos:

• [C-SR] É FORTEMENTE RECOMENDADO a inclusão de um receptor GPS/GNSS.

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

• [C-1-1] PRECISA oferecer suporte a saídas de local a uma taxa de pelo menos 1 Hz quando solicitado por LocationManager#requestLocationUpdate.
• [C-1-2] PRECISA determinar o local em condições de céu aberto (sinais fortes, multicaminho insignificante, HDOP < 2) em até 10 segundos (tempo rápido para a primeira correção) quando conectado a uma conexão de Internet com velocidade de dados de 0,5 Mbps ou mais rápida. Esse requisito normalmente é atendido com o uso de alguma forma de técnica de GPS/GNSS assistido ou previsto 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 efêmeras/relógios de satélite).
  • [C-1-6] Após fazer esse cálculo, as implementações de dispositivos PRECISAM determinar a localização dele em céu aberto em até cinco segundos quando as solicitações de localização forem reiniciadas, até uma hora após o cálculo inicial, mesmo quando a solicitação seguinte for feita sem uma conexão de dados e/ou após um ciclo de energia.

• Em condições de céu aberto após determinar o local, enquanto está estacionário ou em movimento com menos de 1 metro por segundo ao quadrado de aceleração:

  • [C-1-3] PRECISA determinar a localização dentro de 20 metros e a velocidade dentro de 0, 5 metro por segundo, pelo menos 95% do tempo.
  • [C-1-4] PRECISA rastrear e informar simultaneamente por GnssStatus.Callback pelo menos oito satélites de uma constelação.
  • DEVE ser capaz de rastrear simultaneamente pelo menos 24 satélites, de várias constelações (por exemplo, GPS + pelo menos um Glonass, Beidou, Galileo).
  • [C-SR] É FORTEMENTE RECOMENDADO para continuar a fornecer saídas de localização de GPS/GNSS normais por meio de APIs do provedor de localização de GNSS durante uma chamada telefônica de emergência.
  • [C-SR] É FORTEMENTE RECOMENDADO para informar medições de GNSS de todas as constelações rastreadas (conforme relatado em mensagens GnssStatus), exceto SBAS.
  • [C-SR] É MUITO RECOMENDADO que você informe o AGC e a frequência de medição do GNSS.
  • [C-SR] É FORTEMENTE RECOMENDADO para informar todas as estimativas de precisão (incluindo rumo, velocidade e vertical) como parte de cada localização do GPS/GNSS.
  • [C-SR] É FORTEMENTE RECOMENDADO a informar medições do GNSS assim que elas forem encontradas, mesmo que uma localização calculada com o GPS/GNSS ainda não tenha sido informada.
  • [C-SR] É RECOMENDADO para informar pseudodistâncias e pseudodistâncias de GNSS que, em condições de céu aberto após determinar o local, enquanto estacionárias ou em movimento com menos de 0, 2 metro por segundo ao quadrado de aceleração, são suficientes para calcular uma posição dentro de 20 metros e velocidade dentro de 0, 2 metro por segundo, pelo menos 95% do tempo.

7.3.4. Giroscópio

Implementações de dispositivos:

• [C-SR] É MUITO RECOMENDADO incluir um sensor de giroscópio.

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

• [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
• [C-1-2] PRECISA implementar o sensor TYPE_GYROSCOPE e é MUITO RECOMENDADO para implementar também 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] PRECISA ser compensado pela temperatura.
• [C-1-6] PRECISA ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• [C-1-7] PRECISA ter uma variação não superior a 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar de acordo com a taxa de amostragem, mas PRECISA ser limitada por esse valor. Em outras palavras, se você medir a variância do giroscópio a uma taxa de amostragem de 1 Hz, ela DEVE ser no máximo 1e-7 rad^2/s^2.
• [SR] O erro de calibração é RECOMENDADO tanto que seja menor que 0,01 rad/s quando o dispositivo estiver parado na temperatura ambiente.
• DEVE relatar eventos de até pelo menos 200 Hz.

Se as implementações de dispositivos incluírem um giroscópio de três eixos, um sensor de acelerômetro e um sensor de magnetômetro, elas:

• [C-2-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

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

• [C-3-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [C-SR] É MUITO RECOMENDADO a implementação do sensor composto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

Implementações de dispositivos:

• [C-SR] É MUITO RECOMENDADO incluir um barômetro (sensor de pressão do ar ambiente).

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

• [C-1-1] PRECISA implementar e informar o sensor TYPE_PRESSURE.
• [C-1-2] PRECISA entregar eventos com frequência de 5 Hz ou mais.
• [C-1-3] PRECISA ser compensado pela temperatura.
• [SR] MUITO RECOMENDADO para informar medições de pressão no intervalo de 300 hPa a 1.100 hPa.
• DEVE ter uma precisão absoluta de 1hPa.
• DEVE ter uma precisão relativa de 0,12 hPa em uma faixa de 20 hPa (equivalente a uma precisão de ~1 m em uma mudança de ~200 m no nível do mar).

7.3.6. Termômetro

Se as implementações do dispositivo incluírem um termômetro ambiente (sensor de temperatura), elas:

• [C-1-1] PRECISA definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura ambiente, que PRECISA medir em graus Celsius a temperatura ambiente (da cabine do usuário/ambiente) onde o usuário está interagindo com o dispositivo.

Se as implementações do dispositivo incluírem um sensor de termômetro que mede uma temperatura diferente da temperatura ambiente, como a temperatura da CPU, elas:

• [C-2-1] NÃO PODE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para o sensor de temperatura.

7.3.7. Fotômetro

• As implementações de dispositivos PODEM incluir um fotômetro (sensor de luz ambiente).

7.3.8. Sensor de proximidade

• As implementações de dispositivos podem incluir um sensor de proximidade.

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

• [C-1-1] PRECISA medir a proximidade de um objeto na mesma direção que a tela. Ou seja, o sensor de proximidade PRECISA estar orientado para detectar objetos próximos à tela, já que a intenção principal desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se as implementações do dispositivo incluírem um sensor de proximidade com qualquer outra orientação, ele NÃO PODERÁ ser acessível por essa API.
• [C-1-2] PRECISA ter 1 bit de precisão 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] PRECISA identificar o recurso pela flag de recurso android.hardware.sensor.hifi_sensors.

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

• [C-2-1] PRECISA ter um sensor TYPE_ACCELEROMETER que:

  • PRECISA ter um intervalo de medição entre -8 g e + 8 g, e é MUITO RECOMENDADO que tenha um intervalo de medição entre -16 g e + 16 g.
  • PRECISA ter uma resolução de medição de pelo menos 2.048 LSB/g.
  • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais. DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
  • PRECISA ter um ruído de medição menor ou igual a 400 μg/✓Hz.
  • PRECISA implementar uma forma sem ativação deste sensor, com uma capacidade de armazenamento em buffer de pelo menos 3.000 eventos de sensor.
  • PRECISA ter um consumo de energia em lote não inferior a 3 mW.
  • [C-SR] É MUITO RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
  • DEVE ter uma aceleração aleatória de caminhada com menos de 30 μg ≧Hz testada à temperatura ambiente.
  • DEVE ter uma mudança de viés x temperatura de ≤ +/- 1 mg/°C.
  • DEVE ter uma não linearidade de linha com melhor ajuste de ≤ 0,5%, e a mudança de sensibilidade x temperatura de ≤ 0,03%/C°.
  • DEVE ter sensibilidade entre eixos de < 2,5 % e variação da sensibilidade entre eixos < Faixa de temperatura de funcionamento do dispositivo de 0,2%.

• [C-2-2] PRECISA ter um TYPE_ACCELEROMETER_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_ACCELEROMETER.

• [C-2-3] PRECISA ter um sensor TYPE_GYROSCOPE que:

  • PRECISA ter um intervalo de medição entre -1.000 e +1.000 dps.
  • PRECISA ter uma resolução de medida de pelo menos 16 LSB/dps.
  • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais. DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
  • PRECISA ter um ruído de medição não superior a 0,014°/s/concordate.
  • [C-SR] É MUITO RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
  • DEVE ter uma taxa de caminhada aleatória com menos de 0,001 °/s cione Hz testada à temperatura ambiente.
  • DEVE ter uma mudança de viés x temperatura ≤ +/- 0,05 °/ s / °C.
  • DEVE ter uma mudança de sensibilidade x temperatura de ≤ 0,02% / °C.
  • DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,2%.
  • DEVE ter uma densidade de ruído menor ou igual a 0,007 °/s/shaped Hz.
  • DEVE ter um erro de calibração inferior a 0,002 rad/s na faixa de temperatura de 10 ~ 40 °C quando o dispositivo estiver parado.
  • DEVE ter sensibilidade à g menor que 0,1°/s/g.
  • DEVE ter sensibilidade entre eixos de < 4,0 % e variação de sensibilidade entre eixos < Faixa de temperatura de funcionamento do dispositivo de 0,3%.

• [C-2-4] PRECISA ter um TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_GYROSCOPE.

• [C-2-5] PRECISA ter um sensor TYPE_GEOMAGNETIC_FIELD que:

  • PRECISA ter um intervalo de medição entre -900 e +900 μT.
  • PRECISA ter uma resolução de medida de pelo menos 5 LSB/uT.
  • PRECISA ter uma frequência de medição mínima de 5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 50 Hz ou mais.
  • PRECISA ter um ruído de medição menor que 0,5 uT.

• [C-2-6] PRECISA ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_GEOMAGNETIC_FIELD, além de:

  • PRECISA implementar uma forma sem ativação deste sensor, com uma capacidade de armazenamento em buffer de pelo menos 600 eventos de sensor.
  • [C-SR] É FORTEMENTE RECOMENDADO que tenha um espectro de ruído branco de 1 Hz a 10 Hz, no mínimo, quando a taxa do relatório for de 50 Hz ou superior.

• [C-2-7] PRECISA ter um sensor TYPE_PRESSURE que:

  • PRECISA ter um intervalo de medição entre 300 e 1.100 hPa.
  • PRECISA ter uma resolução de medida de pelo menos 80 LSB/hPa.
  • PRECISA ter uma frequência de medição mínima de 1 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 10 Hz ou mais.
  • PRECISA ter um ruído de medição não superior a 2 Pa/cioneHz.
  • PRECISA implementar uma forma sem ativação deste sensor, com uma capacidade de armazenamento em buffer de pelo menos 300 eventos de sensor.
  • PRECISA ter um consumo de energia em lote não inferior a 2 mW.
• [C-2-8] PRECISA ter um sensor TYPE_GAME_ROTATION_VECTOR.
• [C-2-9] PRECISA ter um sensor TYPE_SIGNIFICANT_MOTION que:
  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.
• [C-2-10] PRECISA ter um sensor TYPE_STEP_DETECTOR que:
  • PRECISA implementar uma forma sem ativação deste sensor, com uma capacidade de armazenamento em buffer de pelo menos 100 eventos de sensor.
  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.
  • PRECISA ter um consumo de energia em lote não inferior a 4 mW.
• [C-2-11] PRECISA ter um sensor TYPE_STEP_COUNTER que:
  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.
• [C-2-12] PRECISA ter um sensor TILT_DETECTOR que:
  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.
• [C-2-13] O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro, giroscópio e magnetômetro PRECISA estar a no máximo 2, 5 milissegundos um do outro. O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro e pelo giroscópio PRECISA estar no intervalo de 0,25 milissegundo um do outro.
• [C-2-14] PRECISA ter carimbos de data/hora do evento do sensor do giroscópio na mesma base de horário que o subsistema da câmera e em 1 milissegundo de erro.
• [C-2-15] PRECISA entregar as amostras aos aplicativos em até cinco milissegundos a partir do momento em que os dados estão disponíveis em qualquer um dos sensores físicos acima para o aplicativo.
• [C-2-16] NÃO PODE ter um consumo de energia superior a 0,5 mW quando o dispositivo está estático e de 2,0 mW quando o dispositivo está em movimento quando qualquer combinação dos seguintes sensores está ativada:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] PODE ter um sensor TYPE_PROXIMITY, mas, se presente, PRECISA ter uma capacidade mínima de buffer de 100 eventos de sensor.

Observe que todos os requisitos de consumo de energia nesta seção não incluem o consumo de energia do processador do aplicativo. Ela inclui a potência puxada por toda a cadeia do sensor: o sensor, qualquer circuito de suporte, qualquer sistema de processamento de sensor dedicado etc.

Se as implementações do dispositivo incluírem suporte direto a sensores, elas:

• [C-3-1] PRECISA declarar corretamente o suporte aos tipos de canal direto e às taxas de subordinados diretos com as APIs isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
• [C-3-2] PRECISA oferecer suporte a pelo menos um dos dois tipos de canal direto do sensor para todos os sensores que declaram suporte ao canal direto do sensor.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DEVE oferecer suporte a relatórios de eventos pelo canal direto do sensor para o sensor principal (variante sem ativação) dos seguintes tipos:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensores biométricos

Para mais informações sobre como medir a segurança do desbloqueio biométrico, consulte a documentação sobre como medir a segurança biométrica.

Se as implementações de dispositivos incluírem uma tela de bloqueio segura, elas:

• DEVE incluir um sensor biométrico

Os sensores biométricos podem ser classificados como Classe 3 (anteriormente Forte), Classe 2 (anteriormente Fraco) ou Classe 1 (anteriormente Conveniência) com base nas taxas de aceitação de spoofing e impostores e na segurança do pipeline biométrico. Essa classificação determina os recursos que o sensor biométrico tem para interagir com a plataforma e com aplicativos de terceiros. Os sensores são classificados como Classe 1 por padrão e precisam atender aos requisitos adicionais abaixo para serem classificados como Classe 2 ou Classe 3. As biometrias de Classe 2 e Classe 3 recebem recursos adicionais, conforme detalhado abaixo.

Se as implementações do dispositivo disponibilizarem um sensor biométrico para aplicativos de terceiros via android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt e android.provider.Settings.ACTION_BIOMETRIC_ENROLL, elas:

• [C-4-1] PRECISA atender aos requisitos de biometria de Classe 3 ou Classe 2, conforme definido neste documento.
• [C-4-2] PRECISA reconhecer e respeitar cada nome de parâmetro definido como uma constante na classe Authenticators e as combinações deles. Por outro lado, NÃO É NECESSÁRIO respeitar ou reconhecer as constantes inteiras passadas aos métodos canAuthenticate(int) e setAllowedAuthenticators(int) além daqueles documentadas como constantes públicas em Authenticators e suas combinações.
• [C-4-3] PRECISA implementar a ação ACTION_BIOMETRIC_ENROLL em dispositivos que têm biometria de Classe 3 ou de Classe 2. Essa ação PRECISA apresentar apenas os pontos de entrada de registro para biometria de Classe 3 ou de Classe 2.

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

• [C-5-1] PRECISA, por padrão, exigir uma etapa de confirmação adicional (por exemplo, o pressionamento de um botão).
• [C-SR] É FORTEMENTE RECOMENDADO ter uma configuração para permitir que os usuários substituam a preferência do aplicativo e sempre exigir uma etapa de confirmação associada.
• [C-SR] É FORTEMENTE RECOMENDADO que a ação de confirmação seja protegida, de modo que um sistema operacional ou comprometimento do kernel não possa fazer spoofing. Por exemplo, isso significa que a ação de confirmação com base em um botão físico é roteada por um pin de entrada/saída de uso geral (GPIO, na sigla em inglês) somente de entrada de um elemento de segurança (SE) que não pode ser conduzido por nenhum outro meio além do pressionamento de um botão físico.
• [C-5-2] PRECISA implementar também um fluxo de autenticação implícito (sem etapa de confirmação) correspondente a setConfirmationRequired(boolean), que pode ser configurado pelos aplicativos para serem utilizados em fluxos de login.

Se as implementações de dispositivos tiverem vários sensores biométricos, elas:

• [C-SR] É RECOMENDADO que só uma biometria seja confirmada por autenticação (por exemplo, se a impressão digital e os sensores faciais estiverem disponíveis no dispositivo, onAuthenticationSucceeded depois que qualquer um deles for confirmado).

Para que as implementações de dispositivos permitam o acesso a chaves de armazenamento de chaves para aplicativos de terceiros, elas:

• [C-6-1] PRECISA atender aos requisitos da Classe 3, conforme definido na seção abaixo.
• [C-6-2] PRECISA apresentar apenas biometrias de Classe 3 quando a autenticação exigir BIOMETRIC_STRONG ou quando a autenticação for invocada com um CryptoObject.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Class 1 (anteriormente Convenience), elas:

• [C-1-1] PRECISA ter uma taxa de aceitação falsa menor que 0,002%.
• [C-1-2] PRECISA divulgar que esse modo pode ser menos seguro que um PIN, padrão ou senha fortes e enumerar claramente os riscos de ativá-lo, se as taxas de aceitação de spoofing e impostores forem superiores a 7%, conforme avaliado pelos Protocolos de teste de biometria do Android.
• [C-1-3] OBRIGATÓRIO o limite de tentativas por pelo menos 30 segundos após cinco testes falsos para verificação biométrica. Nesse caso, um teste falso é aquele com qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
• [C-1-4] PRECISA evitar a adição de novas biometrias sem antes estabelecer uma cadeia de confiança. Para isso, o usuário precisa confirmar a existência atual ou adicionar uma nova credencial de dispositivo (PIN/padrão/senha) protegida pelo TEE. a implementação do Android Open Source Project oferece o mecanismo da estrutura para fazer isso.
• [C-1-5] PRECISA remover completamente todos os dados biométricos identificáveis de um usuário quando a conta dele for removida (inclusive por meio de uma redefinição para a configuração original).
• [C-1-6] PRECISA respeitar a sinalização individual da biometria (por exemplo, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT , DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] PRECISA desafiar o usuário quanto à autenticação principal recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 24 horas ou menos para novos dispositivos lançados com o Android 10 ou a cada 72 horas ou menos para dispositivos atualizados de versões anteriores do Android.

• [C-1-8] PRECISA contestar o usuário quanto à autenticação principal recomendada (por exemplo: PIN, padrão, senha) após uma das seguintes opções:

  • um tempo limite de inatividade de 4 horas OU
  • 3 tentativas de autenticação biométrica falharam.
  • O tempo limite de inatividade e a contagem de autenticação com falha são redefinidos após a confirmação das credenciais do dispositivo.

  O upgrade de dispositivos de uma versão anterior do Android pode estar isento do C-1-8. * [C-SR] É FORTEMENTE RECOMENDADO usar a lógica no framework fornecido pelo Android Open Source Project para aplicar as restrições especificadas em [C-1-7] e [C-1-8] para novos dispositivos. * [C-SR] É FORTEMENTE RECOMENDADO que tenham uma taxa de rejeição falsa menor que 10%, conforme medido no dispositivo. * [C-SR] É RECOMENDADO que tenham uma latência inferior a 1 segundo, medida a partir do momento em que a biometria é detectada, até a tela ser desbloqueada, para cada biometria registrada.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Classe 2 (anteriormente Fraco), elas:

• [C-2-1] PRECISA atender a todos os requisitos da Classe 1 acima.
• [C-2-2] PRECISA ter uma taxa de aceitação de impostor e de impostor não superior a 20%, conforme avaliado pelos Protocolos de teste de biometria do Android.
• [C-2-3] PRECISA realizar a correspondência biométrica em um ambiente de execução isolado fora do usuário Android ou do espaço do kernel, como o ambiente de execução confiável (TEE), ou em um chip com um canal seguro para o ambiente de execução isolado.
• [C-2-4] PRECISA ter todos os dados identificáveis criptografados e autenticados criptograficamente para que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução isolado ou um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação no site do Android Open Source Project.
• [C-2-5] Para biometria baseada em câmera, enquanto a autenticação ou o registro biométrico está acontecendo:
  • PRECISA operar a câmera de um modo que impeça a leitura ou alteração dos frames fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado.
  • Para soluções RGB de câmera única, os frames da câmera PODEM ser legíveis fora do ambiente de execução isolado para dar suporte a operações como visualização para registro, mas NÃO DEVEM ser alteráveis.
• [C-2-6] NÃO PODE permitir que aplicativos de terceiros façam a distinção entre registros biométricos individuais.
• [C-2-7] NÃO PODE permitir o acesso não criptografado a dados biométricos identificáveis ou dados derivados deles (como embeddings) para o processador do aplicativo fora do contexto do TEE.

• [C-2-8] PRECISA ter um pipeline de processamento seguro, de modo que o comprometimento do sistema operacional ou do kernel não permita que os dados sejam injetados diretamente para autenticar falsamente como o usuário.

  Se as implementações de dispositivos já tiverem sido lançadas em uma versão anterior do Android e não puderem atender ao requisito C-2-8 com uma atualização de software do sistema, elas PODEM ser isentas da exigência.

• [C-SR] É MUITO RECOMENDADO incluir a detecção de atividade em todas as modalidades biométricas e a detecção de atenção para biometria facial.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Class 3 (anteriormente Strong), elas:

• [C-3-1] PRECISA atender a todos os requisitos da Classe 2 acima, exceto [C-1-7] e [C-1-8]. O upgrade de dispositivos de uma versão anterior do Android não está isento do C-2-7.
• [C-3-2] PRECISA ter uma implementação de keystore suportada por hardware.
• [C-3-3] PRECISA ter uma taxa de aceitação de impostor e de impostor não superior a 7%, conforme medido pelos Protocolos de teste de biometria do Android.
• [C-3-4] PRECISA desafiar o usuário quanto à autenticação principal recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos.

7.3.12. Sensor de posição

Implementações de dispositivos:

• PODE suportar o sensor de pose com 6 graus de liberdade.

Se as implementações de dispositivos oferecerem suporte ao sensor de pose com 6 graus de liberdade, elas:

• [C-1-1] PRECISA implementar e informar o sensor TYPE_POSE_6DOF.
• [C-1-2] PRECISA ser mais preciso do que apenas o vetor de rotação.

7.3.13. Sensor de ângulo de dobradiça

Se as implementações de dispositivos oferecerem suporte a um sensor de ângulo de dobradiça, elas:

• [C-1-1] PRECISA implementar e informar TYPE_HINGLE_ANGLE.
• [C-1-2] PRECISA oferecer suporte a pelo menos duas leituras entre 0 e 360 graus (incluindo 0 e 360 graus).
• [C-1-3] PRECISA retornar um sensor de ativação para getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7,4. Conectividade de dados

7.4.1. Telefonia

A "telefonia", conforme usada pelas APIs do Android, e neste documento, se refere especificamente ao hardware relacionado à realização de chamadas de voz e ao envio de mensagens SMS por uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ter comutação por pacote, elas são para fins do Android consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade de “telefonia” do Android e as APIs referem-se 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, independentemente de usarem uma rede celular para conectividade de dados.

• O Android PODE ser usado em dispositivos que não incluem hardware de telefonia. Ou seja, o Android é compatível com dispositivos que não são smartphones.

Se as implementações de dispositivos incluírem telefonia GSM ou CDMA, elas:

• [C-1-1] PRECISA declarar a flag de recurso android.hardware.telephony e outras flags de recursos secundários de acordo com a tecnologia.
• [C-1-2] PRECISA implementar o suporte completo da API para essa tecnologia.

Se as implementações de dispositivos não incluírem hardware de telefonia, elas:

• [C-2-1] PRECISA implementar as APIs completas como ambiente autônomo.

Se as implementações de dispositivos forem compatíveis com eUICCs ou eSIMs/chips incorporados e incluírem um mecanismo reservado para disponibilizar a funcionalidade de eSIM para desenvolvedores terceirizados, elas:

• [C-3-1] PRECISA fornecer uma implementação completa de EuiccManager API.

7.4.1.1 Compatibilidade com bloqueio de número

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

• [C-1-1] PRECISA incluir suporte para bloqueio de número
• [C-1-2] PRECISA implementar totalmente o BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.
• [C-1-3] PRECISA bloquear todas as chamadas e mensagens de um número de telefone no campo "BlockedNumberProvider" sem interação com apps. A única exceção é quando o bloqueio de números é temporariamente suspenso, conforme descrito na documentação do SDK.
• [C-1-4] NÃO PODE gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada.
• [C-1-5] NÃO É POSSÍVEL gravar uma mensagem bloqueada no provedor de telefonia.
• [C-1-6] PRECISA implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada pelo método TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NÃO PODE permitir que usuários secundários acessem ou editem os números bloqueados no dispositivo, porque a plataforma Android pressupõe que o usuário principal tem controle total dos serviços de telefonia, uma única instância, no dispositivo. Todas as IUs relacionadas ao bloqueio PRECISAM ser ocultadas para usuários secundários e a lista de bloqueio PRECISA ser respeitada.
• DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.

7.4.1.2 API Telecom

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

• [C-1-1] PRECISA oferecer suporte às APIs ConnectionService descritas no SDK.
• [C-1-2] PRECISA mostrar uma nova chamada recebida e oferecer recursos para que o usuário aceite ou rejeite a ligação recebida quando ele estiver em uma chamada em andamento feita por um app de terceiros que não oferece suporte ao recurso de espera especificado no CAPABILITY_SUPPORT_HOLD.
• [C-1-3] PRECISA ter um aplicativo que implemente o InCallService.

• [C-SR] É FORTEMENTE RECOMENDADO notificar o usuário de que atender a uma ligação vai interromper a chamada em andamento.

  A implementação do AOSP atende a esses requisitos por meio de uma notificação de alerta, que indica ao usuário que atender a uma chamada recebida fará com que a outra seja encerrada.

• [C-SR] É FORTEMENTE RECOMENDADO pré-carregar o app discador padrão que mostra uma entrada de registro de chamadas e o nome de um app de terceiros no registro de chamadas quando esse app definir a tecla extra EXTRA_LOG_SELF_MANAGED_CALLS no PhoneAccount como true.

• [C-SR] É ALTAMENTE RECOMENDADO para processar os eventos KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK do fone de ouvido para as APIs android.telecom, conforme mostrado abaixo:
  • Chame Connection.onDisconnect() quando um toque curto do evento de tecla for detectado durante uma chamada em andamento.
  • Chame Connection.onAnswer() quando um toque curto do evento de tecla for detectado durante uma ligação recebida.
  • Chame Connection.onReject() quando um evento de tecla for pressionado durante uma ligação recebida.
  • Alterne o status de silenciamento da CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementações de dispositivos:

• DEVE incluir suporte para uma ou mais formas de 802.11.

Se as implementações de dispositivos incluírem suporte para 802.11 e expõem a funcionalidade a um aplicativo de terceiros, elas:

• [C-1-1] PRECISA implementar a API do Android correspondente.
• [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.wifi.
• [C-1-3] PRECISA implementar a API multicast, conforme descrito na documentação do SDK.
• [C-1-4] PRECISA oferecer suporte a multicast DNS (mDNS) e NÃO PODE filtrar pacotes mDNS (224.0.0.251) em qualquer momento de operação, incluindo:
  • Mesmo quando a tela não está ativa.
  • Para implementações de dispositivos Android Television, mesmo quando em espera.
• [C-1-5] NÃO PODE tratar a chamada do método de API WifiManager.enableNetwork() como uma indicação suficiente para alternar o Network ativo no momento que é usado por padrão para o tráfego de aplicativos e é retornado por métodos da API ConnectivityManager, como getActiveNetwork e registerDefaultNetworkCallback. Em outras palavras, eles só PODEM desativar o acesso à Internet fornecido por qualquer outro provedor de rede (por exemplo, dados móveis) se confirmarem que a rede Wi-Fi está fornecendo acesso à Internet.
• [C-1-6] É RECOMENDADO PARA reavaliar o acesso à Internet no Network quando o método da API ConnectivityManager.reportNetworkConnectivity() for chamado e, quando a avaliação determinar que o Network atual não oferece mais acesso à Internet, mudar para qualquer outra rede disponível (por exemplo, dados móveis) que ofereça acesso à Internet.
• [C-SR] É FORTEMENTE RECOMENDADO para 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 o STA está desconectado.
  • Cada grupo de frames de solicitação de sondagem que compreende uma verificação deve usar um endereço MAC consistente (NÃO DEVE randomizar o endereço MAC no meio da verificação).
  • O número de sequência da solicitação de sondagem deve iterar normalmente (sequencialmente) entre as solicitações de sondagem em uma verificação.
  • O número da sequência da solicitação da sondagem deve ser aleatório entre a última solicitação de sondagem de uma verificação e a primeira solicitação da próxima verificação.
• [C-SR] São RECOMENDADOS FORTEMENTE enquanto o STA estiver desconectado para permitir apenas os seguintes elementos nos frames de solicitação de sondagem:
  • Conjunto de parâmetros do SSID (0)
  • Conjunto de parâmetros do DS (3)

Se as implementações de dispositivos incluírem suporte ao modo de economia de energia Wi-Fi, conforme definido no padrão IEEE 802.11, elas:

• [C-3-1] PRECISA 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 pelas APIs WifiManager.createWifiLock() e WifiManager.WifiLock.acquire() e o bloqueio estiver ativo.
• [C-3-2] A latência média de ida e volta entre o dispositivo e um ponto de acesso enquanto ele está no modo Wi-Fi de baixa latência (WIFI_MODE_FULL_LOW_LATENCY) PRECISA ser menor que a latência durante o modo Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] É FORTEMENTE RECOMENDADO para minimizar a latência de ida e volta do Wi-Fi sempre que um bloqueio de baixa latência (WIFI_MODE_FULL_LOW_LATENCY) for adquirido e entrar em vigor.

Se as implementações de dispositivos forem compatíveis com Wi-Fi e usarem Wi-Fi para a busca de local, elas:

• [C-2-1] PRECISA fornecer uma funcionalidade de usuário para ativar/desativar o valor lido pelo método de API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementações de dispositivos:

• DEVE incluir suporte para Wi-Fi Direct (Wi-Fi ponto a ponto).

Se as implementações de dispositivos forem compatíveis com Wi-Fi Direct, elas:

• [C-1-1] PRECISA implementar a API Android correspondente, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA informar o recurso de hardware android.hardware.wifi.direct.
• [C-1-3] PRECISA permitir o funcionamento normal do Wi-Fi.
• [C-1-4] PRECISA oferecer suporte a operações com Wi-Fi e Wi-Fi Direct simultaneamente.

7.4.2.2. Configuração de link direto encapsulado Wi-Fi

Implementações de dispositivos:

• DEVE incluir suporte à Configuração de link direto com túnel de Wi-Fi (TDLS, na sigla em inglês), conforme descrito na Documentação do SDK do Android.

Se as implementações de dispositivos incluírem suporte para TDLS e TDLS for ativado pela API WiFiManager, elas:

• [C-1-1] PRECISA declarar suporte a TDLS por meio de WifiManager.isTdlsSupported.
• DEVE usar TDLS apenas quando for possível E benéfico.
• DEVE ter alguma heurística e NÃO usar TDLS quando seu 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 compatibilidade com o Wi-Fi Aware.

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

• [C-1-1] PRECISA implementar as APIs WifiAwareManager, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA declarar a flag de recurso android.hardware.wifi.aware.
• [C-1-3] PRECISA oferecer suporte às operações Wi-Fi e Wi-Fi Aware simultaneamente.
• [C-1-4] PRECISA randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de até 30 minutos e sempre que o Wi-Fi Aware estiver ativado, a menos que uma operação de alcance do Aware esteja em andamento ou um caminho de dados do Aware esteja ativo (a ordem aleatória não é esperada enquanto o caminho dos dados estiver ativo).

Se as implementações de dispositivos incluírem suporte para Wi-Fi Aware e localização Wi-Fi, conforme descrito na Seção 7.4.2.5, e expõem essas funcionalidades a apps de terceiros, elas:

• [C-2-1] PRECISA implementar as APIs de descoberta com reconhecimento de local: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm e onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint do Wi-Fi

Implementações de dispositivos:

• DEVE incluir suporte para o Passpoint de Wi-Fi.

Se as implementações de dispositivos forem compatíveis com Passpoint do Wi-Fi, elas:

• [C-1-1] PRECISA implementar as APIs WifiManager relacionadas ao Passpoint, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA oferecer suporte ao padrão IEEE 802.11u, especificamente relacionado à descoberta e seleção de rede, como o Generic Publicidade Service (GAS) e o Access Network Query Protocol (ANQP).

Por outro lado, se as implementações de dispositivos não incluírem suporte para Passpoint de Wi-Fi:

• [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 Localização de Wi-Fi.

Se as implementações de dispositivos incluírem suporte à localização por Wi-Fi e exporem a funcionalidade a apps de terceiros, elas:

• [C-1-1] PRECISA implementar as APIs WifiRttManager, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA declarar a flag de recurso android.hardware.wifi.rtt.
• [C-1-3] PRECISA randomizar o endereço MAC de origem para cada burst de RTT que é executado enquanto a interface Wi-Fi em que o RTT está sendo executado não está associada a um ponto de acesso.

7.4.2.6. Descarregamento de sinal de atividade Wi-Fi

Implementações de dispositivos:

• DEVE incluir suporte para descarga de sinal de atividade Wi-Fi.

Se as implementações de dispositivos incluírem suporte para descarregamento de sinal de atividade Wi-Fi e exporem a funcionalidade a apps de terceiros, elas:

• [C-1-1] PRECISA oferecer suporte à API SocketKeepAlive.

• [C-1-2] PRECISA oferecer suporte a pelo menos três slots de sinal de atividade simultâneos por Wi-Fi e pelo menos um slot de sinal de atividade na rede celular.

Se as implementações de dispositivos não incluírem suporte para descarregamento de sinal de atividade Wi-Fi, elas:

• [C-2-1] PRECISA retornar ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocolo de provisionamento de dispositivo)

Implementações de dispositivos:

• DEVE incluir suporte ao Wi-Fi Easy Connect (DPP).

Se as implementações de dispositivos forem compatíveis com o Wi-Fi Easy Connect e exporem a funcionalidade a apps de terceiros, elas:

• [C-1-1] PRECISA que o método WifiManager#isEasyConnectSupported() retorne true.

7.4.3. Bluetooth

Se as implementações de dispositivos oferecerem suporte ao perfil de áudio Bluetooth, elas:

• DEVE oferecer suporte a codecs de áudio avançados e codecs de áudio Bluetooth (por exemplo, LDAC).

Se as implementações de dispositivos forem compatíveis com HFP, A2DP e AVRCP, elas:

• DEVE oferecer suporte a pelo menos cinco dispositivos conectados no total.

Se as implementações de dispositivos declararem o recurso android.hardware.vr.high_performance, elas:

• [C-1-1] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.

Se as implementações de dispositivos incluírem suporte para Bluetooth e Bluetooth Low Energy, elas:

• [C-2-1] PRECISA declarar os recursos de plataforma relevantes (android.hardware.bluetooth e android.hardware.bluetooth_le, respectivamente) e implementar as APIs da plataforma.
• DEVE implementar perfis de Bluetooth relevantes, como A2DP, AVRCP, OBEX, HFP etc., conforme apropriado para o dispositivo.

Se as implementações de dispositivos incluírem suporte ao Bluetooth de baixa energia (BLE), elas:

• [C-3-1] PRECISA declarar o recurso de hardware android.hardware.bluetooth_le.
• [C-3-2] PRECISA ativar as APIs Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e em android.bluetooth.
• [C-3-3] PRECISA informar o valor correto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar se a lógica de filtragem das classes da API ScanFilter está implementada.
• [C-3-4] PRECISA informar o valor correto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar se a publicidade de baixa energia é compatível.
• [C-3-5] PRECISA implementar um tempo limite de endereço particular solucionável (RPA, na sigla em inglês) de no máximo 15 minutos e alternar o endereço no tempo limite para proteger a privacidade do usuário quando o dispositivo estiver usando BLE na verificação ou na publicidade. Para evitar ataques de temporização, os intervalos de tempo limite também PRECISAM ser aleatórios entre 5 e 15 minutos.
• DEVE oferecer suporte ao descarregamento da lógica de filtragem para o chipset Bluetooth ao implementar a API ScanFilter.
• DEVE oferecer suporte ao descarregamento da leitura em lote para o chipset Bluetooth.
• DEVE ser compatível com vários anúncios com pelo menos quatro espaços.

Se as implementações de dispositivos oferecerem suporte ao Bluetooth LE e usarem essa tecnologia para a busca da localização, elas:

• [C-4-1] PRECISA fornecer uma funcionalidade de usuário para ativar/desativar o valor lido pela API System BluetoothAdapter.isBleScanAlwaysAvailable().

Se as implementações de dispositivos incluírem suporte ao Bluetooth LE e ao perfil de aparelhos auditivos, conforme descrito em Suporte a áudio de aparelho auditivo usando Bluetooth LE, elas:

• [C-5-1] PRECISA retornar true para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

7.4.4. Comunicação a curta distância (NFC, na sigla em inglês)

Implementações de dispositivos:

• DEVE incluir um transceptor e hardware relacionado para comunicação a curta distância (NFC, na sigla em inglês).
• [C-0-1] PRECISA implementar as APIs android.nfc.NdefMessage e android.nfc.NdefRecord, mesmo que não incluam suporte a NFC ou declarem o recurso android.hardware.nfc, já que as classes representam um formato de representação de dados independente de protocolo.

Se as implementações de dispositivos incluírem hardware NFC e planejam disponibilizá-lo para apps de terceiros, elas:

• [C-1-1] PRECISA informar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature().
• PRECISA ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões NFC, conforme mostrado abaixo:
• [C-1-2] PRECISA ser capaz de atuar como leitor/gravador do NFC Forum (conforme definido pela especificação técnica NFCForum-TS-Digital Protocol-1.0) do NFC Forum pelos seguintes padrões NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6.319-4)
  • IsoDep (ISO 14443-4)
  • Tipos de tags do fórum NFC 1, 2, 3, 4, 5 (definidos pelo fórum NFC)

• [SR] FORTEMENTE RECOMENDADO que seja capaz de ler e gravar mensagens NDEF, além de dados brutos, usando os seguintes padrões NFC. Observe que, embora os padrões NFC sejam indicados como FORTEMENTE RECOMENDADOS, a definição de compatibilidade para uma versão futura pretende alterá-los para PRECISA. Esses padrões são opcionais nesta versão, mas serão necessários em versões futuras. Recomendamos que os dispositivos atuais e novos que executam essa versão do Android atendam a esses requisitos agora para poderem fazer upgrade para as próximas versões da plataforma.

• [C-1-13] PRECISA pesquisar todas as tecnologias compatíveis no modo de descoberta NFC.

• DEVE estar no modo de descoberta NFC enquanto o dispositivo estiver ativado com a tela ativa e a tela de bloqueio desbloqueada.
• DEVE ser capaz de ler o código de barras e o URL (se codificado) de produtos Thinfilm NFC Barcode.

Os links disponíveis publicamente não estão disponíveis para as especificações JIS, ISO e NFC Forum citadas acima.

O Android inclui suporte ao modo de emulação de cartão host de NFC (HCE, na sigla em inglês).

Se as implementações do dispositivo incluírem um chipset controlador de NFC compatível com HCE (para NfcA e/ou NfcB) e oferecerem suporte ao roteamento de ID do aplicativo (AID), elas:

• [C-2-1] PRECISA informar a constante de recurso android.hardware.nfc.hce.
• [C-2-2] PRECISA oferecer suporte às APIs NFC HCE, conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem um chipset controlador NFC capaz de HCE para NfcF e implementarem o recurso para aplicativos de terceiros, elas:

• [C-3-1] PRECISA informar a constante de recurso android.hardware.nfc.hcef.
• [C-3-2] PRECISA implementar as APIs de emulação de cartão NfcF, conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem suporte geral a NFC conforme descrito nesta seção e forem compatíveis com tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) na função de leitor/gravador, elas:

• [C-4-1] PRECISA implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
• [C-4-2] É NECESSÁRIO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). Esse não é um recurso padrão do Android e, portanto, não aparece como uma constante na classe android.content.pm.PackageManager.

7.4.5. APIs e protocolos de rede

7.4.5.1. Capacidade mínima de rede

Implementações de dispositivos:

• [C-0-1] PRECISA incluir suporte para uma ou mais formas de rede de dados. Especificamente, as implementações de dispositivos PRECISAM incluir suporte a pelo menos um padrão de dados com capacidade de 200 Kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem EDGE, HSPA, EV-DO, 802.11g, Ethernet e PAN do Bluetooth.
• Também DEVE incluir suporte para pelo menos um padrão de dados sem fio comum, como 802.11 (Wi-Fi), quando um padrão de rede física (como Ethernet) for a conexão de dados principal.
• PODE implementar mais de uma forma de conectividade de dados.

7.4.5.2. IPv6

Implementações de dispositivos:

• [C-0-2] PRECISA incluir uma pilha de rede IPv6 e oferecer suporte à comunicação IPv6 usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, além das APIs nativas, como soquetes AF_INET6.
• [C-0-3] PRECISA ativar o IPv6 por padrão.
• PRECISA garantir que a comunicação do IPv6 seja tão confiável quanto do IPv4, por exemplo:
  • [C-0-4] PRECISA manter a conectividade IPv6 no modo Soneca.
  • [C-0-5] A limitação de taxa NÃO PODE fazer o dispositivo perder conectividade IPv6 em qualquer rede compatível com IPv6 que use ciclos de vida de RA de pelo menos 180 segundos.
• [C-0-6] PRECISA fornecer aplicativos de terceiros com conectividade IPv6 direta à rede quando conectados a uma rede IPv6, sem que nenhuma forma de conversão de endereço ou porta aconteça localmente no dispositivo. Tanto as APIs gerenciadas, como Socket#getLocalAddress ou Socket#getLocalPort) quanto as APIs NDK, como getsockname() ou IPV6_PKTINFO, PRECISAM retornar o endereço IP e a porta que são realmente usadas para enviar e receber pacotes na rede e que são visíveis como o IP e a porta de origem para os servidores da Internet (Web).

O nível obrigatório de suporte a IPv6 depende do tipo de rede, conforme mostrado nos requisitos a seguir.

Se as implementações de dispositivos forem compatíveis com Wi-Fi, elas:

• [C-1-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.

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

• [C-2-1] PRECISA oferecer suporte à operação de pilha dupla e somente IPv6 na Ethernet.

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

• [C-3-1] PRECISA oferecer suporte à operação IPv6 (somente IPv6 e possivelmente de pilha dupla) na rede celular.

Se as implementações de dispositivos oferecem suporte a mais de um tipo de rede (por exemplo, Wi-Fi e dados móveis), eles:

• [C-4-1] PRECISA atender simultaneamente aos requisitos acima em cada rede quando o dispositivo estiver conectado simultaneamente a mais de um tipo de rede.

7.4.5.3. Portais cativos

Um portal cativo é uma rede que exige login para ter acesso à Internet.

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

• [C-1-1] PRECISA fornecer um aplicativo de portal cativo para processar a intent ACTION_CAPTIVE_PORTAL_SIGN_IN e mostrar a página de login do portal cativo enviando essa intent para a API System ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] PRECISA realizar a detecção de portais cativos e permitir login com o respectivo aplicativo quando o dispositivo estiver conectado a qualquer tipo de rede, incluindo celular/móvel, Wi-Fi, Ethernet ou Bluetooth.
• [C-1-3] PRECISA oferecer suporte ao login em portais cativos usando DNS de texto não criptografado quando o dispositivo estiver configurado para usar o modo estrito de DNS particular.
• [C-1-4] PRECISA usar o DNS criptografado, de acordo com a documentação do SDK para android.net.LinkProperties.getPrivateDnsServerName e android.net.LinkProperties.isPrivateDnsActive, para todo o tráfego de rede que não estiver se comunicando explicitamente com o portal cativo.
• [C-1-5] PRECISA garantir que, enquanto o usuário fizer login em um portal cativo, a rede padrão usada pelos aplicativos (como retornada por ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback e usada por padrão por APIs de rede Java, como java.net.Socket e APIs nativas, como connect()) seja qualquer outra rede disponível que forneça acesso à Internet, se disponível.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

• [C-0-1] PRECISA manter a configuração de sincronização automática principal ativada por padrão para que o método getMasterSyncAutomatically() retorne "true".

7.4.7. Economia de dados

Se as implementações de dispositivos incluírem uma conexão limitada, elas serão:

• [SR] RECOMENDADO FORTEMENTE para fornecer o modo de Economia de dados.

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

• [C-1-1] PRECISA oferecer suporte a todas as APIs na classe ConnectivityManager, conforme descrito na documentação do SDK.

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

• [C-2-1] PRECISA retornar o valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().
• [C-2-2] NÃO PODE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Elementos de segurança

Se as implementações de dispositivos forem compatíveis com elementos seguros compatíveis com a Open Mobile API e os disponibilizarem para apps de terceiros, elas:

• [C-1-1] PRECISA enumerar os leitores de elementos de segurança disponíveis pela API android.se.omapi.SEService.getReaders().

• [C-1-2] PRECISA declarar as flags de recurso corretas usando android.hardware.se.omapi.uicc para o dispositivo com elementos de segurança baseados em UICC, android.hardware.se.omapi.ese para dispositivos com elementos de segurança baseados em eSE e android.hardware.se.omapi.sd para dispositivos com elementos de segurança baseados em SD.

7,5. Cameras

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

• [C-1-1] PRECISA declarar a flag de recurso android.hardware.camera.any.
• [C-1-2] PRECISA ser possível para um aplicativo alocar simultaneamente 3 bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo sensor da câmera de maior resolução no dispositivo, enquanto a câmera está aberta para fins de visualização básica e captura.
• [C-1-3] PRECISA garantir que o aplicativo de câmera padrão pré-instalado que processe as 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 enviá-la ao aplicativo receptor quando ele não tiver o ACCESS_FINE_LOCATION.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera localizada na lateral do dispositivo em frente à tela. ou seja, ela retrata cenas do outro lado do dispositivo, como uma câmera tradicional.

Implementações de dispositivos:

• DEVE incluir uma câmera traseira.

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

• [C-1-1] PRECISA informar a flag de recurso android.hardware.camera e android.hardware.camera.any.
• [C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
• DEVE ter foco automático por hardware ou por software implementado no driver da câmera (transparente ao software do aplicativo).
• PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
• PODE incluir um flash.

Se a câmera tiver flash:

• [C-2-1] A lâmpada NÃO PODE ser acesa enquanto uma instância android.hardware.Camera.PreviewCallback tiver sido registrada em uma superfície de visualização da Câmera, a menos que o app tenha ativado explicitamente o flash ativando os atributos FLASH_MODE_AUTO ou FLASH_MODE_ON de um objeto Camera.Parameters. Essa restrição não se aplica ao aplicativo integrado de câmera do sistema do dispositivo, apenas a aplicativos de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela. ou seja, uma câmera geralmente usada para tirar fotos do usuário, como para videoconferências e aplicativos semelhantes.

Implementações de dispositivos:

• PODE incluir uma câmera frontal.

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

• [C-1-1] PRECISA informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
• [C-1-3] NÃO PODE usar uma câmera frontal como padrão para a API Camera nem configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera no dispositivo.
• [C-1-4] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo quando o aplicativo atual tiver solicitado explicitamente que a tela da câmera seja girada por meio de uma chamada para o método android.hardware.Camera.setDisplayOrientation(). Por outro lado, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo quando o aplicativo atual não solicita explicitamente que a tela da câmera seja girada com uma chamada para o método android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NÃO É POSSÍVEL espelhar os streams de vídeo ou a imagem estática final capturados retornados para callbacks de aplicativos ou confirmados para o armazenamento de mídia.
• [C-1-6] PRECISA espelhar a imagem mostrada pela pós-visualização da mesma forma que o stream de imagem de visualização da câmera.
• PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

Se as implementações do dispositivo puderem ser giradas pelo usuário (por exemplo, automaticamente por meio de um acelerômetro ou manualmente por entrada do usuário):

• [C-2-1] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação atual do dispositivo.

7.5.3. Câmera externa

Implementações de dispositivos:

• PODE incluir suporte para uma câmera externa que nem sempre está conectada.

Se as implementações de dispositivos forem compatíveis com uma câmera externa, elas:

• [C-1-1] PRECISA declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
• [C-1-2] PRECISA oferecer suporte à classe de vídeo USB (UVC 1.0 ou mais recente) se a câmera externa se conectar pela porta do host USB.
• [C-1-3] PRECISA passar nos testes de CTS da câmera com um dispositivo físico de câmera externa conectado. Detalhes dos testes CTS da câmera estão disponíveis em source.android.com.
• DEVE oferecer suporte a compactação de vídeo, como MJPEG, para permitir a transferência de streams de alta qualidade não codificados (ou seja, streams de imagens brutos ou comprimidos de forma independente).
• PODE oferecer suporte a várias câmeras.
• PODE oferecer suporte à codificação de vídeo baseada em câmera.

Se a codificação de vídeo baseada na câmera for compatível:

• [C-2-1] Uma transmissão simultânea não codificada / MJPEG (QVGA ou resolução 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 controles de câmera de nível inferior ao app, incluindo fluxos eficientes de burst/streaming de cópia zero e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, remoção de ruído, nitidez e muito mais.

O pacote de API mais antigo, android.hardware.Camera, está marcado como descontinuado no Android 5.0, mas ainda deve estar disponível para uso dos apps. As implementações de dispositivos Android PRECISAM garantir o suporte contínuo da API, conforme descrito nesta seção e no SDK do Android.

Todos os recursos comuns entre a classe android.hardware.Camera descontinuada e o pacote android.hardware.camera2 mais recente PRECISAM ter desempenho e qualidade equivalentes em ambas as APIs. Por exemplo, com configurações equivalentes, a velocidade e a precisão do foco automático precisam ser idênticas, e a qualidade das imagens capturadas precisa ser a mesma. Os recursos que dependem de semânticas diferentes das duas APIs não precisam ter velocidade ou qualidade correspondentes, mas DEVEM ser o mais parecido possível.

As implementações de dispositivos PRECISAM implementar os seguintes comportamentos para as APIs relacionadas à câmera em todas as câmeras disponíveis. Implementações de dispositivos:

• [C-0-1] PRECISA usar android.hardware.PixelFormat.YCbCr_420_SP para dados de visualização fornecidos aos callbacks de aplicativos quando um aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] PRECISA estar ainda no formato de codificação NV21 quando um aplicativo registra uma instância android.hardware.Camera.PreviewCallback e o sistema chama o método onPreviewFrame() e o formato de visualização é YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame(). Ou seja, NV21 PRECISA ser o padrão.
• [C-0-3] PRECISA oferecer suporte ao formato YV12, conforme indicado pela constante android.graphics.ImageFormat.YV12, para visualizações da câmera frontal e traseira para android.hardware.Camera. O codificador de vídeo do hardware e a câmera podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA ser compatível com a conversão para YV12.
• [C-0-4] PRECISA oferecer suporte aos formatos android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG como saídas pela API android.media.ImageReader para dispositivos android.hardware.camera2 que anunciam o recurso REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE no android.request.availableCapabilities.
• [C-0-5] Ainda PRECISA implementar a API Camera completa incluída na documentação do SDK do Android, independente de o dispositivo incluir foco automático de hardware ou outros recursos. Por exemplo, câmeras que não têm foco automático PRECISAM chamar instâncias android.hardware.Camera.AutoFocusCallback registradas, mesmo que isso não seja relevante para câmeras sem foco automático. Observe que isso se aplica a câmeras frontais. por exemplo, mesmo que a maioria das câmeras frontais não tenha suporte para autofoco, os callbacks da API ainda devem ser “falsos”, conforme descrito.
• [C-0-6] PRECISA reconhecer e respeitar cada nome de parâmetro definido como uma constante nas classes android.hardware.Camera.Parameters e android.hardware.camera2.CaptureRequest. Por outro lado, as implementações de dispositivos NÃO PODEM respeitar ou reconhecer constantes de string transmitidas ao método android.hardware.Camera.setParameters() além das documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos PRECISAM oferecer suporte a todos os parâmetros padrão de Câmera, se o hardware permitir, e NÃO PODEM oferecer suporte a tipos personalizados de parâmetros de Câmera. Por exemplo, as implementações de dispositivos que oferecem suporte à captura de imagens usando técnicas de geração de imagens de High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera Camera.SCENE_MODE_HDR.
• [C-0-7] PRECISA informar o nível adequado de suporte com a propriedade android.info.supportedHardwareLevel, conforme descrito no SDK do Android, e informar as sinalizações de recurso do framework adequadas.
• [C-0-8] também PRECISA declarar os recursos individuais da câmera do android.hardware.camera2 usando a propriedade android.request.availableCapabilities e declarar as flags de recurso adequadas. PRECISA definir a flag de recurso se algum dos dispositivos de câmera conectados oferecer suporte ao recurso.
• [C-0-9] PRECISA transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada dela tiver sido adicionada ao armazenamento de mídia.
• [C-0-10] PRECISA transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da imagem tiver sido adicionada ao armazenamento de mídia.
• [C-0-11] PRECISA ter todas as câmeras acessíveis pela API android.hardware.Camera descontinuada e também pela API android.hardware.camera2.
• [C-0-12] PRECISA garantir que a aparência facial NÃO seja alterada, incluindo, mas não se limitando a alterações na geometria, no tom ou na suavização da pele facial em qualquer API do android.hardware.camera2 ou android.hardware.Camera.
• [C-SR] Para dispositivos com várias câmeras RGB voltadas para a mesma direção, é FORTEMENTE RECOMENDADO oferecer suporte a um dispositivo de câmera lógico que liste a capacidade CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, que consiste em todas as câmeras RGB voltadas para essa direção como subdispositivos físicos.

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

• [C-1-1] PRECISA implementar essa API de câmera usando a API android.hardware.camera2.
• PODE fornecer tags e/ou extensões do fornecedor à API android.hardware.camera2.

7.5.5. Orientação da câmera

Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, tais câmeras:

• [C-1-1] PRECISA estar orientada para que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é mantido na orientação paisagem, as câmeras PRECISAM capturar imagens na orientação paisagem. Isso se aplica independentemente da orientação natural do dispositivo. ou seja, aplica-se a dispositivos principais no modo paisagem e modo retrato.

7,6. Memória e armazenamento

7.6.1. Mínimo de memória e armazenamento

Implementações de dispositivos:

• [C-0-1] PRECISA incluir um Gerenciador de downloads que os aplicativos possam usar para fazer o download de arquivos de dados. Além disso, PRECISAM ser capazes de fazer o download de arquivos individuais com pelo menos 100 MB no local padrão de "cache".

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" ou "armazenamento compartilhado do aplicativo". ou pelo caminho do Linux "/sdcard" em que ele é montado.
• [C-0-2] PRECISA ser configurado com armazenamento compartilhado montado por padrão, ou seja, "fora da caixa", independentemente de o armazenamento ser implementado em um componente de armazenamento interno ou em um meio de armazenamento removível (por exemplo, slot de cartão Secure Digital).
• [C-0-3] É NECESSÁRIO montar o armazenamento compartilhado do aplicativo diretamente no caminho sdcard do Linux ou incluir um link simbólico do Linux de sdcard para o ponto de montagem real.
• [C-0-4] PRECISA ativar o armazenamento com escopo por padrão para todos os apps destinados ao nível 29 da API ou mais recente, exceto na seguinte situação:
  • Quando o app solicita android:requestLegacyExternalStorage="true" no manifesto.
• [C-0-5] É NECESSÁRIO editar os metadados de local, como tags GPS Exif, armazenados em arquivos de mídia quando esses arquivos são acessados pelo MediaStore, exceto quando o app de chamada tem a permissão ACCESS_MEDIA_LOCATION.

As implementações de dispositivos PODEM atender aos requisitos acima usando uma das opções a seguir:

• Armazenamento removível acessível pelo usuário, como um slot para cartão SD.
• Uma parte do armazenamento interno (não removível) conforme implementado no Android Open Source Project (AOSP).

Se as implementações de dispositivos usarem o armazenamento removível para atender aos requisitos acima, elas:

• [C-1-1] PRECISA implementar uma interface do usuário de aviso ou pop-up alertando o usuário quando não há mídia de armazenamento inserida no slot.
• [C-1-2] PRECISA incluir uma mídia de armazenamento com formato FAT (por exemplo, cartão SD) ou mostrar na caixa e em outros materiais disponíveis no momento da compra. Esses materiais precisam ser comprados separadamente.

Se as implementações de dispositivos usarem uma parte do armazenamento não removível para atender aos requisitos acima, elas:

• DEVE usar a implementação do AOSP do armazenamento compartilhado interno do app.
• PODE compartilhar o espaço de armazenamento com os dados privados do aplicativo.

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

• [C-3-1] PRECISA fornecer um mecanismo para acessar os dados no armazenamento compartilhado do aplicativo em um computador host.
• DEVE expor o conteúdo dos dois caminhos de armazenamento de forma transparente usando o serviço de verificação de mídia do Android e o android.provider.MediaStore.
• PODE usar armazenamento USB em massa, mas DEVE usar o Media Transfer Protocol para atender a esse requisito.

Se as implementações de dispositivos tiverem uma porta USB com modo de periférico USB e aceitarem o protocolo de transferência de mídia, elas:

• DEVE ser compatível com o host de referência do Android MTP, a Transferência de arquivos do Android.
• DEVE informar uma classe de dispositivo USB de 0x00.
• DEVE informar um nome de interface USB de "MTP".

7.6.3. Armazenamento adotável

Se se espera que o dispositivo seja de natureza móvel, diferentemente da televisão, as implementações de dispositivo são:

• [SR] RECOMENDADO ALTAMENTE a implementação do armazenamento adotável em um local estável de longo prazo, já que desconectá-los acidentalmente pode causar perda/corrupção de dados.

Se a porta do dispositivo de armazenamento removível estiver em um local estável a longo prazo, como dentro do compartimento da bateria ou de outra tampa protetora, as implementações do dispositivo serão:

• [SR] RECOMENDADO ALTAMENTE a implementação do armazenamento adotável.

7,7. USB

Se as implementações de dispositivos tiverem uma porta USB, elas:

• DEVE oferecer suporte ao modo de periférico USB e DEVE oferecer suporte ao modo host USB.

7.7.1. Modo USB periférico

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo de periféricos:

• [C-1-1] A porta PRECISA estar conectada a um host USB que tenha uma porta USB padrão tipo A ou tipo C.
• [C-1-2] PRECISA informar o valor correto de iSerialNumber no descritor de dispositivo USB padrão usando android.os.Build.SERIAL.
• [C-1-3] PRECISA detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão da resistência Type-C e PRECISA detectar alterações no anúncio caso eles ofereçam suporte a USB Type-C.
• [SR] A porta DEVE usar o formato USB micro-B, micro-AB ou tipo C. É altamente RECOMENDADO que dispositivos Android novos e existentes atendam a esses requisitos para que possam fazer upgrade para as próximas versões 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 da tela do software para todos os apps (inclusive a tela inicial), para que a tela mostre corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É altamente RECOMENDADO que dispositivos Android novos e existentes atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
• [SR] DEVE implementar suporte para acionar corrente de 1,5 A durante o sinal de luz HS e o tráfego, conforme especificado na Especificação de carregamento de bateria USB, revisão 1.2. É altamente RECOMENDADO que dispositivos Android novos e existentes atendam a esses requisitos para que possam fazer upgrade para as próximas versões da plataforma.
• [SR] 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 as funções do coletor/fonte. Isso pode resultar em problemas de interoperabilidade com os carregadores ou dispositivos compatíveis com os métodos padrão de fornecimento de energia USB. Embora isso seja chamado de "Fortemente RECOMENDADO", em versões futuras do Android, poderemos EXIGIR que todos os dispositivos type-C ofereçam suporte total à interoperabilidade com carregadores padrão tipo C.
• [SR] FORTEMENTE RECOMENDADO para oferecer suporte ao Power Delivery para troca de papéis de energia e dados quando houver suporte para o modo host USB e USB Type-C.
• DEVE oferecer suporte ao Power Delivery para carregamento de alta tensão e suporte a Modos Alternativos, como saída de tela.
• DEVE implementar a API e a especificação do Android Open Accessory (AOA), conforme documentado na documentação do SDK do Android.

Se as implementações de dispositivos incluírem uma porta USB e implementarem a especificação AOA, elas:

• [C-2-1] PRECISA declarar suporte ao recurso de hardware android.hardware.usb.accessory.
• [C-2-2] A classe de armazenamento em massa USB PRECISA incluir a string "android" no final da descrição da interface iInterface string de armazenamento USB em massa

7.7.2. Modo host USB

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

• [C-1-1] PRECISA implementar a API de host USB do Android, conforme documentado no SDK do Android, e PRECISA declarar suporte ao recurso de hardware android.hardware.usb.host.
• [C-1-2] PRECISA implementar o suporte para conectar periféricos USB padrão. Em outras palavras, é NECESSÁRIO:
  • Ter uma porta tipo C no dispositivo ou enviar com cabos adaptando uma porta proprietária no dispositivo a uma porta USB-C padrão (dispositivo USB-C).
  • Ter um dispositivo do tipo A ou enviar com cabos adaptando 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 padrão tipo A.
• [C-1-3] NÃO PODE enviar com um adaptador que converta de portas USB tipo A ou micro-AB para uma porta tipo C (receptáculo).
• [C-SR] É MUITO RECOMENDADO implementar a classe de áudio USB conforme documentado na documentação do SDK do Android.
• DEVE oferecer suporte ao carregamento de dispositivos periféricos USB conectados no modo host. divulgar uma fonte de corrente de pelo menos 1,5 A, conforme especificado na seção Parâmetros de terminação da Revisão 1.2 da especificação do cabo e do conector USB-C, para conectores USB-C, ou usar o intervalo atual de saída da porta de carregamento downstream(CDP), conforme especificado nas Especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
• DEVE implementar e oferecer suporte aos padrões USB-C.

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

• [C-2-1] PRECISA oferecer suporte à classe HID USB.
• [C-2-2] PRECISA oferecer suporte à detecção e ao mapeamento dos seguintes campos de dados HID especificados nas Tabelas de uso de HID USB e a Solicitação de uso do Voice Command para as constantes KeyEvent, conforme mostrado abaixo:
  • ID de uso da página de uso (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • ID de uso da página de uso (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • ID de uso da página de uso (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • ID de uso da página de uso (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo host e o Framework de acesso ao armazenamento (SAF, na sigla em inglês), elas:

• [C-3-1] PRECISA reconhecer qualquer dispositivo MTP (protocolo de transferência de mídia) conectado remotamente e tornar o conteúdo acessível pelas intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

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

• [C-4-1] PRECISA implementar a funcionalidade Dual Role Port (Porta de função dupla), conforme definido pela especificação USB-C (seção 4.5.1.3.3).
• [SR] MUITO RECOMENDADO para oferecer suporte ao DisplayPort, oferecer suporte a taxas de dados USB SuperSpeed e ser MUITO RECOMENDADO para oferecer suporte ao Power Delivery para troca de funções de dados e energia.
• [SR] RECOMENDADO NÃO oferecer suporte ao modo de acessório do adaptador de áudio, conforme descrito no Apêndice A da Revisão 1.2 das especificações do conector e cabo USB-C.
• DEVE implementar o modelo Try.* mais adequado para o formato do dispositivo. Por exemplo, um dispositivo portátil DEVE implementar o modelo Try.SNK.

7,8. Áudio

7.8.1. Microfone

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

• [C-1-1] PRECISA informar a constante de recurso android.hardware.microphone.
• [C-1-2] PRECISA atender aos requisitos de gravação de áudio da seção 5.4.
• [C-1-3] PRECISA atender aos requisitos de latência de áudio da seção 5.6.
• [SR] É FORTEMENTE RECOMENDADO para oferecer suporte à gravação quase ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos omitirem um microfone, elas:

• [C-2-1] NÃO PODE informar a constante de recurso android.hardware.microphone.
• [C-2-2] PRECISA implementar a API de gravação de áudio pelo menos como ambiente autônomo, de acordo com a seção 7.

7.8.2. Saída de áudio

Se as implementações do dispositivo incluírem um alto-falante ou uma porta de saída de áudio/multimídia para um periférico de saída de áudio, como uma entrada de áudio de 3 condutores de 3,5 mm ou uma porta de modo host USB usando classe de áudio USB, elas:

• [C-1-1] PRECISA informar a constante de recurso android.hardware.audio.output.
• [C-1-2] PRECISA atender aos requisitos de reprodução de áudio da seção 5.5.
• [C-1-3] PRECISA atender aos requisitos de latência de áudio da seção 5.6.
• [SR] FORTEMENTE RECOMENDADO para oferecer suporte à reprodução quase ultrassom, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos não incluírem uma porta de saída de áudio ou alto-falante, elas:

• [C-2-1] NÃO É POSSÍVEL informar o recurso android.hardware.audio.output.
• [C-2-2] PRECISA implementar as APIs relacionadas à saída de áudio como um ambiente autônomo.

Para os fins desta seção, uma "porta de saída" é uma interface física, como uma entrada de áudio de 3,5 mm, HDMI ou porta de modo host USB com classe de áudio USB. O suporte para saída de áudio por protocolos baseados em rádio, como Bluetooth, Wi-Fi ou rede celular, não se qualifica como uma "porta de saída".

7.8.2.1. Portas de áudio analógico

Para serem compatíveis com fones de ouvido e outros acessórios de áudio que usam o plugue de áudio de 3,5 mm em todo o ecossistema Android, se as implementações de dispositivos incluírem uma ou mais portas de áudio analógico, elas:

• [C-SR] É RECOMENDADO que você inclua pelo menos uma das portas de áudio para ser um conector de 3,5 mm com 4 condutores.

Se as implementações do dispositivo tiverem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

• [C-1-1] PRECISA oferecer suporte à reprodução de áudio para fones de ouvido estéreo ou fones de ouvido estéreo com microfone.
• [C-1-2] PRECISA oferecer suporte a plugues de áudio TRRS com a ordem de pinagem CTIA.
• [C-1-3] PRECISA oferecer suporte à detecção e ao mapeamento dos códigos de tecla para os três intervalos de impedância equivalentes entre o microfone e os condutores de terra no plugue de áudio:
  • 70 ohm ou menos: KEYCODE_HEADSETHOOK
  • 210–290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] PRECISA acionar o ACTION_HEADSET_PLUG na inserção do plugue, mas somente depois que todos os contatos no plugue estiverem tocando nos segmentos relevantes na entrada.
• [C-1-5] PRECISA ser capaz de operar com pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohm.
• [C-1-6] PRECISA ter uma tensão de polarização de microfone entre 1,8 V e 2,9 V.
• [C-1-7] PRECISA detectar e mapear o código de tecla para o seguinte intervalo de impedância equivalente entre o microfone e os condutores de terra no plugue de áudio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR] É FORTEMENTE RECOMENDADO a compatibilidade com plugues de áudio com a ordem de pin-out OMTP.
• [C-SR] É FORTEMENTE RECOMENDADO para 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, forem compatíveis com um microfone e transmitirem android.intent.action.HEADSET_PLUG com o microfone de valor extra definido como 1, elas:

• [C-2-1] PRECISA oferecer suporte à detecção de microfone no acessório de áudio conectado.

7.8.2.2. Portas digitais de áudio

Para oferecer compatibilidade com fones de ouvido e outros acessórios de áudio usando conectores USB-C e implementando (classe de áudio USB) em todo o ecossistema Android, conforme definido na especificação de fones de ouvido USB Android.

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

7.8.3. Quase ultrassom

O áudio quase ultrassom é a banda de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

• É NECESSÁRIO informar corretamente o suporte à capacidade de áudio quase ultrassom pela API AudioManager.getProperty da seguinte forma:

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 estar no máximo 15 dB abaixo da resposta a 2 kHz.
• [C-1-2] A proporção não ponderada do microfone para ruído acima de 18,5 kHz a 20 kHz para um tom de 19 kHz a -26 dBFS PRECISA ser inferior a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND for "true":

• [C-2-1] A resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser inferior a 40 dB abaixo da resposta a 2 kHz.

7.8.4. Integridade do sinal

Implementações de dispositivos: * DEVEM fornecer um caminho de sinal de áudio sem falhas para fluxos de entrada e saída em dispositivos portáteis, conforme definido por falhas zero 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 exige um dongle de loopback de áudio, usado diretamente em uma entrada de 3,5 mm e/ou em combinação com um adaptador USB-C para 3,5 mm. Todas as portas de saída de áudio DEVEM ser testadas.

Atualmente, o OboeTester oferece suporte a caminhos da AAudio, então as combinações a seguir DEVEM ser testadas em busca de falhas usando a AAudio:

Modo de desempenho	Compartilhamento	Taxa de amostragem de saída	Em Poss	Out Poss
BAIXO_LATÊNCIA	EXCLUSIVO	NÃO ESPECIFICADO	1	2
BAIXO_LATÊNCIA	EXCLUSIVO	NÃO ESPECIFICADO	2	1
BAIXO_LATÊNCIA	COMPARTILHADO	NÃO ESPECIFICADO	1	2
BAIXO_LATÊNCIA	COMPARTILHADO	NÃO ESPECIFICADO	2	1
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 relação sinal-ruído (SNR, na sigla em inglês) e distorção harmônica total (THD) para 2.000 Hz seno.

Transdutor	THD	SNR
Alto-falante integrado principal, medido com um microfone de referência externo	< 3,0%	>= 50 dB
microfone integrado principal, medido com um alto-falante de referência externo	< 3,0%	>= 50 dB
Entradas de 3,5 mm analógicas integradas, testadas com o adaptador de loopback	Menos de 1%	>= 60 dB
Adaptadores USB fornecidos com o telefone, testados com o adaptador de loopback	< 1,0%	>= 60 dB

7,9. Realidade virtual

O Android inclui APIs e instalações para criar a "Realidade virtual" (RV) incluindo experiências de RV de alta qualidade para dispositivos móveis. As implementações de dispositivos PRECISAM implementar corretamente essas APIs e esses comportamentos, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android é compatível com o Modo 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 de dispositivos oferecerem suporte ao modo RV, elas:

• [C-1-1] PRECISA ter pelo menos dois núcleos físicos.
• [C-1-2] PRECISA declarar o recurso android.hardware.vr.high_performance.
• [C-1-3] PRECISA oferecer suporte ao modo de desempenho sustentado.
• [C-1-4] É FORTEMENTE RECOMENDADO para oferecer suporte ao OpenGL ES 3.2.
• [C-1-5] PRECISA oferecer suporte a android.hardware.vulkan.level 0.
• DEVE oferecer suporte a android.hardware.vulkan.level 1 ou mais recente.
• [C-1-6] PRECISA implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace e expor as extensões na lista de extensões EGL disponíveis.
• [C-1-8] PRECISA implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2 e GL_EXT_protected_textures e expor as extensões na lista de extensões GL disponíveis.
• [C-SR] É MUITO RECOMENDADO implementar GL_EXT_external_buffer, GL_EXT_EGL_image_array e GL_OVR_multiview_multisampled_render_to_texture e expor as extensões na lista de extensões GL disponíveis.
• [C-SR] É FORTEMENTE RECOMENDADO para oferecer suporte ao Vulkan 1.1.
• [C-SR] É MUITO RECOMENDADO que você implemente VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing e VK_KHR_shared_presentable_image e as exponha na lista de extensões do Vulkan disponíveis.
• [C-SR] É FORTEMENTE 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 de olho alternada do conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de ruptura visíveis.
• [C-1-9] PRECISA implementar o suporte às flags AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, conforme descrito no NDK.
• [C-1-10] PRECISA implementar suporte 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] É MUITO RECOMENDADO para oferecer suporte à alocação de AHardwareBuffers com mais de uma camada e flags e formatos especificados em C-1-10.
• [C-1-11] PRECISA oferecer suporte à decodificação H.264 a pelo menos 3.840 x 2.160 a 30 fps, comprimido a uma média de 40 Mbps (equivalente a quatro instâncias de 1920 x1080 a 30 fps a 10 Mbps ou 2 instâncias de 1920 x 6 Mbps a 108ps).
• [C-1-12] PRECISA oferecer suporte a HEVC e VP9, PRECISA ser capaz de decodificar pelo menos 1920 x 1080 a 30 fps comprimido a uma média de 10 Mbps e DEVE ser capaz de decodificar instâncias de 3.840 x 2.160 a 30 fps a 20 Mbps a 20 Mbps a 30 fps a 190 Mbps (equivalente a 20 Mbps a 20 Mbps).
• [C-1-13] PRECISA oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
• [C-1-14] PRECISA ter uma tela incorporada, com resolução de pelo menos 1920 x 1080.
• [C-SR] É MUITO RECOMENDADO que tenham uma resolução de tela de pelo menos 2560 x 1440.
• [C-1-15] A tela PRECISA ser atualizada para pelo menos 60 Hz no modo RV.
• [C-1-17] A tela PRECISA ser compatível com um modo de baixa persistência com persistência de ≤ 5 milissegundos. A persistência é definida como o período pelo qual um pixel está emitindo luz.
• [C-1-18] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE seção 7.4.3.
• [C-1-19] PRECISA oferecer suporte e informar corretamente o Direct Channel Type para todos os seguintes tipos de sensor padrão:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] É MUITO RECOMENDADO oferecer suporte ao tipo de canal direto TYPE_HARDWARE_BUFFER em todos os tipos listados acima.
• [C-1-21] PRECISA atender aos requisitos relacionados ao giroscópio, acelerômetro e magnetômetro para android.hardware.hifi_sensors, conforme especificado na seção 7.3.9.
• [C-SR] É ALTAMENTE RECOMENDADO para oferecer suporte ao recurso android.hardware.sensor.hifi_sensors.
• [C-1-22] PRECISA ter latência de movimento total para fótons de no máximo 28 milissegundos.
• [C-SR] É RECOMENDADO que tenham latência de movimento total para fótons de até 20 milissegundos.
• [C-1-23] PRECISA ter a proporção do primeiro frame, que é a proporção entre o brilho dos pixels no primeiro frame após uma transição do preto para o branco e o brilho dos pixels brancos no estado estável de pelo menos 85%.
• [C-SR] É MUITO RECOMENDADO que a proporção do primeiro frame seja de pelo menos 90%.
• PODE fornecer um núcleo exclusivo para o aplicativo em primeiro plano e pode oferecer suporte à API Process.getExclusiveCores para retornar os números dos núcleos de CPU exclusivos do aplicativo de primeiro plano superior.

Se houver suporte ao núcleo exclusivo, então o núcleo:

• [C-2-1] NÃO PODE permitir que nenhum outro processo do espaço do usuário seja executado nele (exceto drivers de dispositivo usados pelo aplicativo), mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

7,10. Retorno tátil

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

7,11. Classe de desempenho de mídia

A classe de desempenho de mídia da implementação do dispositivo pode ser obtida em a API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Requisitos da classe de desempenho de mídia são definidos para cada versão do Android que começa com R (versão 30). O valor especial de 0 designa que o dispositivo não é classe de desempenho de mídia.

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

• [C-1-1] PRECISA retornar pelo menos um valor de android.os.Build.VERSION_CODES.R.

• [C-1-2] PRECISA ser uma implementação de dispositivo portátil.

• [C-1-3] PRECISA atender a todos os requisitos de "Classe de desempenho de mídia" descreveu na seção 2.2.7.

Consulte a seção 2.2.7 para informações específicas do dispositivo e cumprimento de requisitos regulatórios.

8. Desempenho e potência

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 básicas que os desenvolvedores teriam ao desenvolver um app.

8.1. Consistência da experiência do usuário

Uma interface de usuário tranquila pode ser fornecida ao usuário final se houver determinados requisitos mínimos para garantir um frame rate e tempos de resposta consistentes para aplicativos e jogos. As implementações de dispositivos, dependendo do tipo, podem ter requisitos mensuráveis de latência da interface do usuário e troca de tarefas, conforme descrito na seção 2.

8.2. Desempenho do acesso a E/S de arquivos

Fornecer um valor de referência comum para um desempenho consistente de acesso a arquivos no armazenamento de dados particulares do aplicativo (partição /data) permite que os desenvolvedores de apps definam uma expectativa adequada que ajudaria o design do software. Implementações de dispositivos, dependendo do tipo, PODEM ter determinados requisitos descritos na seção 2 para as seguintes operações de leitura e gravação:

• Desempenho de gravação sequencial. Medida por gravação de um arquivo de 256 MB usando buffer de gravação de 10 MB.
• Desempenho de gravação aleatória. Medida por gravação de um arquivo de 256 MB usando buffer de gravação de 4 KB.
• Desempenho de leitura sequencial. Medida pela leitura de um arquivo de 256 MB com um buffer de gravação de 10 MB.
• Desempenho de leitura aleatória. Medida por meio da leitura de um arquivo de 256 MB usando um buffer de gravação de 4 KB.

8.3. Modos de economia de energia

Se as implementações de dispositivos incluírem recursos para melhorar o gerenciamento de energia do dispositivo incluídos no AOSP (por exemplo, bucket do App em espera e Soneca) ou estenderem os recursos que não aplicam restrições mais rígidas do que o bucket Rare App em espera, elas:

• [C-1-1] NÃO PODE se desviar da implementação do AOSP para os algoritmos de acionamento, manutenção, ativação e uso das configurações globais do sistema dos modos de economia de energia "App em espera" e "Soneca".
• [C-1-2] NÃO PODE se desviar da implementação do AOSP para usar configurações globais com o objetivo de gerenciar a limitação de jobs, alarmes e redes para apps em cada bucket de App em espera.
• [C-1-3] NÃO PODE se desviar da implementação do AOSP para o número de buckets do App em espera usados para o App em espera.
• [C-1-4] PRECISA implementar os buckets do App em espera e o recurso "Soneca", conforme descrito em Gerenciamento de energia.
• [C-1-5] PRECISA retornar true para PowerManager.isPowerSaveMode() quando o dispositivo estiver no modo de economia de energia.
• [C-SR] É FORTEMENTE RECOMENDADO que o usuário tenha affordance para ativar e desativar o recurso de economia de bateria.
• [C-SR] É FORTEMENTE RECOMENDADO para oferecer recursos ao usuário para mostrar todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca".

Se as implementações de dispositivos estenderem os recursos de gerenciamento de energia incluídos no AOSP e essa extensão aplicar restrições mais rigorosas do que o bucket raro 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 de suspensão, conforme definido pela Interface de Energia e Configuração Avançada (ACPI).

Se as implementações de dispositivos implementarem estados de energia S4 conforme definido pela ACPI, elas:

• [C-1-1] PRECISA entrar nesse estado somente após o usuário realizar uma ação explícita para colocar o dispositivo em um estado inativo (por exemplo, fechar uma tampa que faça parte fisicamente do dispositivo ou desligar um veículo ou televisão) e antes de o usuário reativar o dispositivo (por exemplo, abrir a tampa ou ligar o veículo ou a televisão novamente).

Se as implementações de dispositivos implementarem estados de energia do S3 conforme definido pela ACPI, elas:

• [C-2-1] PRECISA atender ao C-1-1 acima ou PRECISA entrar no estado S3 apenas quando aplicativos de terceiros não precisarem dos recursos do sistema (por exemplo, a tela, a CPU).

  Por outro lado, PRECISA sair do estado S3 quando aplicativos de terceiros precisam dos recursos do sistema, conforme descrito neste SDK.

  Por exemplo, enquanto apps de terceiros solicitam manter a tela ligada usando FLAG_KEEP_SCREEN_ON ou a CPU usando PARTIAL_WAKE_LOCK, o dispositivo NÃO PODE entrar no estado S3, a menos que, conforme descrito em C-1-1, o usuário tenha tomado uma ação explícita para colocar o dispositivo em um estado inativo. Por outro lado, quando uma tarefa implementada por apps de terceiros por meio do JobScheduler é acionada ou quando o Firebase Cloud Messaging é entregue a apps de terceiros, o dispositivo PRECISA sair do estado do S3, a menos que o usuário o tenha colocado em um estado inativo. Esses não são exemplos abrangentes, e o AOSP implementa extensos sinais de ativação que acionam uma ativação desse estado.

8.4. Contabilidade de consumo de energia

Uma contabilidade e relatórios mais precisos do consumo de energia fornecem ao desenvolvedor de aplicativos os incentivos e as ferramentas para otimizar o padrão de uso de energia do aplicativo.

Implementações de dispositivos:

• [SR] MUITO RECOMENDADO que você forneça um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado de bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
• [SR] RECOMENDADO fortemente para informar todos os valores de consumo de energia em miliamperes-hora (mAh).
• [SR] RECOMENDADO MUITOMENTE para 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] É RECOMENDADO disponibilizar esse uso de energia pelo comando do shell do adb shell dumpsys batterystats para o desenvolvedor do app.
• DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.

8.5. Desempenho consistente

Em apps de alto desempenho e longa duração, o desempenho pode variar muito, seja por outros apps sendo executados em segundo plano ou por conta da limitação de CPU devido aos limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo for compatível, o aplicativo em primeiro plano poderá solicitar que o sistema otimize a alocação dos recursos para lidar com essas flutuações.

Implementações de dispositivos:

• [C-0-1] PRECISA informar o suporte ao Modo de desempenho sustentado com precisão usando o método PowerManager.isSustainedPerformanceModeSupported() da API.

• DEVE oferecer suporte ao modo de desempenho sustentado.

Se as implementações de dispositivos relatarem suporte ao modo de desempenho sustentado, elas:

• [C-1-1] PRECISA fornecer ao aplicativo em primeiro plano um nível consistente de desempenho por pelo menos 30 minutos, quando solicitado pelo app.
• [C-1-2] PRECISA respeitar a API Window.setSustainedPerformanceMode() e outras APIs relacionadas.

Se as implementações de dispositivos incluírem dois ou mais núcleos de CPU, elas:

• DEVE fornecer pelo menos um núcleo exclusivo que possa ser reservado pelo aplicativo em primeiro plano.

Se as implementações de dispositivos oferecerem suporte à reserva de um núcleo exclusivo para o aplicativo principal em primeiro plano, elas:

• [C-2-1] PRECISA informar, pelo método de API Process.getExclusiveCores(), os números de ID dos núcleos exclusivos que podem ser reservados pelo aplicativo em primeiro plano.
• [C-2-2] NÃO PODE permitir nenhum processo de espaço do usuário, exceto os drivers de dispositivo usados pelo aplicativo para serem executados nos núcleos exclusivos, mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

Se as implementações de dispositivos não oferecerem suporte a um núcleo exclusivo, elas:

• [C-3-1] PRECISA retornar uma lista vazia usando o método de API Process.getExclusiveCores().

9. Compatibilidade do modelo de segurança

Implementações de dispositivos:

• [C-0-1] PRECISA implementar um modelo de segurança consistente com o da Plataforma Android, conforme definido no documento de referência de segurança e permissões das APIs na documentação do desenvolvedor Android.

• [C-0-2] PRECISA oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades. Especificamente, os dispositivos compatíveis PRECISAM ser compatíveis com os mecanismos de segurança descritos nas subseções a seguir.

9,1. Permissões

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao modelo de permissões do Android, conforme definido na documentação do desenvolvedor 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 PRECISAM ser concedidas apenas a apps pré-instalados nos caminhos privilegiados da imagem do sistema e no subconjunto de permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito lendo e respeitando as permissões da lista de permissões para cada app dos arquivos no caminho etc/permissions/ e usando o caminho system/priv-app como o caminho privilegiado.

Permissões com um nível de proteção perigoso são as permissões de execução. Aplicativos com targetSdkVersion > 22 solicitá-las no ambiente de execução.

Implementações de dispositivos:

• [C-0-3] PRECISA mostrar uma interface dedicada para o usuário decidir se vai conceder as permissões de execução solicitadas e também fornecer uma interface para o usuário gerenciar essas permissões.
• [C-0-4] PRECISA ter apenas uma implementação das duas interfaces do usuário.
• [C-0-5] NÃO PODE conceder permissões 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 para o qual o aplicativo pré-instalado é definido como gerenciador padrão.
• [C-0-6] PRECISA conceder a permissão android.permission.RECOVER_KEYSTORE apenas a apps do sistema que registram um Agente de recuperação protegido corretamente. Um Agente de recuperação protegido de forma adequada é definido como um agente de software no dispositivo que é sincronizado com um armazenamento remoto fora do dispositivo. Ele é equipado com hardware seguro com proteção equivalente ou mais forte do que o descrito no Google Cloud Key Vault Service para evitar ataques de força bruta no fator de conhecimento da tela de bloqueio.

Implementações de dispositivos:

• [C-0-7] PRECISA aderir às propriedades de permissão de localização do Android quando um app solicita os dados de local ou de atividade física pela API padrão do Android ou por um mecanismo reservado. Esses dados incluem, entre outros:

  • a localização do dispositivo (por exemplo, latitude e longitude);
  • Informações que podem ser usadas para determinar ou estimar o local do dispositivo (por exemplo, SSID, BSSID, ID do celular ou local da rede à qual o dispositivo está conectado).
  • Atividade física do usuário ou classificação da atividade física.

Mais especificamente, implementações de dispositivos:

• [C-0-8] PRECISA ter o consentimento do usuário para permitir que o app acesse a dados de local ou atividade física.
• [C-0-9] PRECISA conceder uma permissão de execução APENAS ao app que contém permissão suficiente, conforme descrito no SDK. Por exemplo: O TelephonyManager#getServiceState requer 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 um papel associado às permissões hardRestricted a um app.
  • O instalador concede a hardRestricted a um app.
  • Um app recebe o hardRestricted em uma versão anterior do Android.

• [C-0-11] Os apps com uma permissão softRestricted PRECISAM ter acesso limitado e não podem ter acesso total até que estejam na lista de permissões, conforme descrito no SDK, em que o acesso total e limitado é definido para cada permissão do softRestricted (por exemplo, READ_EXTERNAL_STORAGE).

Se as implementações de dispositivos fornecerem funcionalidade ao usuário para escolher quais apps podem desenhar sobre outros com uma atividade que processe a intent ACTION_MANAGE_OVERLAY_PERMISSION, elas:

• [C-2-1] PRECISA garantir que todas as atividades com filtros de intent para a intent ACTION_MANAGE_OVERLAY_PERMISSION tenham a mesma tela da interface, independente do app inicial ou de qualquer informação fornecida.

9,2. UID e isolamento de processos

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao modelo de sandbox do aplicativo Android, no qual cada aplicativo é executado como um UID Unixstyle exclusivo e em um processo separado.
• [C-0-2] PRECISA oferecer suporte à execução de vários aplicativos com o mesmo ID do usuário do Linux, desde que os aplicativos sejam assinados e construídos corretamente, conforme definido na Referência de segurança e permissões.

9,3 Permissões do sistema de arquivos

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao modelo de permissões de acesso a arquivos do Android, conforme definido na Referência de segurança e permissões.

9,4. Ambientes de execução alternativos

As implementações de dispositivos PRECISAM manter a consistência do modelo de permissão e segurança do Android, mesmo que incluam ambientes de execução que executam aplicativos usando outro software ou tecnologia que não o Dalvik Executable Format ou o código nativo. Resumindo:

• [C-0-1] Os tempos de execução alternativos PRECISAM ser aplicativos Android e respeitar o modelo de segurança padrão do Android, conforme descrito em outra seção da seção 9.

• [C-0-2] Ambientes de execução alternativos NÃO PODEM ter acesso a recursos protegidos por permissões não solicitadas no arquivo AndroidManifest.xml do ambiente de execução pelo <uses-permission> mecanismo de atenção.

• [C-0-3] Tempos de execução alternativos NÃO PODEM permitir que aplicativos façam uso de recursos protegidos por permissões do Android restritas a aplicativos do sistema.

• [C-0-4] Tempos de execução alternativos PRECISAM respeitar o modelo de sandbox do Android, e os aplicativos instalados que usam um tempo de execução alternativo NÃO PODEM reutilizar o sandbox de nenhum outro aplicativo instalado no dispositivo, exceto por meio dos mecanismos padrão do Android para ID de usuário compartilhado e certificado de assinatura.

• [C-0-5] Ambientes de execução alternativos NÃO PODEM iniciar com, conceder ou receber acesso às sandboxes correspondentes a outros aplicativos Android.

• [C-0-6] Ambientes de execução alternativos NÃO PODEM ser iniciados, concedidos ou concedidos a outros aplicativos os privilégios do superusuário (raiz) ou de qualquer outro ID de usuário.

• [C-0-7] Quando os arquivos .apk de ambientes de execução alternativos são incluídos na imagem do sistema das implementações do dispositivo, eles PRECISAM ser assinados com uma chave diferente da usada para assinar outros apps incluídos nas implementações do dispositivo.

• [C-0-8] Ao instalar aplicativos, ambientes de execução alternativos PRECISAM receber o consentimento do usuário para as permissões do Android usadas pelo aplicativo.

• [C-0-9] Quando um aplicativo precisa usar um recurso de dispositivo para o qual há uma permissão correspondente do Android (como Câmera, GPS etc.), o tempo de execução alternativo PRECISA informar ao usuário que o aplicativo poderá acessar esse recurso.

• [C-0-10] Quando o ambiente de execução não registra os recursos do aplicativo dessa maneira, ele PRECISA listar todas as permissões mantidas pelo próprio ambiente de execução ao instalar qualquer aplicativo que use esse ambiente.

• Ambientes de execução alternativos DEVEM instalar apps pelo PackageManager em sandboxes separadas do Android (IDs de usuário do Linux etc.).

• Tempos de execução alternativos PODEM fornecer uma única sandbox do Android compartilhada por todos os aplicativos que usam o tempo de execução alternativo.

9,5 Suporte a multiusuário

O Android inclui suporte para vários usuários e permite isolamento total de usuários.

• As implementações de dispositivos PODEM, mas NÃO DEVERÃO ativar o recurso multiusuário se usarem mídia removível para armazenamento externo principal.

Se as implementações de dispositivos incluírem vários usuários, elas:

• [C-1-1] PRECISA atender aos seguintes requisitos relacionados ao suporte multiusuário.
• [C-1-2] PRECISA, para cada usuário, implementar um modelo de segurança consistente com o da Plataforma Android, conforme definido no documento de referência de segurança e permissões das APIs.
• [C-1-3] PRECISA ter diretórios de armazenamento compartilhado de aplicativos separados e isolados (também conhecido como /sdcard) para cada instância de usuário.
• [C-1-4] PRECISA garantir que os aplicativos pertencentes e executados em nome de um determinado usuário não possam listar, ler nem gravar nos arquivos de outro usuário, mesmo que os dados de ambos os usuários estejam armazenados no mesmo volume ou sistema de arquivos.
• [C-1-5] PRECISA criptografar o conteúdo do cartão SD quando o multiusuário estiver ativado usando uma chave armazenada somente em mídia não removível, acessível somente 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, será necessário que as implementações de dispositivos mudem para o MTP ou um sistema similar para fornecer aos PCs host o 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. As mensagens SMS premium são mensagens de texto enviadas a um serviço registrado em uma operadora que podem ser cobradas do usuário.

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

• [C-1-1] PRECISA avisar os usuários antes de enviar uma mensagem SMS para números identificados por expressões regulares definidas no arquivo /data/misc/sms/codes.xml no dispositivo. O Android Open Source Project upstream fornece uma implementação que atende a esse requisito.

9,7. Recursos de segurança

As implementações de dispositivos PRECISAM garantir a conformidade com os recursos de segurança do kernel e da plataforma, conforme descrito abaixo.

O Android Sandbox inclui recursos que usam o sistema de controle de acesso obrigatório (MAC, na sigla em inglês) do Security-Enhanced Linux (SELinux), o sandbox seccomp e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:

• [C-0-1] PRECISA manter a compatibilidade com os aplicativos atuais, mesmo quando o SELinux ou qualquer outro recurso de segurança for implementado abaixo do framework do Android.
• [C-0-2] NÃO PODE ter uma interface do usuário visível quando uma violação de segurança for detectada e bloqueada pelo recurso de segurança implementado abaixo do framework do Android, mas PODE ter uma interface do usuário visível quando ocorrer uma violação de segurança desbloqueada e resultar em uma exploração bem-sucedida.
• [C-0-3] NÃO PODE configurar o SELinux ou qualquer outro recurso de segurança implementado abaixo do framework do Android configurável pelo usuário ou desenvolvedor do app.
• [C-0-4] NÃO PODE permitir que um aplicativo que possa afetar outro por uma API (como uma Device Administration API) configure uma política que viole a compatibilidade.
• [C-0-5] PRECISA dividir o framework de mídia em vários processos para que seja possível conceder acesso mais restrito a cada processo, conforme descrito no site do Android Open Source Project.
• [C-0-6] PRECISA implementar um mecanismo de sandbox do aplicativo do kernel que permita a filtragem de chamadas do sistema usando uma política configurável de programas com várias linhas de execução. O Android Open Source Project upstream atende a esse requisito ativando o seccomp-BPF com sincronização de grupo de encadeamentos (TSYNC), conforme descrito na seção de configuração do kernel de source.android.com.

Os recursos de integridade e autoproteção do kernel são essenciais para a segurança do Android. Implementações de dispositivos:

• [C-0-7] PRECISA implementar mecanismos de proteção contra estouro do buffer da pilha do kernel. Exemplos desses mecanismos são CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] PRECISA implementar proteções rigorosas de memória do kernel em que o código executável é somente leitura, dados somente leitura não são executáveis nem graváveis e dados graváveis não são executáveis (por exemplo, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] PRECISA implementar a verificação de limites de tamanho de objetos estáticos e dinâmicos, verificando as cópias entre o espaço do usuário e o espaço do kernel (por exemplo, CONFIG_HARDENED_USERCOPY) em dispositivos originalmente fornecidos com o nível 28 da API ou mais recente.
• [C-0-10] NÃO PODE executar a memória do espaço do usuário ao executar no modo kernel (por exemplo, hardware PXN ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente fornecidos com o nível de API 28 ou mais recente.
• [C-0-11] NÃO PODE ler nem gravar memória do espaço do usuário no kernel fora das APIs normais de acesso a usercopy (por exemplo, PAN de hardware ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente fornecidos com o nível 28 da API ou mais recente.
• [C-0-12] PRECISA implementar o isolamento da tabela da página do kernel se o hardware estiver vulnerável à CVE-2017-5754 em todos os dispositivos originalmente enviados com o nível 28 da API ou mais recente (por exemplo, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] PRECISA implementar o aumento da proteção de previsão da ramificação se o hardware estiver vulnerável à CVE-2017-5715 em todos os dispositivos originalmente fornecidos com o nível 28 da API ou mais recente (por exemplo, CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] FORTEMENTE RECOMENDADO para 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] É MUITO RECOMENDADO para randomizar o layout do código do kernel e da memória e evitar exposições que comprometam a randomização (por exemplo, CONFIG_RANDOMIZE_BASE com entropia do carregador de inicialização usando /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

• [C-SR] É MUITO RECOMENDADO para ativar a integridade do fluxo de controle (CFI) no kernel para oferecer mais proteção contra ataques de reutilização de código (por exemplo, CONFIG_CFI_CLANG e CONFIG_SHADOW_CALL_STACK).

• [C-SR] É MUITO RECOMENDADO que você não desative a integridade do fluxo de controle (CFI), a pilha de chamadas de sombra (SCS) ou a limpeza de estouro de números inteiros (IntSan) em componentes com esse recurso ativado.
• [C-SR] É RECOMENDADO que você ative CFI, SCS e IntSan para quaisquer componentes adicionais do espaço do usuário sensíveis à segurança, conforme explicado em CFI e IntSan.
• [C-SR] É MUITO RECOMENDADO para ativar a inicialização de pilha no kernel e evitar usos de variáveis locais não inicializadas (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). Além disso, as implementações de dispositivos NÃO DEVEM assumir o valor usado pelo compilador para inicializar os locais.
• [C-SR] É FORTEMENTE RECOMENDADO ativar a inicialização de heap no kernel para evitar usos de alocações de heap não inicializadas (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) e NÃO DEVEM assumir o valor usado pelo kernel para inicializar essas alocações.

Se as implementações de dispositivos usarem um kernel do Linux, elas:

• [C-1-1] PRECISA implementar o SELinux.
• [C-1-2] PRECISA configurar o SELinux para o modo de aplicação global.
• [C-1-3] PRECISA configurar todos os domínios no modo de aplicação. Não são permitidos domínios de modo permissivo, incluindo domínios específicos de um dispositivo/fornecedor.
• [C-1-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes na pasta do sistema/sepolicy fornecida no Android Open Source Project (AOSP) upstream, e a política PRECISA ser compilada com todas as regras nunca permitir presentes, para domínios SELinux do AOSP e domínios específicos do dispositivo/fornecedor.
• [C-1-5] PRECISA executar aplicativos de terceiros direcionados ao nível de API 28 ou superior em sandboxes SELinux por aplicativo com restrições de SELinux por aplicativo no diretório de dados privados de cada aplicativo.
• DEVE manter a política SELinux padrão fornecida na pasta system/sepolicy do Android Open Source Project upstream e só incrementar essa política para a própria configuração específica do dispositivo.

Se as implementações de dispositivos já tiverem sido 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 de software do sistema, elas PODEM ser isentas desses requisitos.

Se as implementações de dispositivos usarem um kernel diferente do Linux, elas:

• [C-2-1] PRECISA usar um sistema de controle de acesso obrigatório equivalente ao SELinux.

O Android contém vários recursos de defesa em profundidade essenciais para a segurança do dispositivo.

9,8. Privacidade

9.8.1. Histórico de uso

O Android armazena o histórico de escolhas do usuário e o gerencia pelo UsageStatsManager.

Implementações de dispositivos:

• [C-0-1] PRECISA manter um período de retenção razoável desse histórico do usuário.
• [SR] É RECOMENDADO manter o período de armazenamento de 14 dias conforme configurado por padrão na implementação do AOSP.

O Android armazena os eventos do sistema usando os identificadores StatsLog e gerencia esse histórico pelo StatsManager e a API do sistema IncidentManager.

Implementações de dispositivos:

• [C-0-2] PRECISA incluir apenas os campos marcados com DEST_AUTOMATIC no relatório de incidentes criado pela classe IncidentManager da API do sistema.
• [C-0-3] Não é permitido usar os identificadores de eventos do sistema para registrar outros eventos além do descrito nos documentos do SDK do StatsLog. Se eventos adicionais do sistema forem registrados, eles PODEM usar um identificador atômico diferente no intervalo entre 100.000 e 200.000.

9.8.2. Gravações

Implementações de dispositivos:

• [C-0-1] NÃO PODE pré-carregar nem distribuir componentes de software prontos para uso que enviam informações particulares do usuário (por exemplo, pressionamentos de teclas, texto exibido na tela, relatório do bug) para fora do dispositivo sem o consentimento do usuário ou sem notificações contínuas.
• [C-0-2] PRECISA exibir e receber o consentimento explícito do usuário, permitindo que qualquer exibidas na tela do usuário sejam capturadas sempre que a transmissão de tela ou a gravação de tela são ativadas pelo MediaProjection ou APIs proprietárias. NÃO PODE fornecer aos usuários uma affordance para desativar futuras exibição do consentimento do usuário.
• [C-0-3] O usuário PRECISA manter uma notificação contínua para o usuário enquanto a transmissão ou a gravação de tela estão ativadas. O AOSP atende a esse requisito mostrando um ícone de notificação contínua na barra de status.

Se as implementações do dispositivo incluírem uma funcionalidade no sistema que capture o conteúdo mostrado na tela e/ou grave o stream de áudio reproduzido no dispositivo de outra forma que não seja a API System ContentCaptureService ou outros meios reservados descritos na Seção 9.8.6 Captura de conteúdo, elas:

• [C-1-1] PRECISA manter sempre uma notificação ao usuário sempre que essa funcionalidade estiver ativada e que estiver capturando/gravando ativamente.

Se as implementações do dispositivo incluírem um componente habilitado e pronto para uso, capaz de gravar áudio do ambiente e/ou gravar o áudio reproduzido no dispositivo para inferir informações úteis sobre o contexto do usuário:

• [C-2-1] NÃO PODE armazenar no armazenamento persistente no dispositivo nem transmitir para fora do dispositivo o áudio bruto gravado ou qualquer formato que possa ser convertido de volta ao áudio original ou a um fax, exceto com o consentimento explícito do usuário.

9.8.3. Conectividade

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

• [C-1-1] PRECISA apresentar uma interface do usuário solicitando o consentimento do usuário antes de permitir o acesso ao conteúdo do armazenamento compartilhado pela porta USB.

9.8.4. Tráfego de rede

Implementações de dispositivos:

• [C-0-1] É NECESSÁRIO pré-instalar os mesmos certificados raiz do repositório da autoridade de certificação (CA) confiável, conforme fornecido no Android Open Source Project.
• [C-0-2] PRECISA enviar com um repositório de CAs raiz de usuário vazio.
• [C-0-3] PRECISA exibir um aviso ao usuário indicando que o tráfego de rede pode ser monitorado quando uma CA raiz do usuário for adicionada.

Se o tráfego do dispositivo for roteado por uma VPN, as implementações do dispositivo:

• [C-1-1] PRECISA exibir um aviso ao usuário indicando:
  • Esse tráfego de rede pode ser monitorado.
  • Esse tráfego de rede está sendo roteado pelo aplicativo de VPN específico que fornece a VPN.

Se as implementações de dispositivos tiverem um mecanismo, ativado e pronto para uso por padrão, que roteie 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] PRECISA solicitar o consentimento do usuário antes de ativar esse mecanismo, a menos que a VPN seja ativada pelo controlador de política de dispositivo pelo DevicePolicyManager.setAlwaysOnVpnPackage(). Nesse caso , o usuário não precisa fornecer um consentimento separado, mas PRECISA ser notificado.

Se as implementações de dispositivos implementarem uma funcionalidade de usuário para alternar para a "VPN sempre ativa" de um app de VPN de terceiros, elas:

• [C-3-1] É NECESSÁRIO desativar essa funcionalidade do usuário para apps que não são compatíveis com o serviço de VPN sempre ativada no arquivo AndroidManifest.xml definindo o atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON como false.

9.8.5. Identificadores de dispositivo

Implementações de dispositivos:

• [C-0-1] PRECISA impedir o acesso ao número de série do dispositivo e, quando aplicável, ao IMEI/MEID, ao número de série do chip e à Identidade internacional de assinante móvel (IMSI, na sigla em inglês) de um app, a menos que ele atenda a um dos seguintes requisitos:
  • é um app de operadora assinado verificado pelos fabricantes de dispositivos.
  • recebeu a permissão READ_PRIVILEGED_PHONE_STATE.
  • tem privilégios de operadora, conforme definido nos Privilégios de operadora do UICC.
  • é um proprietário de dispositivo ou perfil que recebeu a permissão READ_PHONE_STATE.
  • (Somente para o número de série do chip/ICCID) tem o requisito de regulamentações locais de que o app detecte mudanças na identidade do assinante.

9.8.6. Captura de conteúdo

O Android, pela API do sistema ContentCaptureService ou por outros meios reservados, oferece suporte a um mecanismo para implementações de dispositivos que capturem as interações abaixo entre os aplicativos e o usuário.

• Texto e gráficos renderizados na tela, incluindo, mas não se limitando a, notificações e dados de assistência pela API AssistStructure.
• Dados de mídia, como áudio ou vídeo, gravados ou reproduzidos pelo dispositivo.
• Eventos de entrada (por exemplo, tecla, mouse, gesto, voz, vídeo e acessibilidade).
• Quaisquer outros eventos que um aplicativo fornece ao sistema pela API Content Capture ou uma API reservada com recursos semelhantes.
• Qualquer texto ou outro dado enviado pelo TextClassifier API ao TextClassifier do sistema, ou seja, ao serviço do sistema para entender o significado do texto e gerar as próximas ações previstas com base nele.

Se as implementações de dispositivos capturarem os dados acima, elas:

• [C-1-1] PRECISA criptografar todos esses dados quando armazenados no dispositivo. Essa criptografia PODE ser realizada usando a criptografia baseada em arquivos do Android ou qualquer uma das criptografias listadas como versão 26+ da API descrita em SDK de criptografia.
• [C-1-2] NÃO É POSSÍVEL fazer backup de dados brutos ou criptografados usando os métodos de backup do Android ou qualquer outro método de backup.
• [C-1-3] PRECISA enviar apenas todos esses dados e o registro do dispositivo usando um mecanismo de preservação de privacidade. O mecanismo de preservação de privacidade é definido como "aqueles que permitem apenas análises agregadas e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais" para evitar que qualquer dado do usuário seja introspectivo (por exemplo, implementado usando uma tecnologia de privacidade diferencial, como RAPPOR).
• [C-1-4] NÃO PODE associar esses dados a nenhuma identidade do usuário (como o Account) no dispositivo, exceto com o consentimento explícito do usuário toda vez que os dados forem associados.
• [C-1-5] NÃO PODE compartilhar esses dados com outros apps, exceto com o consentimento explícito do usuário sempre que eles forem compartilhados.
• [C-1-6] PRECISA fornecer recursos ao usuário para apagar dados coletados pela ContentCaptureService ou pelos meios reservados se eles estiverem armazenados de qualquer forma no dispositivo.

Se as implementações de dispositivos incluírem um serviço que implemente a API do sistema ContentCaptureService ou qualquer serviço reservado que capture os dados conforme descrito acima, elas:

• [C-2-1] NÃO PODE permitir que os usuários substituam o serviço de captura de conteúdo por um app ou serviço instalável pelo usuário e PRECISA permitir apenas que o serviço pré-instalado capture esses dados.
• [C-2-2] NÃO PODE permitir que outros apps além do mecanismo de serviço de captura de conteúdo pré-instalado capturem esses dados.
• [C-2-3] PRECISA fornecer recursos do usuário para desativar o serviço de captura de conteúdo.
• [C-2-4] NÃO É NECESSÁRIO omitir a funcionalidade do usuário para gerenciar as permissões do Android retidas 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] É FORTEMENTE RECOMENDADO manter os componentes do serviço de captura de conteúdo separados, por exemplo, sem vincular os IDs do processo de compartilhamento ou serviço 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 PODE retornar dados recortados na área de transferência (por exemplo, pela API ClipboardManager), a menos que o app seja o IME padrão ou seja o app em foco no momento.

9.8.8. Local

Implementações de dispositivos:

• [C-0-1] NÃO PODE ativar/desativar a configuração de localização do dispositivo e as configurações de busca por Wi-Fi/Bluetooth sem o consentimento explícito do usuário ou iniciação do usuário.
• [C-0-2] PRECISA fornecer ao usuário recursos para acessar informações relacionadas à localização, incluindo solicitações recentes de localização, permissões no nível do app e uso de busca por Wi-Fi/Bluetooth para determinar a localização.
• [C-0-3] PRECISA garantir que o app que está usando a API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] seja uma sessão de emergência iniciada pelo usuário (por exemplo, disque 911 ou envie uma mensagem de texto para 911). No entanto, para o setor automotivo, um veículo PODE iniciar uma sessão de emergência sem interação do usuário ativo caso um acidente/acidente seja detectado (por exemplo, para atender aos requisitos de chamadas eletrônicas).
• [C-0-4] PRECISA preservar a capacidade da API Emergency Location Bypass de ignorar as configurações de localização do dispositivo sem mudar as configurações.
• [C-0-5] PRECISA programar uma notificação para lembrar o usuário depois que um app em segundo plano acessar a localização dele usando a permissão [ACCESS_BACKGROUND_LOCATION].

9.8.9. Apps instalados

Por padrão, os apps Android destinados ao nível 30 da API ou versões mais recentes não têm acesso a detalhes sobre outros apps instalados. Consulte Visibilidade do pacote na documentação do SDK do Android.

Implementações de dispositivos:

• [C-0-1] NÃO É POSSÍVEL expor detalhes sobre qualquer outro app instalado em apps direcionados ao nível 30 da API ou mais recente, a menos que eles já possam acessar os detalhes do outro app instalado pelas APIs gerenciadas. Isso inclui, sem limitação, detalhes expostos por quaisquer APIs personalizadas adicionadas pelo implementador do dispositivo ou acessíveis por meio do sistema de arquivos.

9.8.10. Relatório de bugs de conectividade

Se as implementações do dispositivo gerarem relatórios de bug usando a API do sistema BUGREPORT_MODE_TELEPHONY com o BugreportManager, elas:

• [C-1-1] PRECISA ter o consentimento do usuário sempre que a API do sistema BUGREPORT_MODE_TELEPHONY for chamada para gerar um relatório e NÃO PODE solicitar o consentimento do usuário para todas as solicitações futuras do aplicativo.
• [C-1-2] PRECISA mostrar e ter o consentimento explícito do usuário quando os relatórios começarem a ser gerados e NÃO PODE retornar o relatório gerado ao app solicitante sem o consentimento explícito do usuário.
• [C-1-3] PRECISA gerar os relatórios solicitados contendo pelo menos as seguintes informações:
  • Dump de TelephonyDebugService
  • Dump de TelephonyRegistry
  • Despejo de Wi-Fi
  • Dump de ConnectivityService
  • Um despejo da instância CarrierService do pacote de chamada (se vinculado)
  • Buffer de registro de rádio
• [C-1-4] NÃO PODE incluir o seguinte nos relatórios gerados:
  • Qualquer tipo de informação não relacionada à depuração de conectividade.
  • Qualquer tipo de registros de tráfego de aplicativos instalados pelo usuário ou perfis detalhados de aplicativos/pacotes instalados pelo usuário (UIDs são aceitos, 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 do fornecedor).

Se as implementações do dispositivo incluírem outras informações (por exemplo, registros do fornecedor) no relatório do bug e isso afetar a privacidade/segurança/bateria/armazenamento/memória, elas:

• [C-SR] É FORTEMENTE RECOMENDADO que a configuração de desenvolvedor seja desativada por padrão. O AOSP atende a isso oferecendo a opção Enable verbose vendor logging nas configurações do desenvolvedor para incluir outros registros de fornecedores específicos do dispositivo nos relatórios do bug.

9.8.11. Compartilhamento de blobs de dados

O Android, por meio do BlobStoreManager, permite que os apps contribuam com blobs de dados para o sistema serem compartilhados com um conjunto selecionado de apps.

Se as implementações de dispositivos forem compatíveis com blobs de dados compartilhados, conforme descrito na documentação do SDK, elas:

• [C-1-1] NÃO PODE compartilhar blobs de dados pertencentes a apps além do que pretendiam permitir (ou seja, o escopo do acesso padrão e os outros modos de acesso que podem ser especificados usando BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowPackageAccess() ou BlobSameStoreManager.session#allowPublicAccess() NÃO PODE ser modificado). A implementação de referência do AOSP atende a esses requisitos.
• [C-1-2] NÃO É POSSÍVEL enviar para fora do dispositivo nem compartilhar com outros apps os hashes seguros dos blobs de dados, que são usados para controlar o acesso.

9,9. Criptografia do armazenamento de dados

Todos os dispositivos PRECISAM atender aos requisitos da seção 9.9.1. Os dispositivos iniciados em um nível de API anterior àquele deste documento estão isentos dos requisitos das seções 9.9.2 e 9.9.3. Em vez disso, eles PRECISAM atender aos requisitos da seção 9.9 do documento de definição de compatibilidade do Android correspondente ao nível da API em que o dispositivo foi iniciado.

9.9.1. Inicialização direta

Implementações de dispositivos:

• [C-0-1] PRECISA implementar as APIs do modo de inicialização direta, mesmo que elas não ofereçam suporte à criptografia de armazenamento.

• [C-0-2] As intents ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED ainda PRECISAM ser transmitidas para sinalizar aos apps com reconhecimento de inicialização direta que os locais de armazenamento criptografado pelo dispositivo (DE) e criptografado por credencial (CE) estão disponíveis para o usuário.

9.9.2. Requisitos de criptografia

Implementações de dispositivos:

• [C-0-1] PRECISA criptografar os dados particulares do aplicativo (partição /data), bem como a partição de armazenamento compartilhado do aplicativo (partição /sdcard) se ela for uma parte permanente e não removível do dispositivo.
• [C-0-2] PRECISA ativar a criptografia do armazenamento de dados por padrão quando o usuário tiver concluído a configuração pronta.

• [C-0-3] PRECISA atender ao requisito de criptografia do armazenamento de dados acima implementando um dos dois métodos de criptografia a seguir:

  • Criptografia baseada em arquivos (FBE, na sigla em inglês) e Criptografia de metadados, conforme descrito na seção 9.9.3.1.
  • Criptografia em nível de bloco por usuário, conforme descrito na seção 9.9.3.2.

9.9.3. Métodos de criptografia

Se as implementações de dispositivos forem criptografadas, elas:

• [C-1-1] PRECISA inicializar sem solicitar credenciais ao usuário e permitir que apps com reconhecimento de inicialização direta acessem o armazenamento criptografado do dispositivo depois que a mensagem ACTION_LOCKED_BOOT_COMPLETED for transmitida.
• [C-1-2] PRECISA permitir o acesso ao armazenamento criptografado por credenciais (CE, na sigla em inglês) somente depois que o usuário desbloquear o dispositivo informando as credenciais dele (por exemplo, senha, PIN, padrão ou impressão digital) e a mensagem ACTION_USER_UNLOCKED for transmitida.
• [C-1-13] NÃO PODE oferecer nenhum método para desbloquear o armazenamento protegido por CE sem as credenciais fornecidas pelo usuário, uma chave de garantia registrada ou um currículo na implementação que atenda aos requisitos da seção 9.9.4.
• [C-1-4] PRECISA usar a Inicialização verificada.

9.9.3.1. Criptografia baseada em arquivos e metadados

Se as implementações de dispositivos usarem a criptografia baseada em arquivos com criptografia de metadados, elas:

• [C-1-5] PRECISA criptografar conteúdos de arquivos e 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, operada no modo XTS. o comprimento total da chave é de 512 bits. Adiantum se refere a Adiantum-XChaCha12-AES, conforme especificado em https://github.com/google/adiantum. Os metadados do sistema de arquivos são dados como tamanhos de arquivo, propriedade, modos e atributos estendidos (xattrs).
• [C-1-6] PRECISA criptografar nomes de arquivos usando AES-256-CBC-CTS ou Adiantum.
• [C-1-12] Se o dispositivo tiver instruções do Padrão de criptografia avançada (AES, na sigla em inglês), como extensões de criptografia ARMv8 em dispositivos baseados em ARM ou AES-NI em dispositivos baseados em x86, as opções baseadas em AES acima para nome do arquivo, conteúdo do arquivo e criptografia de metadados do sistema de arquivos PRECISAM ser usadas, não Adiantum.
• [C-1-13] PRECISA usar uma função de derivação de chaves com criptografia forte e não reversível (por exemplo, HKDF-SHA512) para derivar subchaves necessárias (por exemplo, chaves por arquivo) das chaves CE e DE. "Criptografia forte e irreversível" significa que a função de derivação de chaves tem uma força de segurança de pelo menos 256 bits e se comporta como uma família de funções pseudoaleatórias nas entradas.

• [C-1-14] NÃO PODE usar as mesmas chaves ou subchaves de criptografia baseada em arquivos (FBE, na sigla em inglês) para diferentes propósitos criptográficos (por exemplo, para criptografia e derivação de chaves ou para dois algoritmos de criptografia diferentes).

• As chaves que protegem as áreas de armazenamento CE e DE e os metadados do sistema de arquivos:

• [C-1-7] PRECISA estar vinculado criptograficamente a um Keystore protegido por hardware. Este keystore PRECISA estar vinculado à Inicialização verificada e à raiz de confiança do hardware do dispositivo.

• [C-1-8] As chaves CE PRECISAM estar vinculadas às credenciais da tela de bloqueio de um usuário.
• [C-1-9] As chaves CE PRECISAM ser vinculadas a uma senha padrão quando o usuário não especifica as credenciais da tela de bloqueio.
• [C-1-10] PRECISA ser única e distinta, ou seja, nenhuma chave CE ou DE do usuário corresponde a nenhuma chave CE ou DE de outro usuário.

• [C-1-11] PRECISA usar as criptografias, os comprimentos e os modos de chave aceitos obrigatoriamente.

• DEVE tornar os apps essenciais pré-instalados (por exemplo, Alarme, Telefone, Messenger) com reconhecimento de inicialização direta.

O projeto Android Open Source oferece uma implementação preferencial de criptografia baseada em arquivos com base no kernel "fscrypt" do Linux e de Metadados com base no kernel do Linux "dm-default-key" .

9.9.3.2. Criptografia no nível de bloco por usuário

Se as implementações de dispositivos usarem criptografia no nível de bloco por usuário, elas:

• [C-1-1] PRECISA ativar o suporte multiusuário, conforme descrito na seção 9.5.
• [C-1-2] PRECISA fornecer partições por usuário, usando partições brutas ou volumes lógicos.
• [C-1-3] PRECISA usar chaves de criptografia exclusivas e distintas por usuário para a criptografia dos dispositivos de bloco subjacentes.

• [C-1-4] PRECISA usar o AES-256-XTS para a criptografia em nível de bloco das partições do usuário.

• As chaves que protegem os dispositivos criptografados no nível de bloco por usuário:

• [C-1-5] PRECISA estar vinculado criptograficamente a um Keystore protegido por hardware. Este keystore PRECISA estar vinculado à Inicialização verificada e à raiz de confiança do hardware do dispositivo.

• [C-1-6] PRECISA estar vinculado às credenciais correspondentes da tela de bloqueio do usuário.

A criptografia no nível de bloco por usuário pode ser implementada com o recurso “dm-crypt” do kernel do Linux em partições por usuário.

9.9.4. Retomar na reinicialização

A opção "Retomar na reinicialização" permite desbloquear o armazenamento CE de todos os apps, incluindo aqueles que ainda não são compatíveis com a inicialização direta, após uma reinicialização iniciada por um OTA. Esse recurso permite que os usuários recebam notificações de apps instalados após a reinicialização.

A implementação de "Retomar na reinicialização" precisa continuar para garantir que, quando um dispositivo cair nas mãos de um invasor, seja extremamente difícil para o invasor recuperar os dados criptografados por CE, mesmo que o dispositivo esteja ligado, o armazenamento CE esteja desbloqueado e o usuário o desbloqueie após receber uma atualização OTA. Para resistência a ataques de pessoas com informações privilegiadas, também presumimos que o invasor obtém acesso a chaves de assinatura criptográficas para a transmissão.

Especificamente:

• [C-0-1] O armazenamento CE NÃO PODE ser legível, mesmo para o invasor que tenha o dispositivo fisicamente e que tenha estes recursos e limitações:

  • Pode usar a chave de assinatura de qualquer fornecedor ou empresa para assinar mensagens arbitrárias.
  • Pode fazer com que um OTA seja recebido pelo dispositivo.
  • Pode modificar a operação de qualquer hardware (AP, flash etc.), exceto conforme detalhado abaixo, mas essa modificação envolve um atraso de pelo menos uma hora e uma reinicialização que destrói o conteúdo da RAM.
  • Não pode modificar a operação de hardware resistente a adulterações (por exemplo, Titan M).
  • Não é possível ler a RAM do dispositivo ativo.
  • Não é possível conseguir a credencial do usuário (PIN, padrão, senha) ou fazer com que ela seja inserida.

Por exemplo, uma implementação de dispositivo que implemente e obedeça a todas as descrições encontradas neste link estará em conformidade com [C-0-1].

9,10 Integridade do dispositivo

Os requisitos a seguir garantem que o status da integridade do dispositivo seja transparente. Implementações de dispositivos:

• [C-0-1] PRECISA informar corretamente, pelo método PersistentDataBlockManager.getFlashLockState() da API do sistema, se o estado do carregador de inicialização permite a atualização da imagem do sistema. O estado FLASH_LOCK_UNKNOWN é reservado para implementações de dispositivos que fizeram upgrade de uma versão anterior do Android, em que esse novo método de API do sistema não existia.

• [C-0-2] PRECISA oferecer suporte à Inicialização verificada para garantir a integridade do dispositivo.

Se as implementações de dispositivos já tiverem sido lançadas em uma versão anterior do Android sem suporte à Inicialização verificada e não puderem adicionar suporte a esse recurso com uma atualização de software do sistema, elas PODEM ser isentas da exigência.

A Inicialização verificada é um recurso que garante a integridade do software do dispositivo. Se as implementações de dispositivos forem compatíveis com o recurso, elas:

• [C-1-1] PRECISA declarar a flag de recurso da plataforma android.software.verified_boot.
• [C-1-2] PRECISA fazer a verificação em todas as sequências de inicialização.
• [C-1-3] PRECISA iniciar a verificação usando uma chave de hardware imutável que é a raiz de confiança e ir até a partição do sistema.
• [C-1-4] PRECISA implementar cada estágio da verificação para conferir a integridade e a autenticidade de todos os bytes no estágio seguinte antes de executar o código na etapa seguinte.
• [C-1-5] PRECISA usar algoritmos de verificação tão fortes quanto as recomendações atuais do NIST para algoritmos de hash (SHA-256) e tamanhos de chave pública (RSA-2048).
• [C-1-6] NÃO PODE permitir que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário autorize a inicialização mesmo assim. Nesse caso, os dados de blocos de armazenamento não verificados não PODEM ser usados.
• [C-1-7] NÃO PODE permitir que partições verificadas no dispositivo sejam modificadas, a menos que o usuário tenha desbloqueado explicitamente o carregador de inicialização.
• [C-SR] Se houver vários chips distintos no dispositivo (por exemplo, rádio, processador de imagem especializado), o processo de inicialização de cada um deles será FORTEMENTE RECOMENDADO para verificar cada estágio na inicialização.
• [C-1-8] PRECISA usar um armazenamento inviolável para armazenar se o carregador de inicialização está desbloqueado. Um armazenamento à prova de adulterações significa que o carregador de inicialização pode detectar se o armazenamento foi adulterado no Android.
• [C-1-9] PRECISA solicitar ao usuário enquanto usa o dispositivo e exigir confirmação física antes de permitir uma transição do modo bloqueado do carregador de inicialização para o modo desbloqueado.
• [C-1-10] PRECISA implementar a proteção contra reversão para partições usadas pelo Android (por exemplo, inicialização e partições do sistema) e usar armazenamento à prova de adulterações para armazenar os metadados usados para determinar a versão mínima permitida do SO.
• [C-SR] É ALTAMENTE RECOMENDADO para verificar todos os arquivos APK de apps privilegiados com uma cadeia de confiança enraizada em partições protegidas pela Inicialização verificada.
• [C-SR] É FORTEMENTE RECOMENDADO para verificar todos os artefatos executáveis carregados por um app privilegiado de fora do arquivo APK (como um código carregado dinamicamente ou compilado) antes de executá-los ou RECOMENDADOS FORTEMENTE para não executá-los.
• DEVE implementar proteção contra reversão para qualquer componente com firmware persistente (por exemplo, modem, câmera) e DEVE usar armazenamento à prova de adulterações para armazenar os metadados usados para determinar a versão mínima permitida.

Se as implementações de dispositivos já tiverem sido lançadas sem suporte de 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 oferece uma implementação preferencial desse recurso no repositório external/avb/, que pode ser integrado ao carregador de inicialização usado para carregar o Android.

Implementações de dispositivos:

• [C-0-3] PRECISA 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 PODE permitir que as solicitações de leitura em um arquivo protegido sejam bem-sucedidas quando o conteúdo de leitura não for verificado com base em uma chave confiável.

Se as implementações de dispositivos já tiverem sido lançadas sem a possibilidade de verificar o conteúdo do arquivo com base em uma chave confiável em uma versão anterior do Android e não for possível adicionar suporte para esse recurso com uma atualização de software do sistema, elas PODEM ser isentas da exigência. O projeto upstream do Android Open Source oferece uma implementação preferencial desse recurso com base no recurso fs-verity do kernel do Linux.

Implementações de dispositivos:

• [C-R] São RECOMENDADOS para oferecer suporte à API Confirmação protegida pelo Android.

Se as implementações de dispositivos oferecerem suporte à API Confirmação protegida pelo Android, elas:

• [C-3-1] PRECISA informar true para a API ConfirmationPrompt.isSupported().

• [C-3-2] PRECISA garantir que o código em execução no SO Android, incluindo o kernel, malicioso ou não, não possa gerar uma resposta positiva sem a interação do usuário.

• [C-3-3] PRECISA garantir que o usuário possa analisar e aprovar a mensagem solicitada, mesmo que o SO Android, incluindo o kernel, seja comprometido.

9,11. Chaves e credenciais

O sistema Android Keystore permite que os desenvolvedores de apps armazenem chaves criptográficas em um contêiner e as usem em operações criptográficas com a API KeyChain ou a API Keystore. Implementações de dispositivos:

• [C-0-1] PRECISA permitir a importação ou geração de pelo menos 8.192 chaves.
• [C-0-2] A autenticação da tela de bloqueio PRECISA ter tentativas de limite de taxa e um algoritmo de espera exponencial. Após 150 tentativas com falha, o atraso PRECISA ser de pelo menos 24 horas por tentativa.
• Não devem limitar o número de chaves que podem ser geradas

Quando a implementação do dispositivo é compatível com uma tela de bloqueio segura, ela:

• [C-1-1] PRECISA fazer backup da implementação do keystore com um ambiente de execução isolado.
• [C-1-2] PRECISA ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash das famílias MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos com suporte do sistema Android Keystore em uma área segura e 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 a DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura revisada por terceiros de um isolamento adequado baseado em hipervisor são opções alternativas.
• [C-1-3] PRECISA realizar a autenticação da tela de bloqueio no ambiente de execução isolado e, somente quando bem-sucedido, permitir o uso das chaves vinculadas à autenticação. As credenciais da tela de bloqueio PRECISAM ser armazenadas de uma forma que permita que apenas o ambiente de execução isolado execute a autenticação na tela de bloqueio. O Android Open Source Project fornece a Camada de abstração de hardware (HAL) Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
• [C-1-4] PRECISA oferecer suporte ao atestado de chaves em que a chave de assinatura de atestado é protegida por um hardware seguro e a assinatura é realizada em um hardware seguro. As chaves de assinatura de atestado PRECISAM ser compartilhadas entre um número grande de dispositivos para evitar que elas sejam usadas como identificadores de dispositivos. Uma maneira de atender a esse requisito é compartilhar a mesma chave de atestado,a menos que pelo menos 100.000 unidades de uma determinada SKU sejam produzidas. Se mais de 100.000 unidades de uma SKU forem produzidas, uma chave diferente poderá ser usada para cada 100.000 unidades.

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior do Android, esse dispositivo está isento da exigência de ter um keystore apoiado por um ambiente de execução isolado e oferecer suporte ao atestado de chaves, a menos que ele declare o recurso android.hardware.fingerprint, que exige um keystore apoiado por um ambiente de execução isolado.

• [C-1-5] PRECISA permitir que o usuário escolha o tempo limite de suspensão para fazer a transição do estado desbloqueado para o bloqueado, com um tempo limite mínimo permitido de até 15 segundos. Dispositivos automotivos que bloqueiam a tela sempre que a unidade principal é desligada ou o usuário é ligado podem NÃO ter a configuração de tempo limite de suspensão.

9.11.1. Autenticação e tela de bloqueio segura

A implementação do AOSP segue um modelo de autenticação em camadas em que uma autenticação primária baseada em uma 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] É FORTEMENTE RECOMENDADO definir apenas um dos seguintes como método de autenticação principal:
  • Um PIN numérico
  • Uma senha alfanumérica
  • Um padrão de deslizar em uma grade de exatamente 3 x 3 pontos

Observe que os métodos de autenticação acima são referidos como os métodos de autenticação principais recomendados neste documento.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação principais recomendados e usarem um novo método de autenticação como uma maneira segura de bloquear a tela, o novo método de autenticação:

• [C-2-1] PRECISA ser o método de autenticação do usuário, conforme descrito em Exigir autenticação do usuário para o uso de chaves.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio se forem baseados em um segredo conhecido e usarem um novo método de autenticação a ser tratado como uma maneira segura de bloquear a tela:

• [C-3-1] A entropia do menor comprimento permitido das entradas PRECISA ser maior que 10 bits.
• [C-3-2] A entropia máxima de todas as entradas possíveis PRECISA ser maior que 18 bits.
• [C-3-3] O novo método de autenticação NÃO PODE substituir nenhum dos métodos principais recomendados de autenticação (por exemplo, PIN, padrão, senha) implementados e fornecidos no AOSP.
• [C-3-4] O novo método de autenticação PRECISA ser desativado quando o aplicativo Device Policy Controller (DPC) define a política de qualidade de 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 DEVEM recorrer aos métodos de autenticação principais recomendados (por exemplo, PIN, padrão e senha) uma vez a cada 72 horas ou menos OU divulgar claramente ao usuário que não será feito backup de alguns dados para preservar a privacidade deles.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação principais recomendados para desbloquear a tela de bloqueio e usarem um novo método de autenticação baseado na biometria para ser tratado como uma maneira segura de bloquear a tela, o novo método:

• [C-4-1] PRECISA atender a todos os requisitos descritos na seção 7.3.10 para a Classe 1 (antiga Conveniência).
• [C-4-2] PRECISA ter um mecanismo de fallback para o uso de um dos métodos de autenticação principais recomendados, que é baseado em um secret conhecido.
• [C-4-3] PRECISA ser desativado e só permite que a autenticação principal recomendada desbloqueie a tela quando o aplicativo do controlador de política de dispositivo (DPC) tiver definido a política de recurso de proteção de teclado chamando o método DevicePolicyManager.setKeyguardDisabledFeatures() com qualquer uma das sinalizações biométricas associadas (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 Device Policy Controller (DPC) tiver definido a política de qualidade de senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] O usuário PRECISA ser contestado quanto à autenticação principal recomendada (por exemplo, PIN, padrão, senha), conforme descrito em [C-1-7] e [C-1-8] na seção 7.3.10.
• [C-5-3] Os métodos NÃO PODEM ser tratados como uma tela de bloqueio segura e PRECISAM atender aos requisitos que começam com C-8 nesta seção abaixo.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio e um novo método de autenticação for baseado em um token físico ou no local:

• [C-6-1] Eles PRECISAM ter um mecanismo de fallback para usar um dos métodos de autenticação principais recomendados, que é baseado em um secret conhecido e atender aos requisitos para serem tratados como uma tela de bloqueio segura.
• [C-6-2] O novo método PRECISA ser desativado e permitir apenas um dos métodos de autenticação principais recomendados para desbloquear a tela quando o aplicativo Device Policy Controller (DPC) tiver definido a política com o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva que PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] O usuário PRECISA ser desafiado por um dos métodos principais de autenticação recomendados (por exemplo, PIN, padrão ou 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 PRECISA seguir as restrições listadas em C-8 abaixo.

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

• [C-7-1] PRECISA ter uma indicação clara no menu de configurações e na tela de bloqueio quando o bloqueio do dispositivo é adiado ou quando pode ser desbloqueado por agentes de confiança. Por exemplo, o AOSP atende a esse requisito mostrando uma descrição de texto para a "Configuração de bloqueio automático". e "Botão liga/desliga bloqueia instantaneamente" no menu de configurações e um ícone distinguível na tela de bloqueio.
• [C-7-2] PRECISA respeitar e implementar totalmente todas as APIs do agente de confiança na classe DevicePolicyManager, como a constante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NÃO PODE implementar completamente a função TrustAgentService.addEscrowToken() em um dispositivo usado como dispositivo pessoal principal (por exemplo, portátil), mas PODE implementar totalmente a função em implementações de dispositivo que normalmente são compartilhadas (por exemplo, Android Television ou Automotive).
• [C-7-4] PRECISA criptografar todos os tokens armazenados adicionados por TrustAgentService.addEscrowToken().
• [C-7-5] NÃO PODE armazenar a chave de criptografia ou o token de garantia no mesmo dispositivo em que a chave é usada. Por exemplo, uma chave armazenada em um smartphone pode desbloquear uma conta de usuário em uma TV. Para dispositivos automotivos, não é permitido armazenar o token de garantia em nenhuma parte do veículo.
• [C-7-6] PRECISA informar o usuário sobre as implicações de segurança antes de ativar o token de garantia para descriptografar o armazenamento de dados.
• [C-7-7] PRECISA ter um mecanismo de fallback para o uso de um dos métodos de autenticação principais recomendados.
• [C-7-8] O usuário PRECISA ser desafiado a usar um dos métodos principais de autenticação recomendados (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 72 horas ou menos, a menos que a segurança do usuário (por exemplo, distração do motorista) seja preocupante.
• [C-7-9] O usuário PRECISA ser contestado por um dos principais métodos de autenticação recomendados (por exemplo, PIN, padrão, senha), conforme descrito em [C-1-7] e [C-1-8] na seção 7.3.10, a menos que a segurança do usuário (por exemplo, distração do motorista) seja preocupante.
• [C-7-10] NÃO PODE ser tratado como uma tela de bloqueio segura e PRECISA seguir as restrições listadas em C-8 abaixo.
• [C-7-11] NÃO PODE permitir que os TrustAgents em dispositivos pessoais principais (por exemplo, portáteis) desbloqueiem o dispositivo.Eles só podem ser usados para manter um dispositivo já desbloqueado no estado desbloqueado por até quatro horas. A implementação padrão do TrustManagerService no AOSP atende a esse requisito.
• [C-7-12] PRECISA usar um canal de comunicação seguro criptograficamente (por exemplo, UKEY2) para transmitir o token de garantia do dispositivo de armazenamento para o de destino.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio que não seja segura, conforme descrito acima, e usarem um novo método de autenticação para desbloquear o bloqueio:

• [C-8-1] O novo método PRECISA ser desativado quando o aplicativo Device Policy Controller (DPC) define a política de qualidade de senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] NÃO PODE redefinir os timers de expiração da senha definidos por DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Elas NÃO PODEM expor uma API para uso por apps de terceiros com o objetivo de mudar o estado de bloqueio.

9.11.2. StrongBox

O sistema Android Keystore permite que os desenvolvedores de apps armazenem chaves criptográficas em um processador seguro dedicado, bem como no ambiente de execução isolado descrito acima. Esse processador seguro dedicado é chamado de "StrongBox". Os requisitos de C-1-3 a C-1-11 abaixo definem os requisitos que um dispositivo precisa atender para se qualificar como um StrongBox.

Implementações de dispositivos que têm um processador seguro dedicado:

• [C-SR] É RECOMENDADO A compatibilidade com o StrongBox. O StrongBox provavelmente se tornará um requisito em uma versão futura.

Se as implementações de dispositivos oferecerem suporte ao StrongBox, elas:

• [C-1-1] PRECISA declarar FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] PRECISA fornecer hardware seguro dedicado que é usado para armazenar chaves e proteger a autenticação do usuário. O hardware seguro dedicado também pode ser usado para outros fins.

• [C-1-3] PRECISA ter uma CPU discreta que não compartilhe cache, DRAM, coprocessadores ou outros recursos principais com o processador do aplicativo (AP).

• [C-1-4] PRECISA garantir que qualquer periférico compartilhado com o AP não possa alterar o processamento do StrongBox de maneira alguma ou obter qualquer informação do StrongBox. O AP PODE desativar ou bloquear o acesso ao StrongBox.

• [C-1-5] PRECISA ter um relógio interno com precisão razoável (+10%) que seja imune a manipulação pelo AP.

• [C-1-6] PRECISA ter um gerador de número aleatório verdadeiro que produza uma saída imprevisível e distribuída de maneira uniforme.

• [C-1-7] PRECISA ter resistência a adulterações, incluindo contra penetração física e falhas.

• [C-1-8] PRECISA ter resistência ao canal lateral, incluindo resistência contra vazamento de informações por meio de alimentação, tempo, radiação eletromagnética e canais laterais de radiação térmica.

• [C-1-9] PRECISA ter um armazenamento seguro que garanta confidencialidade, integridade, autenticidade, consistência e atualização do conteúdo. O armazenamento NÃO PODE ser lido ou alterado, exceto conforme permitido pelas APIs do StrongBox.

• Para validar a conformidade com [C-1-3] a [C-1-9], as implementações de dispositivos:

  • [C-1-10] PRECISA incluir o hardware certificado com o perfil de proteção de IC seguro BSI-CC-PP-0084-2014 ou avaliado por um laboratório de testes credenciado nacionalmente que incorpore a avaliação de vulnerabilidade de alto potencial de ataque, de acordo com a Aplicação de Potencial Comum de Ataque a Cartões Inteligentes (link em inglês).
  • [C-1-11] PRECISA incluir o firmware avaliado por um laboratório de testes credenciado nacionalmente que incorpore a avaliação de vulnerabilidade de alto potencial de ataque, de acordo com a Common Criteria Application of Attack Potential to Smartcards.
  • [C-SR] É FORTEMENTE RECOMENDADO incluir o hardware que é avaliado usando uma meta de segurança, nível de garantia de avaliação (EAL) 5, ampliado por AVA_VAN.5. A certificação EAL 5 provavelmente se tornará um requisito em uma versão futura.

• [C-SR] é FORTEMENTE RECOMENDADO a oferecer resistência a ataques de pessoas com informações privilegiadas (IAR, na sigla em inglês), o que significa que uma pessoa com acesso a chaves de assinatura de firmware não pode produzir firmware que faça com que o StrongBox vaze segredos, para contornar requisitos de segurança funcional ou permitir o acesso a dados confidenciais do usuário. A maneira recomendada de implementar o IAR é permitir atualizações de firmware somente quando a senha principal do usuário for fornecida pela HAL IAuthSecret.

9.11.3. Credencial de identidade

O sistema de credenciais de identidade é definido e alcançado implementando todas as APIs no pacote android.security.identity.*. Essas APIs permitem que os desenvolvedores de apps armazenem e recuperem documentos de identidade do usuário. Implementações de dispositivos:

• [C-SR] é MUITO RECOMENDADO para implementar o sistema de credenciais de identidade.

Se as implementações de dispositivos implementarem o sistema de credenciais de identidade, elas:

• [C-0-1] PRECISA retornar um valor não nulo para o método IdentityCredentialStore#getInstance().

• [C-0-2] PRECISA implementar o sistema de credenciais de identidade (por exemplo, as APIs android.security.identity.*) com o código que se comunica com um aplicativo confiável em uma área segura e isolada do código em execução no kernel e em versões mais recentes. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o código do kernel ou do espaço do usuário possa acessar o estado interno do ambiente isolado, incluindo a DMA.

• [C-0-3] As operações criptográficas necessárias para implementar o sistema de credenciais de identidade (por exemplo, as APIs android.security.identity.*) PRECISAM ser executadas inteiramente no aplicativo confiável, e o material da chave privada nunca PRECISA sair do ambiente de execução isolado, a menos que especificamente exigido por APIs de nível superior (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 das credenciais não são liberados a menos que as condições de controle de acesso sejam atendidas, MACs não podem ser produzidos para dados arbitrários), mesmo que o Android esteja com comportamento inadequado ou comprometido.

9,12 Exclusão de dados

Todas as implementações de dispositivos:

• [C-0-1] PRECISA fornecer aos usuários um mecanismo para realizar uma "redefinição para configuração original".
• [C-0-2] PRECISA excluir todos os dados do sistema de dados do usuário.
• [C-0-3] PRECISA excluir os dados para atender aos padrões relevantes do setor, como o NIST SP800-88.
• [C-0-4] PRECISA acionar a "Redefinição para configuração original" acima processo quando a API DevicePolicyManager.wipeData() é chamada pelo app Device Policy Controller do usuário principal.
• PODE fornecer uma opção rápida de limpeza de dados que conduz apenas uma limpeza lógica de dados.

9,13 Modo de inicialização segura

O Android oferece o modo de inicialização segura, que permite aos usuários inicializar de um modo em que apenas apps pré-instalados do sistema podem ser executados e todos os apps de terceiros são desativados. Esse modo, conhecido como "modo de inicialização segura", oferece ao usuário a capacidade de desinstalar apps de terceiros potencialmente nocivos.

As implementações de dispositivos são:

• [SR] RECOMENDADO FORTEMENTE para implementar o modo de inicialização segura.

Se as implementações de dispositivos implementarem o modo de inicialização segura, elas:

• [C-1-1] PRECISA oferecer ao usuário uma opção para entrar no modo de inicialização segura de forma ininterrupta em apps de terceiros instalados no dispositivo, exceto quando o app for um controlador de política do dispositivo e tiver definido a flag UserManager.DISALLOW_SAFE_BOOT como verdadeira.

• [C-1-2] PRECISA oferecer ao usuário a capacidade de desinstalar apps de terceiros no modo de segurança.

• DEVE fornecer ao usuário a opção de entrar no modo de inicialização segura no menu de inicialização usando um fluxo de trabalho diferente do de uma inicialização normal.

9,14 Isolamento de sistemas veiculares automotivos

Os dispositivos Android Automotive precisam trocar dados com subsistemas críticos do veículo usando a HAL do veículo para enviar e receber mensagens por redes de veículos, como o barramento CAN.

A troca de dados pode ser protegida implementando recursos de segurança abaixo das camadas da estrutura do Android para evitar interações maliciosas ou não intencionais com esses subsistemas.

9,15 Planos de assinatura

"Planos de assinatura" Consulte os detalhes do plano do relacionamento de faturamento fornecidos pela operadora de celular no SubscriptionManager.setSubscriptionPlans().

Todas as implementações de dispositivos:

• [C-0-1] PRECISA devolver os planos de assinatura apenas para o app da operadora de celular que os forneceu originalmente.
• [C-0-2] NÃO PODE fazer backup nem upload remotamente de planos de assinatura.
• [C-0-3] PRECISA permitir apenas substituições, como SubscriptionManager.setSubscriptionOverrideCongested(), do app da operadora de celular que oferece planos de assinatura válidos.

9,16 Migração de dados do aplicativo

Se as implementações de dispositivos incluírem um recurso para migrar dados de um dispositivo para outro e não limitarem os dados do aplicativo copiados ao que é configurado pelo desenvolvedor do aplicativo no manifesto por meio do atributo android:fullBackupContent, elas:

• [C-1-1] NÃO PODE iniciar transferências de dados de apps de dispositivos em que o usuário não tenha definido uma autenticação principal, conforme descrito em 9.11.1 Autenticação e tela de bloqueio seguras.
• [C-1-2] PRECISA confirmar com segurança a autenticação principal no dispositivo de origem e com a intenção do usuário de copiar os dados no dispositivo antes da transferência.
• [C-1-3] PRECISA usar o atestado de chave de segurança para garantir que o dispositivo de origem e o de destino na migração sejam dispositivos Android legítimos e tenham um carregador de inicialização bloqueado.
• [C-1-4] PRECISA migrar os dados apenas para o mesmo aplicativo no dispositivo de destino, com o mesmo nome de pacote E certificado de assinatura.
• [C-1-5] PRECISA mostrar uma indicação de que os dados do dispositivo de origem foram migrados no menu de configurações. O usuário NÃO DEVE poder remover essa indicação.

10. Teste de compatibilidade de software

As implementações de dispositivos PRECISAM ser aprovadas em todos os testes descritos nesta seção. No entanto, observe que nenhum pacote de teste de software é totalmente abrangente. Por esse motivo, é altamente RECOMENDADO que os implementadores de dispositivos façam o número mínimo de mudanças possível na referência e na implementação preferencial do Android disponível no Android Open Source Project. Isso vai minimizar o risco de introduzir bugs que criam incompatibilidades que exigem retrabalho e possíveis atualizações do dispositivo.

10.1 Conjunto de teste de compatibilidade

Implementações de dispositivos:

• [C-0-1] PRECISA passar no conjunto de teste de compatibilidade (CTS) do Android, disponível no Android Open Source Project, usando o software de envio final no dispositivo.

• [C-0-2] PRECISA garantir a compatibilidade em casos de ambiguidade no CTS e para reimplementações de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. A versão do CTS será controlada independentemente dessa definição de compatibilidade, e várias revisões do CTS poderão ser lançadas para o Android 11.

Implementações de dispositivos:

• [C-0-3] PRECISA passar pela versão mais recente do CTS no momento em que o software do dispositivo for concluído.

• DEVE usar a implementação de referência na árvore de código aberto do Android o máximo possível.

10,2 Verificador do CTS

O verificador do CTS está incluído no conjunto de teste de compatibilidade e foi projetado para ser executado por um operador humano para testar funcionalidades que não podem ser testadas por um sistema automatizado, como o funcionamento correto de uma câmera e sensores.

Implementações de dispositivos:

• [C-0-1] PRECISA executar corretamente todos os casos aplicáveis no verificador do CTS.

O CTS Verifier tem testes para muitos tipos de hardware, inclusive alguns opcionais.

Implementações de dispositivos:

• [C-0-2] PRECISA passar em todos os testes de hardware que possui; Por exemplo, se um dispositivo tiver um acelerômetro, ele PRECISA executar corretamente o caso de teste desse recurso no verificador do CTS.

Os casos de teste para recursos marcados como opcionais por este Documento de definição de compatibilidade podem ser ignorados ou omitidos.

• [C-0-2] Todos os dispositivos e builds PRECISAM executar corretamente o CTS Verifier, conforme mencionado acima. No entanto, como muitos builds são muito semelhantes, não é esperado que os implementadores de dispositivos executem explicitamente o CTS Verifier em builds que diferem apenas de maneiras triviais. Especificamente, implementações de dispositivos que diferem de uma implementação que passou no verificador do CTS apenas pelo conjunto de localidades incluídas, branding etc. PODEM omitir o teste do verificador do CTS.

11. Software atualizável

• [C-0-1] As implementações de dispositivos PRECISAM incluir um mecanismo para substituir todo o software do sistema. O mecanismo não precisa realizar atualizações “em tempo real”, ou seja, pode ser necessário reiniciar o dispositivo. Qualquer método pode ser usado, desde que possa substituir todo o software pré-instalado no dispositivo. Por exemplo, qualquer uma das abordagens a seguir atenderá a esse requisito:

  • Downloads “over-the-air” (OTA) com atualização off-line por reinicialização.
  • Atualizações "vinculadas" via USB de um PC host.
  • Atualizações “off-line” por meio de uma reinicialização e atualização de um arquivo no armazenamento removível.

• [C-0-2] O mecanismo de atualização usado PRECISA ser compatível com as atualizações sem excluir permanentemente os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados privados e os dados compartilhados do aplicativo. O software Android upstream inclui um mecanismo de atualização que atende a esse requisito.

• [C-0-3] Toda a atualização PRECISA ser assinada, e o mecanismo de atualização no dispositivo PRECISA verificar a atualização e a assinatura usando uma chave pública armazenada no dispositivo.

• [C-SR] O mecanismo de assinatura é FORTEMENTE RECOMENDADO para gerar hash da atualização com SHA-256 e validar o hash em relação à chave pública usando o ECDSA NIST P-256.

Se as implementações de dispositivos incluírem suporte a uma conexão de dados ilimitada, como 802.11 ou perfil Bluetooth PAN (rede de área pessoal), elas:

• [C-1-1] PRECISA oferecer suporte a downloads OTA com atualização off-line por reinicialização.

Para implementações de dispositivos que forem lançadas com o Android 6.0 e versões posteriores, o mecanismo de atualização DEVE 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 DEVEM oferecer suporte às atualizações do sistema A/B. O AOSP implementa esse recurso usando a HAL de controle de inicialização.

Se um erro for encontrado em uma implementação de dispositivo após o lançamento, mas dentro do ciclo de vida razoável do produto, que seja determinado em consulta com a Equipe de Compatibilidade do Android para afetar a compatibilidade de aplicativos de terceiros:

• [C-2-1] O implementador do dispositivo PRECISA corrigir o erro com uma atualização de software disponível, que pode ser aplicada de acordo com o mecanismo que acabamos de descrever.

O Android inclui recursos que permitem que o aplicativo Proprietário do dispositivo (se houver) controle a instalação de atualizações do sistema. Se o subsistema de atualização do sistema para dispositivos informar android.software.device_admin, ele:

• [C-3-1] PRECISA implementar o comportamento descrito na classe SystemUpdatePolicy.

12. Registro de alterações do documento

Para ver um resumo das mudanças na definição de compatibilidade nesta versão:

• Registro de alterações do documento

Para um resumo das alterações nas seções de indivíduos:

1. Introdução
2. Tipos de dispositivo
3. Software
4. Pacote de aplicativos
5. Multimídia
6. Ferramentas e opções para desenvolvedores
7. Compatibilidade de hardware
8. Desempenho e potência
9. Modelo de segurança
10. Teste de compatibilidade de software
11. Software atualizável
12. Registro de alterações do documento
13. Entre em contato

12,1. Dicas de visualização do registro de alterações

As mudanças são marcadas da seguinte maneira:

• CDD
  Mudanças significativas nos requisitos de compatibilidade.

• Documentos
  Alterações estéticas ou relacionadas à criação.

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 do Android e pedir esclarecimentos ou mencionar problemas que você acredita que o documento não abrange.