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 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" está de acordo com o padrão IETF definido na RFC2119.

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

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 omissos, ambíguos ou incompletos, será responsabilidade do implementador do dispositivo garantir a compatibilidade com as implementações atuais.

Por isso, o Android Open Source Project é a implementação de referência e preferida do Android. É ALTAMENTE RECOMENDADO que os implementadores de dispositivos baseiem as implementações, na maior medida possível, no código-fonte "upstream" disponível no Android Open Source Project. Embora alguns componentes possam ser substituídos por implementações alternativas, NÃO É RECOMENDADO seguir essa prática, já que a aprovação nos testes de software vai ficar muito mais difícil. É responsabilidade do implementador garantir a compatibilidade comportamental total com a implementação padrão do Android, incluindo e além do conjunto de teste de compatibilidade. Por fim, observe que algumas substituições e modificações de componentes são explicitamente proibidas por este documento.

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

1.1 Estrutura do documento

1.1.1. Requisitos por tipo de dispositivo

A Seção 2 contém todos os requisitos aplicáveis 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 dispositivo Android, estão listados nas seções após a Seção 2. Esses requisitos são mencionados como "Requisitos principais" neste documento.

1.1.2. ID do requisito

O ID do requisito é atribuído para requisitos MUST.

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

Cada ID é definido da seguinte forma:

  • ID do tipo de dispositivo (saiba mais em 2. Tipos de dispositivo)
    • C: Core (requisitos aplicados a qualquer implementação de dispositivo Android)
    • H: dispositivo portátil Android
    • T: dispositivo Android Television
    • R: Implementação do Android Automotive
    • W: Android Watch implementation
    • Guia: implementação em tablet Android
  • ID da condição
    • Quando o requisito é incondicional, esse ID é definido como 0.
    • Quando o requisito é condicional, 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
    • Ele começa em 1 e aumenta em 1 na mesma seção e condição.

1.1.3. ID do requisito na seção 2

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

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

2. Tipos de dispositivo

Embora o Projeto de código aberto do Android forneça uma pilha de software que pode ser usada em vários tipos de dispositivos e formatos, há alguns tipos de dispositivos que têm um ecossistema de distribuição de aplicativos relativamente mais estabelecido.

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

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

2.1 Configurações do dispositivo

Para conferir as principais diferenças na configuração de hardware por tipo de dispositivo, consulte os requisitos específicos de cada 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 são classificadas como portáteis se atendem a todos os critérios a seguir:

  • Ter uma fonte de energia que ofereça mobilidade, como uma bateria.
  • Ter um tamanho de tela diagonal física entre 2,5 e 8 polegadas.

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

Observação:os requisitos que não se aplicam a tablets Android estão marcados com um asterisco (*).

2.2.1. Hardware

Implementações de dispositivos portáteis:

  • [7.1.1.1/H-0-1] Precisa ter pelo menos uma tela compatível com Android de pelo menos 6,35 cm na diagonal física, e cada tela compatível com Android precisa atender a todos os requisitos descritos neste documento.
  • [7.1.1.3/H-SR] É ALTAMENTE RECOMENDADO oferecer aos usuários uma opção para mudar o tamanho da tela (densidade da tela).

Se as implementações de dispositivos móveis declararem suporte a telas de alto alcance dinâmico usando Configuration.isScreenHdr() , elas:

  • [7.1.4.5/H-1-1] É OBRIGATÓRIO anunciar suporte às 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 para o modo de compatibilidade de aplicativos legados, conforme implementado pelo código-fonte aberto do Android upstream. Ou seja, as implementações de dispositivos NÃO PODEM alterar os gatilhos ou limites em que o modo de compatibilidade é ativado, nem o comportamento do próprio modo de compatibilidade.
  • [7.2.1/H-0-1] PRECISA incluir suporte para aplicativos de editores de método de entrada (IME) de terceiros.
  • [7.2.3/H-0-3] É OBRIGATÓRIO fornecer a função "Início" em todas as telas compatíveis com Android que oferecem a tela inicial.
  • [7.2.3/H-0-4] É OBRIGATÓRIO fornecer a função "Voltar" em todas as telas compatíveis com Android e a função "Recentes" em pelo menos uma das telas compatíveis com Android.
  • [7.2.3/H-0-2] É OBRIGATÓRIO enviar o evento de toque normal e longo da função Voltar (KEYCODE_BACK) para o aplicativo em primeiro plano. Esses eventos NÃO DEVEM ser consumidos pelo sistema e PODEM ser acionados fora do dispositivo Android (por exemplo, um teclado de hardware externo conectado ao dispositivo Android).
  • [7.2.4/H-0-1] PRECISA oferecer suporte à entrada por tela sensível ao toque.
  • [7.2.4/H-SR] É ALTAMENTE RECOMENDADO iniciar o app de assistência selecionado pelo usuário, ou seja, o app que implementa o VoiceInteractionService ou uma atividade que processa o ACTION_ASSIST ao pressionar e manter pressionado KEYCODE_MEDIA_PLAY_PAUSE ou KEYCODE_HEADSETHOOK se a atividade em primeiro plano não processar esses eventos de pressionar e manter pressionado.
  • [7.3.1/H-SR] É ALTAMENTE 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 ser capaz de informar eventos com 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] É OBRIGATÓRIO informar as medições de GNSS assim que forem encontradas, mesmo que um local calculado com base em GPS/GNSS ainda não tenha sido informado.
  • [7.3.3/H-2-2] DEVE informar pseudodistâncias e taxas de pseudodistância do GNSS que, em condições de céu aberto após a determinação do local, enquanto parado ou se movendo com menos de 0, 2 metro por segundo ao quadrado de aceleração, são suficientes para calcular a posição em até 20 metros e a velocidade em até 0, 2 metro por segundo, pelo menos 95% das vezes.

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 ser capaz de informar eventos com uma frequência de pelo menos 100 Hz.
  • [7.3.4/H-3-2] PRECISA ser capaz de medir mudanças de orientação de até 1.000 graus por segundo.

Implementações de dispositivos móveis que podem fazer uma chamada de voz e indicar qualquer valor diferente de PHONE_TYPE_NONE em getPhoneType:

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

Implementações de dispositivos portáteis:

  • [7.3.11/H-SR] SÃO RECOMENDADOS para oferecer suporte ao sensor de postura com 6 graus de liberdade.
  • [7.4.3/H] DEVE incluir suporte para 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] É OBRIGATÓRIO fornecer o modo de economia de dados.

Se as implementações de dispositivos portáteis incluírem um dispositivo de câmera lógica que liste 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, que deve 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 particulares do aplicativo (também conhecida como partição "/data").
  • [7.6.1/H-0-2] MUST return "true" for ActivityManager.isLowRamDevice() when there is less than 1GB of memory available to the kernel and userspace.

Se as implementações de dispositivos móveis declararem suporte apenas a uma ABI de 32 bits:

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

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

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

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

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

  • [7.6.1/H-5-1] A memória disponível para o kernel e o espaço do usuário PRECISA ser de pelo menos 816 MB se a tela padrão usar resoluções de framebuffer 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 1824 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 etc., que não estão sob o controle do kernel em implementações de dispositivos.

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

  • [7.6.1/H-9-1] MUST declare the feature flag android.hardware.ram.low.
  • [7.6.1/H-9-2] DEVE ter pelo menos 1,1 GB de armazenamento não volátil para dados particulares do aplicativo (também conhecida 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] DEVE ter pelo menos 4 GB de armazenamento não volátil disponível para dados particulares do aplicativo (também conhecida como partição "/data").
  • PRECISA 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 periférico.

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] É OBRIGATÓRIO 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] É OBRIGATÓRIO implementar a classe de áudio USB conforme documentado na documentação do SDK do Android.

Implementações de dispositivos portáteis:

  • [7.8.1/H-0-1] 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 VR e incluírem esse suporte, elas:

  • [7.9.1/H-1-1] MUST declare the android.hardware.vr.high_performance feature flag.
  • [7.9.1/H-1-2] PRECISA incluir um aplicativo que implemente android.service.vr.VrListenerService e 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 da seção 7.7.2, elas:

  • [7.8.2.2/H-1-1] DEVE fornecer o seguinte mapeamento de software de códigos HID:
Função Mapeamentos Contexto Comportamento
A Página de uso do HID: 0x0C
Uso do HID: 0x0CD
Tecla do kernel: KEY_PLAYPAUSE
Tecla do Android: KEYCODE_MEDIA_PLAY_PAUSE 		Controles de mídia Entrada: pressione rapidamente
Saída: reproduzir ou pausar
Entrada: toque e pressione
Saída: iniciar comando de voz
Envia: android.speech.action.VOICE_SEARCH_HANDS_FREE se o dispositivo estiver bloqueado ou com a tela desligada. Envia android.speech.RecognizerIntent.ACTION_WEB_SEARCH caso contrário
Chamada recebida Entrada: pressione rapidamente
Saída: aceitar chamada
Entrada: toque e mantenha pressionado
Saída: rejeitar a chamada
Chamada em andamento Entrada: pressione rapidamente
Saída: encerrar ligação
Entrada: pressione e mantenha pressionado
Saída: ativar ou desativar o som do microfone
B Página de uso do HID: 0x0C
Uso do HID: 0x0E9
Tecla do kernel: KEY_VOLUMEUP
Tecla do Android: VOLUME_UP 		Reprodução de mídia, chamada em andamento Entrada: pressione rapidamente ou por mais tempo
Saída: aumenta o volume do sistema ou do headset
C Página de uso do HID: 0x0C
Uso do HID: 0x0EA
Chave do kernel: KEY_VOLUMEDOWN
Chave do Android: VOLUME_DOWN 		Reprodução de mídia, chamada em andamento Entrada: pressione rapidamente ou por mais tempo
Saída: diminui o volume do sistema ou do headset
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 acionada em qualquer instância. Entrada: toque curto ou longo em
Saída: inicia o comando de voz
  • [7.8.2.2/H-1-2] DEVE acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que as interfaces e os endpoints de áudio USB forem enumerados corretamente para identificar o tipo de terminal conectado.

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

  • [7.8.2.2/H-2-1] MUST broadcast Intent ACTION_HEADSET_PLUG with "microphone" extra set to 0.

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

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

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

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

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

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

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

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

  • [7.8.2.2/H-4-7] PRECISA listar um dispositivo do tipo AudioDeviceInfo.TYPE_USB_DEVICE e 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 ao conectar um periférico de áudio USB-C para realizar a enumeração de descritores USB, identificar tipos de terminais e transmitir a intent ACTION_HEADSET_PLUG em menos de 1.000 milissegundos.

2.2.2. Multimídia

As implementações de dispositivos móveis 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 HE AAC MPEG-4 (AAC+)
  • [5.1/H-0-5] AAC ELD (AAC aprimorado com atraso baixo)

As implementações de dispositivos móveis 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 móveis precisam oferecer suporte aos seguintes formatos de decodificação de vídeo e disponibilizá-los para aplicativos de terceiros:

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

2.2.3. Software

Implementações de dispositivos portáteis:

  • [3.2.3.1/H-0-1] É obrigatório ter um aplicativo que processe as intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE e ACTION_CREATE_DOCUMENT conforme descrito nos documentos do SDK, além de oferecer ao usuário a possibilidade de acessar os dados do provedor de documentos usando a API DocumentsProvider.
  • [3.4.1/H-0-1] É OBRIGATÓRIO fornecer uma implementação completa da API android.webkit.Webview.
  • [3.4.2/H-0-1] PRECISA incluir um aplicativo de navegador independente para navegação na Web do usuário em geral.
  • [3.8.1/H-SR] É ALTAMENTE RECOMENDADO implementar um iniciador padrão que ofereça suporte à fixação no app de atalhos, widgets e widgetFeatures.
  • [3.8.1/H-SR] É ALTAMENTE RECOMENDADO implementar um iniciador padrão que ofereça acesso rápido aos atalhos adicionais fornecidos por apps de terceiros usando a API ShortcutManager.
  • [3.8.1/H-SR] É ALTAMENTE RECOMENDADO incluir um app de tela de início padrão que mostre selos nos ícones dos apps.
  • [3.8.2/H-SR] É FORTEMENTE RECOMENDADO que eles ofereçam suporte a widgets de apps de terceiros.
  • [3.8.3/H-0-1] PRECISA permitir que apps de terceiros notifiquem os usuários sobre eventos importantes usando as classes de API Notification e NotificationManager.
  • [3.8.3/H-0-2] Precisa oferecer suporte a notificações avançadas.
  • [3.8.3/H-0-3] Precisa oferecer suporte a notificações heads-up.
  • [3.8.3/H-0-4] PRECISA incluir uma aba de notificações, permitindo que o usuário controle diretamente (por exemplo, responder, adiar, dispensar, bloquear) as notificações usando recursos como botões de ação ou o painel de controle implementado no AOSP.
  • [3.8.3/H-0-5] É OBRIGATÓRIO mostrar as opções fornecidas por RemoteInput.Builder setChoices() na aba de notificações.
  • [3.8.3/H-SR] É ALTAMENTE RECOMENDADO mostrar a primeira opção fornecida por RemoteInput.Builder setChoices() na tela de notificações sem interação adicional do usuário.
  • [3.8.3/H-SR] É FORTEMENTE RECOMENDADO mostrar todas as opções fornecidas por RemoteInput.Builder setChoices() na aba de notificações quando o usuário expande todas as notificações.
  • [3.8.3.1/H-SR] É ALTAMENTE RECOMENDADO mostrar ações em que Notification.Action.Builder.setContextual está definido como true em linha com as respostas mostradas por Notification.Remoteinput.Builder.setChoices.
  • [3.8.4/H-SR] É ALTAMENTE RECOMENDADO implementar um assistente no dispositivo para processar a ação de assistência.

Se as implementações de dispositivos móveis oferecerem suporte à ação Assistente, elas:

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

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

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

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

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

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

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

  • [3.16/H-1-1] Precisa oferecer suporte ao recurso de pareamento de 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 "Início" NÃO DEVE ter mais de 32 dp de altura da parte de baixo da tela.

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

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

2.2.4. Desempenho e bateria

  • [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 PODE acontecer mais de cinco vezes por segundo e DEVE ser inferior a um frame por segundo.
  • [8.1/H-0-2] Latência da interface do usuário. As implementações de dispositivos PRECISAM garantir uma experiência do usuário de baixa latência rolando uma lista de 10 mil entradas de 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 forem iniciados, a reinicialização de um aplicativo já em execução após o lançamento DEVE levar menos de um segundo.

Implementações de dispositivos portáteis:

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

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

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

Implementações de dispositivos portáteis:

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

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

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 com a permissão android.permission.PACKAGE_USAGE_STATS e fornecer um mecanismo acessível ao usuário para conceder ou revogar o acesso a esses apps em resposta à intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implementações de dispositivos móveis (* Não aplicável a tablets):

  • [9.11/H-0-2]* É OBRIGATÓRIO fazer backup da implementação do keystore com um ambiente de execução isolado.
  • [9.11/H-0-3]* PRECISA ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções hash MD5, SHA1 e da família SHA-2 para oferecer suporte adequado aos algoritmos compatíveis do sistema Android Keystore em uma área isolada com segurança do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais pelos quais o kernel ou o código do espaço do usuário podem acessar o estado interno do ambiente isolado, incluindo 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]* É OBRIGATÓRIO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e permitir o uso das chaves vinculadas à autenticação somente quando ela for bem-sucedida. As credenciais da tela de bloqueio PRECISAM ser armazenadas de forma que apenas o ambiente de execução isolado possa fazer a autenticação da tela de bloqueio. O projeto de código aberto Android upstream fornece a camada de abstração de hardware (HAL) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
  • [9.11/H-0-5]* PRECISA oferecer suporte ao atestado de chave em que a chave de assinatura do atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser compartilhadas em um número grande o suficiente de dispositivos para evitar que sejam usadas como identificadores de dispositivo. Uma maneira de atender a esse requisito é compartilhar a mesma chave de comprovação,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de uma SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

Se uma implementação de dispositivo já tiver sido lançada em uma versão anterior do Android, ela será isenta da exigência de ter um keystore apoiado por um ambiente de execução isolado e de oferecer suporte à confirmação de chaves, a menos que declare o recurso android.hardware.fingerprint, que exige um keystore apoiado por um ambiente de execução isolado.

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

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

Se as implementações de dispositivos móveis 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 aos proprietários de dispositivos gerenciar outros usuários e os recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para outros usuários trabalharem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.

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

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

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

Implementações de dispositivos móveis (* Não aplicável a tablets):

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

Implementações de dispositivos móveis (* Não aplicável a tablets):

  • Perfetto
    • [6.1/H-0-2]* PRECISA expor um binário /system/bin/perfetto ao usuário do shell, e a linha de comando precisa estar em conformidade com a documentação do perfetto.
    • [6.1/H-0-3]* O binário do perfetto PRECISA aceitar como entrada uma configuração protobuf que 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 rastreamento do 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 de televisão

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

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

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

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

2.3.1. Hardware

Implementações de dispositivos de 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 "Início" e "Voltar".
  • [7.2.3/T-0-2] É OBRIGATÓRIO enviar o evento de toque 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 para controles de jogos e declarar a flag de recurso android.hardware.gamepad.
  • [7.2.7/T] DEVE fornecer um controle remoto com que os usuários possam acessar entradas de navegação sem toque e teclas de navegação principais.

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

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

Implementações de dispositivos de televisão:

  • [7.4.3/T-0-1] Precisa oferecer suporte a Bluetooth e Bluetooth LE.
  • [7.6.1/T-0-1] Precisa ter pelo menos 4 GB de armazenamento não volátil disponível para dados particulares do aplicativo (também conhecida 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 para uma câmera externa que se conecta por essa porta USB, mas não precisa estar 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 alguma das seguintes densidades for usada:

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

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 alguma das seguintes densidades for usada:

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

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

Implementações de dispositivos de televisão:

  • [7.8.1/T] DEVE 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 HE AAC MPEG-4 (AAC+)
  • [5.1/T-0-3] AAC ELD (AAC aprimorado com atraso baixo)

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] É ALTAMENTE RECOMENDADO que ofereçam 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:

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

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

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

  • [5.3.4/T-1-1] HD 1080p a 60 frames por segundo com perfil básico
  • [5.3.4/T-1-2] HD 1080p a 60 frames por segundo com perfil principal
  • [5.3.4/T-1-3] HD 1080p a 60 frames por segundo com High Profile Level 4.2

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

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

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

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

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 frame rates de vídeo padrão e resoluções de até:

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

As implementações de dispositivos de televisão com decodificadores de hardware VP9 PRECISAM ser compatíveis com a decodificação VP9, conforme detalhado na seção 5.3.7, em taxas de frame e resoluções de vídeo padrão até:

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

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

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

Implementações de dispositivos de televisão:

  • [5.5/T-0-1] DEVE incluir suporte para atenuação do volume principal do sistema e do volume de saída de áudio digital em saídas compatíveis, exceto para saída de transmissão direta de áudio compactado (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 por HDMI, elas:

  • [5.8/T-0-1] É NECESSÁRIO 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] É ALTAMENTE RECOMENDADO fornecer um seletor de taxa de atualização HDMI configurável pelo usuário.
  • [5.8] DEVE definir a taxa de atualização do modo de saída HDMI como 50 Hz ou 60 Hz, dependendo da taxa de atualização de vídeo da região em que o dispositivo é vendido.

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

  • [5.8/T-1-1] Precisa oferecer suporte ao HDCP 2.2.

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

  • [5.8/T-2-1] DEVE oferecer suporte ao 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] É OBRIGATÓRIO fornecer uma implementação completa da API android.webkit.Webview.

Se as implementações de dispositivos Android Television forem compatíveis com uma tela de bloqueio,elas:

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

Implementações de dispositivos de televisão:

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

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

  • [3.11/T-SR] É ALTAMENTE RECOMENDADO incluir um mecanismo de TTS compatível com os idiomas disponíveis no dispositivo.
  • [3.11/T-1-1] DEVE oferecer suporte à instalação de mecanismos de 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 bateria

  • [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 PODE acontecer mais de cinco vezes por segundo e DEVE ser inferior a um frame por segundo.
  • [8.2/T-0-1] PRECISA garantir uma performance 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] DEVE garantir uma performance de leitura sequencial de pelo menos 15 MB/s.
  • [8.2/T-0-4] PRECISA garantir uma performance 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 que estão incluídos no AOSP ou estender os recursos incluídos no AOSP, elas:

  • [8.3/T-1-1] PRECISA oferecer ao usuário a possibilidade de ativar e desativar o recurso de economia de bateria.

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

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

  • [8.3/T-1-3] É OBRIGATÓRIO oferecer ao usuário a possibilidade de exibir 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] É OBRIGATÓRIO fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto de código aberto do Android.
  • [8.4/T-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliampère-hora (mAh).
  • [8.4/T-0-3] É OBRIGATÓRIO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
  • [8.4/T] DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
  • [8.4/T-0-4] PRECISA disponibilizar esse uso de energia ao desenvolvedor de apps usando o comando de shell adb shell dumpsys batterystats.

2.3.5. Modelo de segurança

Implementações de dispositivos de televisão:

  • [9.11/T-0-1] É OBRIGATÓRIO fazer backup da implementação do keystore com um ambiente de execução isolado.
  • [9.11/T-0-2] É OBRIGATÓRIO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções hash MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos compatíveis do sistema Android Keystore em uma área isolada com segurança do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais pelos quais o kernel ou o código do espaço do usuário podem acessar o estado interno do ambiente isolado, incluindo 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] É OBRIGATÓRIO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e permitir o uso das chaves vinculadas à autenticação somente quando ela for bem-sucedida. As credenciais da tela de bloqueio PRECISAM ser armazenadas de forma que apenas o ambiente de execução isolado possa fazer a autenticação da tela de bloqueio. O projeto de código aberto Android upstream fornece a camada de abstração de hardware (HAL) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
  • [9.11/T-0-4] PRECISA oferecer suporte ao atestado de chave em que a chave de assinatura do atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser compartilhadas em um número grande o suficiente de dispositivos para evitar que sejam usadas como identificadores de dispositivo. Uma maneira de atender a esse requisito é compartilhar a mesma chave de comprovação,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de uma SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

Se uma implementação de dispositivo já tiver sido lançada em uma versão anterior do Android, ela será isenta da exigência de ter um keystore apoiado por um ambiente de execução isolado e de oferecer suporte à confirmação de chaves, a menos que 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] DEVE permitir que o usuário escolha o tempo limite de inatividade para 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] DEVE oferecer suporte a perfis restritos, um recurso que permite aos proprietários de dispositivos gerenciar outros usuários e os recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para outros usuários trabalharem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.

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

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

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

Implementações de dispositivos de televisão:

2.4. Requisitos do relógio

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

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

  • Ter uma tela com comprimento diagonal física entre 1,1 e 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

Assista às implementações de dispositivos:

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

  • [7.2.3/W-0-1] É OBRIGATÓRIO ter a função "Início" disponível para o usuário e a função "Voltar", exceto quando ela estiver em UI_MODE_TYPE_WATCH.

  • [7.2.4/W-0-1] DEVE oferecer suporte à entrada por tela sensível ao toque.

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

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

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

Se as implementações de dispositivos 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 de até 1.000 graus por segundo.

Assista às implementações de dispositivos:

  • [7.4.3/W-0-1] Precisa oferecer suporte a Bluetooth.

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

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

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

  • [7.8.2/W] PODE, mas NÃO DEVE ter saída de áudio.

2.4.2. Multimídia

Nenhum requisito extra.

2.4.3. Software

Assista às implementações de dispositivos:

  • [3/W-0-1] MUST declare the feature android.hardware.type.watch.
  • [3/W-0-2] Precisa oferecer suporte a uiMode = UI_MODE_TYPE_WATCH.

Assista às implementações de dispositivos:

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

  • [3.10/W-1-1] DEVE oferecer suporte a serviços de acessibilidade de terceiros.

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

  • [3.11/W-SR] É ALTAMENTE RECOMENDADO incluir um mecanismo de TTS compatível com os idiomas disponíveis no dispositivo.

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

2.4.4. Desempenho e bateria

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

  • [8.3/W-SR] É ALTAMENTE RECOMENDADO oferecer ao usuário a capacidade de exibir todos os apps isentos dos modos de economia de energia App em espera e Soneca.
  • [8.3/W-SR] É ALTAMENTE RECOMENDADO oferecer ao usuário a possibilidade de ativar e desativar o recurso de economia de bateria.

Assista às implementações de dispositivos:

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

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

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

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

2.5. Requisitos automotivos

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

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

  • São incorporados como parte de um veículo automotivo ou podem ser conectados a ele.
  • Usar uma tela na fileira do banco do motorista como a 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 de pelo menos 6 polegadas na diagonal física.

  • [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 "Início" e PODE fornecer as funções "Voltar" e "Recentes".

  • [7.2.3/A-0-2] É OBRIGATÓRIO enviar o evento de toque normal e o de toque 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 que o fotômetro.
  • [7.3/A-0-3] É necessário fornecer o campo de informações adicionais do sensor TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor fornecido.
  • [7.3/A-0-1] PODE estimar a localização por estimação combinando GPS/GNSS com outros sensores. Se a Localização for estimada, é ALTAMENTE RECOMENDADO implementar e informar os tipos de Sensor e/ou IDs de propriedade do veículo correspondentes usados.
  • [7.3/A-0-2] O local solicitado via LocationManager#requestLocationUpdates() NÃO PODE ser associado ao mapa.

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

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

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

Implementações de dispositivos automotivos:

  • [7.4.3/A-0-1] DEVE oferecer suporte a Bluetooth e DEVERIA oferecer suporte a Bluetooth LE.

  • [7.4.3/A-0-2] As implementações do Android Automotive precisam oferecer suporte aos seguintes perfis Bluetooth:

    • Chamadas telefônicas pelo perfil viva-voz (HFP).
    • Reprodução de mídia pelo perfil de distribuição de áudio (A2DP).
    • Controle de reprodução de mídia pelo perfil de controle remoto (AVRCP).
    • Compartilhamento de contatos usando o perfil de acesso à agenda telefônica (PBAP, na sigla em inglês).

  • [7.4.3/A-SR] É ALTAMENTE RECOMENDADO oferecer suporte ao perfil de acesso a mensagens (MAP, na sigla em inglês).

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

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

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

Implementações de dispositivos automotivos:

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

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

  • [7.5/A-1-1] NÃO PODE ter câmeras com visão externa acessíveis pelas APIs de câmera do Android, a menos que elas atendam aos requisitos principais de câmera.
  • [7.5/A-SR] É ALTAMENTE RECOMENDADO não girar nem espelhar horizontalmente a visualização da câmera.
  • [7.5.5/A-SR] É FORTEMENTE RECOMENDADO que sejam orientados de forma que a dimensão longa da câmera se alinhe ao horizonte.
  • [7.5/A-SR] É ALTAMENTE RECOMENDADO que tenham uma resolução de pelo menos 1,3 megapixel.
  • PRECISA ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
  • PODE ter foco automático de hardware ou 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 particulares do aplicativo (também conhecida como partição "/data").

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

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

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

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

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

    • 280 dpi ou menos em telas pequenas/normais
    • ldpi ou inferior em telas extragrandes
    • mdpi ou inferior 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 alguma das seguintes densidades for usada:

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

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

    • 400 dpi ou mais em telas pequenas/normais
    • xhdpi ou superior em telas grandes
    • tvdpi ou superior em telas extra 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 1344 MB se alguma das seguintes densidades for usada:

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

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

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

    • 280 dpi ou menos em telas pequenas/normais
    • ldpi ou inferior em telas extragrandes
    • mdpi ou inferior 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 alguma das seguintes densidades for usada:

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

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

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

  • [7.6.1/A-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 alguma das seguintes densidades for usada:

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

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

Implementações de dispositivos automotivos:

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

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 HE AAC MPEG-4 (AAC+)
  • [5.1/A-0-3] AAC ELD (AAC aprimorado com atraso baixo)

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

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

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

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

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

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

2.5.3. Software

Implementações de dispositivos automotivos:

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

  • [3/A-0-2] MUST support 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 na página de referência de permissões automotivas.

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

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

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

Se as implementações de dispositivos automotivos incluírem um botão de pressionar para falar, elas:

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

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

Implementações de dispositivos automotivos:

2.5.4. Desempenho e bateria

Implementações de dispositivos automotivos:

  • [8.2/A-0-1] É OBRIGATÓRIO informar o número de bytes lidos e gravados no armazenamento não volátil por UID de cada processo para que as estatísticas estejam disponíveis aos desenvolvedores pela API do sistema android.car.storagemonitoring.CarStorageMonitoringManager. O Android Open Source Project atende ao requisito com o módulo do kernel uid_sys_stats.
  • [8.3/A-1-3] É necessário 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 é programado.
    • O motorista sai do modo garagem.
  • [8.4/A-0-1] É OBRIGATÓRIO fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto de código aberto do Android.
  • [8.4/A-0-2] É OBRIGATÓRIO informar todos os valores de consumo de energia em miliampères-hora (mAh).
  • [8.4/A-0-3] É OBRIGATÓRIO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
  • [8.4/A] DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.
  • [8.4/A-0-4] PRECISA disponibilizar esse uso de energia ao desenvolvedor de apps usando o comando de shell adb shell dumpsys batterystats.

2.5.5. Modelo de segurança

Se as implementações de dispositivos automotivos forem compatíveis com vários usuários, elas:

Implementações de dispositivos automotivos:

  • [9.11/A-0-1] É OBRIGATÓRIO fazer backup da implementação do keystore com um ambiente de execução isolado.
  • [9.11/A-0-2] É OBRIGATÓRIO ter implementações de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos compatíveis do sistema Android Keystore em uma área isolada de maneira segura do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais pelos quais o kernel ou o código do espaço do usuário podem acessar o estado interno do ambiente isolado, incluindo 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] É OBRIGATÓRIO realizar a autenticação da tela de bloqueio no ambiente de execução isolado e permitir o uso das chaves vinculadas à autenticação somente quando ela for bem-sucedida. As credenciais da tela de bloqueio PRECISAM ser armazenadas de forma que apenas o ambiente de execução isolado possa fazer a autenticação da tela de bloqueio. O projeto de código aberto Android upstream fornece a camada de abstração de hardware (HAL) do Gatekeeper e o Trusty, que podem ser usados para atender a esse requisito.
  • [9.11/A-0-4] DEVE oferecer suporte ao atestado de chaves em que a chave de assinatura do atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser compartilhadas em um número grande o suficiente de dispositivos para evitar que sejam usadas como identificadores de dispositivo. Uma maneira de atender a esse requisito é compartilhar a mesma chave de comprovação,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de uma SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

Se uma implementação de dispositivo já tiver sido lançada em uma versão anterior do Android, ela será isenta da exigência de ter um keystore apoiado por um ambiente de execução isolado e de oferecer suporte à confirmação de chaves, a menos que 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 oferecem suporte a uma tela de bloqueio segura, elas:

  • [9.11/A-1-1] DEVE permitir que o usuário escolha o tempo limite de inatividade para 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] É OBRIGATÓRIO controlar o acesso a mensagens de subsistemas de veículos do framework Android, por exemplo, permitindo tipos e fontes de mensagens permitidos.
  • [9.14/A-0-2] É NECESSÁRIO usar um watchdog contra ataques de negação de serviço do framework Android ou de apps de terceiros. Isso protege contra softwares maliciosos que inundam a rede do veículo com tráfego, o que pode levar a um mau funcionamento dos subsistemas do veículo.

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

Implementações de dispositivos automotivos:

2.6. Requisitos para tablets

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

  • Normalmente usado com as duas mãos.
  • Não tem uma configuração clamshell ou conversível.
  • Qualquer implementação de teclado físico usada com o dispositivo PRECISA ser conectada por uma conexão padrão.
  • Tem uma fonte de energia que oferece mobilidade, como uma bateria.
  • Tem um tamanho de tela diagonal física entre 7 e 18 polegadas.

