Definição de compatibilidade do Android 10

1. Introdução

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

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 10. Uma "implementação de dispositivo" ou "implementação" é a solução de hardware/software assim desenvolvida.

Para serem consideradas compatíveis com o Android 10, 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 mencionados como "Requisitos principais" neste documento.

1.1.2. ID do requisito

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

• O ID é atribuído apenas para os requisitos OBRIGATÓRIOS.
• Os requisitos FORTEMENTE RECOMENDADOS são marcados como [SR], mas o ID não foi atribuído.
• O ID consiste em : ID do tipo de dispositivo, ID da condição 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 dispositivo

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;
• A tela deve ter um tamanho de tela diagonal físico de 2,5 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:

• Os [7.1.1.1/H-0-1] PRECISAM ter pelo menos uma tela compatível com Android de pelo menos 2,5 polegadas de tamanho diagonal.Cada tela compatível com Android PRECISA atender 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 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.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).

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

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

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

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

• [7.6.1/H-10-1] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados 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	O contexto	Comportamento
R	Página de uso do HID: 0x0C Uso do HID: 0x0CD Chave do kernel: KEY_PLAYPAUSE Chave do Android: KEYCODE_MEDIA_PLAY_PAUSE	Reprodução de mídia	Entrada: pressione rapidamente Saída: toque ou pause
			Entrada: toque e mantenha pressionado Saída: inicia um comando de voz Envia: android.speech.action.VOICE_SEARCH_HANDS_FREE se o dispositivo estiver bloqueado ou a tela estiver desligada. Caso contrário, envia android.speech.RecognizerIntent.ACTION_WEB_SEARCH.
		Alguém está ligando	Entrada: pressionamento curto Saída: aceitar chamada
			Entrada: tocar e manter pressionado Saída: rejeitar a chamada
		Chamada em andamento	Entrada: pressione rapidamente Saída: encerrar a chamada
			Entrada: tocar e manter pressionado Saída: ativar ou desativar o som do microfone
B	Página de uso do HID: 0x0C Uso do HID: 0x0E9 Chave do kernel: KEY_VOLUMEUP Chave do Android: VOLUME_UP	Reprodução de mídia, ligação em andamento	Entrada: toque curto ou longo. Saída: aumenta o volume do sistema ou do fone de ouvido
C	Página de uso do HID: 0x0C Uso de HID: 0x0EA Chave do kernel: KEY_VOLUMEDOWN Chave do Android: VOLUME_DOWN	Reprodução de mídia, ligação em andamento	Entrada: toque curto ou longo. Saída: diminui o volume do sistema ou do fone de ouvido
D	Página de uso do HID: 0x0C Uso do HID: 0x0CF Chave do kernel: KEY_VOICECOMMAND Chave do Android: KEYCODE_VOICE_ASSIST	Todas. Pode ser acionado em qualquer instância.	Entrada: toque curto ou longo. Saída: inicia o comando de voz.

• [7.8.2.2/H-1-2] PRECISA acionar ACTION_HEADSET_PLUG 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 o extra de "microfone" definido como 0.

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

• [7.8.2.2/H-3-1] PRECISA transmitir a intent ACTION_HEADSET_PLUG com o extra de "microfone" 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.

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.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 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.

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 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 em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os possíveis mecanismos pelos quais o código do kernel ou do espaço do usuário possa acessar o estado interno do ambiente isolado, incluindo a DMA. O Android Open Source Project (AOSP) upstream atende a esse requisito usando a implementação Trusty, mas outra solução baseada em ARM TrustZone ou uma implementação segura 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.

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

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

Implementações de dispositivos de televisão:

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

2.3.2 Multimídia

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

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

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

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

Implementações de dispositivos de televisão:

• [5.2.2/T-SR] É 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 resoluções e frame rates padrão de vídeo, 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 taxas de quadros e resoluções padrão de até, 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.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] É NECESSÁRIO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash das famílias MD5, SHA1 e SHA-2 para oferecer suporte 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.
  • [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, mas NÃO DEVE 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.

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.

• [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

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 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 visã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).
• 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

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

2.5.2 Multimídia

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

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

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

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

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

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

As implementações de dispositivos automotivos são MUITO RECOMENDADAS para oferecer suporte à 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.*.

• [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.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] É FORTEMENTE RECOMENDADO a implementação de 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 limitar a capacidade de 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 limitar a capacidade de mudar as cores atrás dos elementos da interface do sistema, para garantir que esses elementos estejam claramente visíveis o tempo todo, conforme descrito em WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS e WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION.

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 entrar no modo garagem pelo menos uma vez antes de desligar o carro.
• [8.3/A-1-4] PRECISA estar no modo garagem por pelo menos 15 minutos, a menos que:
  • A bateria está descarregada.
  • Nenhum job ocioso está programado.
  • O motorista sai do modo garagem.
• [8.4/A-0-1] PRECISA fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado de bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
• [8.4/A-0-2] PRECISA informar todos os valores de consumo de energia em miliamperes-hora (mAh).
• [8.4/A-0-3] PRECISA informar o consumo de energia da CPU pelo UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
• [8.4/A] DEVE ser atribuída ao próprio componente de hardware se não for possível atribuir o uso de energia 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.

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

• [9.11/A-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.

Implementações de dispositivos automotivos:

• [9.14/A-0-1] PRECISA bloquear as mensagens dos subsistemas de veículos do framework do Android, como colocar tipos e origens de mensagens permitidos na 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 atende a todos os critérios a seguir:

• Normalmente, usado segurando as duas mãos.
• Não tem configuração flip ou conversível.
• Qualquer implementação de teclado físico usada com o dispositivo PRECISA se conectar por uma conexão padrão.
• 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.

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 de lista provisória 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.

  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.
  • Talvez, se ainda não houver uma API oculta no AOSP, adicione essa API a qualquer uma das listas restritas.

• [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.

3.1.1. Extensões Android

O Android permite ampliar as APIs gerenciadas, mantendo a mesma versão de nível da API.

• [C-0-1] As implementações de dispositivos Android PRECISAM pré-carregar a implementação do AOSP da biblioteca compartilhada ExtShared e dos serviços ExtServices com versões superiores 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.

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 10.
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 10, esse campo PRECISA ter o valor inteiro 10_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 10, esse campo PRECISA ter o valor inteiro 10_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. Um possível uso desse campo é indicar a revisão específica da placa que fornece energia ao dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”.
MARCA	Um valor que reflete o nome da marca associada ao dispositivo, como conhecido pelos usuários finais. PRECISA estar em um formato legível por humanos e DEVE representar o fabricante do dispositivo ou a marca da empresa sob a qual o dispositivo é comercializado. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”.
ABIS_SUPORTE	O nome do conjunto de instruções (tipo de CPU + convenção ABI) 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 deste campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". O nome do dispositivo NÃO PODE ser alterado durante a vida útil do produto.
IMPRESSORA	Uma string que identifica exclusivamente este build. Ele DEVE ser legível por humanos. Ele PRECISA seguir este modelo: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Por exemplo: acme/myproduct/ mydevice:10/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 deste campo, exceto que ele NÃO PODE ser nulo nem 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 deste campo, exceto que ele NÃO PODE ser nulo nem 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 deste campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". Esse nome de produto NÃO PODE ser alterado durante a vida útil do produto.
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 ("").
PATCH DE SEGURANÇA	Um valor que indica o nível do patch de segurança de uma versão. Ela PRECISA indicar que o build não está vulnerável a nenhum dos problemas descritos no boletim de segurança pública do Android. Ele PRECISA estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no Boletim de segurança pública do Android ou no Aviso de segurança do Android, por exemplo, "2015-11-01".
BASE_SO	Um valor que representa o parâmetro FINGERPRINT do build que é idêntico a 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. Principais intents do aplicativo

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 considerados aplicativos principais do Android, que implementa vários padrões de intent para realizar ações comuns.

• [C-0-1] As implementações de dispositivos PRECISAM pré-carregar um ou mais apps ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intent pública definidos pelos seguintes apps Android principais no AOSP:

  • Relógio de mesa
  • Navegador
  • Agenda
  • Contatos
  • Galeria
  • Pesquisa global
  • Lançador
  • Música
  • Configurações

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 ao uso desses padrões de intent por aplicativos do sistema nem impedir que aplicativos de terceiros se vinculem e assumam o controle desses padrões. Essa proibição inclui especificamente, mas não se limita a desativar a interface 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 se aplicar igualmente a todos os filtros de intent de URI candidatos.
  • [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 respeitem qualquer intent nova ou padrão de intent de transmissão usando uma string ACTION, CATEGORY ou outra string de chave no namespace android. ou com.android..
• [C-0-2] Os implementadores de dispositivos NÃO PODEM incluir componentes Android que respeitem novas intents ou transmitam padrões de intent usando ACTION, CATEGORY ou outra string de chave em um espaço de pacote que pertença a outra organização.
• [C-0-3] Os implementadores de dispositivos NÃO PODEM mudar nem estender os padrões de intent usados pelos apps principais listados 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 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.

3.2.3.5. Configurações padrão do app

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 RoleManager.createRequestRoleIntent(String) com RoleManager.ROLE_SMS 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 ao incluir um menu "Opção de contas de chamadas" no menu de configurações "Chamadas".

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

• [C-2-5] PRECISA fornecer recursos para o usuário escolher um app com o papel android.app.role.CALL_REDIRECTION.

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

• [C-3-1] PRECISA respeitar a intent android.settings.NFC_PAYMENT_SETTINGS para mostrar um menu de configurações padrão do app para o recurso "tocar e pagar".

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.

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 definidas e implementar compatibilidade com o Android NDK.
• [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
  • 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 10 para a implementação da API android.webkit.WebView.

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

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

  • O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
  • A string $(MODEL) PODE estar vazia, mas se não estiver, ela PRECISA ter o mesmo valor que android.os.Build.MODEL.
  • "Build/$(BUILD)" PODE ser omitido, mas se estiver presente, a string $(BUILD) PRECISA ser o mesmo que o valor de android.os.Build.ID.
  • O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium no Android Open Source Project.
  • 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-4] PRECISA renderizar o conteúdo fornecido ou o conteúdo do URL remoto em um processo diferente do aplicativo que instancia a WebView. Especificamente, o processo 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
  • Tag<video>
  • 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 apps em segundo plano:
  • [C-0-4] eles PRECISAM parar de executar callbacks registrados pelo app para receber saídas de GnssMeasurement e GnssNavigationMessage.
  • [C-0-5] eles PRECISAM limitar a frequência de atualizações fornecidas ao app pela classe de API LocationManager ou pelo método WifiManager.startScan().
  • [C-0-6] Se o app for 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 em segundo plano

Se as implementações de dispositivos implementarem as restrições de apps incluídas no AOSP ou estenderem as restrições de apps, 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 É NECESSÁRIO 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.
• [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 aos namespaces de outras empresas.
• [C-0-6] PRECISA ser empacotado em uma biblioteca compartilhada do Android para que apenas os apps que as usam explicitamente (por meio do mecanismo <uses-library>) sejam afetados pelo aumento do uso de memória dessas APIs.

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; esta seção simplesmente 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 reservado de selos 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, exibir e remover AppWidgets diretamente na Tela de início.
• [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 os desenvolvedores de apps de terceiros notifiquem os usuários sobre eventos importantes e atraiam a atenção deles usando os componentes de hardware (por exemplo, som, vibração e luz) e recursos de software (por exemplo, aba de notificações, barra 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 exibir automaticamente uma funcionalidade de usuário para bloquear uma determinada notificação de app de terceiros por cada canal e nível de pacote de app depois que o usuário dispensar essa notificação várias vezes.
• DEVE ser compatível com notificações avançadas.
• DEVE apresentar algumas notificações de prioridade mais alta como notificações de alerta.
• DEVE ter um recurso do usuário para adiar notificações.
• PODE gerenciar apenas a visibilidade e o momento em que apps de terceiros podem notificar os usuários sobre eventos importantes para reduzir problemas de segurança, como distração do motorista.

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.

Se as implementações de dispositivos informarem a flag de recurso android.hardware.ram.normal, elas:

• [C-1-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-1-2] PRECISA respeitar a chamada de API snoozeNotification(), dispensar a notificação e fazer um callback após a duração do adiamento definida na chamada de API.

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

• [C-2-1] PRECISA refletir o status das notificações adiadas corretamente usando APIs padrão, como NotificationListenerService.getSnoozedNotifications().
• [C-2-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] PRECISA implementar uma atividade que responda à intent ACTION_NOTE_POLICY_ACCESS_SETTINGS, que, para implementações com UI_MODE_TYPE_NORMAL, PRECISA ser uma atividade em que o usuário possa conceder ou negar o acesso do app às configurações da política de Não perturbe.
• [C-1-2] É 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 das seguintes 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 uma família de temas "Holo" e "Material" como um conjunto de estilos definidos que os desenvolvedores de apps usam se quiserem combinar com a aparência do tema Holo (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.

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 solicite 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 do 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.
• [C-1-2] 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_CONFIG.

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

• [C-2-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.

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)

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 está inativo ou encaixado em uma base de mesa. Os dispositivos Android Watch PODEm implementar protetores de tela, mas outros tipos de implementações de dispositivos DEVEM 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.8.12. Localização

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 esse modo não estiver implementado, a chave PRECISA estar disponível para a atividade em primeiro plano.
• [C-3-5] PRECISA fornecer uma funcionalidade do usuário para bloquear a exibição de um app no modo PIP. A implementação do AOSP atende a esse requisito com controles na aba de notificações.
• [C-3-6] PRECISA alocar a largura e a altura mínimas de 108 dp para a janela do PIP, de 240 dp e da altura de 135 dp para a janela do PIP quando a Configuration.uiMode estiver configurada como UI_MODE_TYPE_TELEVISION.

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 não funciona para mostrar conteúdo.

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

• [C-1-1] PRECISA ter cortes apenas nas bordas curtas do dispositivo. Por outro lado, se a proporção do dispositivo for 1,0 (1:1), eles NÃO PODEM ter cortes.
• [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,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 tiver dados do usuário configurados, 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 durante o processo de provisionamento para permitir que o app seja definido como Proprietário do dispositivo. O consentimento pode ser feito por ação do usuário ou por meios programáticos durante o provisionamento, mas NÃO PODE ser codificado nem impedir o uso de outros apps do proprietário do dispositivo.

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

• [C-2-1] PRECISA ter um processo para verificar se o app específico que está sendo promovido pertence a uma solução legítima de gerenciamento de dispositivos corporativos e 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 Recents e Notifications.
• [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 houver um perfil gerenciado, PRECISA expor as seguintes affordances do usuário, tanto para o usuário principal quanto para 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.
• [C-1-10] PRECISA oferecer suporte à capacidade de especificar uma tela de bloqueio separada, atendendo aos seguintes requisitos para conceder acesso 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 interface 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-3] 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é-instalados.
• [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, 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 junto com os 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 usando 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.
• As implementações de dispositivos PRECISAM fornecer as seguintes funcionalidades do usuário para interagir com os Apps instantâneos. O AOSP atende aos requisitos da interface, das configurações e da tela de início padrão do sistema. Implementações de dispositivos:
  • [C-0-5] É NECESSÁRIO oferecer aos usuários uma funcionalidade para visualizar e excluir os Instant Apps armazenados localmente em cache para cada pacote de app.
  • [C-0-6] 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. No caso de Apps instantâneos iniciados por intents da Web, conforme definido usando uma intent com ação definida como Intent.ACTION_VIEW e com um esquema de "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-0-7] PRECISA permitir que Apps instantâneos em execução sejam acessados pela função "Recentes" se ela estiver disponível no dispositivo.

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 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.

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 que apps que não sejam o "instalador de registro" atual do pacote desinstalem silenciosamente o app sem 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 menos.
  • 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 aos usuários affordance para desinstalar ou iniciar um aplicativo na caixa de diálogo de aviso.

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 não garantem 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 PRECISAM 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. Observe que esse requisito serve apenas para decodificação, e que 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 no "Controle de intervalo dinâmico (DRC)" na 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] É MUITO RECOMENDADO que os requisitos C-2-1 e C-2-2 acima sejam atendidos por todos os decodificadores de áudio AAC.

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

• [C-3-1] Os metadados de volume e DRC PRECISAM ser interpretados e aplicados de acordo com o nível 1 do perfil de controle de intervalo dinâmico MPEG-D DRC.
• [C-3-2] O decodificador PRECISA se comportar de acordo com a configuração definida com as 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 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)
Perfil MPEG-4 HE AACv2 (AAC+ aprimorado)	Suporte a conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC aprimorado com atraso baixo)	Suporte a conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Suporte a conteúdo mono/estéreo com taxas de amostragem padrão de 7,35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 a 12,2 kbps com amostragem a 8 kHz.	3GPP (.3gp)
AMR-WB	9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz, conforme definido em AMR-WB, Adaptive Multi-Rate - Codec de voz 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) OTA (.ota) 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		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
• [C-0-7] HEIF (HEIC)

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

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

5.1.6. Detalhes dos codecs de imagem

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

Codificadores e decodificadores de imagens expostos na API MediaCodec

• [C-1-1] PRECISA oferecer suporte ao formato de 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 MUITO 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 entrada e saída 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 ser compatíveis com 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 MUITO RECOMENDADOS para oferecer suporte aos dois.

• [SR] Os codificadores e decodificadores de vídeo são RECOMENDADOS para 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 de alta profundidade de bits (mais de 9 bits por canal) PRECISAM oferecer suporte à saída de um formato equivalente a 8 bits, se solicitado pelo aplicativo. Isso PRECISA ser refletido com a compatibilidade com um formato de cores YUV420 8:8:8 via android.media.MediaCodecInfo.

Se as implementações de dispositivos anunciarem suporte ao perfil HDR 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 o suporte à atualização 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 do software OMX sejam executados em um processo de codec que não tenha acesso a drivers de hardware que não sejam mapeadores de memória.

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

• [C-3-1] PRECISA incluir o codec de software Codec 2.0 correspondente do Android Open Source Project (se disponível) para cada formato e tipo de mídia (codificador ou decodificador) 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, os codecs chamados "decodificadores" PRECISAM oferecer suporte à decodificação, e os chamados "codificadores" PRECISAM oferecer suporte à 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 (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) usando as APIs Media:

• [C-3-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR necessários (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis em HDR) do aplicativo usando a API MediaCodec, além de oferecer suporte à extração dos metadados HDR necessários (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis HDR e MediaFormat#KEY_HDR10_PLUS_INFO/contêiner relevante do bit1 Plus definido pelo HDR0Plus_INFO ou o contêiner relevante do HDR1+. Eles também PRECISAM oferecer suporte à saída dos metadados HDR necessários (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis HDR) do bitstream e/ou contêiner, conforme definido pelas especificações relevantes.

• [C-SR] As implementações do dispositivo são ALTAMENTE RECOMENDADAS para oferecer suporte à saída dos metadados MediaFormat#KEY_HDR10_PLUS_INFO para perfis HDR10Plus via MediaCodec#getOutputFormat(int).

• [C-3-2] As implementações de dispositivos PRECISAM exibir corretamente o conteúdo HDR para o perfil HEVCProfileMain10HDR10 na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

• [C-SR] As implementações de dispositivo são RECOMENDADAS para mostrar corretamente o conteúdo HDR do perfil HEVCProfileMain10HDR10Plus 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 (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis em HDR, bem como o parâmetro MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO para perfis de HDR10Plus) do aplicativo usando a API MediaCodec, além de oferecer suporte à extração dos metadados HDR necessários (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis HDR e MediaFormat#KEY_HDR10_PLUS_INFO para perfis HDR10Plus) do bitstream e/ou contêiner, conforme definido pelas especificações relevantes. Eles também PRECISAM oferecer suporte à saída dos metadados HDR necessários (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis HDR) do bitstream e/ou contêiner, conforme definido pelas especificações relevantes.

• [C-4-2] As implementações de dispositivos PRECISAM mostrar corretamente o conteúdo HDR para perfis VP9Profile2HDR e VP9Profile3HDR na tela do dispositivo ou em uma porta de saída de vídeo padrão (por exemplo, HDMI.

• [C-SR] As implementações de dispositivos são RECOMENDADAS PARA oferecer suporte à saída dos metadados MediaFormat#KEY_HDR10_PLUS_INFO para perfis do HDR10Plus via MediaCodec#getOutputFormat(int).

• [C-SR] As implementações de dispositivos são RECOMENDADAS para mostrar corretamente o conteúdo HDR para os perfis VP9Profile2HDR10Plus e VP9Profile3HDR10Plus 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 de 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. É RECOMENDADO que dispositivos Android novos e existentes atendam a esses requisitos listados como DEVEEM. 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, acessíveis aos aplicativos de terceiros pela API AudioManager.getMicrophones(), e 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 cada aumento ou redução de 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 de 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 fontes de ponto flutuante/amostras de áudio de 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 nas 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

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.
• timestamp. 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 RFC 4629 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 as telas conectadas por meio de protocolos sem fio, como o Miracast.

Se as implementações de dispositivos declararem suporte a Display.FLAG_SECURE e tiverem 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
  • Modo USB periférico, 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)

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 uma latência de ida e volta contínua de áudio, conforme definido na seção 5.6 Latência de áudio, de 20 milissegundos ou menos e DEVE ter 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 DEVE 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.Fixed.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] É RECOMENDADO para oferecer suporte a E/S simultâneas de até oito canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usados com periféricos de áudio USB que também 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 zero 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-SR] É FORTEMENTE RECOMENDADO para oferecer suporte ao comando de shell cmd testharness.
  • [C-0-3] NÃO PODE alterar o formato ou o conteúdo dos eventos do sistema do dispositivo (batterystats , diskstats, impression improvisa, Graphstats, netstats, notification, 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. Por exemplo:

    • Implementações de dispositivos sem uma porta USB compatível com o modo de periférico PRECISAM implementar o adb via rede local (como Ethernet ou Wi-Fi).
    • PRECISA fornecer drivers para o Windows 7, 9 e 10, permitindo que os desenvolvedores se conectem ao dispositivo usando o protocolo adb.

• 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.
• Monkey
  • [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 é PRECISO haver um mecanismo acessível ao usuário para ativá-lo.

• Perfetto (link em inglês)

  • [C-SR] É altamente 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).

• Modo arcabouço de testes

  Se as implementações de dispositivos 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 no diretório base dos aplicativos depuráveis para oferecer suporte aos métodos de API vkEnumerateInstanceLayerProperties() e vkCreateInstance().

6.2. Opções do desenvolvedor

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

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

• [C-0-1] PRECISA respeitar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar 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 abram as "Opções do desenvolvedor" depois de pressionar sete (7) vezes no item de menu Settings > About Device > Build Number.
• [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 que não sejam telefônicos, essas APIs PRECISAM ser implementadas como um ambiente autônomo razoável.

7.1. Tela e gráficos

O Android inclui instalações que ajustam automaticamente os recursos de aplicativos e os layouts 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 PRECISA 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 corretamente o suporte declarado dos aplicativos para tamanhos de tela com o atributo <supports-screens> no AndroidManifest.xml, conforme descrito na documentação do SDK do Android.

• PODE ter telas compatíveis com Android com cantos arredondados.

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

• [C-1-1] PRECISA garantir que o raio dos cantos arredondados seja menor ou igual a 38 dp.
• DEVE incluir affordance do usuário para alternar para o modo de exibição com os cantos retangulares.

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 do dispositivo PRECISAM informar apenas uma das densidades de framework do Android listadas em DisplayMetrics pela API DENSITY_DEVICE_STABLE. Esse valor NÃO PODE mudar a qualquer momento. No entanto, o dispositivo PODE informar uma densidade arbitrária diferente de acordo com as mudanças de configuração de tela feitas pelo usuário (por exemplo, o tamanho da tela) definidas após a inicialização inicial.

• As implementações de dispositivos DEVEM definir a densidade padrão do framework do Android que é numericamente mais próxima da densidade física da tela, a menos que a densidade lógica coloque o tamanho da tela informado abaixo do mínimo compatível. Se a densidade do framework padrão do Android que é numericamente mais próxima da densidade física resultar em um tamanho de tela menor que o menor tamanho de tela compatível 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 por 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 ela identificou 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] É ALTAMENTE RECOMENDADO para oferecer suporte à extensão OES_EGL_image_external_essl3.

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

• [C-4-1] PRECISA 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.

Se as implementações de dispositivos incluírem suporte ao Vulkan 1.0, 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 É POSSÍVEL enumerar as camadas fornecidas por bibliotecas fora do pacote do aplicativo nem fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o atributo android:debuggable definido como true.
• [C-1-6] PRECISA informar todas as strings de extensão 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-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 em um modo equivalente ao tamanho de tela "normal" (320 dp de largura) em benefício de aplicativos legados não desenvolvidos para versões antigas do Android que são anteriores à independência de tamanho de tela.

7.1.6. Tecnologia da tela

A plataforma Android inclui APIs que permitem que os aplicativos renderizem gráficos avançados em uma tela compatível com o Android. Os dispositivos PRECISAM 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 de dispositivos: * [C-0-1] NÃO PODE incluir um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.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 funcionalidade do usuário.
• DEVE fornecer botões para as funções Recentes e Voltar.

Se as funções Home, Recents ou Back forem fornecidas, elas:

• [C-1-1] PRECISA ser acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou 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 do dispositivo não fornecerem a função de menu, para compatibilidade com versões anteriores, elas: * [C-SR] É FORTEMENTE RECOMENDADO disponibilizar a função de menu para aplicativos quando targetSdkVersion for menor que 10, seja por um botão físico, uma tecla de software ou gestos. Essa função de menu DEVE estar acessível, a menos que esteja oculta com outras funções de navegação.

Se as implementações de dispositivos fornecerem a função 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), 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, 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 não incluírem uma tela touchscreen (e dependerem apenas de um dispositivo ponteiro) e atenderem aos requisitos de toque falso na seção 7.2.5, elas:

• [C-3-1] NÃO É POSSÍVEL informar nenhuma flag de recurso que comece com android.hardware.touchscreen e PRECISA informar apenas android.hardware.faketouch.

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 de um ponteiro para cima, o que permite que os usuários emulem uma ação de arrastar por toque.
• [C-1-6] PRECISA oferecer suporte ao ponteiro para baixo e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, apontem para cima na tela, o que permite que os usuários arrastem um objeto na tela.
• [C-1-7] É NECESSÁRIO informar TOUCHSCREEN_NOTOUCH no campo da API Configuration.touchscreen.

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

Se as implementações de dispositivo declararem a flag de recurso android.hardware.gamepad, elas:

• [C-1-1] PRECISA ter um controlador incorporado ou um navio com um controlador separado na caixa, o que daria meios de inserir todos os eventos listados nas tabelas abaixo.
• [C-1-2] PRECISA ser capaz de mapear eventos HID para as constantes view.InputEvent do Android associadas, conforme listado nas tabelas abaixo. A implementação upstream do Android inclui a implementação para controles de jogos que atendem a esse requisito.

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 à esquerda1 Botão direcional à 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_Botão_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 Esse uso PRECISA ter um Mínimo lógico de 0, um Máximo Lógico de 7, um Mínimo Físico de 0, um Máximo Físico de 315, Unidades em Graus e um Tamanho de Relatório de 4. O valor lógico é definido como a rotação no sentido horário longe do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima está sendo pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e para a esquerda 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	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

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

7,3 Sensores

Se as implementações do dispositivo 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.

• [SR] DEVE 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(). É RECOMENDADO que dispositivos Android novos e atuais atendam a esses requisitos para que eles possam fazer upgrade para as próximas versões da plataforma, em que isso pode se tornar um componente OBRIGATÓRIO. O erro de sincronização DEVE ser inferior a 100 milissegundos.

• [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.

• 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.

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.

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^, no qual 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] é MUITO RECOMENDADO 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] É FORTEMENTE 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 abaixo de 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 com a taxa de amostragem mais rápida, não superior a 1,5 μT. DEVE ter um desvio padrão menor que 0,5 μT.
• DEVE implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] Dispositivos Android novos e já existentes são RECOMENDADOS PARA implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Se as implementações de dispositivos incluírem um magnetômetro de três eixos, um sensor de acelerômetro e um sensor de giroscópio de três eixos, elas:

• [C-2-1] PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR.

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

• PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

• [C-3-1] PRECISA consumir menos de 10 mW.
• DEVE consumir menos de 3 mW quando o sensor estiver registrado no modo de lote a 10 Hz.

7.3.3. GPS

Implementações de dispositivos:

• [C-SR] É 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] Depois de fazer esse cálculo, as implementações do dispositivo PRECISAM determinar a localização dele em céu aberto em até cinco segundos quando as solicitações de localização forem reiniciadas, até uma hora após o cálculo inicial, mesmo quando a solicitação 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 pelas APIs de provedor de localização GNSS durante uma chamada 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, a menos que um acelerômetro de três eixos também esteja incluído.

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] É FORTEMENTE 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] FORTEMENTE 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

Implementações de dispositivos:

• PODE incluir um termômetro ambiente (sensor de temperatura).
• PODE, mas NÃO DEVE incluir um sensor de temperatura da CPU.

Se as implementações do dispositivo incluírem um termômetro ambiente (sensor de temperatura), elas:

• [C-1-1] PRECISA ser definida como SENSOR_TYPE_AMBIENT_TEMPERATURE e medir em graus Celsius a temperatura ambiente (da cabine do usuário/ambiente) em que o usuário está interagindo com o dispositivo.
• [C-1-2] PRECISA ser definido como SENSOR_TYPE_TEMPERATURE.
• [C-1-3] PRECISA medir a temperatura da CPU do dispositivo.
• [C-1-4] NÃO PODE medir nenhuma outra temperatura.

O tipo de sensor SENSOR_TYPE_TEMPERATURE foi descontinuado no Android 4.0.

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 acessado 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 pelo menos -8 g e +8 g. DEVE ter um intervalo entre pelo menos -16 g e +16 g.
  • PRECISA ter uma resolução de medição de pelo menos 2.048 LSB/g.
  • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais. DEVE oferecer suporte ao SensorDirectChannel RATE_VERY_FAST.
  • PRECISA ter um ruído de medição menor ou igual a 400 μg/✓Hz.
  • PRECISA implementar uma forma sem ativação 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 < 2,5 % e variação de sensibilidade entre eixos < 0,2% na faixa de temperatura de operação do dispositivo.

• [C-2-2] PRECISA ter um TYPE_ACCELEROMETER_UNCALIBRATED com os mesmos requisitos de qualidade 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 abaixo de 0,001 °/s cione Hz testada à temperatura ambiente.
  • DEVE ter uma mudança de viés x temperatura ≤ +/- 0,05 °/ s / °C.
  • DEVE ter uma mudança de sensibilidade x temperatura de ≤ 0,02% / °C.
  • DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,2%.
  • DEVE ter uma densidade de ruído menor ou igual a 0,007 °/s/shaped Hz.
  • DEVE ter um erro de calibração inferior a 0,002 rad/s na faixa de temperatura de 10 ~ 40 °C quando o dispositivo estiver parado.
  • DEVE ter sensibilidade à g menor que 0,1°/s/g.
  • DEVE ter sensibilidade entre eixos inferior a 4 % e variação de sensibilidade entre eixos inferior a 0,3% na faixa de temperatura de funcionamento do dispositivo.

• [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 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 Forte, Fraco ou 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 Conveniência por padrão e precisam atender a requisitos adicionais, conforme detalhado abaixo, para serem classificados como Fracos ou Forte. Tanto a biometria fraca quanto a forte têm recursos adicionais, conforme detalhado abaixo.

Para disponibilizar um sensor biométrico para aplicativos de terceiros, as implementações de dispositivos:

• [C-0-1] PRECISA atender aos requisitos de biometria Forte ou Fraco, conforme definido neste documento.

Para permitir o acesso a chaves de armazenamento de chaves para aplicativos de terceiros, as implementações de dispositivos:

• [C-0-2] PRECISA atender aos requisitos de Forte, conforme definido neste documento.

Além disso:

• [C-0-3] PRECISA ser pareada com uma ação de confirmação explícita (por exemplo, o pressionamento de um botão) se a biometria Forte for passiva (por exemplo, rosto ou íris quando não houver sinal explícito da intenção do usuário).
  • [C-SR] A ação de confirmação da biometria passiva é FORTEMENTE RECOMENDADA para ser protegida, de modo que um comprometimento do sistema operacional ou do kernel não possa ser falsificado. Por exemplo, isso significa que a ação de confirmação 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.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Conveniência, elas:

• [C-1-1] PRECISA ter uma taxa de aceitação falsa menor que 0,002%.
• [C-1-2] DEVE 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%.
• [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, pedindo que o usuário confirme já existente ou adicione uma nova credencial de dispositivo (PIN/padrão/senha) protegida pelo TEE. A implementação do Android Open Source Project fornece o mecanismo no framework para fazer isso.
• [C-1-5] PRECISA remover completamente todos os dados biométricos identificáveis de um usuário quando a conta dele for removida (inclusive por meio de uma redefinição para a configuração original).
• [C-1-6] PRECISA respeitar a sinalização individual 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 quatro 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] É MUITO 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 fraco, elas:

• [C-2-1] PRECISA atender a todos os requisitos de Conveniência acima, exceto [C-1-2].
• [C-2-2] PRECISA ter uma taxa de aceitação de impostor e de impostor não superior a 20%.
• [C-2-3] PRECISA ter uma implementação de keystore protegido por hardware e realizar a correspondência biométrica em um ambiente de execução isolado fora do espaço do usuário Android ou 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.

Se as implementações de dispositivos quiserem tratar um sensor biométrico como Forte, elas:

• [C-3-1] PRECISA atender a todos os requisitos da seção Fraco acima. 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 taxa de aceitação de impostor e de impostor não superior a 7%.
• [C-3-3] 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 a sensores de posição com 6 graus de liberdade, elas:

• [C-1-1] PRECISA implementar e informar o sensor TYPE_POSE_6DOF.
• [C-1-2] PRECISA ser mais preciso do que apenas o vetor de rotação.

7,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 em "BlockedNumberProvider" sem nenhuma interação com apps. A única exceção é quando o bloqueio de números é temporariamente suspenso, conforme descrito na documentação do SDK.
• [C-1-4] 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] É 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 define a tecla extra EXTRA_LOG_SELF_MANAGED_CALLS no PhoneAccount como true.

• [C-SR] É MUITO 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 de sequência da solicitação de sondagem DEVE ser aleatório entre a última solicitação de uma verificação e a primeira solicitação de sondagem 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 exporem a funcionalidade a apps de terceiros, elas:

• [C-1-1] PRECISA implementar as APIs WifiAwareManager, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA declarar a flag de recurso android.hardware.wifi.aware.
• [C-1-3] PRECISA oferecer suporte às operações Wi-Fi e Wi-Fi Aware simultaneamente.
• [C-1-4] PRECISA randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de até 30 minutos e sempre que o Wi-Fi Aware estiver ativado.

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 incluírem suporte ao Wi-Fi Easy Connect e expõem a funcionalidade a apps de terceiros, elas:

• [C-1-1] PRECISA implementar as APIs de intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI, conforme descrito na documentação do SDK.
• [C-1-2] 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 para Bluetooth Low Energy, 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.
• 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.

• [SR] RECOMENDADO ALTAMENTE que implemente um tempo limite de endereço particular solucionável (RPA, na sigla em inglês) de até 15 minutos e alterne o endereço quando o tempo limite for atingido para proteger a privacidade do usuário.

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 atuar como leitor/gravador do NFC Forum (conforme definido pela especificação técnica do NFCForum-TS-Digital Protocol-1.0) usando os seguintes padrões NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6.319-4)
  • IsoDep (ISO 14443-4)
  • Tipos de tag do fórum NFC 1, 2, 3, 4, 5 (definidos pelo fórum NFC)

• [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. Dispositivos novos e atuais que executam essa versão do Android são MUITO FORTEMENTE incentivados a atender a esses requisitos agora para poderem fazer upgrade para as futuras 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 de controlador NFC capaz de 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. 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.
• [C-0-2] PRECISA incluir uma pilha de rede IPv6 e oferecer suporte à comunicação IPv6 usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, além das APIs nativas, como soquetes AF_INET6.
• [C-0-3] PRECISA ativar o IPv6 por padrão.
• PRECISA garantir que a comunicação do IPv6 seja tão confiável quanto com o IPv4, por exemplo:
  • [C-0-4] PRECISA manter a conectividade IPv6 no modo Soneca.
  • [C-0-5] A limitação de taxa NÃO PODE fazer o dispositivo perder 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.

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 na Ethernet.

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

• DEVE 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-3-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.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.
• [C-1-2] PRECISA fornecer uma interface do usuário nas configurações que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, permitindo que os usuários adicionem ou removam aplicativos da lista de permissões.

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

• [C-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.
• [C-2-3] PRECISA ter uma atividade que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mas PODE a implementar como um ambiente autônomo.

7.4.8. Elementos de segurança

Se as implementações de dispositivos forem compatíveis com elementos de segurança compatíveis com a Open Mobile API e os disponibilizarem para apps de terceiros, elas:

• [C-1-1] PRECISA enumerar os leitores de elementos de segurança disponíveis quando o método android.se.omapi.SEService.getReaders() é chamado.

7,5. Câmeras

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

• [C-1-1] PRECISA declarar a flag de recurso android.hardware.camera.any.
• [C-1-2] PRECISA ser possível para 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 oposta à tela, ou seja, ela captura cenas no outro lado do dispositivo, como uma câmera tradicional.

Implementações de dispositivos:

• DEVE incluir uma câmera traseira.

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

• [C-1-1] PRECISA informar a flag de recurso android.hardware.camera e android.hardware.camera.any.
• [C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
• DEVE ter foco automático 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 normalmente usada para imagens do usuário, por exemplo, para videoconferências e aplicativos semelhantes.

Implementações de dispositivos:

• PODE incluir uma câmera frontal.

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

• [C-1-1] PRECISA informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
• [C-1-3] NÃO PODE usar uma câmera frontal como padrão para a API Camera nem configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera no dispositivo.
• [C-1-4] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo quando o aplicativo atual tiver solicitado explicitamente que a tela da câmera seja girada por meio de uma chamada para o método android.hardware.Camera.setDisplayOrientation(). Por outro lado, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo quando o aplicativo atual não solicita explicitamente que a tela da câmera seja girada com uma chamada para o método android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NÃO É POSSÍVEL espelhar os streams de vídeo ou 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 o controle 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 retornos de chamada da API ainda PRECISAM ser “falsos”, como 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 de android.hardware.camera2 pela propriedade android.request.availableCapabilities e declarar as flags de recursos adequadas. É NECESSÁRIO 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-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, é aplicado a dispositivos com modo paisagem e modo retrato principal.

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", "armazenamento compartilhado do aplicativo" ou pelo caminho do Linux "/sdcard" no qual está montado.
• [C-0-2] PRECISA ser configurado com o armazenamento compartilhado montado por padrão, ou seja, "fora da caixa", independentemente de o armazenamento ser implementado em um componente de armazenamento interno ou em 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 aplicar a permissão android.permission.WRITE_EXTERNAL_STORAGE nesse armazenamento compartilhado, conforme documentado no SDK.
• [C-0-5] PRECISA ativar o armazenamento com escopo por padrão para todos os apps destinados ao nível 29 da API ou mais recente, exceto nas seguintes situações:
  • quando o app foi instalado antes do upgrade do dispositivo para o nível da API 29, independentemente da API de destino do app.
  • quando o app solicita android:requestLegacyExternalStorage="true" no manifesto.
  • quando o app recebe a permissão android.permission.WRITE_MEDIA_STORAGE.
• [C-0-6] PRECISA garantir que os apps com o armazenamento com escopo ativado não tenham acesso direto ao sistema de arquivos para arquivos fora dos diretórios específicos do aplicativo, como retornado por métodos da API Context, como Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() e Context.getObbDirs().
• [C-0-7] É 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 do dispositivo incluírem vários caminhos de armazenamento compartilhado (como um slot para cartão SD e armazenamento interno compartilhado), elas:

• [C-2-1] PRECISA permitir que apenas apps Android pré-instalados e privilegiados com a permissão WRITE_MEDIA_STORAGE façam gravações no armazenamento externo secundário, exceto ao gravar nos diretórios específicos do pacote ou no URI retornado pelo disparo da intent ACTION_OPEN_DOCUMENT_TREE.
• [C-2-2] PRECISA exigir que o acesso direto associado à permissão android.permission.WRITE_MEDIA_STORAGE só seja dado a apps visíveis ao usuário quando a permissão android.permission.WRITE_EXTERNAL_STORAGE também for concedida.
• [SR] RECOMENDOU ALTAMENTE que apps Android pré-instalados e privilegiados usem APIs públicas, como MediaStore, para interagir com dispositivos de armazenamento, em vez de depender do acesso direto concedido pelo android.permission.WRITE_MEDIA_STORAGE.

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. É 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. É RECOMENDADO que dispositivos Android novos e atuais atendam a esses requisitos para que possam ser atualizados 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. É 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 fim da string iInterface de descrição da interface do armazenamento USB em massa.

7.7.2. Modo host USB

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

• [C-1-1] PRECISA implementar a API de host USB do Android, conforme documentado no SDK do Android, e PRECISA declarar suporte ao recurso de hardware android.hardware.usb.host.
• [C-1-2] PRECISA implementar o suporte para conectar periféricos USB padrão. Em outras palavras, é NECESSÁRIO:
  • Ter uma porta tipo C no dispositivo ou enviar com cabos adaptando uma porta 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 do dispositivo periférico USB conectado no modo host, divulgando 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 do cabo e da especificação do conector USB-C para conectores USB-C ou usando o intervalo atual de saída da porta de encaminhamento de carregamento(CDP, na sigla em inglês), conforme especificado nas Especificações de carregamento de bateria USB-AB, revisão 1.2.
• 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 de 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 oferecer suporte à gravação de áudio de fones de ouvido estéreo com microfone.

Se as implementações do dispositivo tiverem uma entrada de áudio de 3, 5 mm com quatro condutores e 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:

• DEVE fornecer um caminho de sinal de áudio sem falhas para fluxos de entrada e saída em dispositivos portáteis, conforme definido por zero falhas medidas durante um teste de um minuto por caminho. Teste usando o "Automated Glitch Test" do [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester).

O teste 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
NUNCA	COMPARTILHADO	48000	1	2
NUNCA	COMPARTILHADO	48000	2	1
NUNCA	COMPARTILHADO	44100	1	2
NUNCA	COMPARTILHADO	44100	2	1
NUNCA	COMPARTILHADO	16000	1	2
NUNCA	COMPARTILHADO	16000	2	1

Um stream confiável DEVE atender aos seguintes critérios de relação sinal-ruído (SNR, na sigla em inglês) e distorção harmônica total (THD) para 2.000 Hz seno.

Transdutor	THD	SNR
Alto-falante integrado principal, medido com um microfone de referência externo	Menor que 3%	>= 50 dB
microfone integrado principal, medido com um alto-falante de referência externo	Menor que 3%	>= 50 dB
Entradas de 3,5 mm analógicas integradas, testadas com o adaptador de loopback	Menos de 1%	>= 60 dB
Adaptadores USB fornecidos com o telefone, testados com o adaptador de loopback	Menor que 1%	>= 60 dB

7,9. Realidade virtual

O Android inclui APIs e instalações para criar aplicativos de "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] PRECISA oferecer suporte ao OpenGL ES 3.2.
• [C-1-5] PRECISA oferecer suporte a android.hardware.vulkan.level 0.
• DEVE oferecer suporte a android.hardware.vulkan.level 1 ou mais recente.
• [C-1-6] PRECISA implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace e expor as extensões na lista de extensões EGL disponíveis.
• [C-1-8] PRECISA implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, 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 e GL_EXT_EGL_image_array 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 1.920 x 1.080 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 20 Mbps a 10 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 de pixels no primeiro frame após uma transição de preto para branco e o brilho de pixels brancos em estado estável de pelo menos 85%.
• [C-SR] É 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.

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 ou ampliar os recursos do AOSP, 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 a Soneca, conforme descrito em Gerenciamento de energia.
• [C-1-5] PRECISA retornar true para PowerManager.isPowerSaveMode() quando o dispositivo estiver no modo de economia de energia.
• [C-SR] É 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".

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 inserir o 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 pelo 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 do aplicativo 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 que você informe todos os valores de consumo de energia em milissegundos por 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 as solicitam no momento da execução.

Implementações de dispositivos:

• [C-0-3] PRECISA mostrar uma interface dedicada para o usuário decidir se vai conceder as permissões de execução solicitadas e também fornecer uma interface para o usuário gerenciar essas permissões.
• [C-0-4] PRECISA ter apenas uma implementação das duas interfaces do usuário.
• [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, buscas por Bluetooth 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] O usuário PRECISA ter o consentimento do usuário para permitir que o app acesse os dados de localização ou atividade física.
• [C-0-9] PRECISA conceder uma permissão de execução APENAS ao app que tiver permissões suficientes, conforme descrito no SDK. Por exemplo, 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é serem adicionados a uma lista de permissões, conforme descrito no SDK, em que o acesso total e limitado é definido para cada permissão do softRestricted (por exemplo, WRITE_EXTERNAL_STORAGE e READ_EXTERNAL_STORAGE).

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:

• [SR] é FORTEMENTE RECOMENDADO fornecer um mecanismo acessível ao usuário para conceder ou revogar acesso às estatísticas de uso em resposta à intent android.settings.ACTION_USAGE_ACCESS_SETTINGS 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-1-1] ainda PRECISA ter uma atividade que processe o padrão de intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mas PRECISA implementá-la como ambiente autônomo, ou seja, ter um comportamento equivalente ao de um usuário recusado para acesso.

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 de 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 que não foram solicitadas no arquivo AndroidManifest.xml do ambiente de execução pelo mecanismo <uses-permission>.

• [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 uma violação de segurança desbloqueada ocorrer 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 que envolvam segurança, conforme explicado em CFI e IntSan.

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] após 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 mostrar e receber o consentimento explícito do usuário com a mesma mensagem do AOSP sempre que a transmissão ou gravação de tela for ativada usando o MediaProjection ou APIs próprias. NÃO PODE fornecer aos usuários uma affordance para desativar a exibição futura do consentimento do usuário.

• [C-0-3] O usuário PRECISA 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 mostrar um aviso ao usuário indicando:
  • Esse tráfego de rede pode ser monitorado.
  • Esse tráfego de rede está sendo roteado pelo aplicativo de VPN específico que fornece a VPN.

Se as implementações de dispositivos tiverem um mecanismo, ativado e pronto para uso por padrão, que 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 do usuário para ativar a função "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.

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 que apenas 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. Localização

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).
• [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,9. Criptografia do armazenamento de dados

Todos os dispositivos PRECISAM atender aos requisitos da seção 9.9.1. Os dispositivos iniciados em um nível de API anterior ao deste documento estão isentos dos requisitos das seções 9.9.2 e 9.9.3. Em vez disso, eles PRECISAM atender aos requisitos da seção 9.9 do documento de definição de compatibilidade do Android correspondente ao nível da API em que o dispositivo foi iniciado.

9.9.1. Inicialização direta

Implementações de dispositivos:

• [C-0-1] PRECISA implementar as APIs do modo de inicialização direta, mesmo que elas não ofereçam suporte à criptografia de armazenamento.

• [C-0-2] As intents ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED ainda PRECISAM ser transmitidas para sinalizar aos 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 de armazenamento de dados acima implementando a criptografia baseada em arquivos (FBE, na sigla em inglês).

9.9.3. Criptografia baseada em arquivos

Dispositivos criptografados:

• [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-3] NÃO PODE oferecer nenhum método para desbloquear o armazenamento protegido por CE sem as credenciais fornecidas pelo usuário ou uma chave de garantia registrada.
• [C-1-4] PRECISA usar a Inicialização verificada e garantir que as chaves DE estejam vinculadas criptograficamente à raiz de confiança do hardware do dispositivo.
• [C-1-5] PRECISA criptografar o conteúdo do arquivo 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.
• [C-1-6] PRECISA criptografar nomes de arquivos usando AES-256-CBC-CTS ou Adiantum.

• [C-1-12] PRECISA usar AES-256-XTS para conteúdos de arquivos e AES-256-CBC-CTS para nomes de arquivos (em vez de Adiantum) se o dispositivo tiver instruções Padrão de criptografia avançada (AES). As instruções do AES são extensões de criptografia ARMv8 em dispositivos com processador ARM ou AES-NI em dispositivos baseados em x86. Se o dispositivo não tiver instruções de AES, ele PODE usar o Adiantum.

• As chaves que protegem as áreas de armazenamento CE e DE:

• [C-1-7] PRECISA estar vinculado criptograficamente a um Keystore protegido por hardware.

• [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.

• [C-SR] É MUITO RECOMENDADO para criptografar metadados do sistema de arquivos, como tamanhos de arquivo, propriedade, modos e atributos estendidos (xattrs), com uma chave vinculada criptograficamente à raiz de confiança do hardware do dispositivo.

• DEVE tornar os apps essenciais pré-instalados (por exemplo, Alarme, Telefone, Messenger) com reconhecimento de inicialização direta.

O projeto upstream do Android Open Source oferece uma implementação preferencial desse recurso com base no recurso de criptografia "fscrypt" do kernel do Linux.

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 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-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.

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.
• [C-2-2] É NECESSÁRIO desbloquear todas as chaves de um app de desenvolvedor terceirizado quando o usuário desbloqueia a tela de bloqueio segura. Por exemplo, todas as chaves PRECISAM estar disponíveis para um app de desenvolvedor terceirizado usando APIs relevantes, como createConfirmDeviceCredentialIntent e setUserAuthenticationRequired.

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] 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 sobre 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 (ou seja, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Se os métodos de autenticação biométrica não atenderem aos requisitos de 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 desafiado quanto à autenticação principal recomendada (por exemplo: PIN, padrão, senha) após qualquer tempo limite de inatividade de quatro horas. O tempo limite de inatividade é redefinido após qualquer confirmação bem-sucedida das credenciais do dispositivo.
• [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 ele pode ser mantido desbloqueado por agentes de confiança. Por exemplo, o AOSP atende a esse requisito mostrando uma descrição de texto para a "Configuração de bloqueio automático" e "O botão liga/desliga é bloqueado instantaneamente" no menu de configurações e um ícone distinguível na tela de bloqueio.
• [C-7-2] PRECISA respeitar e implementar totalmente todas as APIs do agente de confiança na classe DevicePolicyManager, como a constante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NÃO PODE implementar completamente a função TrustAgentService.addEscrowToken() em um dispositivo usado como dispositivo pessoal principal (por exemplo, portátil), mas PODE implementar totalmente a função em implementações de dispositivo que normalmente são compartilhadas (por exemplo, Android Television ou Automotive).
• [C-7-4] PRECISA criptografar todos os tokens armazenados adicionados por TrustAgentService.addEscrowToken().
• [C-7-5] NÃO PODE armazenar a chave de criptografia ou o token de garantia no mesmo dispositivo em que a chave é usada. Por exemplo, uma chave armazenada em um smartphone pode desbloquear uma conta de usuário em uma TV.
• [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 desafiado por um dos métodos principais de autenticação recomendados (por exemplo, PIN, padrão, senha) após qualquer tempo limite de inatividade de quatro horas, a menos que seja uma preocupação para a segurança do usuário (por exemplo, distração do motorista). O tempo limite de inatividade é redefinido após qualquer confirmação bem-sucedida das credenciais do dispositivo.
• [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 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,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 o processo de "redefinição para configuração original" acima quando a API DevicePolicyManager.wipeData() é chamada pelo app Device Policy Controller do usuário principal.
• PODE fornecer uma opção rápida de limpeza de dados que conduz apenas uma limpeza lógica de dados.

9,13 Modo de inicialização segura

O Android oferece o modo de inicialização segura, que permite 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" são os detalhes do plano da relação de faturamento fornecidos pela operadora de celular pelo 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.

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, é FORTEMENTE RECOMENDADO que os implementadores de dispositivos façam o número mínimo de alterações 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 10.

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 têm. Por exemplo, se um dispositivo tiver um acelerômetro, ele PRECISA executar corretamente o caso de teste do acelerômetro no CTS Verifier.

Os casos de teste para recursos marcados como opcionais por este Documento de definição de compatibilidade podem ser 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 ao build.

Para uma melhor visualização, anexe os parâmetros de URL pretty=full e no-merges aos URLs do registro de alterações.

13. Entre em contato

Você pode participar do fórum de compatibilidade do Android e pedir esclarecimentos ou mencionar problemas que você acredita que o documento não abrange.