As implementações de dispositivos tablet têm requisitos semelhantes às de dispositivos móveis. As exceções são indicadas por um asterisco (*) nessa seção e mencionadas para referência nesta seção.

2.6.1. Hardware

Tamanho da tela

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

Giroscópio

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

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

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

As densidades de tela listadas para telas pequenas/normais nos requisitos de dispositivos móveis não se aplicam a tablets.

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

Se as implementações de dispositivos tablet 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)

Realidade virtual de alta performance (Seção 7.9.2)

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

2.6.2. Modelo de segurança

Chaves e credenciais (Seção 9.11)

Consulte a seção [9.11].

Se as implementações de dispositivos tablet 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 aos proprietários de dispositivos gerenciar outros usuários e os recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para outros usuários trabalharem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.

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

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

3. Software

3.1. Compatibilidade gerenciada de API

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

Implementações de dispositivos:

  • [C-0-1] É OBRIGATÓRIO fornecer implementações completas, incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo SDK do Android ou qualquer API decorada com o marcador "@SystemApi" no código-fonte 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 no-ops, exceto quando especificamente permitido por esta Definição de compatibilidade.

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

  • [C-0-5] NÃO PODE permitir que apps de terceiros usem interfaces não SDK, que são definidas como métodos e campos nos pacotes da linguagem Java que estão no boot classpath 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 um @SystemAPI, conforme descrito nos documentos do SDK e membros de classe privados e privados do pacote.

  • [C-0-6] DEVE ser enviado com todas as interfaces não SDK nas mesmas listas restritas fornecidas pelos flags de lista provisória e 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, eles:

    • PODE, se uma API oculta estiver ausente ou implementada de maneira diferente na implementação do dispositivo, mover a API oculta para a lista de bloqueio ou omiti-la de todas as listas restritas.
    • PODE, se uma API oculta ainda não existir no AOSP, adicione-a 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 inclui suporte para estender as APIs gerenciadas, mantendo a mesma versão de nível de 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 maiores ou iguais às versões mínimas permitidas para cada nível de 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 à suspensão de uso do cliente Apache HTTP, as implementações de dispositivos:

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

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

3.2. Compatibilidade flexível de API

Além das APIs gerenciadas da seção 3.1, o Android também inclui uma API "soft" significativa somente de 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, que descrevem o dispositivo atual.

  • [C-0-1] Para fornecer valores consistentes e significativos em todas as implementações de dispositivos, a tabela abaixo inclui outras restrições aos formatos desses valores, que as implementações de dispositivos PRECISAM seguir.
Parâmetro Detalhes
VERSION.RELEASE A versão do sistema Android em execução no momento, em formato legível. Esse 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 de aplicativo de terceiros. Para o 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 de aplicativo de terceiros. Para o Android 10, esse campo PRECISA ter o valor inteiro 10_INT.
VERSION.INCREMENTAL Um valor escolhido pelo implementador do dispositivo que designa o build específico do sistema Android em execução no momento, em formato legível para humanos. Esse valor NÃO PODE ser reutilizado para diferentes builds disponibilizados aos usuários finais. Um uso típico desse campo é indicar qual número de build ou identificador de mudança de controle de origem foi usado para gerar o build. O valor desse campo PRECISA ser codificável como ASCII de 7 bits imprimível e corresponder à expressão regular "^[^ :\/~]+$".
TABULEIRO Um valor escolhido pelo implementador do dispositivo que identifica o hardware interno específico usado pelo dispositivo, em formato legível para humanos. Um possível uso desse campo é indicar a revisão específica da placa que alimenta o dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$".
MARCA Um valor que reflete o nome da marca associada ao dispositivo, conforme conhecido pelos usuários finais. PRECISA estar em um formato legível para humanos e DEVE representar o fabricante do dispositivo ou a marca da empresa em que ele é comercializado. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade de API nativa.
SUPPORTED_32_BIT_ABIS O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade de API nativa.
SUPPORTED_64_BIT_ABIS O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade de 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 de API nativa.
CPU_ABI2 O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade de API nativa.
DISPOSITIVO Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o codinome que identifica a configuração dos recursos de hardware e o design industrial do dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". O nome do dispositivo NÃO PODE mudar durante a vida útil do produto.
FINGERPRINT Uma string que identifica exclusivamente esta build. Ele PRECISA ser razoavelmente legível. Ele PRECISA seguir este modelo:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

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 (na linha de comando do kernel ou em /proc). Ele PRECISA ser razoavelmente legível. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$".
HOST Uma string que identifica de maneira exclusiva o host em que o build foi criado, em formato legível por humanos. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
ID Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão específica, em formato legível por humanos. Esse campo pode ser igual a android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor significativo o suficiente para que os usuários finais distingam entre builds de software. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-]+$".
FABRICANTE O nome comercial do fabricante de equipamento original (OEM) do produto. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia (""). Esse campo NÃO PODE mudar durante o ciclo de vida do produto.
MODEL Um valor escolhido pelo implementador do dispositivo que contém o nome do dispositivo conhecido pelo usuário final. Esse nome PRECISA ser o mesmo usado para comercializar e vender o dispositivo aos usuários finais. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia (""). Esse campo NÃO PODE mudar durante o ciclo de vida do produto.
PRODUTO Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o codinome do produto específico (SKU) que PRECISA ser exclusivo na mesma marca. Precisa ser legível por humanos, mas não necessariamente destinado à visualização por usuários finais. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". O nome do produto NÃO PODE mudar durante a vida útil dele.
SERIAL PRECISA retornar "UNKNOWN".
TAGS Uma lista separada por vírgulas de tags escolhidas pelo implementador do dispositivo que distinguem ainda mais o build. As tags precisam ser codificáveis como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-]+". Além disso, elas 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 que especifica a configuração de tempo de execução do build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas de tempo de execução do Android: user, userdebug ou eng.
USUÁRIO Um nome ou ID do usuário (ou usuário automatizado) que gerou o build. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
SECURITY_PATCH Um valor que indica o nível do patch de segurança de um build. Ele PRECISA indicar que o build não está vulnerável a nenhum dos problemas descritos no Boletim público de segurança do Android designado. Ele PRECISA estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no Boletim público de segurança do Android ou no Aviso de segurança do Android, por exemplo, "2015-11-01".
BASE_OS Um valor que representa o parâmetro FINGERPRINT do build, que é idêntico a este, 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 específica do carregador de inicialização interno usada no dispositivo, em formato legível para humanos. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-]+$".
getRadioVersion() PRECISA ser ou retornar um valor escolhido pelo implementador do dispositivo que identifique a versão específica do rádio/modem interno usado no dispositivo, em formato legível. Se um dispositivo não tiver nenhum rádio/modem interno, ele precisará 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() PRECISA ser ou retornar um número de série de hardware, que PRECISA estar disponível e ser exclusivo em dispositivos com o mesmo MODELO e FABRICANTE. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilidade de intents

3.2.3.1. Intents principais do aplicativo

As intents do Android permitem que componentes de aplicativos solicitem funcionalidades de outros componentes do Android. O projeto upstream do Android inclui uma lista de aplicativos considerados principais, que implementam 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 aplicativos ou componentes de serviço com um gerenciador de intents para todos os padrões de filtro de intent públicos definidos pelos seguintes aplicativos principais do Android no AOSP:

    • Relógio de mesa
    • Navegador
    • Agenda
    • Contatos
    • Galeria
    • GlobalSearch
    • Tela de início
    • 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 referenciado na seção 3.2.3.1 , exceto as configurações, seja substituído por aplicativos de terceiros. A implementação de código aberto do Android upstream permite isso por padrão.

  • [C-0-2] Os implementadores de dispositivos NÃO DEVEM 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, entre outras opções, desativar a interface do usuário "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 que apps de terceiros declarem um comportamento de vinculação de app padrão autorizado para determinados tipos de intents de URI da Web. Quando essas declarações autorizadas são definidas nos padrões de filtro de intent de um app, as implementações de dispositivo:

  • [C-0-4] DEVE tentar validar todos os filtros de intent seguindo as etapas de validação definidas na especificação do Digital Asset Links, conforme implementado pelo gerenciador de pacotes no projeto de código aberto Android upstream.
  • [C-0-5] DEVE tentar validar os filtros de intent durante a instalação do aplicativo e definir todos os filtros de intent de URI validados como gerenciadores de apps padrão para os URIs.
  • PODE definir filtros de intent de URI específicos como gerenciadores de apps padrão para os URIs, se eles forem verificados com sucesso, mas outros filtros de URI candidatos falharem na verificação. Se uma implementação de dispositivo fizer isso, ela DEVERÁ fornecer ao usuário substituições adequadas de padrão por URI no menu de configurações.
  • É OBRIGATÓRIO fornecer ao usuário controles de Links do app por aplicativo em "Configurações" da seguinte forma:
    • [C-0-6] O usuário PRECISA conseguir substituir de forma holística o comportamento padrão dos links de apps para que um app seja: sempre aberto, sempre perguntado ou nunca aberto, o que PRECISA se aplicar a todos os filtros de intent de URI candidatos igualmente.
    • [C-0-7] O usuário PRECISA conseguir ver uma lista dos filtros de intent de URI candidatos.
    • A implementação do dispositivo PODE permitir que o usuário substitua filtros de intent de URI candidatos específicos que foram verificados com sucesso, com base em cada filtro de intent.
    • [C-0-8] A implementação do dispositivo PRECISA permitir que os usuários vejam e substituam filtros de intent de URI candidatos específicos se a implementação do dispositivo permitir que alguns filtros de intent de URI candidatos passem na verificação, enquanto outros podem falhar.
3.2.3.3. Namespaces de intents
  • [C-0-1] As implementações de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou intent de transmissão usando uma ACTION, CATEGORY ou outra string de chave no namespace android. ou com.android..
  • [C-0-2] Os implementadores de dispositivos NÃO PODEM incluir componentes do Android que respeitem novos padrões de intent ou intent de transmissão usando uma ACTION, CATEGORY ou outra string de chave em um espaço de pacote pertencente a outra organização.
  • [C-0-3] Os implementadores de dispositivos NÃO PODEM alterar ou estender nenhum dos padrões de intent 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 claramente 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

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

Implementações de dispositivos:

  • [C-0-1] DEVE transmitir as intents de transmissão pública em resposta a eventos apropriados do sistema, conforme descrito na documentação do SDK. Esse requisito não entra em conflito com a seção 3.5, já que a limitação para aplicativos em segundo plano também é descrita na documentação do SDK.
3.2.3.5. Configurações padrão de app

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

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

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

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

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

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

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

Se as implementações de dispositivos permitirem iniciar atividades do Android normais 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 semelhante a uma atividade em execução na tela principal.
  • [C-1-3] É OBRIGATÓRIO iniciar a nova atividade na mesma tela da atividade que a iniciou quando a nova atividade é iniciada sem especificar uma tela de destino usando a API ActivityOptions.setLaunchDisplayId().
  • [C-1-4] DEVE destruir todas as atividades quando uma tela com a flag Display.FLAG_PRIVATE for removida.
  • [C-1-5] É OBRIGATÓRIO ocultar o conteúdo de todas as telas quando o dispositivo estiver bloqueado com uma tela de bloqueio segura, a menos que o app permita mostrar na parte de cima da tela de bloqueio usando a API Activity#setShowWhenLocked().
  • PRECISA ter android.content.res.Configuration, que corresponde a essa tela, para ser exibida, funcionar corretamente e manter a compatibilidade se uma atividade for iniciada na tela secundária.

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

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

3.3. Compatibilidade da API nativa

A compatibilidade com código nativo é difícil. Por isso, os implementadores de dispositivos:

  • [SR] É ALTAMENTE RECOMENDÁVEL usar as implementações das bibliotecas listadas abaixo do projeto de código aberto Android upstream.

3.3.1. Interfaces binárias de aplicativos

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

Implementações de dispositivos:

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

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

    • armeabi
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64

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

    • libaaudio.so (compatibilidade nativa de áudio do AAudio)

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

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

  • [C-0-9] PRECISA 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 direcionados ao nível 24 da API ou mais recente, já que elas são reservadas.
  • [C-0-11] É OBRIGATÓRIO exportar todos os símbolos de função do OpenGL ES 3.1 e do Android Extension Pack, conforme definido no NDK, pela biblioteca libGLESv3.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.1 descreve em mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
  • [C-0-12] É OBRIGATÓRIO exportar símbolos de função para os símbolos de função principais do Vulkan 1.0, bem como as extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 e VK_KHR_get_physical_device_properties2 pela biblioteca libvulkan.so. Embora todos os símbolos precisem estar presentes, a seção 7.1.4.2 descreve com mais detalhes os requisitos para quando a implementação completa de cada função correspondente é esperada.
  • PRECISA ser criado usando o código-fonte e os arquivos de cabeçalho disponíveis no projeto de código aberto do Android upstream.

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

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

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

  • [C-3-1] Também é necessário oferecer suporte a armeabi-v7a e informar esse suporte, já que armeabi é apenas para compatibilidade retroativa com apps mais antigos.

Se as implementações de dispositivos informarem o suporte à ABI armeabi-v7a, os apps que usam essa ABI:

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

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

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

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

  • [C-2-3] DEVE incluir suporte para a 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] É OBRIGATÓRIO informar android.software.webview.
  • [C-1-2] É OBRIGATÓRIO usar o build do projeto Chromium do projeto upstream 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 pela WebView PRECISA estar neste formato:

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

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

  • O componente WebView DEVE incluir suporte para o maior número possível de recursos do HTML5 e, se for compatível com o recurso, 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 distinto do aplicativo que cria a instância do WebView. Especificamente, o processo de renderização separado PRECISA ter privilégio menor, ser executado como um ID de usuário separado, não ter acesso ao diretório de dados do app, não ter acesso direto à rede e ter acesso apenas aos serviços do sistema mínimos necessários pelo Binder. A implementação do WebView no AOSP atende a esse requisito.

Implementações de dispositivos de 32 bits ou que declaram a flag de recurso android.hardware.ram.low estão isentas da C-1-3.

3.4.2. Compatibilidade de navegadores

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

  • [C-1-1] PRECISA oferecer suporte a cada uma destas APIs associadas ao HTML5:
  • [C-1-2] PRECISA oferecer suporte à API webstorage HTML5/W3C e DEVE oferecer suporte à API IndexedDB HTML5/W3C. À medida que os órgãos de padrões de desenvolvimento da Web fazem a transição para favorecer o IndexedDB em vez do webstorage, espera-se que o IndexedDB se torne um componente obrigatório em uma versão futura do Android.
  • PODE enviar uma string de user agent personalizada no aplicativo navegador independente.
  • DEVE implementar o suporte para o máximo possível de HTML5 no aplicativo de navegador independente (seja com base no aplicativo de navegador WebKit upstream ou em uma substituição de terceiros).

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

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

3.5. Compatibilidade comportamental da 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 PODE implementar a abordagem de lista de permissões que garante a compatibilidade comportamental da API apenas para apps selecionados pelos implementadores de dispositivos.

Os comportamentos de cada um dos tipos de API (gerenciada, flexível, nativa e da Web) PRECISAM ser consistentes com a implementação preferida do Projeto de código aberto do Android (link em inglês). Algumas áreas específicas de compatibilidade são:

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

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

3.5.1. Restrição em segundo plano

Se as implementações de dispositivos implementarem ou estenderem as restrições de apps incluídas no AOSP, elas:

  • [C-1-1] É OBRIGATÓRIO oferecer uma opção para que o usuário possa ver a lista de apps restritos.
  • [C-1-2] É OBRIGATÓRIO oferecer ao usuário a opção de ativar / desativar as restrições em cada app.
  • [C-1-3] NÃO PODE aplicar restrições automaticamente sem evidências de comportamento inadequado da integridade do sistema, mas PODE aplicar as restrições aos apps ao detectar comportamento inadequado da integridade do sistema, como bloqueios de despertar presos, serviços de longa duração e outros critérios. Os critérios PODEM ser determinados pelos implementadores de dispositivos, mas PRECISAM estar relacionados ao impacto do app na integridade do sistema. Outros critérios que não estão puramente relacionados à integridade do sistema, como a falta de popularidade do app no mercado, NÃO DEVEM ser usados como critérios.
  • [C-1-4] NÃO PODE aplicar restrições de apps automaticamente quando um usuário as desativa manualmente e PODE sugerir que o usuário as aplique.
  • [C-1-5] É OBRIGATÓRIO informar aos usuários se as restrições de apps 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 principal que é usado explicitamente pelo usuário.
  • [C-1-8] É OBRIGATÓRIO suspender as restrições em um app que se torna o principal aplicativo em primeiro plano quando o usuário começa a usar explicitamente o app que era restrito.

3.6. Namespaces de API

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

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

Ou seja, eles:

  • [C-0-1] NÃO MODIFIQUE as APIs expostas publicamente na plataforma Android mudando assinaturas de métodos ou classes nem removendo classes ou campos de classe.
  • [C-0-2] NÃO é permitido adicionar elementos expostos publicamente (como classes ou interfaces, ou campos ou métodos a classes ou interfaces atuais) 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 das APIs, mas essas modificações:

  • [C-0-3] NÃO PODE afetar o comportamento declarado e a assinatura da 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 de outra organização ou que se refira a ela. Por exemplo, os implementadores de dispositivos NÃO PODEM adicionar APIs ao namespace com.google.* ou semelhante. Somente o Google pode fazer isso. Da mesma forma, o Google NÃO PODE adicionar APIs aos namespaces de outras empresas.
  • [C-0-6] PRECISA ser empacotado em uma biblioteca compartilhada do Android para que apenas os apps que as usam explicitamente (pelo mecanismo <uses-library>) sejam afetados pelo aumento do uso de memória dessas APIs.

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

As restrições acima correspondem às convenções padrão para nomear APIs na linguagem de programação Java. Esta seção apenas reforça essas convenções e as torna vinculativas ao incluí-las nesta Definição de compatibilidade.

3.7. Compatibilidade com o ambiente de execução

Implementações de dispositivos:

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

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

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

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

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

Layout da tela Densidade da tela Memória mínima do aplicativo
Relógio Android 120 dpi (ldpi) 32MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi)
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi) 36MB
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 48MB
360 dpi (360dpi)
400 dpi (400dpi) 56MB
420 dpi (420dpi) 64MB
480 dpi (xxhdpi) 88MB
560 dpi (560dpi) 112MB
640 dpi (xxxhdpi) 154MB
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 acesso rápido (tela inicial) e suporte para aplicativos de terceiros que substituem o acesso rápido do dispositivo (tela inicial).

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

  • [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 usa a tag <adaptive-icon> para fornecer o ícone e os métodos PackageManager para recuperar ícones são chamados.

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

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

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

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

Se as implementações de dispositivos incluírem um app de tela de início padrão que mostre selos nos ícones de apps, eles:

  • [C-5-1] MUST respect the NotificationChannel.setShowBadge() API method. Em outras palavras, mostre uma affordance visual associada ao ícone do app se o valor for definido como true e não mostre nenhum esquema de ícones de apps quando todos os canais de notificação do app tiverem definido o valor como false.
  • PODE substituir os selos de ícones de apps com o esquema de selos proprietário quando aplicativos de terceiros indicam suporte ao esquema de selos proprietário usando APIs proprietárias, mas DEVE usar os recursos e valores fornecidos pelas APIs de selos de notificação descritas no SDK , como as APIs Notification.Builder.setNumber() e Notification.Builder.setBadgeIconType().

3.8.2. Widgets

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

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

  • [C-1-1] PRECISA declarar suporte ao recurso da plataforma android.software.app_widgets.
  • [C-1-2] PRECISA incluir suporte integrado para AppWidgets e expor recursos da interface do usuário para adicionar, configurar, visualizar e remover AppWidgets diretamente no Launcher.
  • [C-1-3] PRECISA ser capaz de renderizar widgets de 4 x 4 no tamanho padrão da grade. Consulte as Diretrizes de design para widgets de app na documentação do SDK do Android para 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:

3.8.3. Notificações

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

3.8.3.1. Apresentação de notificações

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

  • [C-1-1] PRECISA oferecer suporte a notificações que usam recursos de hardware, conforme descrito na documentação do SDK e na medida do possível com o hardware de implementação do dispositivo. Por exemplo, se uma implementação de dispositivo incluir um vibrador, ela DEVERÁ implementar corretamente as APIs de vibração. Se uma implementação de dispositivo não tiver hardware, as APIs correspondentes precisarão ser implementadas como no-ops. 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 ícones da barra de status/sistema, embora POSSA oferecer uma experiência do usuário alternativa para notificações diferente da fornecida pela implementação de referência do Android Open Source.
  • [C-1-3] PRECISA respeitar e implementar corretamente os comportamentos descritos para as APIs de atualização, remoção e agrupamento de notificações.
  • [C-1-4] PRECISA fornecer o comportamento completo da API NotificationChannel documentada no SDK.
  • [C-1-5] PRECISA oferecer uma opção para o usuário bloquear e modificar a notificação de um determinado app de terceiros em cada canal e nível de pacote do app.
  • [C-1-6] Também é necessário oferecer uma opção para o usuário mostrar os canais de notificação excluídos.
  • [C-1-7] É OBRIGATÓRIO renderizar corretamente todos os recursos (imagens, adesivos, ícones etc.) fornecidos por Notification.MessagingStyle junto com o texto da notificação sem interação adicional do usuário. Por exemplo, DEVE mostrar todos os recursos, incluindo ícones fornecidos por android.app.Person, em uma conversa em grupo definida por setGroupConversation.
  • [C-SR] SÃO FORTEMENTE RECOMENDADOS para mostrar automaticamente uma opção ao usuário para bloquear a notificação de um determinado app de terceiros em cada canal e nível de pacote do app depois que o usuário dispensa essa notificação várias vezes.
  • DEVE oferecer suporte a notificações avançadas.
  • DEVE apresentar algumas notificações de maior prioridade como notificações de alerta.
  • DEVE ter uma opção para adiar notificações.
  • A MAY só pode gerenciar a visibilidade e o tempo em que apps de terceiros podem notificar os usuários sobre eventos importantes para mitigar 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] É OBRIGATÓRIO usar os recursos exatos fornecidos pela classe da API Notification.Style e as subclasses dela para os elementos de recursos apresentados.
  • DEVE apresentar todos os elementos de recursos (por exemplo, ícone, título e texto de resumo) definidos na classe da API Notification.Style e nas subclasses dela.

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

  • [C-3-1] É OBRIGATÓRIO usar a visualização e os recursos de notificação de alerta, conforme descrito na classe da API Notification.Builder, quando as notificações de alerta são apresentadas.
  • [C-3-2] PRECISA mostrar as ações fornecidas por Notification.Builder.addAction() junto 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 (depois de serem ativados explicitamente pelo usuário) recebam uma cópia de todas as notificações à medida que 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 corretamente e imediatamente as notificações por completo para todos os serviços de listener instalados e ativados pelo usuário, incluindo todos os metadados anexados ao objeto de notificação.
  • [C-1-2] PRECISA respeitar a chamada de API snoozeNotification(), dispensar a notificação e fazer um callback após o período de adiamento definido na chamada de API.

Se as implementações de dispositivos tiverem uma opção para adiar notificações, elas:

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

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

  • [C-1-1] É obrigatório implementar uma atividade que responda à intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. Para implementações com UI_MODE_TYPE_NORMAL, essa atividade precisa ser uma 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] DEVE, quando a implementação do dispositivo fornecer um meio para o usuário conceder ou negar o acesso de apps de terceiros à configuração da política de NMD, mostrar as regras automáticas de NMD criadas por aplicativos junto com as regras predefinidas e criadas pelo usuário.
  • [C-1-3] PRECISA obedecer aos valores suppressedVisualEffects transmitidos com o NotificationManager.Policy e, se um app tiver definido uma das flags SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, PRECISA indicar ao usuário que os efeitos visuais estão desativados no menu de configurações do modo Não perturbe.

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

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

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

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

Se não houver apps de terceiros instalados que usem a pesquisa global:

  • O comportamento padrão DEVE ser mostrar resultados e sugestões do mecanismo de pesquisa na Web.

O Android também inclui as APIs Assist para permitir que os aplicativos escolham quanta informação do contexto atual é compartilhada com o assistente no dispositivo.

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

  • [C-2-1] É OBRIGATÓRIO indicar claramente ao usuário final quando o contexto é compartilhado, de uma das seguintes maneiras:
    • Cada vez que o app assistivo acessa o contexto, uma luz branca aparece nas bordas da tela que atendem ou excedem a duração e o brilho da implementação do Projeto de código aberto do Android.
    • Para o app de assistência pré-instalado, ofereça uma conveniência para o usuário a menos de duas navegações de distância do menu de configurações padrão do app de entrada por voz e do Google Assistente e compartilhe o contexto apenas quando o app de assistência for invocado explicitamente pelo usuário com uma palavra de ativação ou uma tecla de navegação do Google Assistente.
  • [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, ou seja, o app que implementa VoiceInteractionService ou uma atividade que processa a intent ACTION_ASSIST.

3.8.5. Alertas e toasts

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

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

  • [C-1-1] PRECISA oferecer uma opção para o usuário bloquear a exibição de janelas de alerta de um app que usam o TYPE_APPLICATION_OVERLAY . A implementação do AOSP atende a esse requisito com controles na tela de notificações.

  • [C-1-2] PRECISA obedecer à API Toast e mostrar toasts de aplicativos para usuários finais de alguma forma altamente visível.

3.8.6. Temas

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

O Android inclui uma família de temas "Holo" e "Material" como um conjunto de estilos definidos para desenvolvedores de aplicativos usarem se quiserem corresponder à aparência do tema Holo, conforme definido pelo SDK do Android.

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

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

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

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 do 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] É OBRIGATÓRIO 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 um app solicite uma barra de status clara usando a flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
  • [C-2-2] As implementações de dispositivos Android PRECISAM mudar a cor dos ícones de status do sistema para preto (para mais detalhes, consulte R.style) quando um app 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. Os papéis de parede animados 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 dinâmicos de maneira confiável se puder executar todos eles, sem limitações de funcionalidade, a uma taxa de frames razoável e sem efeitos adversos em outros aplicativos. Se as limitações no hardware fizerem com que os papéis de parede e/ou aplicativos falhem, apresentem mau funcionamento, consumam energia excessiva da CPU ou da bateria ou sejam executados com taxas de frames inaceitavelmente baixas, o hardware será considerado incapaz de executar o papel de parede dinâmico. Por exemplo, alguns papéis de parede animados podem usar um contexto OpenGL 2.0 ou 3.x para renderizar o conteúdo. O papel de parede animado não será executado de maneira confiável em hardware que não oferece suporte a vários contextos do OpenGL, porque o uso de um contexto do OpenGL pelo papel de parede animado pode entrar em conflito com outros aplicativos que também usam um contexto do OpenGL.

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

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

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

3.8.8. Troca de atividade

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

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 de dispositivos, incluindo a tecla de navegação da função "Recentes", conforme detalhado na seção 7.2.3, alterarem a interface, elas:

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

3.8.9. Gerenciamento de entradas

O Android inclui suporte para gerenciamento de entrada e para 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, eles:

  • [C-1-1] PRECISA declarar o recurso da plataforma android.software.input_methods e oferecer suporte às APIs IME, conforme definido na documentação do SDK Android.
  • [C-1-2] DEVE fornecer um mecanismo acessível ao usuário para adicionar e configurar métodos de entrada de terceiros em resposta à intent android.settings.INPUT_METHOD_SETTINGS.

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

3.8.10. Controle de mídia na tela de bloqueio

A API Remote Control Client foi descontinuada no Android 5.0 em favor do modelo de notificação de mídia, que permite que aplicativos de mídia se integrem aos controles de reprodução exibidos na tela de bloqueio.

3.8.11. Protetores de tela (antes chamados de "Sonhos")

O Android inclui suporte para protetores de tela interativos, antes chamados de Dreams. Os protetores de tela permitem que os usuários interajam com aplicativos quando um dispositivo conectado a uma fonte de energia está ocioso ou encaixado em um suporte 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ções para que os usuários configurem protetores de tela em resposta à intent android.settings.DREAM_SETTINGS.

3.8.12. Local

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

3.8.13. Unicode e fonte

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

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

  • [C-1-1] PRECISA ser capaz de renderizar esses caracteres de emoji em glifo colorido.
  • [C-1-2] PRECISA incluir suporte para:
    • Fonte Roboto 2 com diferentes pesos: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light para os idiomas disponíveis no dispositivo.
    • Cobertura completa do Unicode 7.0 de latim, grego e cirílico, incluindo os intervalos A, B, C e D do latim estendido e todos os glifos no bloco de símbolos de moeda do Unicode 7.0.
  • DEVE oferecer suporte aos emojis de tom de pele e de família diversificada, conforme especificado no Relatório técnico do Unicode nº 51.

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

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

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

Se as implementações de dispositivos incluem suporte para 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 tiverem a capacidade de mostrar várias atividades ao mesmo tempo, elas:

  • [C-1-1] PRECISA implementar esses modos de várias janelas de acordo com os comportamentos e as APIs do aplicativo descritos na documentação de suporte ao modo de várias janelas do SDK do Android e atender aos seguintes requisitos:
  • [C-1-2] PRECISA respeitar 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 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 picture-in-picture.
  • Implementações de dispositivos com tamanho de tela xlarge DEVEM oferecer suporte ao modo de formato livre.

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

  • [C-2-1] É obrigatório pré-carregar uma tela de início redimensionável como padrão.
  • [C-2-2] PRECISA cortar a atividade ancorada de uma tela dividida com várias janelas, mas DEVE mostrar algum conteúdo dela se o app Launcher 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 picture-in-picture, elas:

  • [C-3-1] PRECISA iniciar atividades no modo picture-in-picture em várias janelas quando o app: * Segmenta o nível 26 da API ou mais recente e declara android:supportsPictureInPicture * Segmenta o nível 25 da API ou anterior e declara android:resizeableActivity e android:supportsPictureInPicture.
  • [C-3-2] PRECISA expor as ações na SystemUI, conforme especificado pela atividade PIP atual, usando a API setActions().
  • [C-3-3] PRECISA oferecer suporte a proporções maiores ou iguais a 1:2,39 e menores ou iguais a 2,39:1, conforme especificado pela atividade PIP usando a API setAspectRatio().
  • [C-3-4] É OBRIGATÓRIO usar KeyEvent.KEYCODE_WINDOW para controlar a janela PIP. Se o modo PIP não for implementado, a chave DEVERÁ estar disponível para a atividade em primeiro plano.
  • [C-3-5] PRECISA oferecer um affordance ao 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 bandeja de notificações.
  • [C-3-6] É OBRIGATÓRIO alocar largura e altura mínimas de 108 dp para a janela PIP e largura mínima de 240 dp e altura de 135 dp para a janela PIP quando o Configuration.uiMode estiver configurado como UI_MODE_TYPE_TELEVISION.

3.8.15. Corte da tela

O Android é compatível com um corte da tela, conforme descrito no documento do SDK. A API DisplayCutout define uma área na borda da tela que não é funcional para mostrar conteúdo.

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

  • [C-1-1] SÓ PODE ter cortes nas bordas curtas do dispositivo. Por outro lado, se a proporção da tela do dispositivo for 1,0 (1:1), ele NÃO PODE 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 usando a API WindowManager.LayoutParams, conforme descrito no SDK.
  • [C-1-4] PRECISA informar os valores corretos para 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 foco em segurança realizem funções de administração de dispositivos no nível do sistema, como aplicar políticas de senha ou realizar 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] DEVE 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 dispositivo

3.9.1.1 Provisionamento do proprietário do dispositivo

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

  • [C-1-1] PRECISA oferecer suporte ao registro de um cliente de política de dispositivo (DPC) como um app proprietário do dispositivo, conforme descrito abaixo:
  • [C-1-2] PRECISA exigir alguma ação afirmativa durante o processo de provisionamento para consentir que o app seja definido como proprietário do dispositivo. O consentimento pode ser por ação do usuário ou por algum meio programático durante o provisionamento, mas NÃO pode ser codificado ou impedir o uso de outros apps de proprietário do dispositivo.

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

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

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

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

  • [C-1-2] O processo de provisionamento de perfil gerenciado (o fluxo iniciado por android.app.action.PROVISION_MANAGED_PROFILE) que os usuários experimentam PRECISA estar alinhado à implementação do AOSP.

  • [C-1-3] PRECISA oferecer as seguintes opções ao usuário nas Configurações para indicar quando uma função específica do sistema foi desativada pelo Controlador de políticas do dispositivo (DPC):

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

3.9.2 Suporte a perfil gerenciado

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

  • [C-1-1] PRECISA oferecer suporte a perfis gerenciados pelas APIs android.app.admin.DevicePolicyManager.
  • [C-1-2] PRECISA permitir a criação de apenas um perfil gerenciado.
  • [C-1-3] DEVE usar um ícone de identificação (semelhante ao ícone de trabalho upstream do AOSP) para representar os aplicativos e widgets gerenciados e outros elementos da interface com identificação, como "Recentes" e "Notificações".
  • [C-1-4] DEVE mostrar um ícone de notificação (semelhante ao indicador de trabalho upstream do AOSP) para indicar quando o usuário está em um aplicativo de perfil gerenciado.
  • [C-1-5] DEVE mostrar um aviso indicando que o usuário está no perfil gerenciado quando o dispositivo é ativado (ACTION_USER_PRESENT) e o aplicativo em primeiro plano está no perfil gerenciado.
  • [C-1-6] Quando um perfil gerenciado existir, MOSTRE uma affordance visual no "Seletor" de intent para permitir que o usuário encaminhe a intent do perfil gerenciado para o usuário principal ou vice-versa, se ativado pelo Controlador de políticas de dispositivo.
  • [C-1-7] Quando um perfil gerenciado existir, É OBRIGATÓRIO expor as seguintes opções de interação para o usuário principal e o perfil gerenciado:
    • Contabilidade separada para uso de bateria, localização, dados móveis e armazenamento para o usuário principal e o perfil gerenciado.
    • Gerenciamento independente de aplicativos de VPN instalados no usuário principal ou no perfil gerenciado.
    • Gerenciamento independente de aplicativos instalados no usuário principal ou no perfil gerenciado.
    • Gerenciamento independente de contas no usuário principal ou perfil gerenciado.
  • [C-1-8] DEVE garantir que os aplicativos de discador, contatos e mensagens pré-instalados possam pesquisar e consultar informações do autor da chamada no perfil gerenciado (se houver) e no perfil principal, se o Controlador de políticas do dispositivo permitir.
  • [C-1-9] PRECISA garantir que ele atenda a todos os requisitos de segurança aplicáveis a um dispositivo com vários usuários ativados (consulte a seção 9.5), mesmo que o perfil gerenciado não seja contado como outro usuário além do principal.
  • [C-1-10] PRECISA oferecer suporte à capacidade de especificar uma tela de bloqueio separada que atenda aos seguintes requisitos para conceder acesso a apps em execução em um perfil gerenciado.
    • As implementações de dispositivos PRECISAM obedecer à 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 principal, conforme documentado no site do projeto de código aberto do Android.
    • As políticas de senha do DPC SÓ devem ser aplicadas às credenciais da tela de bloqueio do perfil gerenciado, a menos que sejam chamadas na instância DevicePolicyManager retornada por getParentProfileInstance.
  • Quando os contatos do perfil gerenciado são mostrados no registro de chamadas pré-instalado, na interface de chamadas, nas notificações de chamadas em andamento e perdidas, nos apps de mensagens e de contatos, eles DEVEM ser identificados com o mesmo selo usado para indicar aplicativos do perfil gerenciado.

3.9.3 Suporte para usuários gerenciados

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

  • [C-1-1] DEVE fornecer uma ação do usuário para sair do usuário atual e voltar ao usuário principal em uma sessão com vários usuários quando isLogoutEnabled retornar true. O recurso 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ência a navegar pelos dispositivos com mais facilidade. Além disso, o Android oferece APIs de plataforma que permitem que implementações de serviços de acessibilidade recebam callbacks para eventos do usuário e do sistema e gerem mecanismos de feedback alternativos, como conversão de texto em voz, feedback tátil e navegação com trackball/d-pad.

Se as implementações de dispositivos forem compatíveis com 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 a todas as implementações AccessibilityService registradas, conforme documentado no SDK.
  • [C-1-3] PRECISA obedecer à intent android.settings.ACCESSIBILITY_SETTINGS para oferecer um mecanismo acessível ao usuário que permita ativar e desativar os serviços de acessibilidade de terceiros junto com os serviços pré-instalados.
  • [C-1-4] É OBRIGATÓRIO adicionar um botão na barra de navegação do sistema para permitir que o usuário controle o serviço de acessibilidade quando os serviços ativados declararem a AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Para implementações de dispositivos sem uma barra de navegação do sistema, esse requisito não se aplica, mas as implementações de dispositivos DEVEM oferecer uma conveniência ao usuário para controlar esses serviços de acessibilidade.

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

  • [C-2-1] PRECISA implementar esses serviços de acessibilidade pré-instalados como apps compatíveis com inicialização direta 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 inicial para que os usuários ativem os serviços de acessibilidade relevantes, além de opções para ajustar o tamanho da fonte, o tamanho da tela e os gestos de ampliação.

3.11. Conversão de texto em voz

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

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

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

  • [C-2-1] DEVE oferecer ao usuário a possibilidade de 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 TV. O TIF oferece uma API padrão para criar módulos de entrada que controlam dispositivos Android TV.

Se as implementações de dispositivos forem compatíveis com 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 usa essas APIs e o serviço de entradas de terceiros baseadas em TIF possa ser instalado e usado no dispositivo.

3.13. Configurações rápidas

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

Se as implementações de dispositivos incluírem um componente de interface do usuário de Configurações rápidas, elas vão:

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

3.14. Interface de mídia

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

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

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

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

  • [C-1-5] DEVE considerar o toque duplo em 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Ó PODEM receber permissões que tenham o android:protectionLevel definido como "instant".
  • [C-0-2] Os apps instantâneos NÃO PODEM interagir com apps instalados usando intents implícitos, a menos que uma das seguintes condições seja verdadeira:
    • O filtro de padrão de intent do componente é exposto e tem CATEGORY_BROWSABLE
    • A ação é uma das seguintes: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • O destino é exposto explicitamente com android:visibleToInstantApps
  • [C-0-3] Os apps instantâneos NÃO PODEM interagir explicitamente com apps instalados, a menos que o componente seja exposto via android:visibleToInstantApps.
  • [C-0-4] Os apps instalados NÃO PODEM ver detalhes sobre apps instantâneos no dispositivo, a menos que o app instantâneo se conecte explicitamente ao aplicativo instalado.
  • As implementações de dispositivos PRECISAM oferecer as seguintes opções de interação do usuário com apps instantâneos. O AOSP atende aos requisitos com a interface do sistema, as configurações e o iniciador padrão. Implementações de dispositivos:
    • [C-0-5] É OBRIGATÓRIO fornecer uma ação do usuário para ver e excluir os apps instantâneos armazenados em cache localmente para cada pacote de app individual.
    • [C-0-6] PRECISA fornecer uma notificação persistente ao usuário que pode ser recolhida enquanto um app instantâneo está em execução em primeiro plano. Essa notificação precisa incluir que os apps instantâneos não exigem instalação e fornecer um affordance que direcione o usuário para a tela de informações do aplicativo nas configurações. Para apps instantâneos iniciados por intents da Web, conforme definido pelo uso de uma intent com a ação definida como Intent.ACTION_VIEW e com um esquema "http" ou "https", uma conveniência adicional para o usuário DEVE permitir que ele não inicie o app instantâneo e abra o link associado com o navegador da Web configurado, se um navegador estiver disponível no dispositivo.
    • [C-0-7] É OBRIGATÓRIO permitir que os 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 para pareamento de dispositivos complementares para gerenciar de forma mais eficaz a associação com eles e oferece 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 dispositivos complementares, 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 oferecer recursos para que o usuário selecione/confirme a presença e o funcionamento de um dispositivo complementar.

3.17. Apps pesados

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

  • [C-1-1] É obrigatório ter apenas um app instalado que especifique cantSaveState em execução no sistema por vez. Se o usuário sair de um app desse tipo sem sair explicitamente dele (por exemplo, pressionando a tela inicial ao sair de uma atividade ativa em vez de pressionar "Voltar" sem atividades ativas restantes no sistema), as implementações de dispositivos PRECISAM priorizar esse app na RAM, assim como fazem com outras coisas que devem permanecer em execução, como serviços em primeiro plano. Enquanto um app desse tipo está em segundo plano, o sistema ainda pode aplicar recursos de gerenciamento de energia a ele, como limitar o acesso à CPU e à rede.
  • [C-1-2] PRECISA fornecer uma affordance de interface para escolher o app que não vai participar do mecanismo normal de salvar/restaurar estado quando o usuário iniciar um segundo app declarado com o atributo cantSaveState.
  • [C-1-3] NÃO PODE aplicar outras mudanças na política a apps que especificam cantSaveState, como mudar o desempenho da CPU ou a priorização de 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 de empacotamento de aplicativos

Implementações de dispositivos:

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

Implementações de dispositivos:

  • [C-0-2] 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 .apk, manifesto do Android, bytecode Dalvik ou bytecode RenderScript de forma que impeça a instalação e a execução correta desses arquivos em outros dispositivos compatíveis.

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

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

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

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

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

  • [C-0-7] PRECISA 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 foi marcado pela mesma API do sistema PackageManager.setHarmfulAppWarning como potencialmente prejudicial.

  • DEVE fornecer uma opção para o usuário escolher desinstalar ou iniciar um aplicativo na caixa de diálogo de alerta.

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 todos os codecs declarados por MediaCodecList.
  • [C-0-2] É OBRIGATÓRIO declarar e informar o suporte dos codificadores e decodificadores disponíveis para aplicativos de terceiros via MediaCodecList.
  • [C-0-3] PRECISA ser capaz de decodificar e disponibilizar corretamente para apps de terceiros todos os formatos que pode codificar. Isso inclui todos os fluxos de bits gerados pelos codificadores e os perfis informados no CamcorderProfile.

Implementações de dispositivos:

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

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

O Google e a Open Handset Alliance não garantem que esses codecs não tenham patentes de terceiros. Quem pretende usar esse código-fonte em produtos de hardware ou software precisa saber que as implementações dele, inclusive em software de código aberto ou shareware, podem exigir licenças de patente dos titulares relevantes.

5.1. Codecs de mídia

5.1.1. Codificação de áudio

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

Se as implementações de dispositivos declararem android.hardware.microphone, elas precisarão 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:

5.1.2. Decodificação de áudio

Confira 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 DEVERÃO oferecer suporte à decodificação dos seguintes formatos de áudio:

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

Se as implementações de dispositivos forem compatíveis com a 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 DEVE ser compatível:

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

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

  • [C-3-1] Os metadados de intensidade sonora e DRC precisam ser interpretados e aplicados de acordo com o perfil de controle de faixa dinâmica DRC MPEG-D nível 1.
  • [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:

  • O MAY é compatível com o controle de intensidade e faixa dinâmica usando o perfil de controle de faixa dinâmica ISO/IEC 23003-4.

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

  • Os metadados ISO/IEC 23003-4 têm precedência.

Todos os decodificadores de áudio PRECISAM ser compatíveis com a saída de:

5.1.3. Detalhes dos codecs de áudio

Formato/Codec Detalhes Tipos de arquivo/formatos de contêiner compatíveis
Perfil AAC MPEG-4
(AAC LC) 		Compatível com conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 8 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC bruto ADTS (.aac, ADIF não compatível)
  • MPEG-TS (.ts, não pesquisável, somente decodificação)
  • Matroska (.mkv, somente decodificação)
Perfil MPEG-4 HE AAC (AAC+) Compatível com conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
Perfil MPEG-4 HE AACv2
(AAC+ aprimorado) 		Compatível com conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (AAC aprimorado com atraso baixo) Compatível com conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
USAC Compatível com conteúdo mono/estéreo com taxas de amostragem padrão de 7,35 a 48 kHz. MPEG-4 (.mp4, .m4a)
AMR-NB 4,75 a 12,2 kbps com amostragem a 8 kHz. 3GPP (.3gp)
AMR-WB 9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz, conforme definido em AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec (em inglês) 3GPP (.3gp)
FLAC Para codificador e decodificador: pelo menos os modos mono e estéreo precisam ser compatíveis. As taxas de amostragem de até 192 kHz PRECISAM ser compatíveis, assim como as resoluções de 16 bits e 24 bits. O processamento de dados de áudio FLAC de 24 bits PRECISA estar disponível com a configuração de áudio de ponto flutuante.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, somente decodificação)
  • Matroska (.mkv, somente decodificação)
MP3 Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8-320 kbps.
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, somente decodificação)
  • Matroska (.mkv, somente decodificação)
MIDI MIDI tipos 0 e 1. DLS versões 1 e 2. XMF e XMF para celular. Compatível com os formatos de toque RTTTL/RTX, OTA e iMelody.
  • Tipo 0 e 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • 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 ponto flutuante de 16 bits. O extrator WAVE precisa ser compatível com PCM linear de 16, 24 e 32 bits e ponto flutuante de 32 bits (taxas até o limite de hardware). As taxas de amostragem precisam ser compatíveis de 8 kHz a 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

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

As implementações de dispositivos PRECISAM oferecer suporte à codificação de imagem a seguir:

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

Se as implementações de dispositivos forem compatíveis com a 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 codificador HEVC acelerado por hardware que seja compatível com o modo de controle de taxa de bits BITRATE_MODE_CQ, o perfil HEVCProfileMainStill e o tamanho de frame de 512 x 512 px.

5.1.5. Decodificação de imagem

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

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

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Bruto
  • [C-0-7] HEIF (HEIC)

Decodificadores de imagem que oferecem suporte a 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 arquivo/formatos de contêiner compatíveis
JPEG Básico+progressivo JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
bruto ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF Imagem, coleção de imagens, sequência de imagens HEIF (.heif), HEIC (.heic)

Codificadores e decodificadores de imagens expostos pela API MediaCodec

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

  • [SR] É ALTAMENTE RECOMENDADO oferecer suporte ao formato de cor RGB888 para o modo de superfície de entrada.

  • [C-1-3] PRECISA oferecer suporte a pelo menos um formato de cor YUV420 8:8:8 planar ou semiplanar: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). É ALTAMENTE RECOMENDADO que ambos sejam compatíveis.

5.1.7. Codecs de vídeo

  • Para uma qualidade aceitável de streaming de vídeo na Web e serviços de videoconferência, as implementações de dispositivos DEVEM usar um codec VP8 de hardware 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 bytebuffer de entrada e saída que acomodem o maior frame compactado e não compactado possível, conforme determinado pelo padrão e pela configuração, mas sem alocação excessiva.

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

  • [C-1-3] Os codificadores e decodificadores de vídeo PRECISAM ser compatíveis com pelo menos um formato de cor YUV420 8:8:8 planar ou semiplanar: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). É ALTAMENTE RECOMENDADO que eles sejam compatíveis com os dois.

  • [SR] É ALTAMENTE RECOMENDADO que os codificadores e decodificadores de vídeo sejam compatíveis com pelo menos um formato de cor YUV420 8:8:8 planar ou semiplanar otimizado para hardware (YV12, NV12, NV21 ou formato equivalente otimizado para fornecedor).

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

Se as implementações de dispositivos anunciarem a compatibilidade com o perfil HDR usando Display.HdrCapabilities, elas:

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

Se as implementações de dispositivos anunciarem suporte à atualização intra através de 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 em até 20% do período de atualização configurado.

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

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

5.1.8. Lista de codecs de vídeo

Formato/Codec Detalhes Tipos de arquivo/formatos de contêiner compatíveis
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, apenas decodificação)
  • Matroska (.mkv, somente decodificação)
MPEG-4 SP
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, somente decodificação)
VP8 Consulte as seções 5.2 e 5.3 para mais detalhes.
VP9 Consulte detalhes na seção 5.3.

5.1.9. Segurança do codec de mídia

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

O Android inclui suporte para OMX, uma API de aceleração multimídia multiplataforma, bem como o Codec 2.0, uma API de aceleração multimídia de baixa sobrecarga.

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

  • [C-1-1] É OBRIGATÓRIO oferecer suporte a codecs de mídia usando OMX ou APIs Codec 2.0 (ou ambos), como no Android Open Source Project, e não desativar nem burlar as proteções de segurança. Isso não significa que todos os codecs PRECISAM usar a API OMX ou Codec 2.0, apenas que o suporte 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] É ALTAMENTE RECOMENDADO incluir suporte para a API Codec 2.0.

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

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

Se as implementações de dispositivos forem compatíveis com a API Codec 2.0, elas:

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

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

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

  • [C-1-1] PRECISA retornar os 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 estejam de acordo com as diretrizes de nomenclatura da OMX IL.
  • [C-1-3] Codecs com nomes que começam com "c2." É necessário usar a API Codec 2.0 e ter nomes que estejam de acordo 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 e mapeadores de memória NÃO DEVEM ser caracterizados como somente software.
  • [C-1-6] Os codecs que não estão presentes no Android Open Source Project ou que não são baseados no código-fonte desse projeto DEVEM ser caracterizados como fornecedores.
  • [C-1-7] Os codecs que usam aceleração de hardware PRECISAM ser caracterizados como acelerados por hardware.
  • [C-1-8] Os nomes de codecs NÃO PODEM ser enganosos. Por exemplo, codecs chamados de "decoders" precisam oferecer suporte à decodificação, e aqueles chamados de "encoders" precisam oferecer suporte à codificação. Os codecs com nomes que contêm formatos de mídia precisam ser compatíveis com 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 de taxa de frames alcançável para os seguintes tamanhos, se compatíveis com o codec:
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p Ultra HD
Resolução do vídeo
  • 176 x 144 px (H263, MPEG2, MPEG4)
  • 352 x 288 px (codificador MPEG4, H263, MPEG2)
  • 320 x 180 px (VP8, VP8)
  • 320 x 240 px (outros)
  • 704 x 576 px (H263)
  • 640 x 360 px (VP8, VP9)
  • 640 x 480 px (codificador MPEG4)
  • 720 x 480 px (outros)
  • 1408 x 1152 px (H263)
  • 1280 x 720 px (outros)
1920 x 1080 px (que não seja MPEG4) 3840 x 2160 px (HEVC, VP9)
  • [C-2-2] Os codecs de vídeo caracterizados como acelerados por hardware precisam publicar informações sobre pontos de desempenho. Cada um DEVE listar todos os pontos de desempenho padrão compatíveis (listados na API PerformancePoint), a menos que estejam cobertos por outro ponto de desempenho padrão compatível.
  • Além disso, eles DEVEM publicar pontos de desempenho estendido se forem compatíveis com desempenho de vídeo sustentado diferente de um dos padrões listados.

5.2. Codificação de vídeo

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

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

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

  • [C-1-1] PRECISA incluir o suporte a pelo menos um dos codificadores de vídeo VP8 ou H.264 e disponibilizá-lo para aplicativos de terceiros.
  • PRECISA oferecer suporte aos 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 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 intervalo de bits com base nessa duração.

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

  • PRECISA 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 acelerados por hardware e forem compatíveis com uma ou mais câmeras de hardware conectadas ou plugáveis expostas pelas APIs android.camera:

  • [C-4-1] Todos os codificadores de vídeo e imagem acelerados por hardware PRECISAM oferecer suporte à codificação de frames das câmeras de hardware.
  • PRECISA 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 forem compatíveis com codificadores H.263 e os disponibilizarem para apps de terceiros, elas:

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

  • [C-1-1] PRECISA oferecer suporte ao nível 3 do perfil de referência. No entanto, o suporte para ASO (ordenação arbitrária de segmentos), FMO (ordenação flexível de macroblocos) e RS (segmentos redundantes) é OPCIONAL. Além disso, para manter a compatibilidade com outros dispositivos Android, é RECOMENDADO que ASO, FMO e RS não sejam 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.
  • PRECISA oferecer suporte ao nível 4 do perfil principal.
  • PRECISA ser compatível com os perfis de codificação de vídeo HD (alta definição) conforme indicado na tabela a seguir.

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

  • [C-2-1] PRECISA oferecer suporte aos perfis de codificação na tabela a seguir.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p
Resolução do vídeo 320 x 240 px 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px
Frame rate do vídeo 20 qps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3. VP8

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

  • [C-1-1] PRECISA ser compatível com os perfis de codificação de vídeo SD.
  • PRECISA ser compatível com os seguintes perfis de codificação de vídeo em HD (alta definição).
  • [C-1-2] MUST support writing Matroska WebM files.
  • PRECISA 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 na Web e serviços de videoconferência.

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

  • [C-2-1] 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 nível 3.
  • [C-1-1] PRECISA oferecer suporte à gravação de arquivos Matroska WebM.
  • [C-1-3] MUST generate CodecPrivate data.
  • PRECISA oferecer suporte aos perfis de decodificação HD, conforme indicado na tabela a seguir.
  • [SR] são FORTEMENTE RECOMENDADOS para oferecer suporte aos perfis de decodificação HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.
SD HD 720p HD 1080p Ultra HD
Resolução do vídeo 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3840 x 2160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

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

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

5.2.5. H.265

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

  • [C-1-1] PRECISA oferecer suporte ao nível 3 do perfil principal.
  • DEVE oferecer suporte aos perfis de codificação HD, conforme indicado na tabela a seguir.
  • [SR] são FORTEMENTE RECOMENDADOS para oferecer suporte aos perfis de codificação HD, conforme indicado na tabela a seguir, se houver um codificador de hardware.
SD HD 720p HD 1080p Ultra HD
Resolução do vídeo 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3840 x 2160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3. Decodificação de vídeo

Se as implementações de dispositivos forem compatíveis com codecs VP8, VP9, H.264 ou H.265, elas:

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

5.3.1. MPEG-2

Se as implementações de dispositivos forem compatíveis com decodificadores MPEG-2, elas:

  • [C-1-1] PRECISA ser compatível com o perfil principal de alto nível.

5.3.2. H.263

Se as implementações de dispositivos forem compatíveis com 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 as implementações de dispositivos tiverem decodificadores MPEG-4, elas:

  • [C-1-1] PRECISA oferecer suporte ao Simple Profile Level 3.

5.3.4. H.264

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

  • [C-1-1] PRECISA oferecer suporte ao nível 3.1 do perfil principal e ao perfil de referência. O suporte para ASO (ordenação arbitrária de segmentos), FMO (ordenação flexível de macroblocos) e RS (segmentos 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 nível 3.1 (incluindo 720p30).
  • PRECISA ser capaz de decodificar vídeos com os perfis HD (alta definição) indicados 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 de dispositivo:

  • [C-2-1] PRECISA oferecer suporte aos perfis de decodificação de vídeo HD 720p na tabela a seguir.
  • [C-2-2] PRECISA oferecer suporte aos perfis de decodificação de vídeo HD 1080p na tabela a seguir.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p
Resolução do vídeo 320 x 240 px 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px
Frame rate do vídeo 30 fps 30 fps 60 qps 30 qps (60 qpsTelevisã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 forem compatíveis com o codec H.265, elas:

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

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

  • [C-2-1] As implementações de dispositivos PRECISAM oferecer suporte a pelo menos uma das decodificações H.265 ou VP9 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 px 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3840 x 2160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30/60 QPS (60 QPSTelevisã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 afirmarem oferecer suporte a um perfil HDR (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) pelas APIs de mídia:

  • [C-3-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR obrigatórios (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis HDR) do aplicativo usando a API MediaCodec, além de oferecer suporte à extração dos metadados HDR obrigatórios (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis HDR e MediaFormat#KEY_HDR10_PLUS_INFO para perfis HDR10Plus) do fluxo de bits 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 fluxo de bits e/ou contêiner, conforme definido pelas especificações relevantes.

  • [C-SR] É ALTAMENTE RECOMENDADO que as implementações de dispositivos ofereçam 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, como HDMI.

  • [C-SR] É ALTAMENTE RECOMENDADO que as implementações de dispositivos mostrem corretamente o conteúdo HDR para o perfil HEVCProfileMain10HDR10Plus na tela do dispositivo ou em uma porta de saída de vídeo padrão, como HDMI.

5.3.6. VP8

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

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

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

  • [C-2-1] As implementações de dispositivos PRECISAM oferecer suporte a perfis de 720p na tabela a seguir.
  • [C-2-2] As implementações de dispositivos PRECISAM oferecer suporte a perfis de 1080p na tabela a seguir.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p
Resolução do vídeo 320 x 180 px 640 x 360 px 1.280 x 720 px 1.920 x 1.080 px
Frame rate do vídeo 30 fps 30 fps 30 qps (60 qpsTelevisão) 30 (televisão de 60 fps)
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.
  • PRECISA oferecer suporte aos perfis de decodificação 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 HD, conforme indicado na tabela a seguir.

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

  • [C-3-1] As implementações de dispositivos PRECISAM oferecer suporte a pelo menos uma das decodificações VP9 ou H.265 dos perfis 720, 1080 e UHD.
SD (baixa qualidade) SD (alta qualidade) HD 720p HD 1080p Ultra HD
Resolução do vídeo 320 x 180 px 640 x 360 px 1.280 x 720 px 1.920 x 1.080 px 3840 x 2160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps (60 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 afirmarem oferecer suporte a VP9Profile2 ou VP9Profile3 pelas APIs de mídia CodecProfileLevel:

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

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

  • [C-4-1] As implementações de dispositivos PRECISAM aceitar os metadados HDR obrigatórios (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis HDR, bem como o parâmetro MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO para perfis HDR10Plus) do aplicativo usando a API MediaCodec, além de oferecer suporte à extração dos metadados HDR obrigatórios (MediaFormat#KEY_HDR_STATIC_INFO para todos os perfis HDR, bem como MediaFormat#KEY_HDR10_PLUS_INFO para perfis HDR10Plus) do fluxo de bits 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 fluxo de bits e/ou contêiner, conforme definido pelas especificações relevantes.

  • [C-4-2] As implementações de dispositivos PRECISAM exibir 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, como HDMI.

  • [C-SR] É ALTAMENTE RECOMENDADO que as implementações de dispositivos ofereçam suporte à saída dos metadados MediaFormat#KEY_HDR10_PLUS_INFO para perfis HDR10Plus via MediaCodec#getOutputFormat(int).

  • [C-SR] É ALTAMENTE RECOMENDADO que as implementações de dispositivos mostrem 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, como HDMI.

5.3.8. Dolby Vision

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

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

5.3.9. AV1

Se as implementações 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 SHOULD desde o Android 4.3, a Definição de compatibilidade para versões futuras planeja mudar isso para MUST. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos listados como "SHOULD". Caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

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

Se as implementações de dispositivos 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: 8.000, 11.025, 16.000, 44.100, 48.000 Hz
    • Canais: mono

  • DEVE permitir a captura de conteúdo de áudio bruto com as seguintes características:

    • Formato: PCM linear de 16 e 24 bits
    • Taxas de amostragem: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 Hz
    • Canais: tantos canais quanto o número de microfones no dispositivo

  • [C-1-2] PRECISA capturar nas taxas de amostragem acima sem upsampling.

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

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

    • Formato: PCM linear, 16 bits
    • Taxas de amostragem: 22050, 48000 Hz
    • Canais: estéreo

  • [C-1-4] PRECISA obedecer à API MicrophoneInfo e preencher corretamente as informações dos microfones disponíveis no dispositivo acessíveis aos aplicativos de terceiros pelas APIs AudioManager.getMicrophones(), AudioRecord.getActiveMicrophones() e MediaRecorder.getActiveMicrophones(). Se as implementações de dispositivos permitirem a captura de rádio AM e qualidade de DVD de conteúdo de áudio bruto, elas:

  • [C-2-1] É OBRIGATÓRIO capturar sem upsampling em qualquer proporção maior que 16000:22050 ou 44100:48000.

  • [C-2-2] PRECISA incluir um filtro anti-aliasing adequado para qualquer upsampling ou downsampling.

5.4.2. Captura para reconhecimento de voz

Se as implementações de dispositivos 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] POR PADRÃO, é necessário desativar qualquer processamento de áudio de redução de ruído ao gravar um stream de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
  • [C-1-3] Por padrão, é necessário desativar qualquer controle automático de ganho ao gravar um fluxo de áudio da fonte de áudio AudioSource.VOICE_RECOGNITION.
  • GRAVE o fluxo de áudio de reconhecimento de voz com amplitude aproximadamente estável em relação às características de frequência: especificamente, ±3 dB, de 100 Hz a 4.000 Hz.
  • GRAVE o stream de áudio de reconhecimento de voz com a sensibilidade de entrada definida de forma que uma fonte de nível de potência sonora (SPL) de 90 dB a 1.000 Hz produza RMS de 2.500 para amostras de 16 bits.
  • DEVE gravar o stream de áudio de reconhecimento de voz para que os níveis de amplitude de PCM acompanhem linearmente as mudanças de SPL de entrada em pelo menos um intervalo de 30 dB, de -18 dB a +12 dB re 90 dB SPL no microfone.
  • DEVE gravar o fluxo de áudio de reconhecimento de voz com distorção harmônica total (THD) menor que 1% para 1 kHz em um nível de entrada de 90 dB SPL no microfone.

Se as implementações de dispositivos declararem android.hardware.microphone e tecnologias 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 controlado com a API android.media.audiofx.NoiseSuppressor.
  • [C-2-2] PRECISA identificar exclusivamente cada implementação de tecnologia de redução de ruído usando o campo AudioEffect.Descriptor.uuid.

5.4.3. Captura para redirecionamento da reprodução

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

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

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

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

5.4.4. Cancelador de eco acústico

Se as implementações de dispositivos 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 ao usar AudioSource.VOICE_COMMUNICATION

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

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 que captura com qualquer AudioSource.
  • [C-1-2] DEVE permitir o acesso simultâneo ao microfone por um aplicativo pré-instalado que tenha uma função do Google Assistente e pelo menos um aplicativo que capture 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 chamada de voz se for um app privilegiado (pré-instalado) com a permissão CAPTURE_AUDIO_OUTPUT.
  • [C-1-4] Se dois ou mais aplicativos estiverem capturando simultaneamente e nenhum deles tiver uma interface na parte de cima, o que iniciou a captura mais recentemente vai receber o áudio.

5.4.6. Níveis de ganho do microfone

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

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

5.5. Reprodução de áudio

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

5.5.1. Reprodução de áudio bruto

Se as implementações de dispositivos 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, ponto flutuante
    • Canais: mono, estéreo, configurações multicanal válidas com até 8 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 para efeitos de áudio para implementações de dispositivos.

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

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

5.5.3. Volume da saída de áudio

Implementações de dispositivos automotivos:

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

5.6. Latência de áudio

A latência de áudio é o atraso de tempo à medida 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 fins desta seção, use as seguintes definições:

  • latência de saída. O intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e o momento em que o som correspondente é apresentado ao ambiente em um transdutor no dispositivo ou o sinal sai do dispositivo por uma porta e pode ser observado externamente.
  • latência de saída fria. A latência de saída do primeiro frame, quando o sistema de saída de áudio estava inativo e desligado antes da solicitação.
  • latência de saída contínua. A latência de saída para frames subsequentes, depois que o dispositivo começa a tocar áudio.
  • latência de entrada. O intervalo entre o momento em que um som é apresentado pelo ambiente ao dispositivo em um transdutor no dispositivo ou um sinal entra no dispositivo por uma porta e o momento em que 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 usada ou está indisponível.
  • latência de entrada fria. A soma do tempo de entrada perdido e da latência de entrada do primeiro frame, quando o sistema de entrada de áudio ficou inativo e desligado antes da solicitação.
  • latência de entrada contínua. A latência de entrada para frames subsequentes enquanto o dispositivo captura áudio.
  • instabilidade de saída fria. A variabilidade entre medições separadas de valores de latência de saída fria.
  • instabilidade de entrada fria. 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, da latência de saída contínua e de um período de buffer. O período de buffer permite que o app processe o sinal e mitigue a diferença de fase entre os fluxos de entrada e saída.
  • API de fila de buffer PCM do OpenSL ES. O conjunto de APIs OpenSL ES relacionadas a PCM no NDK do Android.
  • API de áudio nativa AAudio. O conjunto de APIs AAudio no Android NDK.
  • timestamp. Um par que consiste em uma posição de frame relativa em um fluxo e o tempo estimado em que esse frame entra ou sai do pipeline de processamento de áudio no endpoint associado. Consulte também AudioTimestamp.
  • glitch. Uma interrupção temporária ou um valor de amostra incorreto no sinal de áudio, geralmente causado por um buffer underrun para saída, 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 a frio de 500 milissegundos ou menos.

Se as implementações de dispositivos declararem android.hardware.audio.output, é ALTAMENTE RECOMENDADO que atendam ou excedam os seguintes requisitos:

  • [C-SR] Latência de saída a frio de 100 milissegundos ou menos. É MUITO RECOMENDADO que os dispositivos novos e atuais que executam essa versão do Android atendam 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 um MUST.
  • [C-SR] Latência de saída contínua de 45 milissegundos ou menos.
  • [C-SR] Minimize a instabilidade da saída fria.
  • [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 calibragem inicial, ao usar a fila de buffer PCM do OpenSL ES e as APIs de áudio nativo do AAudio, para latência de saída contínua e latência de saída fria em pelo menos um dispositivo de saída de áudio compatível, elas serão:

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

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

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

  • [C-3-1] Limite o erro nas marcações de tempo 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 que elas atendam a estes requisitos de áudio de entrada:

  • [C-SR] Latência de entrada a frio de 100 milissegundos ou menos. É MUITO RECOMENDADO que os dispositivos novos e atuais que executam essa versão do Android atendam a esses requisitos agora. Em uma versão futura da plataforma em 2021, vamos exigir uma latência de entrada a frio de 200 ms ou menos como um requisito 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 o jitter de entrada a frio.
  • [C-SR] Limite o erro nas marcações de tempo de entrada, conforme retornado por AudioRecord.getTimestamp ou AAudioStream_getTimestamp, para +/- 1 ms.

5.7. Protocolos de rede

As implementações de dispositivos precisam oferecer suporte aos protocolos de rede de mídia para reprodução de áudio e vídeo, conforme especificado na documentação do SDK 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 por HTTP(S).

  • [C-1-2] PRECISA ser compatível com os formatos de segmento de mídia mostrados na tabela abaixo no 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 RTSP abaixo. Para exceções, consulte as notas de rodapé da tabela na seção 5.1.

Formatos de segmento de mídia

Formatos de segmento Referência(s) Suporte obrigatório a codecs
Stream de transporte MPEG-2 ISO 13818 Codecs de vídeo:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Consulte a seção 5.1.3 para mais detalhes sobre H264 AVC, MPEG2-4 SP,
e MPEG-2.

Codecs de áudio:

  • AAC
Consulte a seção 5.1.1 para mais detalhes sobre o AAC e suas variantes.
AAC com framing ADTS e tags ID3 ISO 13818-7 Consulte a seção 5.1.1 para detalhes sobre o AAC e suas variantes.
WebVTT WebVTT

RTSP (RTP, SDP)

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

5.8. Secure Media

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

  • [C-1-1] É OBRIGATÓRIO declarar suporte para Display.FLAG_SECURE.

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

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

Se as implementações de dispositivos declararem suporte para Display.FLAG_SECURE e telas externas com fio, elas:

  • [C-3-1] PRECISA oferecer suporte ao HDCP 1.2 ou versões mais recentes para todas as telas externas conectadas por uma porta com fio acessível ao usuário.

5.9. Interface digital para instrumentos musicais (MIDI)

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

  • [C-1-1] PRECISA oferecer suporte a MIDI em todos os transportes de hardware compatíveis com MIDI para os quais fornecem conectividade genérica não MIDI, em que esses transportes são:

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

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

5.10. Áudio profissional

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

  • [C-1-1] MUST report support for feature android.hardware.audio.low_latency.
  • [C-1-2] PRECISA ter uma latência de áudio de ida e volta contínua, conforme definido na seção 5.6 Latência de áudio, de 20 milissegundos ou menos e DEVE ser de 10 milissegundos ou menos em pelo menos um caminho compatível.
  • [C-1-3] PRECISA incluir uma ou mais portas USB compatíveis com o modo host USB e o modo periférico USB.
  • [C-1-4] MUST report support for feature android.software.midi.
  • [C-1-5] PRECISA atender aos requisitos de latência e áudio USB usando a API de fila de buffer PCM OpenSL ES e pelo menos um caminho da API AAudio native audio.
  • [SR] É ALTAMENTE RECOMENDÁVEL atender aos requisitos de latência e áudio USB usando a API AAudio native audio em vez do MMAP path.
  • [C-1-6] PRECISA ter uma latência de saída fria de 200 milissegundos ou menos.
  • [C-1-7] PRECISA ter uma latência de entrada fria de 200 milissegundos ou menos.
  • [SR] SÃO FORTEMENTE RECOMENDADOS para oferecer um nível consistente de desempenho da CPU enquanto o áudio está ativo e a carga da CPU está variando. Isso DEVE ser testado usando a versão do app Android do ID de commit 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 do SynthMark. O SynthMark usa um sintetizador de software executado em uma estrutura de áudio simulada que mede o desempenho do sistema. O app SynthMark precisa ser executado usando a opção "Teste automatizado" e alcançar os seguintes resultados:
    • voicemark.90 >= 32 vozes
    • latencymark.fixed.little <= 15 msec
    • latencymark.dynamic.little <= 50 msec

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

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

Se as implementações de dispositivos atenderem a todos os requisitos acima, elas:

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

Se as implementações de dispositivos omitirem uma entrada de áudio de 3,5 mm com quatro condutores e incluírem uma ou mais 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 áudio de ida e volta contínua de 20 milissegundos ou menos na porta do modo host USB usando a classe de áudio USB.
  • A latência de áudio de ida e volta contínua DEVE ser de 10 milissegundos ou menos na porta do modo host USB usando a classe de áudio USB.
  • [C-SR] É ALTAMENTE RECOMENDADO para oferecer suporte a E/S simultâneas de até 8 canais em cada direção, taxa de amostragem de 96 kHz e profundidade de 24 ou 32 bits, quando usado com periféricos de áudio USB que também oferecem suporte a esses requisitos.

Se as implementações de dispositivos incluírem uma porta HDMI, elas:

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

5.11. Captura para "Não processado"

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

Se as implementações de dispositivos pretendem oferecer suporte a fontes de áudio não processadas e disponibilizá-las para apps de terceiros, elas:

  • [C-1-1] MUST report the support through the android.media.AudioManager property PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

  • [C-1-2] DEVE apresentar características de amplitude versus frequência aproximadamente planas na faixa de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz para todos os microfones usados para gravar a fonte de áudio não processada.

  • [C-1-3] PRECISA apresentar níveis de amplitude na faixa de baixa frequência: especificamente de ±20 dB de 5 Hz a 100 Hz em comparação com a faixa de frequência média para todos os microfones usados para gravar a fonte de áudio não processada.

  • [C-1-4] PRECISA apresentar 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 de média frequência para todos os microfones usados para gravar a fonte de áudio não processada.

  • [C-1-5] É OBRIGATÓRIO definir a sensibilidade da entrada de áudio para que uma fonte de tom senoidal de 1.000 Hz reproduzida a 94 dB de nível de pressão sonora (NPS) produza uma resposta com RMS de 520 para amostras de 16 bits (ou -36 dB de escala completa para amostras de ponto flutuante/precisão dupla) para cada microfone usado para gravar a fonte de áudio não processada.

  • [C-1-6] PRECISA ter uma relação sinal-ruído (SNR) de 60 dB ou mais para cada microfone usado para gravar a fonte de áudio não processada. A relação sinal-ruído é medida como a diferença entre 94 dB SPL e o SPL equivalente do ruído próprio, ponderado A.

  • [C-1-7] PRECISA ter uma distorção harmônica total (THD) menor que 1% para 1 kHz em um nível de entrada de 90 dB SPL em todos os microfones usados para gravar a fonte de áudio não processada.

  • NÃO pode ter nenhum outro processamento de sinal (por exemplo, controle automático de ganho, filtro passa-alta ou cancelamento de eco) no caminho, além de um multiplicador de nível para trazer o nível ao intervalo desejado. Resumindo:

  • [C-1-8] Se o processamento de sinal estiver presente na arquitetura por qualquer motivo, ele DEVE ser desativado e introduzir efetivamente atraso zero ou latência extra no caminho do sinal.
  • [C-1-9] O multiplicador de nível, embora possa estar no caminho, NÃO PODE introduzir atraso ou latência no caminho do sinal.

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

Se as implementações de 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 da API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), indicando corretamente a falta de suporte.
  • [SR] ainda são FORTEMENTE RECOMENDADOS para atender ao máximo de requisitos do caminho de sinal da fonte de gravação não processada.

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

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

  • [C-0-1] PRECISA oferecer suporte às ferramentas para desenvolvedores 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 dumpsys cmd stats
    • [C-SR] É ALTAMENTE RECOMENDADO que eles sejam compatíveis com o comando do shell cmd testharness.
    • [C-0-3] NÃO PODE alterar o formato ou o conteúdo dos eventos do sistema do dispositivo (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrados com o comando dumpsys.
    • [C-0-10] DEVE registrar, sem omissão, e disponibilizar os seguintes eventos para o comando de shell cmd stats e a classe da API do sistema StatsManager.
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] O daemon adb do lado do dispositivo PRECISA estar inativo por padrão, e PRECISA haver um mecanismo acessível ao usuário para ativar o Android Debug Bridge.
    • [C-0-5] É obrigatório oferecer suporte ao adb seguro. O Android inclui suporte para adb seguro. O adb seguro permite o adb em hosts autenticados conhecidos.

    • [C-0-6] PRECISA fornecer um mecanismo que permita a conexão do adb de uma máquina host. Exemplo:

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

  • Serviço de monitoramento de depuração do Dalvik (ddms)

    • [C-0-7] Precisa oferecer suporte a todos os recursos do ddms, conforme documentado no SDK do Android. Como o ddms usa o adb, o suporte a ele DEVE estar inativo por padrão, mas PRECISA ser oferecido sempre que o usuário ativar o Android Debug Bridge, como acima.
  • Monkey
    • [C-0-8] PRECISA incluir o framework Monkey e disponibilizá-lo para uso em aplicativos.
  • SysTrace
    • [C-0-9] PRECISA oferecer suporte à ferramenta systrace, conforme documentado no SDK do Android. O Systrace PRECISA estar inativo por padrão, e PRECISA haver um mecanismo acessível ao usuário para ativar o Systrace.

  • Perfetto (link em inglês)

    • [C-SR] É ALTAMENTE RECOMENDADO expor um binário /system/bin/perfetto ao usuário do shell, cuja linha de comando esteja em conformidade com a documentação do perfetto.
    • [C-SR] É ALTAMENTE RECOMENDADO que o binário do perfetto aceite como entrada uma configuração do protobuf que esteja em conformidade com o esquema definido na documentação do perfetto.
    • [C-SR] É ALTAMENTE RECOMENDADO que o binário do Perfetto grave como saída um rastreamento do protobuf que esteja em conformidade com o esquema definido na documentação do Perfetto.
    • [C-SR] É ALTAMENTE RECOMENDADO fornecer, pelo binário do perfetto, pelo menos as fontes de dados descritas na documentação do perfetto.

  • Modo de arcabouço de testes

    Se as implementações de dispositivos forem compatíveis com o comando do shell cmd testharness e executarem cmd testharness enable, elas:

    • [C-2-1] MUST return true for ActivityManager.isRunningInUserTestHarness()
    • [C-2-2] É OBRIGATÓRIO implementar o modo de arcabouço de testes conforme descrito na documentação do modo de arcabouço.

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

  • [C-1-1] PRECISA oferecer uma opção para o desenvolvedor de apps ativar/desativar camadas de depuração de GPU.
  • [C-1-2] DEVE, quando as camadas de depuração da GPU estiverem ativadas, enumerar camadas em bibliotecas fornecidas por ferramentas externas (ou seja, não fazem parte do pacote de plataforma ou aplicativo) encontradas no diretório base de aplicativos depuráveis para oferecer suporte aos métodos de API vkEnumerateInstanceLayerProperties() e vkCreateInstance().

6.2. Opções do desenvolvedor

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

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

  • [C-0-1] PRECISA obedecer à intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar configurações relacionadas ao desenvolvimento de aplicativos. A implementação upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários iniciem esse menu depois de pressionar sete vezes o item Configurações > Sobre o dispositivo > Número da versão.
  • [C-0-2] As Opções do desenvolvedor precisam ficar ocultas por padrão.
  • [C-0-3] PRECISA fornecer um mecanismo claro que não dê tratamento preferencial a um app de terceiros em vez de outro para ativar as opções do desenvolvedor. É NECESSÁRIO fornecer um documento ou site visível ao público que descreva como ativar as Opções do desenvolvedor. Esse documento ou site PRECISA ter um link nos documentos do SDK do Android.
  • PRECISA ter uma notificação visual contínua para o usuário quando as opções do desenvolvedor estão ativadas e a segurança do usuário é uma preocupação.
  • O MAY pode limitar temporariamente o acesso ao menu "Opções do desenvolvedor", ocultando ou desativando visualmente o menu para evitar distrações em situações em que a segurança do usuário é uma preocupação.

7. Compatibilidade de hardware

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

  • [C-0-1] A implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK 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 de componentes AINDA precisam ser apresentadas.
  • [C-0-3] Os comportamentos da API precisam ser implementados como no-ops de maneira razoável.
  • [C-0-4] Os métodos da API PRECISAM retornar valores nulos quando permitido pela documentação do SDK.
  • [C-0-5] Os métodos de API precisam retornar implementações no-op de classes em que valores nulos não são permitidos pela documentação do SDK.
  • [C-0-6] Os métodos de API NÃO PODEM gerar exceções não documentadas pela documentação do SDK.
  • [C-0-7] As implementações de dispositivos PRECISAM informar de maneira consistente informações precisas de configuração de hardware usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para a mesma impressão digital de build.

Um exemplo típico de cenário em que esses requisitos se aplicam é a API de telefonia: mesmo em dispositivos que não são smartphones, essas APIs PRECISAM ser implementadas como operações nulas razoáveis.

7.1. Display e gráficos

O Android inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts da interface de acordo com o dispositivo para garantir que os aplicativos de terceiros funcionem bem em uma variedade de configurações de hardware. Nos dispositivos Android compatíveis em que todos os apps Android de terceiros podem ser executados, as implementações de dispositivos PRECISAM implementar corretamente essas APIs e comportamentos, conforme detalhado nesta seção.

As unidades referenciadas pelos requisitos nesta seção são definidas da seguinte maneira:

  • tamanho físico da diagonal. 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 polegada. Quando os valores de dpi são listados, os dpis horizontal e vertical precisam estar dentro do intervalo.
  • proporção. A proporção entre os pixels da dimensão mais longa e a mais curta da tela. Por exemplo, uma tela de 480 x 854 pixels seria 854/480 = 1,779, ou aproximadamente "16:9".
  • pixel de densidade independente (dp). A unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como: pixels = dps * (density/160).

7.1.1. Configuração da tela

7.1.1.1. Tamanho e forma da tela

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

Implementações de dispositivos:

  • [C-0-1] PRECISA informar o tamanho correto do layout para o Configuration.screenLayout, conforme definido na documentação do SDK Android. Especificamente, as implementações de dispositivos PRECISAM informar as dimensões corretas da tela em pixels lógicos de densidade independente (dp), conforme abaixo:

    • Dispositivos com o Configuration.uiMode definido como qualquer valor diferente de UI_MODE_TYPE_WATCH e que informam um tamanho small para o Configuration.screenLayout precisam ter pelo menos 426 dp x 320 dp.
    • Os dispositivos que informam um tamanho de normal para o Configuration.screenLayout precisam ter pelo menos 480 dp x 320 dp.
    • Os dispositivos que informam um tamanho large para o Configuration.screenLayout precisam ter pelo menos 640 dp x 480 dp.
    • Os dispositivos que informam um tamanho de xlarge para o Configuration.screenLayout precisam ter pelo menos 960 dp x 720 dp.

  • [C-0-2] PRECISA respeitar corretamente o suporte declarado pelos aplicativos para tamanhos de tela usando o atributo <supports-screens> no AndroidManifest.xml, conforme descrito na documentação do SDK Android.

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

Se as implementações de dispositivos forem compatíveis com UI_MODE_TYPE_NORMAL e incluírem telas compatíveis com o 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 a capacidade do usuário de mudar para o modo de exibição com cantos retangulares.
7.1.1.2. Proporção da tela

Embora não haja restrição à proporção da tela física para as telas compatíveis com 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 das seguintes condições:

    • O app declarou que é compatível com uma proporção de tela maior usando o valor de metadados android.max_aspect.
    • O app declara que pode ser redimensionado pelo atributo android:resizeableActivity.
    • O app é destinado ao nível 24 da API ou mais recente e não declara um android:maxAspectRatio que restringiria 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 para ficar mais largo atendendo a uma das seguintes condições:

  • [C-0-3] As implementações de dispositivos com o 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 UI do Android define um conjunto de densidades lógicas padrão para ajudar os desenvolvedores de aplicativos a segmentar recursos.

  • [C-0-1] Por padrão, as implementações de dispositivos precisam informar apenas uma das densidades do framework Android listadas em DisplayMetrics pela API DENSITY_DEVICE_STABLE, e esse valor não pode mudar em nenhum momento. No entanto, o dispositivo PODE informar uma densidade arbitrária diferente de acordo com as mudanças na configuração da tela feitas pelo usuário (por exemplo, tamanho da tela) definidas após a inicialização.

  • As implementações de dispositivos DEVEM definir a densidade padrão do framework Android que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica reduza o tamanho da tela informado abaixo do mínimo aceito. Se a densidade padrão do framework Android numericamente mais próxima da densidade física resultar em um tamanho de tela menor que o menor tamanho de tela compatível (320 dp de largura), as implementações de dispositivos DEVERÃO informar a próxima densidade padrão mais baixa do framework Android.

Se houver uma ação para mudar o tamanho da tela do dispositivo:

  • [C-1-1] O tamanho da tela NÃO PODE ser dimensionado para mais de 1,5 vez a densidade nativa nem produzir uma dimensão mínima efetiva da tela menor que 320 dp (equivalente ao qualificador de recursos sw320dp), o que ocorrer primeiro.
  • [C-1-2] O tamanho da tela NÃO PODE ser reduzido em uma escala menor que 0,85 vezes a densidade nativa.
  • Para garantir uma boa usabilidade e tamanhos de fonte consistentes, é RECOMENDADO que o escalonamento a seguir das opções de display nativo seja fornecido (obedecendo aos limites especificados acima):
  • Pequena: 0,85x
  • Padrão: 1x (escala de exibição nativa)
  • Grande: 1,15x
  • Maior: 1,3x
  • Maior 1,45x

7.1.2. Métricas de display

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

  • [C-1-1] DEVE informar valores corretos para todas as métricas de exibição 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] DEVE informar os valores corretos da tela compatível com o Android, conforme definido na API android.util.DisplayMetrics para o view.Display padrão emulado.

7.1.3. Orientação da tela

Implementações de dispositivos:

  • [C-0-1] 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 compatível. Por exemplo, um dispositivo com uma tela paisagem de orientação fixa, como uma televisão ou um laptop, SÓ DEVE informar android.hardware.screen.landscape.
  • [C-0-2] Precisa informar o valor correto da orientação atual do dispositivo sempre que for consultado pelas APIs android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras.

Se as implementações de dispositivos forem compatíveis com as duas orientações de tela, elas:

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

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

7.1.4.1 OpenGL ES

Implementações de dispositivos:

  • [C-0-1] DEVE identificar corretamente as versões compatíveis do OpenGL ES (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 o suporte para todas as APIs gerenciadas e nativas correspondentes em todas as versões do OpenGL ES que identificaram como compatíveis.

Se as implementações de dispositivos incluírem uma tela ou saída de 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 Android.
  • [C-SR] É ALTAMENTE RECOMENDADO oferecer suporte ao OpenGL ES 3.1.
  • DEVE ser compatível com o OpenGL ES 3.2.

Se as implementações de dispositivos forem compatíveis com alguma das versões do OpenGL ES, elas:

  • [C-2-1] É OBRIGATÓRIO informar pelas APIs gerenciadas e nativas do OpenGL ES qualquer outra extensão do OpenGL ES implementada e, inversamente, NÃO É PERMITIDO informar strings de extensão que não têm suporte.
  • [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] É ALTAMENTE RECOMENDADO para oferecer suporte às extensões EGL_KHR_partial_update e OES_EGL_image_external.
  • DEVE informar 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 compatibilidade com o 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] SÃO ALTAMENTE RECOMENDADOS 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 oferecer suporte ao pacote de extensões para Android do OpenGL ES por completo.

Se as implementações de dispositivos forem compatíveis com o pacote de extensões do Android do OpenGL ES por completo, elas:

  • [C-5-1] MUST identify the support through the android.hardware.opengles.aep feature flag.

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

  • [C-6-1] Também é necessário oferecer suporte à extensão EGL_ANDROID_front_buffer_auto_refresh.
7.1.4.2 Vulkan

O Android inclui suporte ao Vulkan (link em inglês), 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] É ALTAMENTE RECOMENDADO incluir suporte para Vulkan 1.1.

Se as implementações de dispositivos incluírem uma tela ou saída de 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] É OBRIGATÓRIO implementar totalmente as APIs Vulkan 1.0 para cada VkPhysicalDevice enumerado.
  • [C-1-4] É OBRIGATÓRIO enumerar as camadas, contidas em bibliotecas nativas nomeadas como libVkLayer*.so no diretório de bibliotecas nativas do pacote do aplicativo, usando as APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
  • [C-1-5] NÃO PODE enumerar camadas fornecidas por bibliotecas fora do pacote do aplicativo nem oferecer 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 pelas APIs nativas do Vulkan e NÃO PODE informar strings de extensão que não são compatíveis corretamente.
  • [C-1-7] Precisa oferecer suporte às extensões VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain e VK_KHR_incremental_present.
  • [C-SR] É ALTAMENTE RECOMENDADO 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 recursos 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 recursos do Vulkan, elas:

  • [C-3-1] PRECISA expor suporte para o semáforo externo SYNC_FD e tipos de identificadores e a extensão VK_ANDROID_external_memory_android_hardware_buffer.
7.1.4.3 RenderScript
  • [C-0-1] As implementações de dispositivos precisam oferecer suporte ao Android RenderScript, conforme detalhado na documentação do SDK do Android.
7.1.4.4 Aceleração de gráficos 2D

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

Implementações de dispositivos:

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

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

Implementações de dispositivos:

  • [C-0-3] Precisa oferecer suporte à API TextureView e ter um comportamento consistente com a implementação upstream do Android.
7.1.4.5 Telas de ampla gama

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

  • [C-1-1] PRECISA ter uma tela calibrada por cores.
  • [C-1-2] PRECISA ter uma tela cuja gama cubra totalmente a gama de cores sRGB no espaço CIE 1931 xyY.
  • [C-1-3] PRECISA ter uma tela cujo gamut tenha uma área de pelo menos 90% do DCI-P3 no espaço CIE 1931 xyY.
  • [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.1 ou 3.2 e informar isso corretamente.
  • [C-1-5] PRECISA anunciar suporte às 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] SÃO ALTAMENTE RECOMENDADOS 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 do sRGB no espaço CIE 1931 xyY, embora a gama de cores da tela não esteja definida.

7.1.5. Modo de compatibilidade de aplicativos legados

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

7.1.6. Tecnologia da tela

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

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

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

7.1.7. Telas secundárias

O Android inclui suporte para telas secundárias compatíveis com o Android para ativar recursos de compartilhamento de mídia e 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 uma conexão de tela adicional integrada, elas:

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

7.2. Dispositivos de entrada

Implementações de dispositivos:

7.2.1. Teclado

Se as implementações de dispositivos incluírem suporte para aplicativos de Editor de método de entrada (IME) de terceiros, elas:

Implementações de dispositivos: * [C-0-1] NÃO PODEM incluir um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.keyboard (QWERTY ou 12 teclas). * DEVE incluir implementações adicionais de teclado virtual. * PODE incluir um teclado físico.

7.2.2. Navegação sem toque

O Android inclui suporte para botão direcional, trackball e roda como mecanismos de navegação sem toque.

Implementações de dispositivos:

Se as implementações de dispositivos não tiverem navegações sem toque, elas:

  • [C-1-1] PRECISA fornecer um mecanismo alternativo razoável de interface do usuário para seleção e edição de texto, compatível com mecanismos de gerenciamento de entrada. 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 Início, Recentes e Voltar, normalmente fornecidas por uma interação com um botão físico dedicado ou uma parte distinta da tela sensível ao toque, são essenciais para o paradigma de navegação do Android e, portanto, para as implementações de dispositivos:

  • [C-0-1] DEVE fornecer um recurso ao usuário para iniciar aplicativos instalados que tenham uma atividade com o <intent-filter> definido como 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 facilidade do usuário.
  • DEVE fornecer botões para as funções "Recentes" e "Voltar".

Se as funções "Início", "Recentes" ou "Voltar" forem fornecidas, elas:

  • [C-1-1] PRECISA ser acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou fazer um gesto) quando qualquer uma delas estiver acessível.
  • [C-1-2] PRECISA indicar claramente qual ação única acionaria cada função. Ter um ícone visível impresso no botão, mostrar um ícone de software na parte da barra de navegação da tela ou guiar o usuário por um fluxo de demonstração guiado durante a experiência de configuração inicial são exemplos dessa indicação.

Implementações de dispositivos:

  • [SR] é FORTEMENTE RECOMENDADO a não fornecer o mecanismo de entrada para a função de menu, já que ela foi descontinuada em favor da barra de ações desde o Android 4.0.

Se as implementações de dispositivos oferecerem a função "Menu", elas:

  • [C-2-1] O botão de estouro de ação DEVE ser exibido sempre que o pop-up do menu de estouro de ação não estiver vazio e a barra de ações estiver visível.
  • [C-2-2] NÃO PODE modificar a posição do pop-up de estouro de ação exibido ao selecionar o botão de estouro na barra de ações, mas PODE renderizar o pop-up de estouro de ação em uma posição modificada na tela quando ele é exibido ao selecionar a função "Menu".

Se as implementações de dispositivos não fornecerem a função "Menu", para compatibilidade com versões anteriores, elas: * [C-SR] É ALTAMENTE RECOMENDADO que a função "Menu" esteja disponível para aplicativos quando targetSdkVersion for menor que 10, seja por um botão físico, uma tecla de software ou gestos. Essa função de menu PRECISA estar acessível, a menos que esteja oculta com outras funções de navegação.

Se as implementações de dispositivos oferecem a função Assist, elas:

  • [C-4-1] DEVE tornar a função Assistente acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando outras teclas de navegação estiverem acessíveis.
  • [SR] É ALTAMENTE RECOMENDADO usar o toque longo na função HOME como essa interação designada.

Se as implementações de dispositivos usarem uma parte distinta da tela para mostrar as teclas de navegação, elas:

  • [C-5-1] As teclas de navegação precisam usar uma parte distinta da tela, não disponível para aplicativos, e não podem obscurecer nem interferir na parte da tela disponível para aplicativos.
  • [C-5-2] DEVE disponibilizar uma parte da tela para aplicativos que atendam aos requisitos definidos na seção 7.1.1.
  • [C-5-3] PRECISA obedecer às flags definidas pelo app usando o método da API View.setSystemUiVisibility() para que essa parte distinta da tela (ou seja, a barra de navegação) seja ocultada corretamente, conforme documentado no SDK.

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

Se uma função de navegação for fornecida em qualquer lugar nas bordas esquerda e direita da orientação atual da tela:

  • [C-7-1] A função de navegação PRECISA ser "Voltar" e ser fornecida como um deslize das bordas esquerda e direita da orientação atual da tela.
  • [C-7-2] Se painéis do sistema personalizados que podem ser deslizados forem fornecidos nas bordas esquerda ou direita, eles PRECISAM ser colocados no terço superior da tela com uma indicação visual clara e persistente de que o arrastar para dentro invocaria os painéis mencionados e, portanto, não o botão "Voltar". Um painel do sistema PODE ser configurado por um usuário para ficar abaixo do 1/3 superior das bordas da tela, mas NÃO PODE usar mais de 1/3 das bordas.
  • [C-7-3] Quando o app em primeiro plano tem as flags View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY definidas, o gesto de deslizar nas 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 do sistema personalizados que podem ser deslizados precisam ficar ocultos até que o usuário traga as barras de sistema (também conhecidas como barra de navegação e de status), conforme implementado no AOSP.

7.2.4. Entrada por toque

O Android inclui suporte para vários sistemas de entrada de ponteiro, como touchscreens, touchpads e dispositivos de entrada de toque simulado. Implementações de dispositivos com tela sensível ao toque estã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á tocando diretamente na tela, o sistema não exige mais recursos para indicar os objetos que estão sendo manipulados.

Implementações de dispositivos:

  • PRECISA ter um sistema de entrada de ponteiro de algum tipo (semelhante a um mouse ou toque).
  • DEVE oferecer suporte a ponteiros rastreados de forma totalmente independente.

Se as implementações de dispositivos incluírem uma tela sensível ao toque (toque único ou melhor), elas:

  • [C-1-1] MUST report TOUCHSCREEN_FINGER for the Configuration.touchscreen API field.
  • [C-1-2] PRECISA informar as flags de recursos android.hardware.touchscreen e android.hardware.faketouch.

Se as implementações de dispositivos incluírem uma tela sensível ao toque que pode rastrear mais de um toque, elas:

  • [C-2-1] PRECISA informar as flags de recursos adequadas android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand correspondentes ao tipo de touchscreen específico no dispositivo.

Se as implementações de dispositivos não incluírem uma tela touchscreen (e dependerem apenas de um dispositivo apontador) e atenderem aos requisitos de toque simulado na seção 7.2.5, elas:

  • [C-3-1] NÃO PODE informar nenhuma flag de recurso que comece com android.hardware.touchscreen e DEVE informar apenas android.hardware.faketouch.

7.2.5. Entrada por toque simulada

A interface de toque simulado oferece um sistema de entrada do usuário que se aproxima de um subconjunto de recursos da tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela se aproxima do toque, mas exige que o usuário primeiro aponte ou foque e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse aéreo baseado em giroscópio, giroponto, joystick e trackpad multitoque, podem oferecer suporte a interações de toque simulado. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada não sensível ao toque (baseado em ponteiro) de alta fidelidade, 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 é compatível com um subconjunto emulado de funcionalidades da tela sensível ao toque.

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:

  • PRECISA declarar suporte à flag de recurso android.hardware.faketouch.

Se as implementações de dispositivos declararem suporte para android.hardware.faketouch, elas:

  • [C-1-1] É OBRIGATÓRIO informar as posições absolutas X e Y da tela do local do ponteiro e mostrar um ponteiro visual na tela.
  • [C-1-2] É OBRIGATÓRIO informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre quando o ponteiro sobe ou desce na tela.
  • [C-1-3] PRECISA oferecer suporte a pressionar e soltar um objeto na tela, o que permite que os usuários emulem um toque em um objeto na tela.
  • [C-1-4] DEVE oferecer suporte a pressionar e soltar o ponteiro, pressionar e soltar o ponteiro no mesmo lugar em um objeto na tela dentro de um limite de tempo, o que permite que os usuários emulem um toque duplo em um objeto na tela.
  • [C-1-5] PRECISA oferecer suporte a pressionar um ponto arbitrário na tela, mover o ponteiro para qualquer outro ponto arbitrário na tela e soltar o ponteiro, o que permite que os usuários emulem um arrastar e soltar por toque.
  • [C-1-6] PRECISA oferecer suporte ao toque para baixo e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, toquem para cima na tela, o que permite que os usuários joguem um objeto na tela.
  • [C-1-7] É OBRIGATÓRIO informar TOUCHSCREEN_NOTOUCH para o campo da API Configuration.touchscreen.

Se as implementações de dispositivos declararem suporte para android.hardware.faketouch.multitouch.distinct, elas:

  • [C-2-1] É OBRIGATÓRIO declarar suporte para 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 para android.hardware.faketouch.multitouch.jazzhand, elas:

  • [C-3-1] É OBRIGATÓRIO declarar suporte para android.hardware.faketouch.
  • [C-3-2] PRECISA oferecer suporte ao rastreamento distinto de 5 (rastreamento de uma mão de dedos) ou mais entradas de ponteiro de forma totalmente independente.

7.2.6. Suporte a controles de jogos

7.2.6.1. Mapeamentos de botões

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

  • [C-1-1] PRECISA ter um controlador integrado ou ser enviado com um controlador separado na caixa, que forneça meios para inserir todos os eventos listados nas tabelas abaixo.
  • [C-1-2] PRECISA ser capaz de mapear eventos de HID para as constantes view.InputEvent do Android associadas, conforme listado nas tabelas abaixo. A implementação upstream do Android inclui a implementação de controles de jogos que atende a esse requisito.
Botão Uso de HID2 Botão do Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Botão direcional para cima1
Botão direcional para baixo1 		0x01 0x00393 AXIS_HAT_Y4
Esquerda do D-pad1
Direita do D-pad1 		0x01 0x00393 AXIS_HAT_X4
Botão esquerdo do ombro1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Botão direito do ombro1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clique no stick esquerdo1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clique no stick direito1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Início1 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 afastada do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e para a esquerda pressionadas.

4 MotionEvent

Controles analógicos1 Uso de HID Botão do Android
Gatilho esquerdo 0x02 0x00C5 AXIS_LTRIGGER
Gatilho direito 0x02 0x00C4 AXIS_RTRIGGER
Joystick esquerdo 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
Joystick direito 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

Consulte a Seção 2.3.1 para ver os requisitos específicos de cada dispositivo.

7.3. Sensores

Se as implementações de dispositivos incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, a implementação do dispositivo DEVE 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] É OBRIGATÓRIO 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 compatíveis usando SensorManager.getSensorList() e métodos semelhantes.
  • [C-0-3] DEVE se comportar de maneira razoável para todas as outras APIs de sensor (por exemplo, retornando true ou false conforme apropriado quando os aplicativos tentam registrar listeners, não chamando listeners de sensor quando os sensores correspondentes não estão presentes etc.).

Se as implementações de dispositivos incluírem um tipo específico de sensor que tenha uma API correspondente para desenvolvedores terceirizados, elas:

  • [C-1-1] É OBRIGATÓRIO informar todas as medições do sensor usando os valores relevantes do Sistema Internacional de Unidades (métrico) para cada tipo de sensor, conforme definido na documentação do SDK do Android.
  • [C-1-2] DEVE informar dados do sensor com uma latência máxima de 100 milissegundos + 2 * sample_time no caso de um fluxo de sensor com uma latência máxima solicitada de 0 ms quando o processador de aplicativo está ativo. Esse atraso não inclui atrasos de filtragem.
  • [C-1-3] DEVE informar a primeira amostra do sensor em até 400 milissegundos + 2 * sample_time do sensor ativado. É aceitável que essa amostra tenha uma acurácia de 0.

  • [SR] DEVE informar o horário do evento em nanossegundos, conforme definido na documentação do SDK do Android, representando o horário em que o evento ocorreu e sincronizado com o relógio SystemClock.elapsedRealtimeNano(). É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam ser atualizados para as versões futuras 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 qualquer API indicada na documentação do SDK do Android como um sensor contínuo, as implementações de dispositivos PRECISAM fornecer continuamente amostras de dados periódicas que DEVEM ter um jitter abaixo de 3%, em que jitter é definido como o desvio padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.

  • [C-1-5] MUST ensure that the sensor event stream MUST NOT prevent the device CPU from entering a suspend state or waking up from a suspend state.

  • Quando vários sensores são ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia informado de cada sensor.

A lista acima não é abrangente. O comportamento documentado do SDK do Android e as documentações de código aberto do Android sobre sensores devem ser considerados autoritativos.

Alguns tipos de sensores são compostos, ou seja, podem ser derivados de dados fornecidos por um ou mais sensores. Por exemplo, o sensor de orientação e o sensor de aceleração linear.

Implementações de dispositivos:

  • DEVE implementar esses tipos de sensores quando eles incluírem os sensores físicos pré-requisitos, conforme descrito em tipos de sensores.

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

  • [C-2-1] É OBRIGATÓRIO 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] É ALTAMENTE 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 ser capaz de informar eventos com uma frequência de pelo menos 50 Hz.
  • [C-1-2] É OBRIGATÓRIO implementar e informar o sensor TYPE_ACCELEROMETER.
  • [C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor Android, conforme detalhado nas APIs Android.
  • [C-1-4] PRECISA ser capaz de medir desde 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 maior que 0,05 m/s², em que o desvio padrão DEVE ser calculado por eixo em amostras coletadas por um período de pelo menos 3 segundos na taxa de amostragem mais rápida.
  • [SR] são ALTAMENTE RECOMENDADOS para implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
  • [SR] é FORTEMENTE RECOMENDADO para implementar e informar o sensor TYPE_ACCELEROMETER_UNCALIBRATED. É FORTEMENTE RECOMENDADO que os dispositivos Android atendam a esse requisito para que possam fazer upgrade para a versão futura da plataforma, em que isso pode se tornar OBRIGATÓRIO.
  • DEVE implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER, conforme descrito no documento do SDK do Android.
  • DEVE informar eventos de até pelo menos 200 Hz.
  • PRECISA ter uma resolução de pelo menos 16 bits.
  • PRECISA 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.
  • PRECISA ter compensação de temperatura.

Se as implementações de dispositivos incluírem um acelerômetro de três eixos e um dos sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR ou TYPE_STEP_COUNTER for implementado:

  • [C-2-1] A soma do consumo de energia DEVE sempre ser inferior a 4 mW.
  • Cada um DEVE estar abaixo de 2 mW e 0,5 mW quando o dispositivo estiver em uma condição dinâmica ou estática.

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

  • [C-3-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [C-SR] É ALTAMENTE RECOMENDÁVEL implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

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

  • [C-4-1] É OBRIGATÓRIO implementar um sensor composto TYPE_ROTATION_VECTOR.

7.3.2. Magnetômetro

Implementações de dispositivos:

  • [C-SR] É ALTAMENTE RECOMENDADO incluir um magnetômetro de três eixos (bússola).

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

  • [C-1-1] PRECISA implementar o sensor TYPE_MAGNETIC_FIELD.
  • [C-1-2] DEVE ser capaz de informar eventos com uma frequência de pelo menos 10 Hz e DEVE informar eventos com uma frequência de pelo menos 50 Hz.
  • [C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor Android, conforme detalhado nas APIs 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 de ferro duro menor que 700 µT e DEVE ter um valor abaixo de 200 µT, colocando o magnetômetro longe de campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímã).
  • [C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 µT.
  • [C-1-7] PRECISA oferecer suporte à calibragem e compensação on-line do viés de ferro duro e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • [C-1-8] PRECISA ter a compensação de ferro macio aplicada. A calibragem 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 por um período de pelo menos 3 segundos na taxa de amostragem mais rápida, não maior que 1,5 µT; DEVE ter um desvio padrão não maior que 0,5 µT.
  • DEVE implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] É ALTAMENTE RECOMENDÁVEL que dispositivos Android novos e atuais implementem 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, eles:

  • [C-2-1] É obrigatório 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, eles:

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

7.3.3. GPS

Implementações de dispositivos:

  • [C-SR] É ALTAMENTE RECOMENDADO incluir um receptor GPS/GNSS.

Se as implementações de dispositivos incluírem um receptor de 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 localização a uma taxa de pelo menos 1 Hz quando solicitado via LocationManager#requestLocationUpdate.
  • [C-1-2] DEVE ser capaz de determinar a localização em condições de céu aberto (sinais fortes, multipath insignificante, HDOP < 2) em até 10 segundos (tempo rápido para o primeiro fixo), quando conectado a uma conexão de Internet com velocidade de dados de 0,5 Mbps ou mais rápida. Normalmente, esse requisito é atendido com o uso de alguma forma de técnica de GPS/GNSS assistido ou previsto para minimizar o tempo de fixação do GPS/GNSS. Os dados de assistência incluem hora de referência, local de referência e efemérides/relógio de satélite.
    • [C-1-6] Depois de fazer esse cálculo de localização, as implementações de dispositivos PRECISAM determinar a localização, em céu aberto, em até 5 segundos, quando as solicitações de localização são reiniciadas, até uma hora após o cálculo inicial, mesmo quando a solicitação subsequente é feita sem uma conexão de dados e/ou após um ciclo de energia.

  • Em condições de céu aberto, depois de determinar o local, parado ou se movendo com menos de 1 metro por segundo ao quadrado de aceleração:

    • [C-1-3] PRECISA ser capaz de determinar a localização em um raio de 20 metros e a velocidade em um raio de 0, 5 metro por segundo, pelo menos 95% do tempo.
    • [C-1-4] PRECISA rastrear e gerar relatórios simultaneamente via GnssStatus.Callback de 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 e pelo menos um dos seguintes: Glonass, Beidou, Galileo).
    • [C-SR] É ALTAMENTE RECOMENDADO continuar fornecendo saídas normais de localização GPS/GNSS pelas APIs do provedor de localização GNSS durante uma ligação de emergência.
    • [C-SR] É ALTAMENTE RECOMENDÁVEL informar as medições do GNSS de todas as constelações rastreadas (conforme informado nas mensagens GnssStatus), exceto o SBAS.
    • [C-SR] É ALTAMENTE RECOMENDÁVEL informar o AGC e a frequência da medição do GNSS.
    • [C-SR] É ALTAMENTE RECOMENDADO informar todas as estimativas de acurácia (incluindo direção, velocidade e vertical) como parte de cada localização por GPS/GNSS.
    • [C-SR] É ALTAMENTE RECOMENDADO informar as medições de GNSS assim que forem encontradas, mesmo que um local calculado por GPS/GNSS ainda não tenha sido informado.
    • [C-SR] É ALTAMENTE RECOMENDADO informar pseudodistâncias e taxas de pseudodistância do GNSS que, em condições de céu aberto após a determinação do local, enquanto parado ou se movendo com menos de 0, 2 metro por segundo ao quadrado de aceleração, são suficientes para calcular a posição em até 20 metros e a velocidade em até 0, 2 metro por segundo, pelo menos 95% das vezes.

7.3.4. Giroscópio

Implementações de dispositivos:

  • [C-SR] É ALTAMENTE RECOMENDÁVEL 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 ser capaz de informar eventos com uma frequência de pelo menos 50 Hz.
  • [C-1-2] PRECISA implementar o sensor TYPE_GYROSCOPE e é FORTEMENTE RECOMENDADO que também implemente 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 ter compensação de temperatura.
  • [C-1-6] PRECISA ser calibrado e compensado durante o uso, além de preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • [C-1-7] PRECISA ter uma variância não maior que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variância pode variar 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 NÃO DEVE ser maior que 1e-7 rad^2/s^2.
  • [SR] É ALTAMENTE RECOMENDADO que o erro de calibragem seja menor que 0,01 rad/s quando o dispositivo estiver parado à temperatura ambiente.
  • DEVE informar 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] É obrigatório 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, eles:

  • [C-3-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
  • [C-SR] É ALTAMENTE RECOMENDÁVEL implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

Implementações de dispositivos:

  • [C-SR] É ALTAMENTE RECOMENDADO incluir um barômetro (sensor de pressão atmosférica).

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

  • [C-1-1] É OBRIGATÓRIO implementar e informar o sensor TYPE_PRESSURE.
  • [C-1-2] PRECISA ser capaz de gerar eventos a 5 Hz ou mais.
  • [C-1-3] PRECISA ter compensação de temperatura.
  • [SR] É ALTAMENTE RECOMENDADO para poder informar medições de pressão no intervalo de 300 hPa a 1.100 hPa.
  • PRECISA ter uma precisão absoluta de 1 hPa.
  • DEVE ter uma acurácia relativa de 0,12 hPa em uma faixa de 20 hPa (equivalente a uma acurácia de ~1 m em uma mudança de ~200 m ao 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 de dispositivos incluírem um termômetro ambiente (sensor de temperatura), elas:

  • [C-1-1] PRECISA ser definido como SENSOR_TYPE_AMBIENT_TEMPERATURE e medir a temperatura ambiente (sala/cabine do veículo) de onde o usuário está interagindo com o dispositivo em graus Celsius.
  • [C-1-2] PRECISA ser definido como SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] É OBRIGATÓRIO medir a temperatura da CPU do dispositivo.
  • [C-1-4] NÃO PODE medir nenhuma outra temperatura.

O tipo de sensor SENSOR_TYPE_TEMPERATURE teve o uso suspenso 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 da tela. Ou seja, o sensor de proximidade PRECISA estar orientado para detectar objetos próximos à tela, já que o objetivo principal desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se as implementações de dispositivos incluírem um sensor de proximidade com qualquer outra orientação, ele NÃO DEVERÁ estar acessível por essa API.
  • [C-1-2] PRECISA ter 1 bit de precisão ou mais.

7.3.9. Sensores de alta fidelidade

Se as implementações de dispositivos incluírem um conjunto de sensores de qualidade superior, conforme definido nesta seção, e os disponibilizarem para apps de terceiros, elas:

  • [C-1-1] É OBRIGATÓRIO identificar o recurso usando a flag android.hardware.sensor.hifi_sensors.

Se as implementações de dispositivos declararem android.hardware.sensor.hifi_sensors, elas:

  • [C-2-1] PRECISA ter um sensor TYPE_ACCELEROMETER que:

    • PRECISA ter um intervalo de medição entre pelo menos -8g e +8g, DEVE ter um intervalo de medição entre pelo menos -16g e +16g.
    • PRECISA ter uma resolução de medição de pelo menos 2048 LSB/g.
    • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
    • PRECISA ter uma frequência máxima de medição de 400 Hz ou mais; DEVE oferecer suporte ao RATE_VERY_FAST do SensorDirectChannel.
    • PRECISA ter um ruído de medição não superior a 400 μg/√Hz.
    • PRECISA implementar uma forma não ativada desse sensor com capacidade de buffer de pelo menos 3.000 eventos de sensor.
    • PRECISA ter um consumo de energia em lote não pior que 3 mW.
    • [C-SR] É ALTAMENTE RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
    • PRECISA ter uma caminhada aleatória de aceleração menor que 30 μg √Hz testada em temperatura ambiente.
    • DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 1 mg/°C.
    • PRECISA ter uma não linearidade da linha de ajuste ideal de ≤ 0,5% e uma mudança de sensibilidade em relação à 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 de TYPE_ACCELEROMETER.

  • [C-2-3] PRECISA ter um sensor TYPE_GYROSCOPE que:

    • PRECISA ter um intervalo de medição entre pelo menos -1000 e +1000 dps.
    • PRECISA ter uma resolução de medição de pelo menos 16 LSB/dps.
    • PRECISA ter uma frequência mínima de medição de 12,5 Hz ou menos.
    • PRECISA ter uma frequência máxima de medição de 400 Hz ou mais; DEVE oferecer suporte ao RATE_VERY_FAST do SensorDirectChannel.
    • PRECISA ter um ruído de medição não superior a 0,014°/s/√Hz.
    • [C-SR] É ALTAMENTE RECOMENDADO ter uma largura de banda de medição de 3 dB de pelo menos 80% da frequência de Nyquist e um espectro de ruído branco dentro dessa largura de banda.
    • DEVE ter uma caminhada aleatória de taxa menor que 0,001 °/s √Hz testada em temperatura ambiente.
    • DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 0,05 °/ s / °C.
    • PRECISA ter uma mudança de sensibilidade em relação à temperatura de ≤ 0,02% / °C.
    • DEVE ter uma não linearidade de linha de regressão ajustada de ≤ 0,2%.
    • PRECISA ter uma densidade de ruído de ≤ 0,007 °/s/√Hz.
    • DEVE ter um erro de calibragem menor que 0,002 rad/s na faixa de temperatura de 10 a 40 °C quando o dispositivo estiver parado.
    • DEVE ter sensibilidade a g menor que 0,1°/s/g.
    • PRECISA ter sensibilidade entre eixos < 4,0 % e variação de sensibilidade entre eixos < 0,3% na faixa de temperatura de operação do dispositivo.

  • [C-2-4] PRECISA ter um TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_GYROSCOPE.

  • [C-2-5] PRECISA ter um sensor TYPE_GEOMAGNETIC_FIELD que:

    • PRECISA ter um intervalo de medição entre pelo menos -900 e +900 μT.
    • PRECISA ter uma resolução de medição de pelo menos 5 LSB/uT.
    • Precisa ter uma frequência mínima de medição de 5 Hz ou menos.
    • PRECISA ter uma frequência máxima de medição de 50 Hz ou mais.
    • PRECISA ter um ruído de medição não superior a 0,5 uT.

  • [C-2-6] PRECISA ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_GEOMAGNETIC_FIELD e, além disso:

    • PRECISA implementar uma forma não ativada desse sensor com capacidade de buffer de pelo menos 600 eventos de sensor.
    • [C-SR] É ALTAMENTE RECOMENDADO ter um espectro de ruído branco de 1 Hz a pelo menos 10 Hz quando a taxa de relatório é de 50 Hz ou mais.

  • [C-2-7] PRECISA ter um sensor TYPE_PRESSURE que:

    • PRECISA ter um intervalo de medição entre pelo menos 300 e 1.100 hPa.
    • PRECISA ter uma resolução de medição de pelo menos 80 LSB/hPa.
    • Precisa ter uma frequência mínima de medição de 1 Hz ou menos.
    • PRECISA ter uma frequência máxima de medição de 10 Hz ou mais.
    • Precisa ter um ruído de medição não superior a 2 Pa/√Hz.
    • PRECISA implementar uma forma não wake-up desse sensor com capacidade de buffer de pelo menos 300 eventos de sensor.
    • PRECISA ter um consumo de energia em lote não pior que 2 mW.
  • [C-2-8] PRECISA ter um sensor de TYPE_GAME_ROTATION_VECTOR.
  • [C-2-9] PRECISA ter um sensor TYPE_SIGNIFICANT_MOTION que:
    • Precisa ter um consumo de energia não superior a 0,5 mW quando o dispositivo está parado e 1,5 mW quando ele está em movimento.
  • [C-2-10] PRECISA ter um sensor TYPE_STEP_DETECTOR que:
    • PRECISA implementar uma forma não wake-up desse sensor com capacidade de buffer de pelo menos 100 eventos de sensor.
    • Precisa ter um consumo de energia não superior a 0,5 mW quando o dispositivo está parado e 1,5 mW quando ele está em movimento.
    • PRECISA ter um consumo de energia em lote não pior que 4 mW.
  • [C-2-11] PRECISA ter um sensor TYPE_STEP_COUNTER que:
    • Precisa ter um consumo de energia não superior a 0,5 mW quando o dispositivo está parado e 1,5 mW quando ele está em movimento.
  • [C-2-12] PRECISA ter um sensor TILT_DETECTOR que:
    • Precisa ter um consumo de energia não superior a 0,5 mW quando o dispositivo está parado e 1,5 mW quando ele está 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 dentro de 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 dentro de 0,25 milissegundos um do outro.
  • [C-2-14] PRECISA ter carimbos de data/hora de eventos do sensor de giroscópio na mesma base de tempo que o subsistema de câmera e com um erro de 1 milissegundo.
  • [C-2-15] PRECISA entregar amostras aos aplicativos em até 5 milissegundos a partir do momento em que os dados ficam disponíveis em qualquer um dos sensores físicos acima.
  • [C-2-16] NÃO PODE ter um consumo de energia maior que 0,5 mW quando o dispositivo está parado e 2,0 mW quando o dispositivo está em movimento com qualquer combinação dos seguintes sensores ativados:
    • 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 tiver, PRECISA ter uma capacidade mínima de buffer de 100 eventos de sensor.

Todos os requisitos de consumo de energia nesta seção não incluem o consumo de energia do processador de aplicativos. Isso inclui a energia consumida por toda a cadeia de sensores: o sensor, qualquer circuito de suporte, qualquer sistema dedicado de processamento de sensores etc.

Se as implementações de dispositivos incluírem suporte direto a sensores, elas:

  • [C-3-1] É OBRIGATÓRIO declarar corretamente o suporte a tipos de canais diretos e níveis de taxas de denúncia direta usando 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 a esse tipo de canal.
  • DEVE oferecer suporte a relatórios de eventos pelo canal direto do sensor para o sensor principal (variante não de 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 Fortes, Fracos ou de Conveniência com base nas taxas de aceitação de falsificação e impostor 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, se quiserem ser classificados como Fraco ou Forte. As biometrias fracas e fortes recebem recursos adicionais, conforme detalhado abaixo.

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

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

Para permitir o acesso a chaves do keystore a aplicativos de terceiros, 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 pareado com uma ação de confirmação explícita (por exemplo, pressionar um botão) se essa biometria forte for passiva (por exemplo, rosto ou íris, em que não há um sinal explícito da intenção do usuário).
    • [C-SR] É ALTAMENTE RECOMENDADO que a ação de confirmação para biometria passiva seja protegida para que uma violação do sistema operacional ou do kernel não possa falsificá-la. Por exemplo, isso significa que a ação de confirmação baseada em um botão físico é encaminhada por um pino de entrada/saída (GPIO) de uso geral somente de entrada de um elemento seguro (SE) que não pode ser acionado por nenhum outro meio além de um pressionamento de botão físico.

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

  • [C-1-1] PRECISA ter uma taxa de aceitação falsa menor que 0,002%.
  • [C-1-2] É OBRIGATÓRIO informar que esse modo pode ser menos seguro do que um PIN, um padrão ou uma senha fortes e enumerar claramente os riscos de ativá-lo, se as taxas de aceitação de falsificação e impostor forem superiores a 7%.
  • [C-1-3] É OBRIGATÓRIO limitar a taxa de tentativas por pelo menos 30 segundos após cinco tentativas falsas de verificação biométrica. Uma tentativa falsa é aquela com uma qualidade de captura adequada (BIOMETRIC_ACQUIRED_GOOD) que não corresponde a uma biometria registrada.
  • [C-1-4] É OBRIGATÓRIO impedir a adição de novas biometrias sem primeiro estabelecer uma cadeia de confiança. Para isso, o usuário precisa confirmar as credenciais de dispositivo (PIN/padrão/senha) atuais ou adicionar uma nova protegida pelo TEE. A implementação do Projeto de código aberto do Android fornece o mecanismo no framework para fazer isso.
  • [C-1-5] É OBRIGATÓRIO remover completamente todos os dados biométricos identificáveis de um usuário quando a conta dele é removida (inclusive por uma redefinição de fábrica).
  • [C-1-6] PRECISA respeitar a flag individual para essa biometria (ou seja, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT , DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
  • [C-1-7] DEVE desafiar o usuário para a autenticação primária recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 24 horas ou menos para novos dispositivos lançados com a versão 10 do Android e uma vez a cada 72 horas ou menos para dispositivos que fizeram upgrade de uma versão anterior do Android.

  • [C-1-8] PRECISA desafiar o usuário para a autenticação principal recomendada (por exemplo, PIN, padrão, senha) após uma das seguintes situações:

    • Um período de tempo limite de inatividade de 4 horas OU
    • Três tentativas de autenticação biométrica falharam.
    • O período de tempo limite de inatividade e a contagem de autenticações com falha são redefinidos após qualquer confirmação bem-sucedida das credenciais do dispositivo.

    O upgrade de dispositivos de uma versão anterior do Android pode ser isento da C-1-8.

  • [C-SR] É ALTAMENTE RECOMENDADO que tenham uma taxa de rejeição falsa menor que 10%, medida no dispositivo.

  • [C-SR] É ALTAMENTE RECOMENDADO que tenham uma latência abaixo de 1 segundo, medida desde a detecção da biometria até o desbloqueio da tela, para cada biometria registrada.

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

  • [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 spoofing e impostores não superior a 20%.
  • [C-2-3] PRECISA ter uma implementação de keystore com suporte de hardware e realizar a correspondência biométrica em um ambiente de execução isolado fora do espaço do usuário ou do kernel do Android, como o ambiente de execução confiável (TEE) ou em um chip com um canal seguro para o ambiente de execução isolado.
  • [C-2-4] PRECISA ter todos os dados identificáveis criptografados e autenticados criptograficamente para que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução isolado ou de um chip com um canal seguro para o ambiente de execução isolado, conforme documentado nas diretrizes de implementação no site do projeto de código aberto do Android.
  • [C-2-5] Para biometria baseada em câmera, enquanto a autenticação ou o registro biométrico está em andamento:
    • É NECESSÁRIO operar a câmera em um modo que impeça a leitura ou alteração de 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 oferecer suporte a operações como visualização prévia para inscrição, mas NÃO PODEM ser alterados.
  • [C-2-6] NÃO PODE permitir que aplicativos de terceiros distingam entre registros biométricos individuais.
  • [C-2-7] NÃO PODE permitir acesso não criptografado a dados biométricos identificáveis ou a dados derivados deles (como incorporações) ao processador de aplicativos fora do contexto do TEE.

  • [C-2-8] PRECISA ter um pipeline de processamento seguro para que uma violação 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 atenderem ao requisito C-2-8 por uma atualização de software do sistema, elas PODERÃO ser isentas do requisito.

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

  • [C-3-1] PRECISA atender a todos os requisitos de Fraco acima. O upgrade de dispositivos de uma versão anterior do Android não está isento da C-2-7.
  • [C-3-2] PRECISA ter uma taxa de aceitação de falsificação e imitação não superior a 7%.
  • [C-3-3] DEVE desafiar o usuário para a autenticação principal recomendada (por exemplo, PIN, padrão, senha) uma vez a cada 72 horas ou menos.

7.3.12. Sensor de postura

Implementações de dispositivos:

  • PODE oferecer suporte a sensor de postura com seis graus de liberdade.

Se as implementações de dispositivos forem compatíveis com o sensor de postura com 6 graus de liberdade, elas:

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

7.4. Conectividade de dados

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android e neste documento, se refere especificamente ao hardware relacionado a fazer chamadas de voz e enviar mensagens SMS por uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ser comutada por pacotes, para fins do Android, elas são consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade e as APIs de "telefonia" do Android se referem especificamente a chamadas de voz e SMS. Por exemplo, implementações de dispositivos que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas dispositivos de telefonia, mesmo que usem uma rede celular para conectividade de dados.

  • O Android PODE ser usado em dispositivos que não incluem hardware de telefonia. Ou seja, o Android é compatível com dispositivos que não são smartphones.

Se as implementações de dispositivos incluírem telefonia GSM ou CDMA, elas:

  • [C-1-1] PRECISA declarar a flag de recurso android.hardware.telephony e outras flags de sub-recursos de acordo com a tecnologia.
  • [C-1-2] PRECISA implementar suporte total à 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 no-ops.

Se as implementações de dispositivos forem compatíveis com eUICCs ou eSIMs/chips SIM incorporados e incluírem um mecanismo proprietário para disponibilizar a funcionalidade de eSIM para desenvolvedores terceirizados, elas:

7.4.1.1. Compatibilidade do bloqueio de números

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

  • [C-1-1] PRECISA incluir suporte ao bloqueio de números
  • [C-1-2] PRECISA implementar totalmente 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 qualquer 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 PODE gravar no provedor de telefonia para uma mensagem bloqueada.
  • [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 vejam ou editem os números bloqueados no dispositivo, já que a plataforma Android pressupõe que o usuário principal tem controle total dos serviços de telefonia, uma única instância, no dispositivo. Toda a interface relacionada ao bloqueio PRECISA ser ocultada para usuários secundários, e a lista de bloqueados PRECISA ser respeitada.
  • DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.
7.4.1.2. API Telecom

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

  • [C-1-1] PRECISA oferecer suporte às APIs ConnectionService descritas no SDK.
  • [C-1-2] DEVE mostrar uma nova chamada recebida e oferecer ao usuário a opção de aceitar ou rejeitar a chamada quando ele estiver em uma ligação feita por um app de terceiros que não oferece suporte ao recurso de espera especificado via CAPABILITY_SUPPORT_HOLD.
  • [C-1-3] PRECISA ter um aplicativo que implemente InCallService.

  • [C-SR] É ALTAMENTE RECOMENDADO notificar o usuário de que atender uma chamada recebida vai encerrar uma chamada em andamento.

    A implementação do AOSP atende a esses requisitos com uma notificação de alerta que indica ao usuário que atender uma chamada recebida vai fazer com que a outra seja encerrada.

  • [C-SR] É ALTAMENTE RECOMENDADO pré-carregar o app discador padrão que mostra uma entrada do registro de chamadas e o nome de um app de terceiros no registro de chamadas quando o app de terceiros define a chave de extras EXTRA_LOG_SELF_MANAGED_CALLS no PhoneAccount como true.

  • [C-SR] É ALTAMENTE RECOMENDADO processar os eventos KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK do fone de ouvido de áudio para as APIs android.telecom da seguinte maneira:

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 expuserem a funcionalidade a um aplicativo de terceiros, elas:

  • [C-1-1] É necessário implementar a API Android correspondente.
  • [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.wifi.
  • [C-1-3] É obrigatório implementar a API multicast conforme descrito na documentação do SDK.
  • [C-1-4] DEVE oferecer suporte a multicast DNS (mDNS) e NÃO DEVE filtrar pacotes mDNS (224.0.0.251) em nenhum momento da operação, incluindo:
    • Mesmo quando a tela não está ativa.
    • Para implementações de dispositivos de televisão Android, mesmo em estados de energia em espera.
  • [C-1-5] NÃO DEVE tratar a chamada do método da API WifiManager.enableNetwork() como uma indicação suficiente para alternar o Network ativo 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 validarem que a rede Wi-Fi está fornecendo acesso à Internet.
  • [C-1-6] É FORTEMENTE RECOMENDADO que, quando o método da API ConnectivityManager.reportNetworkConnectivity() for chamado, reavalie o acesso à Internet no Network e, assim que a avaliação determinar que o Network atual não oferece mais acesso à Internet, mude para qualquer outra rede disponível (por exemplo, dados móveis) que ofereça acesso à Internet.
  • [C-SR] É ALTAMENTE RECOMENDADO randomizar o endereço MAC de origem e o número de sequência dos frames de solicitação de sondagem, uma vez no início de cada verificação, enquanto a STA está desconectada.
    • Cada grupo de frames de solicitação de sondagem que compreende uma verificação DEVE usar um endereço MAC consistente (NÃO DEVE aleatorizar o endereço MAC no meio de uma verificação).
    • O número de sequência da solicitação de sondagem PRECISA iterar normalmente (em sequência) 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 sondagem de uma verificação e a primeira solicitação de sondagem da próxima verificação.
  • [C-SR] SÃO FORTEMENTE RECOMENDADOS, enquanto a STA está desconectada, para permitir apenas os seguintes elementos em frames de solicitação de sondagem:
    • Conjunto de parâmetros de SSID (0)
    • Conjunto de parâmetros do DS (3)

Se as implementações de dispositivos incluírem suporte ao modo de economia de energia do Wi-Fi, conforme definido no padrão IEEE 802.11, elas:

  • [C-3-1] É OBRIGATÓRIO desativar o modo de economia de energia do Wi-Fi sempre que um app adquirir um bloqueio WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY pelas APIs WifiManager.createWifiLock() e WifiManager.WifiLock.acquire() e o bloqueio estiver ativo.
  • [C-3-2] A latência média de ida e volta entre o dispositivo e um ponto de acesso enquanto o dispositivo está no modo de bloqueio de baixa latência do Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) PRECISA ser menor do que a latência durante o modo de bloqueio de alta performance do Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
  • [C-SR] SÃO FORTEMENTE RECOMENDADOS 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) é adquirido e entra em vigor.

Se as implementações de dispositivos forem compatíveis com Wi-Fi e usarem Wi-Fi para a busca de localização, elas:

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 incluírem suporte para Wi-Fi Direct, elas:

  • [C-1-1] É OBRIGATÓRIO 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 oferecer suporte à operação normal de Wi-Fi.
  • [C-1-4] PRECISA oferecer suporte a operações simultâneas de Wi-Fi e Wi-Fi Direct.

Implementações de dispositivos:

Se as implementações de dispositivos incluírem suporte para TDLS e o TDLS for ativado pela API WiFiManager, elas:

  • [C-1-1] É OBRIGATÓRIO declarar suporte para TDLS usando WifiManager.isTdlsSupported.
  • USE TDLS somente quando for possível E benéfico.
  • DEVE ter alguma heurística e NÃO usar TDLS quando o desempenho dele for pior do que passar pelo ponto de acesso Wi-Fi.
7.4.2.3. Wi-Fi Aware

Implementações de dispositivos:

Se as implementações de dispositivos incluírem suporte ao Wi-Fi Aware e expuserem 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 a operações simultâneas de Wi-Fi e Wi-Fi Aware.
  • [C-1-4] É OBRIGATÓRIO randomizar o endereço da interface de gerenciamento do Wi-Fi Aware em intervalos de no máximo 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 por Wi-Fi, conforme descrito na Seção 7.4.2.5, e expuserem essas funcionalidades a apps de terceiros, elas:

7.4.2.4. Passpoint do Wi-Fi

Implementações de dispositivos:

Se as implementações de dispositivos incluírem suporte para o Wi-Fi Passpoint, elas:

  • [C-1-1] É OBRIGATÓRIO 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 serviço de publicidade genérico (GAS) e o protocolo de consulta de rede de acesso (ANQP).

Por outro lado, se as implementações de dispositivos não incluírem suporte ao Wi-Fi Passpoint:

  • [C-2-1] A implementação das APIs WifiManager relacionadas ao Passpoint PRECISA gerar uma UnsupportedOperationException.
7.4.2.5. Localização de Wi-Fi (tempo de retorno do Wi-Fi - RTT)

Implementações de dispositivos:

Se as implementações de dispositivos incluírem suporte para localização por Wi-Fi e expuserem 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] É OBRIGATÓRIO escolher o endereço MAC de origem de forma aleatória para cada sequência de RTT executada 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. Descarga de sinal de atividade do Wi-Fi

Implementações de dispositivos:

  • DEVE incluir suporte para o descarregamento de keepalive do Wi-Fi.

Se as implementações de dispositivos incluírem suporte para o descarregamento de keepalive do Wi-Fi e expuserem 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 keepalive simultâneos por Wi-Fi e pelo menos um slot de keepalive por rede celular.

Se as implementações de dispositivos não incluírem suporte para o descarregamento de keepalive do Wi-Fi, elas:

7.4.2.7. Wi-Fi Easy Connect (protocolo de provisionamento de dispositivo)

Implementações de dispositivos:

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

7.4.3. Bluetooth

Se as implementações de dispositivos forem compatíveis com o 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:

  • PRECISA ser compatível com pelo menos cinco dispositivos conectados.

Se as implementações de dispositivos declararem o recurso android.hardware.vr.high_performance, elas:

  • [C-1-1] DEVE ser compatível com 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 de baixa energia, elas:

  • [C-2-1] É OBRIGATÓRIO declarar os recursos relevantes da plataforma (android.hardware.bluetooth e android.hardware.bluetooth_le, respectivamente) e implementar as APIs da plataforma.
  • DEVE implementar perfis Bluetooth relevantes, como A2DP, AVRCP, OBEX, HFP etc., conforme apropriado para o dispositivo.

Se as implementações de dispositivos incluírem suporte para Bluetooth de baixa energia, elas:

  • [C-3-1] PRECISA declarar o recurso de hardware android.hardware.bluetooth_le.
  • [C-3-2] É OBRIGATÓRIO ativar as APIs Bluetooth baseadas em GATT (perfil de atributo genérico) conforme descrito na documentação do SDK e em android.bluetooth.
  • [C-3-3] É OBRIGATÓRIO informar o valor correto para BluetoothAdapter.isOffloadedFilteringSupported() para indicar se a lógica de filtragem das classes da API ScanFilter está implementada.
  • [C-3-4] É OBRIGATÓRIO informar o valor correto para BluetoothAdapter.isMultipleAdvertisementSupported() e 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.
  • PRECISA oferecer suporte ao descarregamento da verificação em lote para o chipset Bluetooth.

  • DEVE oferecer suporte a vários anúncios com pelo menos quatro espaços.

  • [SR] É ALTAMENTE RECOMENDADO implementar um tempo limite de endereço particular resolúvel (RPA, na sigla em inglês) de no máximo 15 minutos e alternar o endereço no tempo limite para proteger a privacidade do usuário.

Se as implementações de dispositivos forem compatíveis com Bluetooth LE e usarem esse recurso para a verificação de localização, elas:

  • [C-4-1] PRECISA oferecer uma opção para o usuário ativar/desativar a leitura de valores pela API do sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Se as implementações de dispositivos incluírem suporte para Bluetooth LE e perfil de aparelhos auditivos, conforme descrito em Suporte para áudio de aparelho auditivo usando Bluetooth LE, elas:

7.4.4. Comunicação a curta distância

Implementações de dispositivos:

  • DEVE incluir um transceptor e hardware relacionado para comunicação a curta distância (NFC).
  • [C-0-1] É OBRIGATÓRIO implementar as APIs android.nfc.NdefMessage e android.nfc.NdefRecord, mesmo que elas não incluam suporte para 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 planejarem 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:
  • [C-1-2] PRECISA ser capaz de atuar como um leitor/gravador do NFC Forum (conforme definido pela especificação técnica do NFC Forum NFCForum-TS-DigitalProtocol-1.0) usando os seguintes padrões de NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Tipos de tags 1, 2, 3, 4 e 5 do fórum NFC (definidos pelo fórum NFC)

  • [SR] É ALTAMENTE RECOMENDADO que o dispositivo seja capaz de ler e gravar mensagens NDEF, bem como dados brutos, usando os seguintes padrões NFC. Embora os padrões de NFC sejam definidos como FORTEMENTE RECOMENDADOS, a Definição de compatibilidade para uma versão futura planeja mudar isso para OBRIGATÓRIO. Esses padrões são opcionais nesta versão, mas serão obrigatórios em versões futuras. É MUITO RECOMENDADO que os dispositivos atuais e novos que executam essa versão do Android atendam a esses requisitos agora para que possam fazer upgrade para as versões futuras da plataforma.

  • [C-1-13] É OBRIGATÓRIO pesquisar todas as tecnologias compatíveis no modo de descoberta por NFC.

  • PRECISA estar no modo de descoberta NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.
  • PRECISA ser capaz de ler o código de barras e o URL (se codificado) dos produtos Thinfilm NFC Barcode.

Os links disponíveis publicamente não estão disponíveis para as especificações do JIS, ISO e NFC Forum citadas acima.

O Android inclui suporte ao modo de emulação de cartão host (HCE) do NFC.

Se as implementações de dispositivos incluírem um chipset de controlador NFC compatível com HCE (para NfcA e/ou NfcB) e forem compatíveis com o roteamento de ID do aplicativo (AID), elas:

  • [C-2-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.nfc.hce.
  • [C-2-2] DEVE oferecer suporte às APIs NFC HCE, conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem um chipset de controlador NFC compatível com 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 Android correspondentes, conforme documentado pelo SDK Android.
  • [C-4-2] PRECISA 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] É OBRIGATÓRIO incluir suporte para uma ou mais formas de rede de dados. Especificamente, as implementações de dispositivos precisam incluir suporte para pelo menos um padrão de dados capaz de 200 Kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem EDGE, HSPA, EV-DO, 802.11g, Ethernet e Bluetooth PAN.
  • 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 principal conexão de dados.
  • 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.
  • É NECESSÁRIO garantir que a comunicação IPv6 seja tão confiável quanto a IPv4. Por exemplo:
    • [C-0-4] DEVE manter a conectividade IPv6 no modo Doze.
    • [C-0-5] A limitação de taxa NÃO PODE fazer com que o dispositivo perca a conectividade IPv6 em nenhuma rede compatível com IPv6 que use tempos de vida de RA de pelo menos 180 segundos.
  • [C-0-6] DEVE fornecer aos aplicativos de terceiros conectividade IPv6 direta à rede quando conectados a uma rede IPv6, sem qualquer forma de tradução de endereço ou porta ocorrendo localmente no dispositivo. As APIs gerenciadas, como Socket#getLocalAddress ou Socket#getLocalPort, e as APIs do NDK, como getsockname() ou IPV6_PKTINFO, PRECISAM retornar o endereço IP e a porta usados para enviar e receber pacotes na rede.

O nível necessá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 em Ethernet.

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

  • DEVE oferecer suporte à operação IPv6 (somente IPv6 e possivelmente pilha dupla) em redes celulares.

Se as implementações de dispositivos forem compatíveis com mais de um tipo de rede (por exemplo, Wi-Fi e dados móveis), eles:

  • [C-3-1] PRECISA atender simultaneamente aos requisitos acima em cada rede quando o dispositivo está conectado a mais de um tipo de rede.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

  • [C-0-1] A configuração de sincronização automática principal precisa estar ativada por padrão para que o método getMasterSyncAutomatically() retorne "true".

7.4.7. Economia de dados

Se as implementações de dispositivos incluírem uma conexão tarifada, elas serão:

  • [SR] É MUITO RECOMENDADO fornecer o modo de economia de dados.

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

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

  • [C-2-1] MUST return the value RESTRICT_BACKGROUND_STATUS_DISABLED for ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] NÃO PODE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] PRECISA ter uma atividade que processe o intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mas PODE implementá-lo como uma operação nula.

7.4.8. Elementos de segurança

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

7.5. Cameras

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

  • [C-1-1] PRECISA declarar a flag de recurso android.hardware.camera.any.
  • [C-1-2] É NECESSÁRIO que um aplicativo possa alocar simultaneamente três bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo sensor de câmera de maior resolução no dispositivo, enquanto a câmera está aberta para fins de visualização básica e captura de fotos.
  • [C-1-3] PRECISA garantir que o app de câmera padrão pré-instalado que processa intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE seja responsável por remover a localização do usuário nos metadados da imagem antes de enviá-la ao app de recebimento quando ele não tem ACCESS_FINE_LOCATION.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera localizada no lado do dispositivo oposto à tela. Ou seja, ela captura imagens de cenas do lado oposto 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 as flags de recurso android.hardware.camera e android.hardware.camera.any.
  • [C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
  • DEVE ter foco automático de hardware ou software implementado no driver da câmera (transparente para o software de aplicativo).
  • PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
  • PODE incluir um flash.

Se a câmera tiver um flash:

  • [C-2-1] A lâmpada do flash NÃO PODE ser acesa enquanto uma instância android.hardware.Camera.PreviewCallback estiver registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha ativado explicitamente o flash ao ativar os atributos FLASH_MODE_AUTO ou FLASH_MODE_ON de um objeto Camera.Parameters. Essa restrição não se aplica ao app de câmera integrado do dispositivo, mas apenas a aplicativos de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

Uma câmera frontal é localizada no mesmo lado do dispositivo que a tela. Ou seja, é uma câmera normalmente usada para capturar a imagem do usuário, como em 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 as flags 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 e NÃO PODE 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 ele tiver solicitado explicitamente que a tela da câmera seja girada com uma chamada ao método android.hardware.Camera.setDisplayOrientation(). Por outro lado, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo quando o aplicativo atual não solicita explicitamente que a tela da câmera seja girada com uma chamada ao método android.hardware.Camera.setDisplayOrientation().
  • [C-1-5] NÃO PODE espelhar a imagem estática ou os fluxos de vídeo capturados finais retornados aos callbacks do aplicativo ou armazenados na mídia.
  • [C-1-6] PRECISA espelhar a imagem mostrada pela pós-visualização da mesma forma que o stream de imagens da prévia da câmera.
  • PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

Se as implementações de dispositivos puderem ser giradas pelo usuário (automaticamente por 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 não precisa estar sempre conectada.

Se as implementações de dispositivos incluírem suporte para 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 for conectada pela porta de host USB.
  • [C-1-3] PRECISA passar nos testes de CTS da câmera com um dispositivo de câmera externa física conectado. Os detalhes dos testes do CTS da câmera estão disponíveis em source.android.com.
  • DEVE oferecer suporte a compactações de vídeo, como MJPEG, para permitir a transferência de streams não codificados de alta qualidade (ou seja, streams de imagem brutos ou compactados de forma independente).
  • PODE oferecer suporte a várias câmeras.
  • PODE oferecer suporte à codificação de vídeo baseada em câmera.

Se a codificação de vídeo baseada em câmera for compatível:

  • [C-2-1] Um fluxo simultâneo não codificado / MJPEG (QVGA ou resolução maior) PRECISA estar acessível à implementação do dispositivo.

7.5.4. Comportamento da API Camera

O Android inclui dois pacotes de API para acessar a câmera. A API android.hardware.camera2 mais recente expõe o controle de câmera de nível mais baixo ao app, incluindo fluxos eficientes de streaming/fotos em sequência sem cópia 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 em apps. As implementações de dispositivos Android PRECISAM garantir o suporte contínuo da API, conforme descrito nesta seção e no SDK do Android.

Todos os recursos comuns entre a classe android.hardware.Camera descontinuada e o pacote android.hardware.camera2 mais recente precisam ter desempenho e qualidade equivalentes nas duas APIs. Por exemplo, com configurações equivalentes, a velocidade e a precisão do foco automático PRECISAM ser idênticas, e a qualidade das imagens capturadas PRECISA ser a mesma. Os recursos que dependem das diferentes semânticas das duas APIs não precisam ter velocidade ou qualidade correspondentes, mas DEVEM ser o mais parecidos 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] É obrigatório usar android.hardware.PixelFormat.YCbCr_420_SP para dados de prévia fornecidos a callbacks de aplicativos quando um aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] PRECISA estar no formato de codificação NV21 quando um aplicativo registra uma instância android.hardware.Camera.PreviewCallback e o sistema chama o método onPreviewFrame() e o formato de visualização é YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame(). Ou seja, NV21 PRECISA ser o padrão.
  • [C-0-3] DEVE oferecer suporte ao formato YV12 (indicado pela constante android.graphics.ImageFormat.YV12) para visualizações da câmera frontal e traseira em android.hardware.Camera. O codificador de vídeo de hardware e a câmera podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA oferecer suporte à 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 a capacidade REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE em android.request.availableCapabilities.
  • [C-0-5] AINDA É NECESSÁRIO 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 sem foco automático AINDA PRECISAM chamar todas as instâncias android.hardware.Camera.AutoFocusCallback registradas, mesmo que isso não tenha relevância para uma câmera sem foco automático. Isso também se aplica às câmeras frontais. Por exemplo, mesmo que a maioria delas não ofereça suporte ao foco automático, os callbacks da API AINDA PRECISAM ser "falsificados" conforme descrito.
  • [C-0-6] PRECISA reconhecer e respeitar cada nome de parâmetro definido como uma constante nas classes android.hardware.Camera.Parameters e android.hardware.camera2.CaptureRequest. Por outro lado, as implementações de dispositivos NÃO PODEM honrar ou reconhecer constantes de string transmitidas ao método android.hardware.Camera.setParameters() que não sejam aquelas documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos precisam oferecer suporte a todos os parâmetros padrão da câmera se o hardware permitir e não podem oferecer suporte a tipos de parâmetros personalizados da câmera. Por exemplo, as implementações de dispositivos que oferecem suporte à captura de imagens usando técnicas de High Dynamic Range (HDR) precisam ser compatíveis com o parâmetro de câmera Camera.SCENE_MODE_HDR.
  • [C-0-7] É OBRIGATÓRIO informar o nível adequado de suporte com a propriedade android.info.supportedHardwareLevel, conforme descrito no SDK do Android, e informar as flags de recursos do framework adequadas.
  • [C-0-8] Também precisa declarar os recursos individuais de câmera de android.hardware.camera2 usando a 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 a ela for compatível com o 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 da foto for adicionada à loja de mídia.
  • [C-0-10] PRECISA transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da imagem for adicionada à loja de mídia.
  • [C-0-11] PRECISA ter todas as câmeras acessíveis pela API android.hardware.Camera descontinuada também acessíveis pela API android.hardware.camera2.
  • [C-SR] Para dispositivos com várias câmeras RGB apontadas para a mesma direção, é ALTAMENTE RECOMENDADO oferecer suporte a um dispositivo de câmera lógica que liste a capacidade CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, consistindo em todas as câmeras RGB apontadas para essa direção como subdispositivos físicos.

Se as implementações de dispositivos fornecerem uma API de câmera proprietária para apps de terceiros, elas:

7.5.5. Orientação da câmera

Se as implementações de dispositivos tiverem uma câmera frontal ou traseira, elas:

  • [C-1-1] PRECISA estar orientado de forma que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é segurado na orientação paisagem, as câmeras precisam capturar imagens nessa orientação. Isso se aplica independente da orientação natural do dispositivo, ou seja, a dispositivos com orientação principal de paisagem e de retrato.

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos

Implementações de dispositivos:

  • [C-0-1] PRECISA incluir um gerenciador de downloads que os aplicativos PODEM usar para baixar arquivos de dados e PRECISA ser capaz de baixar arquivos individuais de pelo menos 100 MB para o local padrão de "cache".

7.6.2. Armazenamento compartilhado de aplicativos

Implementações de dispositivos:

  • [C-0-1] PRECISA oferecer armazenamento para ser compartilhado por aplicativos, também conhecido como "armazenamento externo compartilhado", "armazenamento compartilhado de aplicativos" ou pelo caminho do Linux "/sdcard" em que ele está montado.
  • [C-0-2] PRECISA ser configurado com o armazenamento compartilhado montado por padrão, ou seja, "pronto para uso", independente de o armazenamento ser implementado em um componente de armazenamento interno ou em uma mídia de armazenamento removível (por exemplo, slot de cartão Secure Digital).
  • [C-0-3] É OBRIGATÓRIO montar o armazenamento compartilhado do aplicativo diretamente no caminho do Linux sdcard ou incluir um link simbólico do Linux de sdcard para o ponto de montagem real.
  • [C-0-4] É OBRIGATÓRIO aplicar a permissão android.permission.WRITE_EXTERNAL_STORAGE nesse armazenamento compartilhado, conforme documentado no SDK.
  • [C-0-5] É OBRIGATÓRIO ativar o armazenamento isolado 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 29 da API, independente da API de destino do app.
    • quando o app tiver solicitado android:requestLegacyExternalStorage="true" no manifesto.
    • quando o app recebe a permissão android.permission.WRITE_MEDIA_STORAGE.
  • [C-0-6] É OBRIGATÓRIO garantir que os apps com armazenamento isolado ativado não tenham acesso direto do sistema de arquivos a arquivos fora dos diretórios específicos do aplicativo, conforme retornado pelos métodos da API Context, como Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() e Context.getObbDirs().
  • [C-0-7] É OBRIGATÓRIO editar metadados de localização, como tags Exif do GPS, armazenados em arquivos de mídia quando esses arquivos são acessados pelo MediaStore, exceto quando o app de chamada tem a permissão ACCESS_MEDIA_LOCATION.

As implementações de dispositivos PODEM atender aos requisitos acima usando uma das seguintes opções:

  • Armazenamento removível acessível ao usuário, como um slot para cartão Secure Digital (SD).
  • Uma parte do armazenamento interno (não removível) implementado no Android Open Source Project (AOSP).

Se as implementações de dispositivos usarem armazenamento removível para atender aos requisitos acima, elas:

  • [C-1-1] É OBRIGATÓRIO implementar uma interface do usuário de aviso em pop-up ou toast quando não houver um dispositivo de armazenamento inserido no slot.
  • [C-1-2] PRECISA incluir um dispositivo de armazenamento formatado em FAT (por exemplo, um cartão SD) ou mostrar na caixa e em outros materiais disponíveis no momento da compra que o dispositivo de armazenamento precisa ser comprado 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 de aplicativos.
  • PODE compartilhar o espaço de armazenamento com os dados particulares do aplicativo.

Se as implementações de dispositivos incluírem vários caminhos de armazenamento compartilhado (como um slot para cartão SD e armazenamento interno compartilhado), elas:

  • [C-2-1] SÓ PODE permitir que aplicativos Android pré-instalados e privilegiados com a permissão WRITE_MEDIA_STORAGE gravem no armazenamento externo secundário, exceto ao gravar nos diretórios específicos do pacote ou no URI retornado ao acionar a intent ACTION_OPEN_DOCUMENT_TREE.
  • [C-2-2] É OBRIGATÓRIO exigir que o acesso direto associado à permissão android.permission.WRITE_MEDIA_STORAGE seja concedido apenas a apps visíveis ao usuário quando a permissão android.permission.WRITE_EXTERNAL_STORAGE também for concedida.
  • [SR] É ALTAMENTE RECOMENDÁVEL que aplicativos 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 por android.permission.WRITE_MEDIA_STORAGE.

Se as implementações de dispositivos tiverem uma porta USB com suporte ao 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 pelo serviço de scanner de mídia do Android e android.provider.MediaStore.
  • PODE usar armazenamento em massa USB, mas DEVE usar o protocolo de transferência de mídia para atender a esse requisito.

Se as implementações de dispositivos tiverem uma porta USB com modo periférico USB e forem compatíveis com o protocolo de transferência de mídia, elas:

  • PRECISA ser compatível com o host MTP de referência do Android, o Android File Transfer.
  • DEVE informar uma classe de dispositivo USB de 0x00.
  • DEVE informar um nome de interface USB de "MTP".

7.6.3. Armazenamento adotável

Se o dispositivo for móvel, ao contrário de uma televisão, as implementações serão:

  • [SR] É ALTAMENTE RECOMENDADO implementar o armazenamento adaptável em um local estável de longo prazo, já que a desconexão acidental pode causar perda/corrupção de dados.

Se a porta do dispositivo de armazenamento removível estiver em um local estável de longo prazo, como dentro do compartimento da bateria ou outra capa de proteção, as implementações do dispositivo serão:

7.7. USB

Se as implementações de dispositivos tiverem uma porta USB, elas:

  • DEVE ser compatível com o modo periférico USB e o modo host USB.

7.7.1. Modo periférico USB

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

  • [C-1-1] A porta PRECISA ser conectável a um host USB com uma porta USB padrão tipo A ou tipo C.
  • [C-1-2] MUST report the correct value of iSerialNumber in USB standard device descriptor through android.os.Build.SERIAL.
  • [C-1-3] DEVE detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão de resistor Type-C e DEVE detectar mudanças no anúncio se eles forem compatíveis com USB Type-C.
  • [SR] A porta DEVE usar o formato micro-B, micro-AB ou USB tipo C. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
  • [SR] A porta precisa estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação da tela de software para todos os apps (incluindo a tela inicial), para que a tela seja renderizada corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
  • [SR] DEVE implementar suporte para extrair uma corrente de 1,5 A durante o chirp HS e o tráfego, conforme especificado na especificação de carregamento de bateria USB, revisão 1.2. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
  • [SR] É ALTAMENTE RECOMENDADO não oferecer suporte a métodos de carregamento proprietários que modifiquem a tensão do Vbus além dos níveis padrão ou alterem as funções de receptor/fonte, já que isso pode resultar em problemas de interoperabilidade com os carregadores ou dispositivos que oferecem suporte aos métodos padrão de USB Power Delivery. Embora isso seja chamado de "ALTAMENTE RECOMENDADO", em versões futuras do Android, podemos EXIGIR que todos os dispositivos tipo C sejam compatíveis com a interoperabilidade total com carregadores padrão tipo C.
  • [SR] É ALTAMENTE RECOMENDADO para oferecer suporte à transmissão de energia para troca de função de dados e energia quando eles são compatíveis com USB tipo C e modo host USB.
  • DEVE oferecer suporte ao Power Delivery para carregamento de alta tensão e 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 Android.

Se as implementações de dispositivos incluírem uma porta USB e implementarem a especificação AOA, elas:

  • [C-2-1] PRECISA declarar suporte ao recurso de hardware android.hardware.usb.accessory.
  • [C-2-2] A classe de armazenamento em massa USB PRECISA incluir a string "android" no final da string de descrição da interface iInterface do armazenamento em massa USB.

7.7.2. Modo de 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 DECLARAR suporte ao recurso de hardware android.hardware.usb.host.
  • [C-1-2] PRECISA implementar suporte para conectar periféricos USB padrão. Em outras palavras, PRECISA:
    • Ter uma porta tipo C no dispositivo ou vir com cabos que adaptam uma porta proprietária do dispositivo a uma porta USB tipo C padrão (dispositivo USB tipo C).
    • Ter um tipo A no dispositivo ou vir com cabos que adaptam uma porta proprietária no dispositivo a uma porta USB tipo A padrão.
    • Ter uma porta micro-AB no dispositivo, que DEVE ser enviada com um cabo que se adapta a uma porta tipo A padrão.
  • [C-1-3] NÃO PODE ser enviado com um adaptador que converte portas USB tipo A ou micro-AB em uma porta tipo C (receptáculo).
  • [C-SR] É ALTAMENTE 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, anunciando uma corrente de origem de pelo menos 1,5 A, conforme especificado na seção "Parâmetros de encerramento" da Especificação do conector e cabo USB-C, revisão 1.2 para conectores USB-C ou usando o intervalo de corrente de saída da porta de carregamento downstream(CDP), conforme especificado nas Especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
  • DEVE implementar e oferecer suporte aos padrões USB Type-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 USB HID.
  • [C-2-2] PRECISA oferecer suporte à detecção e ao mapeamento dos seguintes campos de dados de HID especificados nas Tabelas de uso de HID USB e na Solicitação de uso de comando de voz para as constantes KeyEvent, conforme abaixo:
    • Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
    • Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
    • Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Se as implementações 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] DEVE reconhecer qualquer dispositivo MTP (protocolo de transferência de mídia) conectado remotamente e disponibilizar o conteúdo dele usando as 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] É obrigatório implementar a funcionalidade de porta de função dupla, conforme definido pela especificação USB Type-C (seção 4.5.1.3.3).
  • [SR] É ALTAMENTE RECOMENDADO que ele seja compatível com DisplayPort, com taxas de dados USB SuperSpeed e com Power Delivery para troca de função de dados e energia.
  • [SR] É ALTAMENTE RECOMENDADO NÃO oferecer suporte ao modo acessório do adaptador de áudio, conforme descrito no Apêndice A da Especificação do conector e cabo USB Type-C, revisão 1.2 (em inglês).
  • DEVE implementar o modelo Try.* mais adequado ao formato do dispositivo. Por exemplo, um dispositivo portátil PRECISA implementar o modelo Try.SNK.

7.8. Áudio

7.8.1. Microfone

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

  • [C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.microphone.
  • [C-1-2] PRECISA atender aos requisitos de gravação de áudio na seção 5.4.
  • [C-1-3] PRECISA atender aos requisitos de latência de áudio na seção 5.6.
  • [SR] SÃO FORTEMENTE RECOMENDADOS 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] É OBRIGATÓRIO implementar a API de gravação de áudio pelo menos como no-ops, conforme a seção 7.

7.8.2. Saída de áudio

Se as implementações de dispositivos 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 um conector de áudio de 3,5 mm de 4 condutores ou uma porta de modo host USB usando a classe de áudio USB, eles:

  • [C-1-1] É OBRIGATÓRIO informar a constante de recurso android.hardware.audio.output.
  • [C-1-2] PRECISA atender aos requisitos de reprodução de áudio na seção 5.5.
  • [C-1-3] PRECISA atender aos requisitos de latência de áudio na seção 5.6.
  • [SR] É ALTAMENTE RECOMENDADO oferecer suporte à reprodução quase ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos não incluírem um alto-falante ou uma porta de saída de áudio, elas:

  • [C-2-1] NÃO PODE informar o recurso android.hardware.audio.output.
  • [C-2-2] É preciso implementar as APIs relacionadas à saída de áudio como no-ops, no mínimo.

Para os fins desta seção, uma "porta de saída" é uma interface física, como uma entrada para fone de ouvido de 3,5 mm, HDMI ou uma porta de modo host USB com classe de áudio USB. O suporte à saída de áudio por protocolos baseados em rádio, como Bluetooth, Wi-Fi ou rede celular, não se qualifica como inclusão de uma "porta de saída".

7.8.2.1. Portas de áudio analógicas

Para serem compatíveis com fones de ouvido e outros acessórios de áudio usando o conector 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ógicas, elas precisam:

  • [C-SR] É ALTAMENTE RECOMENDÁVEL incluir pelo menos uma das portas de áudio como um conector de áudio de 3,5 mm com quatro condutores.

Se as implementações de dispositivos tiverem um conector de áudio de 3,5 mm com quatro condutores, elas:

  • [C-1-1] PRECISA oferecer suporte à reprodução de áudio em fones de ouvido estéreo e fones de ouvido estéreo com microfone.
  • [C-1-2] PRECISA oferecer suporte a plugues de áudio TRRS com a ordem de pinagem da CTIA.
  • [C-1-3] PRECISA oferecer suporte à detecção e ao mapeamento para os keycodes dos três intervalos a seguir de impedância equivalente entre o microfone e os condutores de aterramento no conector de áudio:
    • 70 ohms ou menos: KEYCODE_HEADSETHOOK
    • 210-290 ohm: KEYCODE_VOLUME_UP
    • 360 a 680 ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] DEVE acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que todos os contatos do plugue estiverem tocando os segmentos relevantes do conector.
  • [C-1-5] PRECISA ser capaz de gerar pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohms.
  • [C-1-6] PRECISA ter uma tensão de polarização do microfone entre 1,8 V e 2,9 V.
  • [C-1-7] DEVE detectar e mapear para o keycode do seguinte intervalo de impedância equivalente entre o microfone e os condutores de aterramento no conector de áudio:
    • 110-180 ohm:KEYCODE_VOICE_ASSIST
  • [C-SR] SÃO FORTEMENTE RECOMENDADOS para oferecer suporte a plugues de áudio com a ordem de pinagem OMTP.
  • [C-SR] SÃO FORTEMENTE RECOMENDADOS para oferecer suporte à gravação de áudio com fones de ouvido estéreo com microfone.

Se as implementações de dispositivos tiverem um conector de áudio de 3,5 mm com quatro condutores e forem compatíveis com um microfone, além de transmitirem o android.intent.action.HEADSET_PLUG com o valor extra do microfone 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 de áudio digital

Para ser compatível com fones de ouvido e outros acessórios de áudio que usam conectores USB-C e implementam (classe de áudio USB) em todo o ecossistema Android, conforme definido na especificação de fones de ouvido USB do Android.

Consulte a seção 2.2.1 para requisitos específicos do dispositivo.

7.8.3. Quase ultrassom

O áudio quase ultrassônico está na banda de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

  • É OBRIGATÓRIO informar corretamente o suporte ao recurso de áudio quase ultrassônico usando a API AudioManager.getProperty da seguinte maneira:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND for "true", as fontes de áudio VOICE_RECOGNITION e UNPROCESSED PRECISAM atender aos seguintes requisitos:

  • [C-1-1] A resposta de potência média do microfone na banda de 18,5 kHz a 20 kHz NÃO PODE ser mais de 15 dB abaixo da resposta em 2 kHz.
  • [C-1-2] A relação sinal-ruído não ponderada do microfone em 18,5 kHz a 20 kHz para um tom de 19 kHz a -26 dBFS NÃO PODE 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 NÃO PODE ser inferior a 40 dB abaixo da resposta em 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 móveis, conforme definido por zero falhas medidas durante um teste de um minuto por caminho. Teste usando o [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "Automated Glitch Test".

O teste requer um dongle de loopback de áudio, usado diretamente em uma entrada de 3,5 mm e/ou em combinação com um adaptador USB-C para 3,5 mm. Todas as portas de saída de áudio DEVEM ser testadas.

No momento, o OboeTester oferece suporte a caminhos AAudio. Portanto, as seguintes combinações DEVEM ser testadas para falhas usando AAudio:

Modo de desempenho Compartilhamento Taxa de amostragem externa Em canais Out Chans
LOW_LATENCY EXCLUSIVOS NÃO ESPECIFICADO 1 2
LOW_LATENCY EXCLUSIVOS NÃO ESPECIFICADO 2 1
LOW_LATENCY COMPARTILHADO NÃO ESPECIFICADO 1 2
LOW_LATENCY COMPARTILHADO NÃO ESPECIFICADO 2 1
NENHUMA COMPARTILHADO 48000 1 2
NENHUMA COMPARTILHADO 48000 2 1
NENHUMA COMPARTILHADO 44100 1 2
NENHUMA COMPARTILHADO 44100 2 1
NENHUMA COMPARTILHADO 16000 1 2
NENHUMA COMPARTILHADO 16000 2 1

Um stream confiável PRECISA atender aos seguintes critérios de relação sinal-ruído (SNR) e distorção harmônica total (THD) para um senoide de 2.000 Hz.

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

7.9. Realidade virtual

O Android inclui APIs e recursos para criar aplicativos de "realidade virtual" (RV), incluindo experiências de RV móvel de alta qualidade. As implementações de dispositivos PRECISAM implementar corretamente essas APIs e comportamentos, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android inclui suporte ao modo VR, um recurso que processa a renderização estereoscópica de notificações e desativa os componentes monoculares da interface do sistema enquanto um aplicativo de RV está em foco.

7.9.2. Modo de realidade virtual: alto desempenho

Se as implementações de dispositivos forem compatíveis com o 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 performance 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] É OBRIGATÓRIO implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace e expor as extensões na lista de extensões EGL disponíveis.
  • [C-1-8] É OBRIGATÓRIO 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] É ALTAMENTE RECOMENDADO implementar GL_EXT_external_buffer, GL_EXT_EGL_image_array e expor as extensões na lista de extensões do GL disponíveis.
  • [C-SR] É ALTAMENTE RECOMENDÁVEL oferecer suporte ao Vulkan 1.1.
  • [C-SR] É ALTAMENTE RECOMENDADO implementar VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image e expor na lista de extensões Vulkan disponíveis.
  • [C-SR] É ALTAMENTE RECOMENDADO expor pelo menos uma família de filas do Vulkan em que flags contenha VK_QUEUE_GRAPHICS_BIT e VK_QUEUE_COMPUTE_BIT, e queueCount seja pelo menos 2.
  • [C-1-7] A GPU e a tela PRECISAM sincronizar o acesso ao buffer frontal compartilhado para que a renderização alternada de conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de tearing visíveis.
  • [C-1-9] É OBRIGATÓRIO implementar suporte para flags AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA e AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, conforme descrito no NDK.
  • [C-1-10] É OBRIGATÓRIO implementar suporte para AHardwareBuffers com qualquer combinação das flags de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para pelo menos os seguintes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR] É ALTAMENTE RECOMENDADO para oferecer suporte à alocação de AHardwareBuffers com mais de uma camada e flags e formatos especificados em C-1-10.
  • [C-1-11] DEVE oferecer suporte à decodificação H.264 de pelo menos 3840 x 2160 a 30 fps, compactado para uma média de 40 Mbps (equivalente a 4 instâncias de 1920 x 1080 a 30 fps-10 Mbps ou 2 instâncias de 1920 x 1080 a 60 fps-20 Mbps).
  • [C-1-12] PRECISA oferecer suporte a HEVC e VP9, PRECISA ser capaz de decodificar pelo menos 1920 x 1080 a 30 fps compactado para uma média de 10 Mbps e DEVE ser capaz de decodificar 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 instâncias de 1920 x 1080 a 30 fps-5 Mbps).
  • [C-1-13] PRECISA oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
  • [C-1-14] PRECISA ter uma tela incorporada, e a resolução PRECISA ser de pelo menos 1920 x 1080.
  • [C-SR] É ALTAMENTE RECOMENDADO que tenham uma resolução de tela de pelo menos 2560 x 1440.
  • [C-1-15] A tela PRECISA ser atualizada em pelo menos 60 Hz no modo VR.
  • [C-1-17] A tela PRECISA oferecer suporte a um modo de baixa persistência com persistência de ≤ 5 milissegundos, sendo a persistência definida como o tempo em que um pixel emite luz.
  • [C-1-18] PRECISA oferecer suporte ao Bluetooth 4.2 e à extensão de comprimento de dados do Bluetooth LE seção 7.4.3.
  • [C-1-19] PRECISA oferecer suporte e informar corretamente o Tipo de canal direto para todos os seguintes tipos de sensores padrão:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] É ALTAMENTE RECOMENDADO que eles ofereçam suporte ao tipo de canal direto TYPE_HARDWARE_BUFFER para todos os tipos de canal direto listados acima.
  • [C-1-21] PRECISA atender aos requisitos relacionados a giroscópio, acelerômetro e magnetômetro para android.hardware.hifi_sensors, conforme especificado na seção 7.3.9.
  • [C-SR] SÃO FORTEMENTE RECOMENDADOS para oferecer suporte ao recurso android.hardware.sensor.hifi_sensors.
  • [C-1-22] PRECISA ter latência de movimento de ponta a ponta para fóton não superior a 28 milissegundos.
  • [C-SR] É ALTAMENTE RECOMENDADO que tenham latência de movimento de ponta a ponta para fóton não superior a 20 milissegundos.
  • [C-1-23] PRECISA ter uma proporção de primeiro frame, que é a proporção entre o brilho dos pixels no primeiro frame após uma transição do preto para o branco e o brilho dos pixels brancos em estado constante, de pelo menos 85%.
  • [C-SR] É ALTAMENTE RECOMENDADO que tenham uma proporção de primeiro frame de pelo menos 90%.
  • PODE fornecer um núcleo exclusivo para o aplicativo em primeiro plano e PODE oferecer suporte à API Process.getExclusiveCores para retornar os números dos núcleos da CPU exclusivos para o aplicativo em primeiro plano principal.

Se o núcleo exclusivo for compatível, ele:

  • [C-2-1] NÃO PODE permitir que outros processos do espaço do usuário sejam executados nele (exceto drivers de dispositivo usados pelo aplicativo), mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

8. Desempenho e bateria

Alguns critérios mínimos de desempenho e energia são essenciais para a experiência do usuário e afetam as proposições básicas que os desenvolvedores têm ao criar um app.

8.1. Consistência da experiência do usuário

Uma interface do usuário suave pode ser fornecida ao usuário final se houver determinados requisitos mínimos para garantir uma taxa de frames e tempos de resposta consistentes para aplicativos e jogos. As implementações de dispositivos, dependendo do tipo de dispositivo, PODEM ter requisitos mensuráveis para a latência da interface do usuário e a troca de tarefas, conforme descrito na seção 2.

8.2. Desempenho de acesso de E/S de arquivos

Fornecer uma base 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 ajude no design do software. As implementações de dispositivos, dependendo do tipo, PODEM ter determinados requisitos descritos na seção 2 para as seguintes operações de leitura e gravação:

  • Desempenho de gravação sequencial. Medido gravando um arquivo de 256 MB usando um buffer de gravação de 10 MB.
  • Performance de gravação aleatória. Medido gravando um arquivo de 256 MB usando um buffer de gravação de 4 KB.
  • Performance de leitura sequencial. Medido pela leitura de um arquivo de 256 MB usando um buffer de gravação de 10 MB.
  • Desempenho de leitura aleatória. Medido pela 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 que estão incluídos no AOSP ou estender os recursos incluídos no AOSP, elas:

  • [C-1-1] NÃO PODE desviar da implementação do AOSP para os algoritmos de ativação, manutenção e despertar e o uso das configurações globais do sistema dos modos de economia de energia do App Standby e do Soneca.
  • [C-1-2] NÃO PODE desviar da implementação do AOSP para o uso de configurações globais no gerenciamento da limitação de tarefas, alarmes e rede para apps em cada bucket do modo de espera de apps.
  • [C-1-3] NÃO PODE desviar da implementação do AOSP para o número de buckets do App em espera usados para o recurso.
  • [C-1-4] PRECISA implementar os buckets do App em espera e o modo Soneca, conforme descrito em Gerenciamento de energia.
  • [C-1-5] PRECISA retornar true para PowerManager.isPowerSaveMode() quando o dispositivo estiver no modo de economia de energia.
  • [C-SR] É ALTAMENTE RECOMENDADO oferecer ao usuário a possibilidade de ativar e desativar o recurso de economia de bateria.
  • [C-SR] É ALTAMENTE RECOMENDADO oferecer ao usuário a capacidade de exibir todos os apps isentos dos modos de economia de energia App Standby e Doze.

Além dos modos de economia de energia, as implementações de dispositivos Android PODEM implementar qualquer um ou todos os quatro estados de energia em espera, conforme definido pela Interface avançada de energia e configuração (ACPI, na sigla em inglês).

Se as implementações de dispositivos implementarem estados de energia S4 conforme definido pela ACPI, elas:

  • [C-1-1] PRECISA entrar nesse estado somente depois que o usuário realizar uma ação explícita para colocar o dispositivo em um estado inativo (por exemplo, fechando uma tampa que faz parte fisicamente do dispositivo ou desligando um veículo ou uma televisão) e antes que o usuário reative o dispositivo (por exemplo, abrindo a tampa ou ligando o veículo ou a televisão novamente).

Se as implementações de dispositivos implementarem estados de energia S3 conforme definido pela ACPI, elas:

  • [C-2-1] PRECISA atender ao C-1-1 acima ou entrar no estado S3 somente quando aplicativos de terceiros não precisarem dos recursos do sistema (por exemplo, tela, CPU).

    Por outro lado, DEVE sair do estado S3 quando aplicativos de terceiros precisarem dos recursos do sistema, conforme descrito neste SDK.

    Por exemplo, enquanto os aplicativos de terceiros solicitam manter a tela ligada usando FLAG_KEEP_SCREEN_ON ou manter a CPU em execução usando PARTIAL_WAKE_LOCK, o dispositivo NÃO DEVE 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 usando o JobScheduler é acionada ou o Firebase Cloud Messaging é entregue a apps de terceiros, o dispositivo PRECISA sair do estado 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 sinais de despertar extensivos que acionam uma ativação desse estado.

8.4. Contabilização do consumo de energia

Uma contabilidade e um relatório mais precisos do consumo de energia oferecem ao desenvolvedor de apps incentivos e ferramentas para otimizar o padrão de uso de energia do aplicativo.

Implementações de dispositivos:

  • [SR] É ALTAMENTE RECOMENDADO fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto de código aberto do Android.
  • [SR] É ALTAMENTE RECOMENDADO informar todos os valores de consumo de energia em miliampères-hora (mAh).
  • [SR] É ALTAMENTE RECOMENDADO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
  • [SR] É ALTAMENTE RECOMENDADO disponibilizar esse uso de energia ao desenvolvedor do app usando o comando de shell adb shell dumpsys batterystats.
  • DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.

8.5. Performance consistente

O desempenho pode variar muito em apps de alto desempenho e longa duração, seja por causa de outros apps em execução em segundo plano ou da limitação da CPU devido a limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo for capaz, o aplicativo em primeiro plano principal possa solicitar que o sistema otimize a alocação dos recursos para lidar com essas variações.

Implementações de dispositivos:

Se as implementações de dispositivos informarem suporte ao modo performance sustentado, elas:

  • [C-1-1] PRECISA oferecer ao aplicativo em primeiro plano um nível consistente de performance por pelo menos 30 minutos, quando o app solicitar.
  • [C-1-2] PRECISA obedecer à 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 principal.

Se as implementações de dispositivos oferecerem suporte à reserva de um núcleo exclusivo para o aplicativo em primeiro plano principal, elas:

  • [C-2-1] MUST report through the Process.getExclusiveCores() API method the ID numbers of the exclusive cores that can be reserved by the top foreground application.
  • [C-2-2] NÃO PODE permitir processos de espaço do usuário, exceto os drivers de dispositivo usados pelo aplicativo para execução nos núcleos exclusivos, mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

Se as implementações de dispositivos não forem compatíveis com um núcleo exclusivo, elas:

9. Compatibilidade do modelo de segurança

Implementações de dispositivos:

  • [C-0-1] É OBRIGATÓRIO implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs da documentação para desenvolvedores Android.

  • [C-0-2] DEVE oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades. Especificamente, os dispositivos compatíveis PRECISAM oferecer suporte aos mecanismos de segurança descritos nas subseções a seguir.

9.1. Permissões

Implementações de dispositivos:

  • [C-0-1] PRECISA oferecer suporte ao modelo de permissões do Android, conforme definido na documentação para desenvolvedores 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 SÓ podem ser concedidas 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 permitidas para cada app nos arquivos do 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 permissões de execução. Aplicativos com targetSdkVersion > 22 solicitam permissões no momento da execução.

Implementações de dispositivos:

  • [C-0-3] PRECISA mostrar uma interface dedicada para o usuário decidir se concede as permissões de execução solicitadas e também fornecer uma interface para gerenciar essas permissões.
  • [C-0-4] É obrigatório ter uma e apenas uma implementação das duas interfaces de 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 tempo de execução estão associadas a um padrão de intent para o qual o aplicativo pré-instalado é definido como o 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 adequadamente protegido. Um agente de recuperação adequadamente protegido é definido como um agente de software no dispositivo que sincroniza com um armazenamento remoto fora do dispositivo, equipado com hardware seguro com proteção equivalente ou mais forte do que o descrito no Serviço Google Cloud Key Vault para evitar ataques de força bruta no fator de conhecimento da tela de bloqueio.

Implementações de dispositivos:

  • [C-0-7] PRECISA obedecer às propriedades de permissão de localização do Android quando um app solicita dados de localização ou atividade física usando a API padrão do Android ou um mecanismo proprietário. Esses dados incluem, entre outros:

    • Localização do dispositivo (por exemplo, latitude e longitude).
    • Informações que podem ser usadas para determinar ou estimar a localização do dispositivo (por exemplo, SSID, BSSID, ID da célula, buscas por Bluetooth ou localização da rede a que o dispositivo está conectado).
    • Atividade física do usuário ou classificação da atividade física.

Mais especificamente, implementações de dispositivos:

  • [C-0-8] É OBRIGATÓRIO obter o consentimento do usuário para permitir que um app acesse os dados de localização ou atividade física.
  • [C-0-9] PRECISA conceder uma permissão de execução SOMENTE ao app que tem permissão suficiente, conforme descrito no SDK. Por exemplo, TelephonyManager#getServiceState exige android.permission.ACCESS_FINE_LOCATION).

As permissões podem ser marcadas como restritas, alterando o comportamento delas.

  • [C-0-10] As permissões marcadas com a flag hardRestricted NÃO PODEM ser concedidas a um app, a menos que:

    • Um arquivo APK do app está na partição do sistema.
    • O usuário atribui a um app uma função associada às permissões hardRestricted.
    • O instalador concede a hardRestricted a um app.
    • Um app recebe a permissão hardRestricted em uma versão anterior do Android.

  • [C-0-11] Os apps que têm uma permissão softRestricted SÓ podem receber acesso limitado e NÃO podem ter acesso total até serem adicionados a uma lista de permissão, conforme descrito no SDK. O acesso total e limitado é definido para cada permissão softRestricted (por exemplo, WRITE_EXTERNAL_STORAGE e READ_EXTERNAL_STORAGE).

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

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

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

  • [C-1-1] AINDA PRECISA ter uma atividade que processe o padrão de intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mas PRECISA implementá-lo como uma operação nula, ou seja, ter um comportamento equivalente a quando o acesso do usuário é negado.

9.2. UID e isolamento de processos

Implementações de dispositivos:

  • [C-0-1] PRECISA oferecer suporte ao modelo de sandbox de aplicativos do Android, em que cada aplicativo é executado como um UID exclusivo no estilo Unix e em um processo separado.
  • [C-0-2] PRECISA oferecer suporte à execução de vários aplicativos como o mesmo ID de usuário do Linux, desde que os aplicativos estejam devidamente assinados e construídos, conforme definido na referência de segurança e permissões.

9.3. Permissões do sistema de arquivos

Implementações de dispositivos:

9.4. Ambientes de execução alternativos

As implementações de dispositivos PRECISAM manter a consistência do modelo de segurança e permissões do Android, mesmo que incluam ambientes de execução que executem aplicativos usando outro software ou tecnologia que não seja o formato executável Dalvik ou código nativo. Resumindo:

  • [C-0-1] Os runtimes alternativos PRECISAM ser aplicativos Android e obedecer ao modelo de segurança padrão do Android, conforme descrito em seção 9.

  • [C-0-2] Os runtimes alternativos NÃO PODEM receber acesso a recursos protegidos por permissões não solicitadas no arquivo AndroidManifest.xml do runtime pelo mecanismo <uses-permission>.

  • [C-0-3] Os runtimes alternativos NÃO PODEM permitir que os aplicativos usem recursos protegidos por permissões do Android restritas a aplicativos do sistema.

  • [C-0-4] Os runtimes alternativos PRECISAM obedecer ao modelo de sandbox do Android, e os aplicativos instalados usando um runtime alternativo NÃO PODEM reutilizar o sandbox de nenhum outro app instalado no dispositivo, exceto pelos mecanismos padrão do Android de ID de usuário compartilhado e certificado de assinatura.

  • [C-0-5] Os runtimes alternativos NÃO PODEM ser iniciados com, conceder ou receber acesso aos sandboxes correspondentes a outros aplicativos Android.

  • [C-0-6] Runtimes alternativos NÃO PODEM ser iniciados, receber ou conceder a outros aplicativos privilégios de superusuário (raiz) ou de qualquer outro ID de usuário.

  • [C-0-7] Quando os arquivos .apk de runtimes alternativos são incluídos na imagem do sistema de implementações de dispositivos, eles PRECISAM ser assinados com uma chave diferente da usada para assinar outros aplicativos incluídos nas implementações de dispositivos.

  • [C-0-8] Ao instalar aplicativos, os ambientes de execução alternativos PRECISAM obter o consentimento do usuário para as permissões do Android usadas pelo aplicativo.

  • [C-0-9] Quando um aplicativo precisa usar um recurso do dispositivo para o qual há uma permissão correspondente do Android (como câmera, GPS etc.), o 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 usando esse ambiente.

  • Os runtimes alternativos DEVEM instalar apps usando o PackageManager em sandboxes separados do Android (IDs de usuário do Linux etc.).

  • Tempos de execução alternativos PODEM fornecer um único sandbox do Android compartilhado por todos os aplicativos que usam o tempo de execução alternativo.

9.5. Suporte para vários usuários

O Android inclui suporte para vários usuários e oferece suporte para isolamento total do usuário.

  • As implementações de dispositivos PODEM, mas NÃO DEVEM ativar o uso de vários usuários se usarem mídia removível para armazenamento externo principal.

Se as implementações de dispositivos incluírem vários usuários, eles:

  • [C-1-1] PRECISA atender aos seguintes requisitos relacionados ao suporte multiusuário.
  • [C-1-2] DEVE, para cada usuário, implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs.
  • [C-1-3] PRECISA ter diretórios separados e isolados de armazenamento de aplicativos compartilhados (também conhecidos como /sdcard) para cada instância de usuário.
  • [C-1-4] PRECISA garantir que os aplicativos de propriedade de um determinado usuário e executados em nome dele não possam listar, ler ou gravar nos arquivos de propriedade de qualquer outro usuário, mesmo que os dados de ambos estejam armazenados no mesmo volume ou sistema de arquivos.
  • [C-1-5] É OBRIGATÓRIO criptografar o conteúdo do cartão SD quando o modo multiusuário estiver ativado usando uma chave armazenada apenas em mídia não removível acessível somente ao sistema se as implementações de dispositivos usarem mídia removível para as APIs de armazenamento externo. Como isso vai tornar a mídia ilegível para um PC host, as implementações de dispositivos precisarão mudar para MTP ou um sistema semelhante para fornecer aos PCs host acesso aos dados do usuário atual.

9.6. Aviso sobre 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 para um serviço registrado em uma operadora que pode gerar uma cobrança para o usuário.

Se as implementações de dispositivos declararem suporte para android.hardware.telephony, elas:

  • [C-1-1] DEVE alertar os usuários antes de enviar uma mensagem SMS para números identificados por expressões regulares definidas no arquivo /data/misc/sms/codes.xml do dispositivo. O projeto upstream Android Open Source Project oferece uma implementação que atende a esse requisito.

9.7. Recursos de segurança

As implementações de dispositivos PRECISAM garantir a conformidade com os recursos de segurança no kernel e na plataforma, conforme descrito abaixo.

O sandbox do Android inclui recursos que usam o sistema de controle de acesso obrigatório (MAC) do Security-Enhanced Linux (SELinux), o sandbox seccomp e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:

  • [C-0-1] DEVE manter a compatibilidade com aplicativos atuais, mesmo quando o SELinux ou outros recursos de segurança são implementados abaixo do framework do Android.
  • [C-0-2] NÃO PODE ter uma interface visível quando uma violação de segurança é detectada e bloqueada pelo recurso de segurança implementado abaixo da estrutura do Android, mas PODE ter uma interface visível quando uma violação de segurança não bloqueada resulta em uma exploração bem-sucedida.
  • [C-0-3] NÃO PODE tornar o SELinux ou qualquer outro recurso de segurança implementado abaixo da estrutura do Android configurável para o usuário ou desenvolvedor de apps.
  • [C-0-4] NÃO PODE permitir que um aplicativo que possa afetar outro aplicativo por uma API (como uma API Device Administration) configure uma política que quebre a compatibilidade.
  • [C-0-5] PRECISA dividir a estrutura de mídia em vários processos para que seja possível conceder acesso de forma mais restrita a cada processo, conforme descrito no site do Android Open Source Project.
  • [C-0-6] É OBRIGATÓRIO implementar um mecanismo de sandbox de aplicativos de kernel que permita a filtragem de chamadas de sistema usando uma política configurável de programas multithread. O Android Open Source Project upstream atende a esse requisito ao ativar o seccomp-BPF com sincronização de grupo de linhas de execução (TSYNC), conforme descrito na seção "Configuração do kernel" de source.android.com.

A integridade do kernel e os recursos de autoproteção são essenciais para a segurança do Android. Implementações de dispositivos:

  • [C-0-7] É OBRIGATÓRIO implementar mecanismos de proteção contra estouro de buffer de pilha do kernel. Exemplos desses mecanismos são CC_STACKPROTECTOR_REGULAR e CONFIG_CC_STACKPROTECTOR_STRONG.
  • [C-0-8] É OBRIGATÓRIO implementar proteções estritas de memória do kernel em que o código executável seja somente leitura, os dados somente leitura não sejam executáveis nem graváveis e os dados graváveis não sejam executáveis (por exemplo, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] É OBRIGATÓRIO implementar a verificação de limites de tamanho de objetos estáticos e dinâmicos de cópias entre o espaço do usuário e o espaço do kernel (por exemplo, CONFIG_HARDENED_USERCOPY) em dispositivos originalmente enviados com o nível 28 da API ou mais recente.
  • [C-0-10] NÃO PODE executar memória do espaço do usuário ao executar no modo kernel (por exemplo, PXN de hardware ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente enviados com o nível 28 da API ou mais recente.
  • [C-0-11] NÃO PODE ler ou gravar memória do espaço do usuário no kernel fora das APIs de acesso usercopy normais (por exemplo, PAN de hardware ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) em dispositivos originalmente enviados com o nível de API 28 ou mais recente.
  • [C-0-12] É OBRIGATÓRIO implementar o isolamento da tabela de páginas do kernel se o hardware for vulnerável à CVE-2017-5754 em todos os dispositivos originalmente enviados com API de nível 28 ou mais recente (por exemplo, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
  • [C-0-13] É OBRIGATÓRIO implementar a proteção contra previsão de ramificação se o hardware for vulnerável à CVE-2017-5715 em todos os dispositivos originalmente enviados com o nível 28 da API ou mais recente (por exemplo, CONFIG_HARDEN_BRANCH_PREDICTOR).
  • [SR] É ALTAMENTE RECOMENDADO manter os dados do kernel gravados apenas durante a inicialização marcados como somente leitura após a inicialização (por exemplo, __ro_after_init).

  • [C-SR] É ALTAMENTE RECOMENDADO randomizar o layout do código 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 via /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

  • [C-SR] É FORTEMENTE RECOMENDADO 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] É ALTAMENTE RECOMENDADO não desativar a integridade do fluxo de controle (CFI), a pilha de chamadas de sombra (SCS) ou a limpeza de estouro de números inteiros (IntSan) em componentes que têm esses recursos ativados.
  • [C-SR] É ALTAMENTE RECOMENDADO ativar CFI, SCS e IntSan para outros componentes do espaço do usuário sensíveis à 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 definir o SELinux como modo de restrição global.
  • [C-1-3] É OBRIGATÓRIO configurar todos os domínios no modo de aplicação. Nenhum domínio de modo permissivo é permitido, incluindo domínios específicos de um dispositivo/fornecedor.
  • [C-1-4] NÃO PODE modificar, omitir ou substituir as regras neverallow presentes na pasta system/sepolicy fornecida no Android Open Source Project (AOSP) upstream. Além disso, a política PRECISA ser compilada com todas as regras neverallow presentes, tanto para domínios SELinux do AOSP quanto para domínios específicos do dispositivo/fornecedor.
  • [C-1-5] PRECISA executar aplicativos de terceiros destinados ao nível 28 da API ou versões mais recentes em sandboxes SELinux por aplicativo com restrições SELinux por app no diretório de dados particulares de cada aplicativo.
  • DEVE manter a política padrão do SELinux fornecida na pasta system/sepolicy do projeto de código aberto Android upstream e adicionar a essa política apenas a 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 atenderem aos requisitos [C-1-1] e [C-1-5] com uma atualização de software do sistema, elas PODERÃO ser isentas desses requisitos.

Se as implementações de dispositivos usarem um kernel diferente do Linux, elas:

  • [C-2-1] MUST use a mandatory access control system that is equivalent to SELinux.

O Android contém vários recursos de defesa em profundidade que são essenciais para a segurança do dispositivo.

9.8. Privacidade

9.8.1. Histórico de uso

O Android armazena o histórico de escolhas do usuário e o gerencia com o UsageStatsManager.

Implementações de dispositivos:

  • [C-0-1] É OBRIGATÓRIO manter um período de retenção razoável desse histórico do usuário.
  • [SR] É ALTAMENTE RECOMENDADO manter o período de retenção de 14 dias, conforme configurado por padrão na implementação do AOSP.

O Android armazena os eventos do sistema usando os identificadores StatsLog e gerencia esse histórico com a StatsManager e a API IncidentManager do sistema.

Implementações de dispositivos:

  • [C-0-2] SÓ pode incluir os campos marcados com DEST_AUTOMATIC no relatório de incidente criado pela classe IncidentManager da API System.
  • [C-0-3] NÃO PODE usar os identificadores de eventos do sistema para registrar qualquer outro evento que não seja o descrito nos documentos do SDK StatsLog. Se outros eventos do sistema forem registrados, eles PODERÃO usar um identificador de átomo diferente no intervalo entre 100.000 e 200.000.

9.8.2. Gravando

Implementações de dispositivos:

  • [C-0-1] NÃO PODE pré-carregar nem distribuir componentes de software prontos para uso que enviem informações particulares do usuário (por exemplo, pressionamentos de teclas, texto exibido na tela, bugreport) do dispositivo sem o consentimento do usuário ou notificações claras e contínuas.

  • [C-0-2] É OBRIGATÓRIO mostrar e receber o consentimento explícito do usuário que inclua substancialmente a mesma mensagem do AOSP sempre que o espelhamento ou a gravação de tela forem ativados por MediaProjection ou APIs proprietárias. NÃO PODE oferecer aos usuários uma opção para desativar a exibição futura do consentimento do usuário.

  • [C-0-3] DEVE ter uma notificação contínua para o usuário enquanto o compartilhamento ou a gravação de tela estiver ativada. O AOSP atende a esse requisito mostrando um ícone de notificação em andamento na barra de status.

Se as implementações de dispositivos incluírem funcionalidades no sistema que capturem o conteúdo exibido na tela e/ou gravem o fluxo de áudio reproduzido no dispositivo de outra forma que não seja pela API do sistema ContentCaptureService ou por outros meios proprietários descritos na Seção 9.8.6 Captura de conteúdo, elas:

  • [C-1-1] PRECISA ter uma notificação em andamento para o usuário sempre que essa funcionalidade estiver ativada e capturando/gravando ativamente.

Se as implementações de dispositivos incluírem um componente ativado pronto para uso, capaz de gravar áudio ambiente e/ou gravar o áudio reproduzido no dispositivo para inferir informações úteis sobre o contexto do usuário, elas:

  • [C-2-1] NÃO PODE armazenar em armazenamento persistente no dispositivo nem transmitir para fora do dispositivo o áudio bruto gravado ou qualquer formato que possa ser convertido de volta no áudio original ou em um fac-símile próximo, exceto com consentimento explícito do usuário.

9.8.3. Conectividade

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

  • [C-1-1] PRECISA apresentar uma interface do usuário pedindo 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] É OBRIGATÓRIO pré-instalar os mesmos certificados raiz para o repositório de autoridade de certificação (CA) confiável do sistema, conforme fornecido no projeto de código aberto Android upstream.
  • [C-0-2] PRECISA ser enviado com um armazenamento de CA raiz do usuário vazio.
  • [C-0-3] DEVE mostrar um aviso ao usuário indicando que o tráfego de rede pode ser monitorado quando uma CA raiz do usuário é adicionada.

Se o tráfego do dispositivo for encaminhado por uma VPN, as implementações do dispositivo:

  • [C-1-1] DEVE mostrar um aviso ao usuário indicando uma das seguintes opções:
    • 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 por padrão, que roteia o tráfego de dados de rede por um servidor proxy ou gateway de VPN (por exemplo, pré-carregando um serviço de VPN com android.permission.CONTROL_VPN concedido), elas:

  • [C-2-1] É OBRIGATÓRIO pedir o consentimento do usuário antes de ativar esse mecanismo, a menos que a VPN seja ativada pelo Controlador de políticas do dispositivo usando o DevicePolicyManager.setAlwaysOnVpnPackage(). Nesse caso , o usuário não precisa dar um consentimento separado, mas precisa ser notificado.

Se as implementações de dispositivos implementarem uma facilidade para o usuário ativar/desativar a função "VPN sempre ativa" de um app de VPN de terceiros, elas:

  • [C-3-1] É OBRIGATÓRIO desativar essa facilidade para apps que não oferecem suporte ao serviço de VPN sempre ativa no arquivo AndroidManifest.xml definindo o atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON como false.

9.8.5. Identificadores de dispositivo

Implementações de dispositivos:

  • [C-0-1] DEVE impedir o acesso ao número de série do dispositivo e, quando aplicável, ao IMEI/MEID, ao número de série do SIM e à Identidade Internacional de Assinante Móvel (IMSI) de um app, a menos que ele atenda a um dos seguintes requisitos:
    • é um app da operadora assinado e verificado pelos fabricantes de dispositivos.
    • recebeu a permissão READ_PRIVILEGED_PHONE_STATE.
    • tem privilégios de operadora, conforme definido em Privilégios da operadora UICC.
    • é um proprietário do dispositivo ou do perfil que recebeu a permissão READ_PHONE_STATE.
    • (Somente para número de série do SIM/ICCID) tem o requisito das regulamentações locais de que o app detecte mudanças na identidade do assinante.

9.8.6. Captura de conteúdo

O Android, pela API do sistema ContentCaptureService ou por outros meios proprietários, oferece suporte a um mecanismo para que as implementações de dispositivos capturem as seguintes interações entre os aplicativos e o usuário.

  • Texto e gráficos renderizados na tela, incluindo, entre outros, notificações e dados de assistência pela API AssistStructure.
  • Dados de mídia, como áudio ou vídeo, gravados ou reproduzidos pelo dispositivo.
  • Eventos de entrada (por exemplo, tecla, mouse, gesto, voz, vídeo e acessibilidade).
  • Qualquer outro evento que um aplicativo forneça ao sistema usando a API Content Capture ou uma API proprietária com capacidade semelhante.

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 cifras listadas como versão 26 ou mais recente da API, conforme descrito em SDK de cifras.
  • [C-1-2] NÃO PODE fazer backup de dados brutos ou criptografados usando métodos de backup do Android ou qualquer outro método de backup.
  • [C-1-3] SÓ PODE enviar todos esses dados e o registro do dispositivo usando um mecanismo que preserve a privacidade. O mecanismo de preservação da privacidade é definido como "aqueles que permitem apenas a análise agregada e impedem a correspondência de eventos registrados ou resultados derivados a usuários individuais", para evitar que os dados por usuário sejam introspectáveis (por exemplo, implementados usando uma tecnologia de privacidade diferencial, como RAPPOR).
  • [C-1-4] NÃO PODE associar esses dados a nenhuma identidade de usuário (como Account) no dispositivo, exceto com o consentimento explícito do usuário a cada vez que os dados são associados.
  • [C-1-5] NÃO PODE compartilhar esses dados com outros apps, exceto com o consentimento explícito do usuário a cada compartilhamento.
  • [C-1-6] PRECISA oferecer ao usuário a possibilidade de apagar os dados coletados pela ContentCaptureService ou pelos meios proprietários se eles forem armazenados de alguma forma no dispositivo.

Se as implementações de dispositivos incluírem um serviço que implementa a API do sistema ContentCaptureService ou qualquer serviço proprietário 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 aplicativo ou serviço instalável pelo usuário e SÓ PODE permitir que o serviço pré-instalado capture esses dados.
  • [C-2-2] NÃO PODE permitir que outros apps, além do mecanismo de serviço de captura de conteúdo pré-instalado, capturem esses dados.
  • [C-2-3] PRECISA oferecer ao usuário a opção de desativar o serviço de captura de conteúdo.
  • [C-2-4] NÃO PODE omitir a capacidade do usuário de gerenciar as permissões do Android mantidas pelo serviço de captura de conteúdo e seguir o modelo de permissões do Android, conforme descrito na Seção 9.1. Permissão.

  • [C-SR] É ALTAMENTE RECOMENDADO manter os componentes do serviço de captura de conteúdo separados, por exemplo, não vinculando o serviço ou compartilhando IDs de processo, de outros componentes do sistema, exceto os seguintes:

    • 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 cortados na área de transferência (por exemplo, usando a API ClipboardManager) a menos que o app seja o IME padrão ou esteja em foco no momento.

9.8.8. Local

Implementações de dispositivos:

  • [C-0-1] NÃO PODE ativar/desativar a configuração de localização do dispositivo e as configurações de verificação de Wi-Fi/Bluetooth sem o consentimento explícito ou a ação do usuário.
  • [C-0-2] DEVE oferecer ao usuário a possibilidade de acessar informações relacionadas à localização, incluindo solicitações recentes de localização, permissões no nível do app e uso da verificação de Wi-Fi/Bluetooth para determinar a localização.
  • [C-0-3] PRECISA garantir que o aplicativo que usa a API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] seja uma sessão de emergência iniciada pelo usuário (por exemplo, ligar ou enviar uma mensagem de texto para o 190).
  • [C-0-4] É OBRIGATÓRIO preservar a capacidade da API Emergency Location Bypass de ignorar as configurações de localização do dispositivo sem alterá-las.
  • [C-0-5] PRECISA programar uma notificação que lembre 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 de armazenamento de dados

Todos os dispositivos PRECISAM atender aos requisitos da seção 9.9.1. Os dispositivos lançados em um nível 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 de API em que o dispositivo foi lançado.

9.9.1. Inicialização direta

Implementações de dispositivos:

  • [C-0-1] É OBRIGATÓRIO implementar as APIs do modo de inicialização direta, mesmo que elas não sejam compatíveis com a criptografia de armazenamento.

  • [C-0-2] As intents ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED AINDA precisam ser transmitidas para sinalizar aos aplicativos compatíveis com a inicialização direta que os locais de armazenamento criptografados pelo dispositivo (DE) e criptografados por credenciais (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] É OBRIGATÓRIO ativar a criptografia de armazenamento de dados por padrão quando o usuário concluir a experiência de configuração inicial.
  • [C-0-3] PRECISA atender ao requisito acima de criptografia de armazenamento de dados implementando a Criptografia baseada em arquivos (FBE, na sigla em inglês).

9.9.3. Criptografia baseada em arquivos

Dispositivos criptografados:

  • [C-1-1] DEVE inicializar sem pedir credenciais ao usuário e permitir que apps compatíveis com a inicialização direta acessem o armazenamento criptografado pelo dispositivo (DE) depois que a mensagem ACTION_LOCKED_BOOT_COMPLETED for transmitida.
  • [C-1-2] SÓ PODE permitir o acesso ao armazenamento criptografado por credenciais (CE) depois que o usuário desbloquear o dispositivo fornecendo as credenciais (por exemplo, senha, PIN, padrão ou impressão digital) e a mensagem ACTION_USER_UNLOCKED for transmitida.
  • [C-1-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 custódia registrada.
  • [C-1-4] PRECISA usar a inicialização verificada e garantir que as chaves de criptografia de disco estejam criptograficamente vinculadas à raiz de confiança de hardware do dispositivo.
  • [C-1-5] É OBRIGATÓRIO 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 tamanho de chave de criptografia de 256 bits, operado no modo XTS. O comprimento total da chave é de 512 bits. Adiantum se refere a Adiantum-XChaCha12-AES, conforme especificado em https://github.com/google/adiantum.
  • [C-1-6] É OBRIGATÓRIO criptografar nomes de arquivos usando AES-256-CBC-CTS ou Adiantum.

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

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

  • [C-1-7] PRECISA ser 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 de CE PRECISAM ser vinculadas a uma senha padrão quando o usuário não especifica credenciais de tela de bloqueio.
  • [C-1-10] PRECISA ser única e distinta. Em outras palavras, a chave CE ou DE de um usuário não pode corresponder à chave CE ou DE de outro usuário.
  • [C-1-11] MUST use the mandatorily supported ciphers, key lengths and modes.

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

  • DEVE fazer com que os apps essenciais pré-instalados (por exemplo, Alarme, Telefone, Messenger) sejam compatíveis com a inicialização direta.

O projeto upstream 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 a transparência do status da integridade do dispositivo. Implementações de dispositivos:

  • [C-0-1] DEVE informar corretamente pelo método PersistentDataBlockManager.getFlashLockState() da API System se o estado do carregador de inicialização permite a instalação da imagem do sistema. O estado FLASH_LOCK_UNKNOWN é reservado para implementações de dispositivos que estão fazendo upgrade de uma versão anterior do Android em que esse novo método da API do sistema não existia.

  • [C-0-2] PRECISA oferecer suporte à Inicialização verificada para integridade do dispositivo.

Se as implementações de dispositivos já tiverem sido lançadas sem suporte à Inicialização verificada em uma versão anterior do Android e não for possível adicionar suporte a esse recurso com uma atualização de software do sistema, elas PODERÃO 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] É OBRIGATÓRIO realizar a verificação em todas as sequências de inicialização.
  • [C-1-3] DEVE iniciar a verificação com uma chave de hardware imutável que seja a raiz de confiança e ir até a partição do sistema.
  • [C-1-4] PRECISA implementar cada etapa de verificação para conferir a integridade e a autenticidade de todos os bytes na próxima etapa antes de executar o código nela.
  • [C-1-5] PRECISA usar algoritmos de verificação tão fortes quanto as recomendações atuais do NIST para algoritmos de hash (SHA-256) e tamanhos de chave pública (RSA-2048).
  • [C-1-6] NÃO PODE permitir que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário concorde em tentar inicializar de qualquer maneira. Nesse caso, os dados de blocos de armazenamento não verificados NÃO PODEM ser usados.
  • [C-1-7] NÃO PODE permitir que partições verificadas no dispositivo sejam modificadas, a menos que o usuário tenha desbloqueado explicitamente o carregador de inicialização.
  • [C-SR] Se houver vários chips discretos no dispositivo (por exemplo, rádio, processador de imagem especializado), é ALTAMENTE RECOMENDADO que o processo de inicialização de cada um desses chips verifique todas as etapas ao inicializar.
  • [C-1-8] É obrigatório usar armazenamento inviolável para armazenar se o carregador de inicialização está desbloqueado. O armazenamento inviolável significa que o carregador de inicialização pode detectar se o armazenamento foi adulterado de dentro do Android.
  • [C-1-9] PRECISA solicitar ao usuário, enquanto ele usa o dispositivo, e exigir confirmação física antes de permitir uma transição do modo de carregador de inicialização bloqueado para o modo desbloqueado.
  • [C-1-10] É OBRIGATÓRIO implementar a proteção contra rollback para partições usadas pelo Android (por exemplo, partições de inicialização e do sistema) e usar armazenamento inviolável para armazenar os metadados usados para determinar a versão mínima permitida do SO.
  • [C-SR] É ALTAMENTE RECOMENDÁVEL verificar todos os arquivos APK de apps privilegiados com uma cadeia de confiança baseada em partições protegidas pela Inicialização verificada.
  • [C-SR] É ALTAMENTE RECOMENDADO verificar todos os artefatos executáveis carregados por um app privilegiado de fora do arquivo APK (como código carregado dinamicamente ou código compilado) antes de executá-los ou ALTAMENTE RECOMENDADO não executá-los.
  • É RECOMENDADO implementar a proteção contra rollback para qualquer componente com firmware persistente (por exemplo, modem, câmera) e usar armazenamento à prova de violação para armazenar os metadados usados para determinar a versão mínima permitida.

Se as implementações de dispositivos já tiverem sido lançadas sem suporte a C-1-8 a C-1-10 em uma versão anterior do Android e não for possível adicionar suporte a esses requisitos com uma atualização de software do sistema, elas PODERÃO ser isentas dos requisitos.

O Android Open Source Project upstream oferece uma implementação preferencial desse recurso no repositório external/avb/, que pode ser integrado ao carregador de inicialização usado para carregar o Android.

Implementações de dispositivos:

Se as implementações de dispositivos forem compatíveis com a API Android Protected Confirmation, elas:

  • [C-3-1] É OBRIGATÓRIO 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 interação do usuário.

  • [C-3-3] É NECESSÁRIO garantir que o usuário possa analisar e aprovar a mensagem solicitada, mesmo que o SO Android, incluindo o kernel, esteja comprometido.

9.11. Chaves e credenciais

O Android Keystore System permite que os desenvolvedores de apps armazenem chaves criptográficas em um contêiner e as usem em operações criptográficas pela API KeyChain ou pela API Keystore. Implementações de dispositivos:

  • [C-0-1] DEVE permitir a importação ou geração de pelo menos 8.192 chaves.
  • [C-0-2] A autenticação da tela de bloqueio PRECISA limitar a taxa de tentativas e PRECISA ter um algoritmo de espera exponencial. Após 150 tentativas com falha, o atraso PRECISA ser de pelo menos 24 horas por tentativa.
  • NÃO DEVE limitar o número de chaves que podem ser geradas

Quando a implementação do dispositivo oferece suporte a uma tela de bloqueio segura, ela:

  • [C-1-1] DEVE 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 MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos compatíveis com o sistema Android Keystore em uma área isolada com segurança do código em execução no kernel e acima. O isolamento seguro PRECISA bloquear todos os mecanismos potenciais pelos quais o kernel ou o código do espaço do usuário podem acessar o estado interno do ambiente isolado, incluindo 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] DEVE realizar a autenticação da tela de bloqueio no ambiente de execução isolado e permitir o uso das chaves vinculadas à autenticação somente quando ela for bem-sucedida. As credenciais da tela de bloqueio PRECISAM ser armazenadas de forma que apenas o ambiente de execução isolado possa fazer a autenticação da tela de bloqueio. O projeto de código aberto Android upstream fornece a camada de abstração de hardware (HAL) do 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 do atestado é protegida por hardware seguro e a assinatura é realizada em hardware seguro. As chaves de assinatura de atestado precisam ser compartilhadas em um número grande o suficiente de dispositivos para evitar que sejam usadas como identificadores de dispositivo. Uma maneira de atender a esse requisito é compartilhar a mesma chave de comprovação,a menos que pelo menos 100.000 unidades de um determinado SKU sejam produzidas. Se mais de 100.000 unidades de uma SKU forem produzidas, uma chave diferente PODE ser usada para cada 100.000 unidades.

Se uma implementação de dispositivo já tiver sido lançada em uma versão anterior do Android, ela será isenta da exigência de ter um keystore apoiado por um ambiente de execução isolado e de oferecer suporte à confirmação de chaves, a menos que declare o recurso android.hardware.fingerprint, que exige um keystore apoiado por um ambiente de execução isolado.

  • [C-1-5] DEVE permitir que o usuário escolha o tempo limite de suspensão para a transição do estado desbloqueado para o bloqueado, com um tempo limite mínimo permitido de até 15 segundos.

9.11.1. Tela de bloqueio e autenticação seguras

A implementação do AOSP segue um modelo de autenticação em camadas em que uma autenticação principal baseada em um fator de conhecimento pode ser respaldada por uma biometria secundária forte ou por modalidades terciárias mais fracas.

Implementações de dispositivos:

  • [C-SR] É ALTAMENTE RECOMENDADO definir apenas um dos seguintes como o método de autenticação principal:
    • Um PIN numérico
    • Uma senha alfanumérica
    • Um padrão de deslize em uma grade de exatamente 3x3 pontos

Os métodos de autenticação acima são chamados de métodos de autenticação primários recomendados neste documento.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação primários 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:

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio com base em um segredo conhecido e usarem um novo método de autenticação para ser tratado como uma maneira segura de bloquear a tela:

  • [C-3-1] A entropia do menor comprimento permitido de entradas PRECISA ser maior que 10 bits.
  • [C-3-2] A entropia máxima de todas as entradas possíveis PRECISA ser maior que 18 bits.
  • [C-3-3] O novo método de autenticação NÃO PODE substituir nenhum dos métodos de autenticação primários recomendados (ou seja, PIN, padrão, senha) implementados e fornecidos no AOSP.
  • [C-3-4] O novo método de autenticação PRECISA ser desativado quando o aplicativo controlador de política de dispositivo (DPC) tiver definido a política de qualidade de senha usando o método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_SOMETHING.
  • [C-3-5] Os novos métodos de autenticação precisam voltar aos métodos principais recomendados (ou seja, PIN, padrão, senha) a cada 72 horas ou menos OU informar claramente ao usuário que alguns dados não serão armazenados em backup para preservar a privacidade deles.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação primários recomendados para desbloquear a tela de bloqueio e usarem um novo método de autenticação baseado em biometria para ser tratado como uma maneira segura de bloquear a tela, o novo método:

  • [C-4-1] PRECISA atender a todos os requisitos descritos na seção 7.3.10 para Conveniência.
  • [C-4-2] PRECISA ter um mecanismo de substituição para usar um dos métodos de autenticação primária recomendados, que se baseia em um segredo conhecido.
  • [C-4-3] PRECISA ser desativado e permitir apenas a autenticação principal recomendada para desbloquear a tela quando o aplicativo controlador de políticas do dispositivo (DPC) tiver definido a política de recursos do keyguard chamando o método DevicePolicyManager.setKeyguardDisabledFeatures() com qualquer uma das flags biométricas associadas (ou seja, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Se os métodos de autenticação biométrica não atenderem aos requisitos de Forte, conforme descrito na seção 7.3.10:

  • [C-5-1] Os métodos PRECISAM ser desativados se o aplicativo controlador de política de dispositivo (DPC, na sigla em inglês) tiver definido a política de qualidade de senha usando o método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-2] O usuário PRECISA ser desafiado para a autenticação primária recomendada (por exemplo, PIN, padrão, senha) após qualquer período de tempo limite de inatividade de 4 horas. O período de tempo limite de inatividade é redefinido após qualquer confirmação bem-sucedida das credenciais do dispositivo.
  • [C-5-3] Os métodos NÃO DEVEM ser tratados como uma tela de bloqueio segura e precisam atender aos requisitos que começam com C-8 na seção abaixo.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio e um novo método de autenticação for baseado em um token físico ou no local:

  • [C-6-1] Eles PRECISAM ter um mecanismo de substituição para usar um dos métodos de autenticação primária recomendados, que se baseia em um segredo conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
  • [C-6-2] O novo método PRECISA ser desativado e permitir que apenas um dos métodos de autenticação primária recomendados desbloqueie a tela quando o aplicativo do controlador de políticas do dispositivo (DPC) tiver definido a política com o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva que PASSWORD_QUALITY_UNSPECIFIED.
  • [C-6-3] O usuário PRECISA ser desafiado a usar um dos métodos de autenticação primária recomendados (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada quatro horas ou menos.
  • [C-6-4] O novo método NÃO DEVE ser tratado como uma tela de bloqueio segura e DEVE seguir as restrições listadas em C-8 abaixo.

Se as implementações de dispositivos 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] DEVE ter uma indicação clara no menu de configurações e na tela de bloqueio quando o bloqueio do dispositivo é adiado ou 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 bloqueia instantaneamente" no menu de configurações e um ícone distinguível na tela de bloqueio.
  • [C-7-2] É OBRIGATÓRIO respeitar e implementar totalmente todas as APIs de agente de confiança na classe DevicePolicyManager, como a constante KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-7-3] NÃO DEVE implementar totalmente a função TrustAgentService.addEscrowToken() em um dispositivo usado como principal para uso pessoal (por exemplo, portátil), mas PODE implementar totalmente a função em dispositivos que geralmente são compartilhados (por exemplo, Android TV ou dispositivo automotivo).
  • [C-7-4] É OBRIGATÓRIO criptografar todos os tokens armazenados adicionados por TrustAgentService.addEscrowToken().
  • [C-7-5] NÃO PODE armazenar a chave de criptografia ou o token de depósito em 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] É OBRIGATÓRIO informar ao 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 substituição para usar um dos métodos de autenticação primária recomendados.
  • [C-7-8] O usuário PRECISA ser desafiado a usar um dos métodos de autenticação primária recomendados (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 72 horas ou menos, a menos que a segurança do usuário (por exemplo, distração do motorista) seja uma preocupação.
  • [C-7-9] O usuário PRECISA ser desafiado a usar um dos métodos recomendados de autenticação principal (por exemplo, PIN, padrão, senha) após qualquer período de tempo limite de inatividade de 4 horas, a menos que a segurança do usuário (por exemplo, distração do motorista) seja uma preocupação. O período de tempo limite de inatividade é redefinido após qualquer confirmação bem-sucedida das credenciais do dispositivo.
  • [C-7-10] NÃO DEVE ser tratado como uma tela de bloqueio segura e DEVE seguir as restrições listadas em C-8 abaixo.
  • [C-7-11] NÃO PODE permitir que os agentes de confiança em dispositivos pessoais principais (por exemplo, portáteis) desbloqueiem o dispositivo e só podem ser usados para manter um dispositivo já desbloqueado nesse estado por até quatro horas. A implementação padrão do TrustManagerService no AOSP atende a esse requisito.
  • [C-7-12] É OBRIGATÓRIO usar um canal de comunicação criptograficamente seguro (por exemplo, UKEY2) para transmitir o token de custódia do dispositivo de armazenamento para o dispositivo de destino.

Se as implementações de dispositivos adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio que não é segura, conforme descrito acima, e usarem um novo método de autenticação para desbloquear o keyguard:

  • [C-8-1] O novo método PRECISA ser desativado quando o aplicativo controlador de política de dispositivo (DPC) tiver definido a política de qualidade de senha usando o método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_UNSPECIFIED.
  • [C-8-2] Eles NÃO DEVEM redefinir os timers de expiração de senha definidos por DevicePolicyManager.setPasswordExpirationTimeout().
  • [C-8-3] Eles NÃO PODEM expor uma API para uso por apps de terceiros para mudar o estado de bloqueio.

9.11.2. StrongBox

O Android Keystore System permite que os desenvolvedores de apps armazenem chaves criptográficas em um processador seguro dedicado, além do ambiente de execução isolado descrito acima. Esse processador seguro dedicado é chamado de "StrongBox". Os requisitos C-1-3 a C-1-11 abaixo definem os requisitos que um dispositivo PRECISA atender para se qualificar como StrongBox.

Implementações de dispositivos com um processador seguro dedicado:

  • [C-SR] São ALTAMENTE RECOMENDADOS para oferecer suporte ao StrongBox. O StrongBox provavelmente vai se tornar um requisito em uma versão futura.

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

  • [C-1-1] PRECISA declarar FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] PRECISA fornecer hardware seguro dedicado usado para fazer backup do keystore e proteger a autenticação do usuário. O hardware seguro dedicado também pode ser usado para outras finalidades.

  • [C-1-3] PRECISA ter uma CPU discreta que não compartilhe cache, DRAM, coprocessadores ou outros recursos principais com o processador de aplicativos (AP, na sigla em inglês).

  • [C-1-4] PRECISA garantir que nenhum periférico compartilhado com o AP possa alterar o processamento do StrongBox de forma alguma ou obter informações dele. 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 à manipulação pelo PA.

  • [C-1-6] PRECISA ter um gerador de números aleatórios real que produza resultados imprevisíveis e uniformemente distribuídos.

  • [C-1-7] Precisa ter resistência a violações, incluindo resistência contra penetração física e falhas.

  • [C-1-8] PRECISA ter resistência a canais laterais, incluindo resistência contra vazamento de informações por energia, tempo, radiação eletromagnética e canais laterais de radiação térmica.

  • [C-1-9] PRECISA ter armazenamento seguro que garanta a confidencialidade, a integridade, a autenticidade, a consistência e a atualização do conteúdo. O armazenamento NÃO PODE ser lido ou alterado, exceto conforme permitido pelas APIs StrongBox.

  • Para validar a conformidade com [C-1-3] a [C-1-9], as implementações de dispositivos:

    • [C-1-10] PRECISA incluir o hardware certificado de acordo com o Perfil de Proteção de CI 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 do potencial de ataque aos smartcards dos critérios comuns.
    • [C-1-11] PRECISA incluir o firmware avaliado por um laboratório de testes credenciado nacionalmente que incorpora a avaliação de vulnerabilidade de alto potencial de ataque de acordo com a Aplicação de Critérios Comuns de Potencial de Ataque a Smartcards.
    • [C-SR] É FORTEMENTE RECOMENDADO incluir o hardware avaliado usando uma meta de segurança, um nível de garantia de avaliação (EAL) 5, complementado por AVA_VAN.5. A certificação EAL 5 provavelmente será um requisito em uma versão futura.

  • [C-SR] são FORTEMENTE RECOMENDADOS para oferecer resistência a ataques internos (IAR, na sigla em inglês), o que significa que um insider com acesso a chaves de assinatura de firmware não pode produzir um firmware que cause vazamento de segredos da StrongBox, burle requisitos de segurança funcional ou permita o acesso a dados sensíveis do usuário. A maneira recomendada de implementar o IAR é permitir atualizações de firmware somente quando a senha do usuário principal for fornecida pela HAL IAuthSecret.

9.12. Exclusão de dados

Todas as implementações de dispositivos:

  • [C-0-1] DEVE oferecer aos usuários um mecanismo para realizar uma "redefinição de dados de fábrica".
  • [C-0-2] MUST delete all data on the userdata filesystem.
  • [C-0-3] É OBRIGATÓRIO excluir os dados de forma a atender aos padrões relevantes do setor, como o NIST SP800-88.
  • [C-0-4] PRECISA acionar o processo "Redefinição de dados de fábrica" acima quando a API DevicePolicyManager.wipeData() for chamada pelo app controlador de política do dispositivo do usuário principal.
  • PODE oferecer uma opção de limpeza rápida de dados que realiza apenas uma exclusão lógica de dados.

9.13. Modo de inicialização segura

O Android oferece o modo de inicialização segura, que permite aos usuários inicializar um modo em que apenas os apps do sistema pré-instalados podem ser executados e todos os apps de terceiros são desativados. Esse modo, conhecido como "Modo de inicialização segura", permite que o usuário desinstale apps de terceiros potencialmente nocivos.

As implementações de dispositivos são:

  • [SR] STRONGLY RECOMMENDED to implement Safe Boot Mode.

Se as implementações de dispositivos implementarem o modo de inicialização segura, elas:

  • [C-1-1] DEVE oferecer ao usuário uma opção para entrar no modo de inicialização segura de forma ininterrupta por apps de terceiros instalados no dispositivo, exceto quando o app de terceiros for um controlador de políticas de dispositivo e tiver definido a flag UserManager.DISALLOW_SAFE_BOOT como "true".

  • [C-1-2] DEVE oferecer ao usuário a capacidade de desinstalar apps de terceiros no modo de segurança.

  • DEVE oferecer ao usuário uma opção para entrar no modo de inicialização segura no menu de inicialização usando um fluxo de trabalho diferente do de uma inicialização normal.

9.14. Isolamento do sistema de veículos automotivos

Espera-se que os dispositivos Android Automotive troquem dados com subsistemas críticos do veículo usando o HAL do veículo para enviar e receber mensagens em redes de veículos, como o barramento CAN.

A troca de dados pode ser protegida com a implementação de recursos de segurança abaixo das camadas do framework Android para evitar interações maliciosas ou não intencionais com esses subsistemas.

9.15. Planos de assinatura

"Planos de assinatura" se referem aos detalhes do plano de relacionamento de faturamento fornecidos por uma operadora de celular via SubscriptionManager.setSubscriptionPlans().

Todas as implementações de dispositivos:

  • [C-0-1] MUST return subscription plans only to the mobile carrier app that has originally provided them.
  • [C-0-2] NÃO PODE fazer backup ou upload remoto de planos de assinatura.
  • [C-0-3] SÓ PODE permitir 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 passar em todos os testes descritos nesta seção. No entanto, nenhum pacote de teste de software é totalmente abrangente. Por isso, é ALTAMENTE RECOMENDADO que os implementadores de dispositivos façam o mínimo de mudanças possível na implementação de referência e preferida do Android disponível no Android Open Source Project. Isso minimiza o risco de introduzir bugs que criam incompatibilidades que exigem retrabalho e possíveis atualizações de dispositivos.

10.1. Conjunto de teste de compatibilidade

Implementações de dispositivos:

  • [C-0-1] PRECISA ser aprovado no Conjunto de teste de compatibilidade do Android (CTS) disponível no Android Open Source Project, usando o software de envio final no dispositivo.

  • [C-0-2] É OBRIGATÓRIO garantir a compatibilidade em casos de ambiguidade no CTS e em qualquer reimplementação de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. O CTS terá versões independentes 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 na versão mais recente do CTS disponível no momento em que o software do dispositivo é concluído.

  • É RECOMENDADO usar a implementação de referência na árvore do Android Open Source o máximo possível.

10.2. Verificador do CTS

O CTS Verifier está incluído no Compatibility Test Suite e foi criado 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 de sensores.

Implementações de dispositivos:

  • [C-0-1] PRECISA executar corretamente todos os casos aplicáveis no verificador do CTS.

O Verificador do CTS tem testes para vários tipos de hardware, incluindo alguns opcionais.

Implementações de dispositivos:

  • [C-0-2] PRECISA passar em todos os testes do hardware que possui. 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 observados 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 indicado acima. No entanto, como muitas versões são muito semelhantes, não é esperado que os implementadores de dispositivos executem explicitamente o CTS Verifier em versões que diferem apenas de maneiras triviais. Especificamente, as implementações de dispositivos que diferem de uma implementação que passou no Verificador do CTS apenas pelo conjunto de locais incluídos, branding etc. PODEM omitir o teste do Verificador do CTS.

11. Software atualizável

  • [C-0-1] As implementações de dispositivos precisam incluir um mecanismo para substituir todo o software do sistema. O mecanismo não precisa realizar upgrades "ao vivo", ou seja, uma reinicialização do dispositivo PODE ser necessária. Qualquer método pode ser usado, desde que substitua todo o software pré-instalado no dispositivo. Por exemplo, qualquer uma das seguintes abordagens atende a esse requisito:

    • Downloads "over-the-air" (OTA) com atualização off-line por reinicialização.
    • Atualizações "conectadas" por USB de um PC host.
    • Atualizações "off-line" por reinicialização e atualização de um arquivo em armazenamento removível.

  • [C-0-2] O mecanismo de atualização usado PRECISA oferecer suporte a atualizações sem limpar os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados particulares e 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 em relação a uma chave pública armazenada no dispositivo.

  • [C-SR] É ALTAMENTE RECOMENDADO que o mecanismo de assinatura faça o hash da atualização com SHA-256 e valide o hash com a chave pública usando ECDSA NIST P-256.

Se as implementações de dispositivos incluírem suporte para uma conexão de dados sem medição, como 802.11 ou perfil PAN (rede de área pessoal) Bluetooth, elas:

  • [C-1-1] PRECISA oferecer suporte a downloads OTA com atualização off-line via reinicialização.

Para implementações de dispositivos que estão sendo lançadas com o Android 6.0 e versões mais recentes, o mecanismo de atualização DEVE oferecer suporte à verificação de que a imagem do sistema é binariamente idêntica ao resultado esperado após uma OTA. A implementação de 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 a atualizações do sistema A/B. O AOSP implementa esse recurso usando a HAL de controle de inicialização.

Se um erro for encontrado na implementação de um dispositivo após o lançamento, mas dentro da vida útil razoável do produto, determinada em consulta com a equipe de compatibilidade do Android, que afete a compatibilidade de aplicativos de terceiros, então:

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

O Android inclui recursos que permitem que o app Proprietário do dispositivo (se presente) controle a instalação de atualizações do sistema. Se o subsistema de atualização do sistema para dispositivos informar android.software.device_admin, ele:

  • [C-3-1] É OBRIGATÓRIO implementar o comportamento descrito na classe SystemUpdatePolicy.

12. Registro de alterações do documento

Para um resumo das mudanças na Definição de compatibilidade nesta versão:

Para um resumo das mudanças nas seções de indivíduos:

  1. Introdução
  2. Tipos de dispositivo
  3. Software
  4. Pacotes de aplicativos
  5. Multimídia
  6. Ferramentas e opções para desenvolvedores
  7. Compatibilidade de hardware
  8. Desempenho e energia
  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 para visualizar o registro de alterações

As mudanças são marcadas da seguinte forma:

  • CDD
    Mudanças significativas nos requisitos de compatibilidade.

  • Documentos
    Mudanças cosméticas ou relacionadas ao build.

Para uma melhor visualização, adicione os parâmetros de URL pretty=full e no-merges aos URLs do registro de mudanças.

13. Entre em contato

Participe do fórum de compatibilidade do Android e peça esclarecimentos ou levante problemas que você acha que o documento não aborda.