Definição de compatibilidade do Android 8.1

1. Introdução

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

O uso de "PRECISA", "NÃO PODE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVE", "DEVE", "NÃO DEVE", "RECOMENDADO", "PODE" e "OPCIONAL" está de acordo com o padrão IETF definido no RFC2119.

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

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

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

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

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

1.1 Estrutura do documento

1.1.1. Requisitos por tipo de dispositivo

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

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

1.1.2. ID do requisito

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

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

Cada ID é definido conforme abaixo:

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

2. Tipos de dispositivo

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

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

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

2.1 Configurações do dispositivo

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

2.2. Requisitos para dispositivos portáteis

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

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

• usar uma fonte de energia que ofereça mobilidade, como uma bateria;
• A tela deve ter um tamanho de tela diagonal físico de 2,5 a 8 polegadas.

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

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

2.2.1. Hardware

Tamanho da tela (seção 7.1.1.1)

Implementações de dispositivos portáteis:

• [H-0-1] PRECISA ter uma tela de pelo menos 50 centímetros de tamanho diagonal.^*

Densidade da tela (seção 7.1.1.3)

Implementações de dispositivos portáteis:

• [H-SR] É FORTEMENTE RECOMENDADO para fornecer aos usuários uma affordance para mudar o tamanho de exibição.

Modo de compatibilidade de aplicativos legados (Seção 7.1.5)

Implementações de dispositivos portáteis:

• [H-0-1] PRECISA incluir suporte ao modo de compatibilidade do aplicativo legado, conforme implementado pelo código-fonte aberto upstream do Android. Ou seja, as implementações de dispositivos NÃO PODEM alterar os acionadores ou os limites em que o modo de compatibilidade é ativado nem o comportamento do próprio modo de compatibilidade.

Teclado (Seção 7.2.1)

Implementações de dispositivos portáteis:

• [H-0-1] PRECISA incluir suporte a aplicativos de Editor de método de entrada (IME) de terceiros.

Teclas de navegação (seção 7.2.3)

Implementações de dispositivos portáteis:

• [H-0-1] PRECISA fornecer as funções Home, Recents e Back.

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

Entrada de tela touchscreen (seção 7.2.4)

Implementações de dispositivos portáteis:

• [H-0-1] PRECISA oferecer suporte à entrada por touchscreen.

Acelerômetro (seção 7.3.1)

Implementações de dispositivos portáteis:

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

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

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

Giroscópio (seção 7.3.4)

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

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

Sensor de proximidade (Seção 7.3.8)

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

• DEVE incluir um sensor de proximidade.

Sensor de posição (seção 7.3.12)

Implementações de dispositivos portáteis:

• São RECOMENDADOS para oferecer suporte ao sensor de pose com 6 graus de liberdade.

Bluetooth (Seção 7.4.3).

Implementações de dispositivos portáteis:

• DEVE incluir suporte para Bluetooth e Bluetooth LE.

Economia de dados (Seção 7.4.7)

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

• [H-1-1] PRECISA fornecer o modo de economia de dados.

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

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

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

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

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

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

Se as implementações de dispositivos portáteis declararem compatibilidade com ABIs de 32 e 64 bits:

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

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

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

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

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

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

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

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

• [H-10-1] PRECISA ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do aplicativo (também conhecido como partição "/data").
• DEVE declarar a flag de recurso android.hardware.ram.normal.

Armazenamento compartilhado de aplicativos (Seção 7.6.2)

Implementações de dispositivos portáteis:

• [H-0-1] NÃO PODE fornecer um armazenamento compartilhado de aplicativo menor que 1 GiB.

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

Implementações de dispositivos portáteis:

• DEVE incluir uma porta USB compatível com o modo de periféricos.

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

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

Microfone (seção 7.8.1)

Implementações de dispositivos portáteis:

• [H-0-1] PRECISA incluir um microfone.

Saída de áudio (Seção 7.8.2)

Implementações de dispositivos portáteis:

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

Modo de realidade virtual (Seção 7.9.1)

Se as implementações de dispositivos portáteis incluírem suporte para o modo RV, elas:

• [H-1-1] PRECISA declarar o recurso android.software.vr.mode.^*

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

• [H-2-1] PRECISA incluir um aplicativo que implemente android.service.vr.VrListenerService e que possa ser ativado por aplicativos de RV via android.app.Activity#setVrModeEnabled.^*

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

Se as implementações de dispositivos portáteis forem capazes de atender a todos os requisitos para declarar a flag de recurso android.hardware.vr.high_performance, elas:

• [H-1-1] PRECISA declarar a flag de recurso android.hardware.vr.high_performance.^*

2.2.2. Multimídia

Codificação de áudio (seção 5.1.1)

As implementações de dispositivos portáteis PRECISAM ser compatíveis com a seguinte codificação de áudio:

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

Decodificação de áudio (seção 5.1.2)

As implementações de dispositivos portáteis PRECISAM ser compatíveis com a seguinte decodificação de áudio:

• [H-0-1] AMR-NB
• [H-0-2] AMR-WB

Codificação de vídeo (seção 5.2)

As implementações de dispositivos portáteis PRECISAM oferecer suporte à codificação de vídeo a seguir e disponibilizá-la para aplicativos de terceiros:

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

Decodificação de vídeo (Seção 5.3)

As implementações de dispositivos portáteis PRECISAM ser compatíveis com a seguinte decodificação de vídeo:

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

2.2.3. Software

Compatibilidade do WebView (seção 3.4.1)

Implementações de dispositivos portáteis:

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

Compatibilidade do navegador (Seção 3.4.2)

Implementações de dispositivos portáteis:

• [H-0-1] PRECISA incluir um aplicativo de navegador autônomo para a navegação na Web de usuários gerais.

Acesso rápido (seção 3.8.1)

Implementações de dispositivos portáteis:

• [H-SR] É MUITO RECOMENDADO implementar uma tela de início padrão com suporte à fixação de atalhos e widgets no app.

• [H-SR] É MUITO RECOMENDADO implementar uma tela de início padrão que ofereça acesso rápido a atalhos adicionais fornecidos por apps de terceiros com a API ShortcutsManager.

• [H-SR] É ALTAMENTE RECOMENDADO incluir um app de tela de início padrão que mostre selos para os ícones de apps.

Widgets (Seção 3.8.2).

Implementações de dispositivos portáteis:

• [H-SR] É FORTEMENTE RECOMENDADO a compatibilidade com widgets de apps de terceiros.

Notificações (seção 3.8.3)

Implementações de dispositivos portáteis:

• [H-0-1] PRECISA permitir que apps de terceiros notifiquem usuários sobre eventos importantes usando as classes de API Notification e NotificationManager.
• [H-0-2] PRECISA oferecer suporte a notificações avançadas.
• [H-0-3] PRECISA ser compatível com notificações de alerta.
• [H-0-4] PRECISA incluir uma aba de notificações, proporcionando ao usuário a capacidade de controlar diretamente (por exemplo, responder, adiar, dispensar, bloquear) as notificações pela funcionalidade do usuário, como botões de ação ou o painel de controle, conforme implementado no AOSP.

Pesquisa (Seção 3.8.4).

Implementações de dispositivos portáteis:

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

Controle de mídia da tela de bloqueio (seção 3.8.10)

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

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

Administração de dispositivos (seção 3.9)

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

• [H-1-1] PRECISA implementar todas as políticas de administração de dispositivos definidas na documentação do SDK do Android.

Acessibilidade (seção 3.10)

Implementações de dispositivos portáteis:

• [H-SR] PRECISA ser compatível com serviços de acessibilidade de terceiros.

• [H-SR] É FORTEMENTE RECOMENDADO para pré-carregar serviços de acessibilidade no dispositivo comparável ou superior à funcionalidade do acesso com interruptor e do TalkBack (para idiomas compatíveis com o mecanismo de conversão de texto em voz pré-carregado), conforme fornecido no projeto de código aberto de TalkBack.

Conversão de texto em voz (Seção 3.11)

Implementações de dispositivos portáteis:

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

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

Configurações rápidas (seção 3.13)

Implementações de dispositivos portáteis:

• [H-SR] É MUITO RECOMENDADO incluir um componente de interface para as Configurações rápidas.

Pareamento de dispositivo complementar (seção 3.15)

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

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

2.2.4 Desempenho e potência

Consistência da experiência do usuário (seção 8.1)

Para implementações de dispositivos portáteis:

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

Desempenho do acesso a arquivos de E/S (seção 8.2)

Implementações de dispositivos portáteis:

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

Modos de economia de energia (Seção 8.3)

Para implementações de dispositivos portáteis:

• [H-0-1] Todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca" PRECISAM ficar visíveis para o usuário final.
• [H-0-2] Os algoritmos de acionamento, manutenção, ativação e o uso das configurações globais do sistema dos modos de economia de energia "App em espera" e "Soneca" não DEVEM ser diferentes do Android Open Source Project.

Contabilidade de consumo de energia (seções 8.4)

Implementações de dispositivos portáteis:

• [H-0-1] PRECISA fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
• [H-0-2] PRECISA informar todos os valores de consumo de energia em miliamperes-hora (mAh).
• [H-0-3] PRECISA 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.
• [H-0-4] PRECISA disponibilizar esse uso de energia pelo comando do shell do adb shell dumpsys batterystats para o desenvolvedor do app.
• DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.

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

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

2.2.5 Modelo de segurança

Permissões (Seções 9.1)

Implementações de dispositivos portáteis:

• [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 oferecer um mecanismo acessível ao usuário para conceder ou revogar o acesso a esses apps em resposta à intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

2.3. Requisitos para televisão

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

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

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

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

2.3.1 Hardware

Navegação sem toque (Seção 7.2.2)

Implementações de dispositivos de televisão:

• [T-0-1] PRECISA oferecer suporte ao botão direcional.

Teclas de navegação (seção 7.2.3)

Implementações de dispositivos de televisão:

• [T-0-1] PRECISA fornecer as funções Home e Back.
• [T-0-2] PRECISA enviar os eventos de pressionamento normal e longo da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano.

Mapeamentos de botões (Seção 7.2.6.1)

Implementações de dispositivos de televisão:

• [T-0-1] PRECISA incluir suporte a controles de jogos e declarar a flag de recurso android.hardware.gamepad.

Controle remoto (seção 7.2.7)

Implementações de dispositivos de televisão:

• DEVE fornecer um controle remoto para os usuários acessarem as entradas da navegação sem toque e das teclas de navegação principais.

Giroscópio (seção 7.3.4)

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

• [T-1-1] PRECISA relatar eventos com uma frequência de pelo menos 100 Hz.

Bluetooth (Seção 7.4.3).

Implementações de dispositivos de televisão:

• [T-0-1] PRECISA ser compatível com Bluetooth e Bluetooth LE.

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

Implementações de dispositivos de televisão:

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

Microfone (seção 7.8.1)

Implementações de dispositivos de televisão:

• DEVE incluir um microfone.

Saída de áudio (Seção 7.8.2)

Implementações de dispositivos de televisão:

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

2.3.2 Multimídia

Codificação de áudio (seção 5.1)

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

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

Codificação de vídeo (seção 5.2)

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

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

H-264 (Seção 5.2.2)

As implementações de dispositivos de televisão são:

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

Decodificação de vídeo (Seção 5.3)

As implementações de dispositivos de televisão PRECISAM ser compatíveis com a seguinte decodificação de vídeo:

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

As implementações de dispositivos de televisão são FORTEMENTE RECOMENDADAS para oferecer suporte à seguinte decodificação de vídeo:

• [T-SR] MPEG-2

H.264 (seção 5.3.4)

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

• [T-1-1] PRECISA ser compatível com High Profile Level 4.2 e perfil de decodificação HD 1080p (a 60 fps).
• [T-1-2] PRECISA ser capaz de decodificar vídeos com os dois perfis HD, conforme indicado na tabela a seguir e codificados com o perfil de referência, o perfil principal ou o nível alto 4.2.

H.265 (HEVC) (Seção 5.3.5)

Se as implementações de dispositivos de televisão forem compatíveis com o codec H.265 e o perfil de decodificação de 1080p HD, elas:

• [T-1-1] PRECISA ser compatível com o nível principal do perfil principal de nível 4.1.
• [T-SR] É MUITO RECOMENDADO oferecer suporte a frame rate de vídeo de 60 fps para 1080p em HD.

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

• [T-2-1] O codec PRECISA ser compatível com o perfil Main10 Nível 5 do nível principal.

VP8 (seção 5.3.6).

Se as implementações de dispositivos de televisão oferecerem suporte ao codec VP8, elas:

• [T-1-1] PRECISA oferecer suporte ao perfil de decodificação de 1080p60 de alta definição.

Se as implementações de dispositivos de televisão oferecerem suporte ao codec VP8 e a 720p, elas:

• [T-2-1] PRECISA oferecer suporte ao perfil de decodificação de 720p60 HD.

VP9 (seção 5.3.7)

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

• [T-1-1] PRECISA ser compatível com a profundidade de cores de 8 bits e PRECISA ser compatível com VP9 Profile 2 (10 bits).

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

• [T-2-1] PRECISA oferecer suporte a 60 fps para 1080p.

Mídia segura (seção 5.8)

Se as implementações de dispositivos forem dispositivos Android Television e oferecerem suporte à resolução 4K, elas:

• [T-1-1] PRECISA oferecer suporte a HDCP 2.2 para todas as telas externas com fio.

Se as implementações de dispositivos de televisão não oferecerem suporte à resolução 4K, elas:

• [T-2-1] PRECISA oferecer suporte a HDCP 1.4 para todas as telas externas com fio.

Implementações de dispositivos de televisão:

• [T-SR] É MUITO RECOMENDADO para oferecer suporte à decodificação simultânea de streams seguros. No mínimo, a decodificação simultânea de dois fluxos é FORTEMENTE RECOMENDADO.

Volume de saída de áudio (Seção 5.5.3)

Implementações de dispositivos de televisão:

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

2.3.3 Software

Implementações de dispositivos de televisão:

• [T-0-1] PRECISA declarar os recursos android.software.leanback e android.hardware.type.television.

Compatibilidade do WebView (seção 3.4.1)

Implementações de dispositivos de televisão:

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

Controle de mídia da tela de bloqueio (seção 3.8.10)

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

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

Várias janelas (Seção 3.8.14)

Implementações de dispositivos de televisão:

• [T-SR] É MUITO RECOMENDADO a compatibilidade com o modo picture-in-picture (PIP) de várias janelas.

Acessibilidade (seção 3.10)

Implementações de dispositivos de televisão:

• [T-SR] PRECISA ser compatível com serviços de acessibilidade de terceiros.

• [T-SR] As implementações do dispositivo Android Television são FORTEMENTE RECOMENDADAS para pré-carregar serviços de acessibilidade no dispositivo comparável ou superior à funcionalidade dos serviços de acessibilidade de acesso com interruptor e TalkBack (para idiomas compatíveis com o mecanismo de conversão de texto em voz pré-carregado) conforme fornecido no projeto de código aberto de TalkBack.

Conversão de texto em voz (Seção 3.11)

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

• [T-SR] RECOMENDADO ALTAMENTE a inclusão de um mecanismo TTS com suporte para os idiomas disponíveis no dispositivo.

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

TV Input Framework (seção 3.12)

Implementações de dispositivos de televisão:

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

2.2.4 Desempenho e potência

Consistência da experiência do usuário (seção 8.1)

Para implementações de dispositivos de televisão:

• [T-0-1] Latência de frame consistente. A latência de frame inconsistente ou um atraso na renderização de frames NÃO PODEM ocorrer com mais frequência do que 5 frames por segundo e DEVEM ser menores que 1 frames por segundo.

Desempenho do acesso a arquivos de E/S (seção 8.2)

Implementações de dispositivos de televisão:

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

Modos de economia de energia (Seção 8.3)

Para implementações de dispositivos de televisão:

• [T-0-1] Todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca" PRECISAM ficar visíveis para o usuário final.
• [T-0-2] Os algoritmos de acionamento, manutenção, ativação e o uso das configurações globais do sistema dos modos de economia de energia "App em espera" e "Soneca" não DEVEM ser diferentes do Android Open Source Project.

Contabilidade de consumo de energia (seções 8.4)

Implementações de dispositivos de televisão:

• [T-0-1] PRECISA fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
• [T-0-2] PRECISA informar todos os valores de consumo de energia em milissegundos (mAh).
• [T-0-3] PRECISA 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.
• 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.
• [T-0-4] PRECISA disponibilizar esse uso de energia pelo comando do shell do adb shell dumpsys batterystats para o desenvolvedor do app.

2.4. Requisitos do relógio

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

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

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

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

2.4.1. Hardware

Tamanho da tela (seção 7.1.1.1)

Implementações de dispositivos de smartwatches:

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

Teclas de navegação (seção 7.2.3)

Implementações de dispositivos de smartwatches:

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

Entrada de tela touchscreen (seção 7.2.4)

Implementações de dispositivos de smartwatches:

• [W-0-2] PRECISA oferecer suporte à entrada por touchscreen.

Acelerômetro (seção 7.3.1)

Implementações de dispositivos de smartwatches:

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

Bluetooth (Seção 7.4.3).

Implementações de dispositivos de smartwatches:

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

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

Implementações de dispositivos de smartwatches:

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

Microfone (seção 7.8.1)

Implementações de dispositivos de smartwatches:

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

Saída de áudio (Seção 7.8.1)

Implementações de dispositivos de smartwatches:

• PODE, mas NÃO DEVE ter saída de áudio.

2.4.2. Multimídia

Nenhum requisito extra.

2.4.3. Software

Implementações de dispositivos de smartwatches:

• [W-0-1] PRECISA declarar o recurso android.hardware.type.watch.
• [W-0-2] PRECISA oferecer suporte a uiMode = UI_MODE_TYPE_WATCH.

Pesquisa (Seção 3.8.4).

Implementações de dispositivos de smartwatches:

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

Acessibilidade (seção 3.10)

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

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

• [W-SR] É RECOMENDADO pré-carregar serviços de acessibilidade no dispositivo de forma comparável ou superior à funcionalidade do acesso com interruptor e do TalkBack (para idiomas compatíveis com o mecanismo de conversão de texto em voz pré-carregado), conforme fornecido no projeto de código aberto TalkBack.

Conversão de texto em voz (Seção 3.11)

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

• [W-SR] É RECOMENDADO que você inclua um mecanismo TTS com suporte para os idiomas disponíveis no dispositivo.

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

2,5 Requisitos automotivos

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

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

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

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

2.5.1. Hardware

Tamanho da tela (seção 7.1.1.1)

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA ter uma tela de pelo menos 15 cm de tamanho diagonal.
• [A-0-2] PRECISA ter um layout de tamanho de tela de pelo menos 750 dp x 480 dp.

Teclas de navegação (seção 7.2.3)

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA fornecer a função Home e PODE fornecer as funções Back e Recent.
• [A-0-2] PRECISA enviar os eventos de pressionamento normal e longo da função "Voltar" (KEYCODE_BACK) para o aplicativo em primeiro plano.

Acelerômetro (seção 7.3.1)

Implementações de dispositivos automotivos:

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

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

• [A-1-1] PRECISA relatar eventos com uma frequência de pelo menos 100 Hz.
• [A-1-2] PRECISA obedecer ao sistema de coordenadas do sensor do carro do Android.

GPS (seção 7.3.3)

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

• [A-1-1] A geração da tecnologia GNSS PRECISA ser o ano "2017" ou mais recente.

Giroscópio (seção 7.3.4)

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

• [A-1-1] PRECISA relatar eventos com uma frequência de pelo menos 100 Hz.

Sensores exclusivos do Android Automotive (Seção 7.3.11) Current Gear (Seção 7.3.11.1).

Implementações de dispositivos automotivos:

• DEVE fornecer o equipamento atual como SENSOR_TYPE_GEAR.

Modo dia e noite (Seção 7.3.11.2)

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA oferecer suporte ao modo dia/noite definido como SENSOR_TYPE_NIGHT.
• [A-0-2] O valor da flag SENSOR_TYPE_NIGHT PRECISA ser consistente com o modo dia/noite do painel e PRECISA ser baseado na entrada do sensor de luz ambiente.
• O sensor de luz ambiente subjacente PODE ser o mesmo do Photometer.

Status de condução (Seção 7.3.11.3)

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA oferecer suporte ao status de direção definido como SENSOR_TYPE_DRIVING_STATUS, com um valor padrão de DRIVE_STATUS_UNRESTRICTED quando o veículo estiver totalmente parado e estacionado. É responsabilidade dos fabricantes de dispositivos configurar o SENSOR_TYPE_DRIVING_STATUS em conformidade com todas as leis e regulamentações que se aplicam aos mercados em que o produto é enviado.

Velocidade da roda (seção 7.3.11.4)

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA fornecer a velocidade do veículo definida como SENSOR_TYPE_CAR_SPEED.

Bluetooth (Seção 7.4.3).

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA oferecer suporte a Bluetooth e DEVE oferecer suporte a Bluetooth LE.

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

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

Capacidade mínima de rede (seção 7.4.5)

Implementações de dispositivos automotivos:

• DEVE incluir suporte para conectividade de dados baseada em rede celular.

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

Implementações de dispositivos automotivos:

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

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

Implementações de dispositivos automotivos:

• DEVE incluir uma porta USB compatível com o modo de periféricos.

Microfone (seção 7.8.1)

Implementações de dispositivos automotivos:

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

Saída de áudio (Seção 7.8.2)

Implementações de dispositivos automotivos:

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

2.5.2 Multimídia

Codificação de áudio (seção 5.1)

As implementações de dispositivos automotivos PRECISAM oferecer suporte à seguinte codificação de áudio:

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

Codificação de vídeo (seção 5.2)

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

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

Decodificação de vídeo (Seção 5.3)

As implementações de dispositivos automotivos PRECISAM oferecer suporte à decodificação de vídeo a seguir:

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

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

• [A-SR] HEVC H.265

2.5.3 Software

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA declarar o recurso android.hardware.type.automotive.
• [A-0-2] PRECISA oferecer suporte a uiMode = UI_MODE_TYPE_CAR.
• [A-0-3] As implementações do Android Automotive PRECISAM oferecer suporte a todas as APIs públicas no namespace android.car.*.

Compatibilidade do WebView (seção 3.4.1)

Implementações de dispositivos automotivos:

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

Notificações (seção 3.8.3)

Implementações de dispositivos Android Automotive:

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

Pesquisa (Seção 3.8.4).

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA implementar um assistente no dispositivo para processar a ação de assistência.

IU de mídia (seção 3.14)

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA incluir uma estrutura de interface para dar suporte a apps de terceiros que usam as APIs de mídia, conforme descrito na seção 3.14.

2.2.4 Desempenho e potência

Modos de economia de energia (Seção 8.3)

Para implementações de dispositivos automotivos:

• [A-0-1] Todos os apps isentos dos modos de economia de energia "App em espera" e "Soneca" PRECISAM ficar visíveis para o usuário final.
• [A-0-2] Os algoritmos de acionamento, manutenção, ativação e o uso das configurações globais do sistema dos modos de economia de energia "App em espera" e "Soneca" não DEVEM ser diferentes do Android Open Source Project.

Contabilidade de consumo de energia (seções 8.4)

Implementações de dispositivos automotivos:

• [A-0-1] PRECISA fornecer um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
• [A-0-2] PRECISA informar todos os valores de consumo de energia em miliamperes-hora (mAh).
• [A-0-3] PRECISA 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.
• 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.
• [A-0-4] PRECISA disponibilizar esse uso de energia pelo comando do shell do adb shell dumpsys batterystats para o desenvolvedor do app.

2.2.5 Modelo de segurança

Suporte a vários usuários (seção 9.5)

Se as implementações de dispositivos automotivos incluírem vários usuários, elas:

• [A-1-1] PRECISA incluir uma conta de convidado que permita todas as funções fornecidas pelo sistema do veículo sem exigir que o usuário faça login.

Isolamento do sistema de veículos automotivos (seção 9.14)

Implementações de dispositivos automotivos:

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

2,6 Requisitos para tablets

Um tablet Android é uma implementação de dispositivo Android que normalmente é usada segurando com as duas mãos, e não em formato flip.

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

• usar uma fonte de energia que ofereça mobilidade, como uma bateria;
• A tela deve ter um tamanho de tela diagonal físico de 7 a 18 polegadas.

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

2.4.1. Hardware

Tamanho da tela (seção 7.1.1.1)

Implementações de dispositivos tablet:

• [Ta-0-1] PRECISA ter uma tela no intervalo de 7 a 18 polegadas.

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

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

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

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

• PODE implementar a API Android Open Accessory (AOA).

Modo de realidade virtual (Seção 7.9.1)

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

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

3. Software

3.1. Compatibilidade com APIs gerenciadas

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

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

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

• [C-0-3] As implementações de dispositivos NÃO PODEM omitir APIs gerenciadas, alterar interfaces ou assinaturas da API, desviar do comportamento documentado ou incluir ambiente autônomo, exceto quando especificamente permitido por esta Definição de compatibilidade.

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

3.1.1. Extensões Android

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

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

3.2. Compatibilidade leve com APIs

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

3.2.1. Permissões

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

3.2.2. Parâmetros de build

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

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

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

3.2.3. Compatibilidade de intents

3.2.3.1. Principais intents do aplicativo

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

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

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

3.2.3.2. Resolução de intents

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

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

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

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

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

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

3.2.3.3. Namespaces de intents

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

3.2.3.4. Intents de transmissão

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

Implementações de dispositivos:

• [C-0-1] PRECISA transmitir as intents de transmissão públicas em resposta aos eventos apropriados do sistema, conforme descrito na documentação do SDK. Observe que esse requisito não está em conflito com a seção 3.5, pois a limitação para aplicativos em segundo plano também é descrita na documentação do SDK.

3.2.3.5. Configurações padrão do app

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

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

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

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

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

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

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

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

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

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

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

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

3.2.4. Atividades em telas secundárias

Se as implementações de dispositivos permitirem a inicialização de atividades normais do Android em telas secundárias, elas:

• [C-1-1] PRECISA definir a flag de recurso android.software.activities_on_secondary_displays.
• [C-1-2] PRECISA garantir a compatibilidade da API de forma semelhante a uma atividade executada na tela principal.
• [C-1-3] PRECISA colocar a nova atividade na mesma tela que a que a iniciou, quando ela for iniciada sem especificar uma tela de destino com a API ActivityOptions.setLaunchDisplayId().
• [C-1-4] PRECISA destruir todas as atividades quando uma tela com a flag Display.FLAG_PRIVATE for removida.
• [C-1-5] PRECISA redimensionar todas as atividades em uma VirtualDisplay se a tela for redimensionada.
• PODE mostrar um IME (editor de método de entrada, um controle de usuário que permite que os usuários insiram texto) na tela principal, quando um campo de entrada de texto passa a ser focado em uma tela secundária.
• DEVE implementar o foco de entrada na tela secundária independentemente da tela principal, quando houver suporte para entradas por toque ou tecla.
• DEVE ter android.content.res.Configuration, que corresponde a essa tela para ser mostrada, funcionar corretamente e manter a compatibilidade caso uma atividade seja iniciada na tela secundária.

Se as implementações do dispositivo permitirem a inicialização de atividades normais do Android em telas secundárias, e as telas primária e secundária tiverem android.util.DisplayMetrics diferentes:

• [C-2-1] Atividades não redimensionáveis (com resizeableActivity=false em AndroidManifest.xml) e apps destinados ao nível 23 da API ou versões anteriores NÃO PODEM ser permitidos em telas secundárias.

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

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

3.3. Compatibilidade com API nativa

Os implementadores de dispositivos são:

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

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

3.3.1. Interfaces binárias do aplicativo

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

Implementações de dispositivos:

• [C-0-1] PRECISA ser compatível com uma ou mais ABIs definidas e implementar compatibilidade com o Android NDK.
• [C-0-2] PRECISA incluir suporte para código em execução no ambiente gerenciado para chamadas em código nativo, usando a semântica padrão da Interface nativa do Java (JNI).
• [C-0-3] PRECISA ser compatível com a fonte (ou seja, com o cabeçalho) e com o binário (para a ABI) com cada biblioteca necessária na lista abaixo.
• [C-0-4] PRECISA oferecer suporte à ABI equivalente de 32 bits, se houver ABI de 64 bits.
• [C-0-5] PRECISA informar com precisão a Interface binária do aplicativo (ABI) nativa compatível com o dispositivo, usando os parâmetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, cada um com uma lista separada por vírgulas de ABIs ordenadas da maior para a menos preferida.
• [C-0-6] PRECISA informar, usando os parâmetros acima, somente as ABIs documentadas e descritas na versão mais recente da documentação de gerenciamento de ABI do Android NDK e PRECISA incluir suporte à extensão SIMD avançado (também conhecida como NEON).

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

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

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

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

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

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

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

• [C-1-1] Embora a arquitetura ARMv8 suspenda o uso de várias operações de CPU, incluindo algumas operações usadas no código nativo existente, as seguintes operações obsoletas PRECISAM permanecer disponíveis para o código ARM nativo de 32 bits, seja por meio da compatibilidade com CPU nativa ou da emulação de software:

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

Se as implementações de dispositivos incluírem uma ABI ARM de 32 bits, elas:

• [C-2-1] É NECESSÁRIO incluir as linhas abaixo em /proc/cpuinfo quando ele é lido por aplicativos ARM de 32 bits para garantir a compatibilidade com apps criados usando versões legadas do Android NDK.

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

• Não DEVE mudar /proc/cpuinfo quando lido por aplicativos ARM de 64 bits ou não ARM.

3,4 Compatibilidade com a Web

3.4.1. Compatibilidade com WebView

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

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

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

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, como 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.
  • O valor da string $(MODEL) PRECISA ser igual ao valor de android.os.Build.MODEL.
  • O valor da string $(BUILD) PRECISA ser igual ao valor de android.os.Build.ID.
  • O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium no Android Open Source Project.
  • As implementações de dispositivos podem omitir dispositivos móveis na string do user agent.

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

3.4.2. Compatibilidade de navegadores

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

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

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

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

3,5 Compatibilidade comportamental de API

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

• [C-0-1] Os dispositivos NÃO PODEM mudar o comportamento ou a semântica de uma intent padrão.
• [C-0-2] Os dispositivos NÃO PODEM alterar a semântica do ciclo de vida ou do ciclo de vida de um tipo específico de componente do sistema (como Service, Activity, ContentProvider etc.).
• [C-0-3] Os dispositivos NÃO PODEM mudar a semântica de uma permissão padrão.
• Os dispositivos NÃO PODEM alterar as limitações aplicadas a aplicativos em segundo plano. Mais especificamente, para apps em segundo plano:
  • [C-0-4] eles PRECISAM parar de executar callbacks registrados pelo app para receber saídas de GnssMeasurement e GnssNavigationMessage.
  • [C-0-5] eles PRECISAM limitar a frequência de atualizações fornecidas ao app pela classe de API LocationManager ou pelo método WifiManager.startScan().
  • [C-0-6] Se o app for destinado ao nível 25 da API ou mais recente, eles NÃO PODEM permitir o registro de broadcast receivers para as transmissões implícitas de intents padrão do Android no manifesto do app, a menos que a intent de transmissão exija uma permissão "signature" ou "signatureOrSystem" protectionLevel ou esteja na lista de isenções.
  • [C-0-7] Se o app for direcionado ao nível 25 da API ou mais recente, ele PRECISA interromper os serviços em segundo plano, como se tivesse chamado o método stopSelf(), a menos que o app fosse colocado em uma lista de permissões temporária para processar uma tarefa visível para o usuário.
  • [C-0-8] Se o app for direcionado ao nível 25 da API ou mais recente, ele PRECISA liberar os wakelocks que o app retém.

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

3,6 Namespaces da API

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

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

Ou seja, eles:

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

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

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

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

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

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

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

3,7 Compatibilidade de ambiente de execução

Implementações de dispositivos:

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

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

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

• DEVE fazer testes de fuzz em vários modos de execução e arquiteturas-alvo para garantir a estabilidade do ambiente de execução. Consulte JFuzz e DexFuzz no site do Android Open Source Project.

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

Layout da tela	Densidade da tela	Memória mínima do aplicativo
Relógio Android	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	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
	160 dpi (mdpi)
	213 dpi (tvdpi)	48MB
	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
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	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
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3,8. Compatibilidade da interface do usuário

3.8.1. Tela de início (tela inicial)

O Android inclui um aplicativo de inicialização (tela inicial) e suporte a aplicativos de terceiros para substituir o inicializador do dispositivo (tela inicial).

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

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

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

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

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

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

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

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

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

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

3.8.2. Widgets

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

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

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

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

• [C-2-1] PRECISA informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] PRECISA ter affordance do usuário antes de adicionar um atalho solicitado pelos apps com o método de API AppWidgetManager.requestPinAppWidget().

3.8.3. Notificações

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

3.8.3.1. Apresentação de notificações

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

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

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

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

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

• [C-3-1] PRECISA usar a visualização e os recursos das notificações de alerta, conforme descrito na classe da API Notification.Builder quando elas forem apresentadas.

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

O Android inclui as APIs NotificationListenerService que permitem que os apps (após a ativação explícita do usuário) recebam uma cópia de todas as notificações conforme são postadas ou atualizadas.

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

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

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

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

3.8.3.3. Não perturbe

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

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

3.8.4. Pesquisar

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

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

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

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

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

• O comportamento padrão DEVE ser exibir sugestões e resultados de mecanismos de pesquisa na web.

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

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

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

3.8.5. Alertas e avisos

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

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

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

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

3.8.6. Temas

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

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

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

• [C-1-1] NÃO PODE alterar nenhum dos atributos de tema Holo expostos a aplicativos.
• [C-1-2] PRECISA ser compatível com a família de temas "Material" e NÃO pode alterar nenhum dos atributos de tema do Material Design ou os recursos deles expostos a aplicativos.

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

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

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

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

• [C-2-1] PRECISA usar branco para ícones de status do sistema (como intensidade do sinal e nível da bateria) e notificações emitidas pelo sistema, a menos que o ícone esteja indicando um status problemático ou se um aplicativo solicite uma barra de status clara usando a sinalização SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
• [C-2-2] As implementações de dispositivos Android PRECISAM mudar a cor dos ícones de status do sistema para preto (para mais detalhes, consulte R.style) quando um app solicita uma barra de status clara.

3.8.7. Planos fundo interativos

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

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

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

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

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

3.8.8. Troca de atividades

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

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

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

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

• PODE exibir recentes afiliadas como um grupo que é movido em conjunto.

• [SR] É FORTEMENTE RECOMENDADO usar a interface do usuário upstream do Android (ou uma interface semelhante baseada em miniatura) para a tela de visão geral.

3.8.9. Gerenciamento de entradas

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

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

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

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

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

3.8.10. Controle de mídia da tela de bloqueio

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

3.8.11. Protetores de tela (antigo Dreams)

O Android oferece suporte a recursos de proteção de tela interativa, anteriormente chamados de Dreams. Os protetores de tela permitem que os usuários interajam com os aplicativos quando um dispositivo conectado a uma fonte de energia está inativo ou encaixado em uma base de mesa. Os dispositivos Android Watch PODEm implementar protetores de tela, mas outros tipos de implementações de dispositivos DEVEM incluir suporte a protetores de tela e oferecer uma opção de configuração para que os usuários configurem protetores de tela em resposta à intent android.settings.DREAM_SETTINGS.

3.8.12. Localização

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

• [C-1-1] Os modos de localização PRECISAM ser exibidos no menu "Local" em "Configurações".

3.8.13. Unicode e fonte

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

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

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

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

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

3.8.14. Várias janelas

Se as implementações de dispositivos puderem mostrar várias atividades ao mesmo tempo, elas:

• [C-1-1] PRECISA implementar esses modos de várias janelas de acordo com os comportamentos dos aplicativos e as APIs descritos na documentação de suporte do modo de várias janelas do SDK do Android e atender aos seguintes requisitos:
• [C-1-2] Os aplicativos podem indicar se podem operar no modo de várias janelas no arquivo AndroidManifest.xml explicitamente definindo o atributo android:resizeableActivity como true ou implicitamente com a targetSdkVersion maior que 24. Apps que definem explicitamente esse atributo como false no manifesto NÃO PODEM ser iniciados no modo de várias janelas. Apps mais antigos com uma targetSdkVersion anterior a 24 que não definiram o atributo android:resizeableActivity PODEM ser iniciados no modo de várias janelas, mas o sistema PRECISA fornecer avisos de que o app pode não funcionar como esperado nesse modo.
• [C-1-3] NÃO PODE oferecer o modo de tela dividida ou formato livre se a altura da tela < 440 dp e a largura da tela < 440 dp.
• As implementações de dispositivos com tamanho de tela xlarge DEVEM ser compatíveis com o modo de forma livre.

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

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

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

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

3,9. Administração do dispositivo

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

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

• [C-1-1] PRECISA declarar android.software.device_admin.
• [C-1-2] PRECISA oferecer suporte ao provisionamento do proprietário do dispositivo, conforme descrito na seção 3.9.1 e na seção 3.9.1.1.
• [C-1-3] PRECISA declarar o suporte a perfis gerenciados usando a flag de recurso android.software.managed_users, exceto quando o dispositivo está configurado para informar a si mesmo como um dispositivo com pouca RAM ou para alocar o armazenamento interno (não removível) como armazenamento compartilhado.

3.9.1 Provisionamento de dispositivos

3.9.1.1 Provisionamento do proprietário do dispositivo

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

• [C-1-1] PRECISA ser compatível com a inscrição de um cliente Device Policy (DPC) como um app proprietário do dispositivo, conforme descrito abaixo.
  • Quando a implementação do dispositivo ainda não tiver dados do usuário configurados, ela:
    • [C-1-3] PRECISA informar true para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] PRECISA registrar o aplicativo DPC como o app Proprietário do dispositivo em resposta à ação da intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] PRECISA registrar o aplicativo DPC como o app Proprietário do dispositivo se o dispositivo declarar suporte a comunicações a curta distância (NFC, na sigla em inglês) usando a flag de recurso android.hardware.nfc e receber uma mensagem NFC contendo um registro com o tipo MIME MIME_TYPE_PROVISIONING_NFC.
  • Quando a implementação do dispositivo tem dados do usuário, ela:
    • [C-1-6] PRECISA informar false para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] NÃO PODE mais registrar aplicativos DPC como o aplicativo Proprietário do dispositivo.
• [C-1-2] NÃO É POSSÍVEL definir um app (inclusive apps pré-instalados) como o app Proprietário do dispositivo sem consentimento explícito ou ação do usuário ou administrador do dispositivo.

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

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

3.9.1.2 Provisionamento de perfil gerenciado

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

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

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

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

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

3.9.2 Suporte de perfil gerenciado

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

• [C-1-1] PRECISA oferecer suporte aos perfis gerenciados usando as APIs android.app.admin.DevicePolicyManager.
• [C-1-2] PRECISA permitir a criação de apenas um perfil gerenciado.
• [C-1-3] PRECISA usar um selo de ícone (semelhante ao de trabalho upstream do AOSP) para representar os aplicativos e widgets gerenciados, além de outros elementos de interface com selo, como Recents e Notifications.
• [C-1-4] PRECISA mostrar um ícone de notificação (semelhante ao selo de trabalho upstream do AOSP) para indicar quando o usuário está em um app de perfil gerenciado.
• [C-1-5] PRECISA exibir um aviso indicando que o usuário está no perfil gerenciado se e quando o dispositivo for ativado (ACTION_USER_PRESENT) e o aplicativo em primeiro plano estiver no perfil gerenciado.
• [C-1-6] Onde existe um perfil gerenciado, PRECISA mostrar uma affordance visual no "Seletor" da intent para permitir que o usuário encaminhe a intent do perfil gerenciado para o usuário principal ou vice-versa, se ativado pelo Device Policy Controller.
• [C-1-7] Quando houver um perfil gerenciado, PRECISA expor as seguintes affordances do usuário, tanto para o usuário principal quanto para o perfil gerenciado:
  • Contabilização separada do uso de bateria, localização, dados móveis e armazenamento para o usuário principal e o perfil gerenciado.
  • Gerenciamento independente de apps de VPN instalados no usuário principal ou no perfil gerenciado.
  • Gerenciamento independente de apps instalados no usuário principal ou no perfil gerenciado.
  • Gerenciamento independente de contas no perfil gerenciado ou do usuário principal.
• [C-1-8] PRECISA garantir que o discador, os contatos e os apps de mensagens pré-instalados possam pesquisar e procurar informações do autor da chamada no perfil gerenciado (se houver) e no perfil principal, se o Device Policy Controller permitir.
• [C-1-9] PRECISA garantir que ele atenda a todos os requisitos de segurança aplicáveis a um dispositivo com vários usuários ativados (consulte a seção 9.5), mesmo que o perfil gerenciado não seja contabilizado como outro usuário além do usuário principal.
• [C-1-10] PRECISA oferecer suporte à capacidade de especificar uma tela de bloqueio separada, atendendo aos seguintes requisitos para conceder acesso a apps em execução em um perfil gerenciado.
  • As implementações de dispositivos PRECISAM respeitar a intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrar uma interface para configurar uma credencial de tela de bloqueio separada para o perfil gerenciado.
  • As credenciais da tela de bloqueio do perfil gerenciado PRECISAM usar os mesmos mecanismos de armazenamento e gerenciamento de credenciais do perfil pai, conforme documentado no site do Android Open Source Project.
  • As políticas de senha do DPC PRECISAM ser aplicadas apenas às credenciais da tela de bloqueio do perfil gerenciado, a menos que chamadas na instância DevicePolicyManager retornada por getParentProfileInstance.
• Quando os contatos do perfil gerenciado aparecem no registro de chamadas pré-instalado, na interface em chamada, nas notificações de chamadas perdidas e em andamento, nos contatos e nos apps de mensagens, eles DEVEM receber um selo com o mesmo selo usado para indicar os apps do perfil gerenciado.

3,10 Acessibilidade

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

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

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

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

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

3,11. Conversão de texto em voz

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

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

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

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

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

3,12. TV Input Framework

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

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

• [C-1-1] PRECISA declarar o recurso da plataforma android.software.live_tv.
• [C-1-2] PRECISA pré-carregar um aplicativo de TV (app de TV) e atender a todos os requisitos descritos na seção 3.12.1.

3.12.1. App de TV

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

• [C-1-1] O app de TV PRECISA oferecer recursos para instalar e usar canais de TV e atender aos seguintes requisitos:

O app de TV necessário para implementações de dispositivos Android que declaram a flag de recurso android.software.live_tv PRECISA atender aos seguintes requisitos:

• As implementações de dispositivos DEVEM permitir que entradas baseadas em TIF de terceiros (entradas de terceiros) sejam instaladas e gerenciadas.
• As implementações de dispositivos podem fornecer separação visual entre as entradas baseadas em TIF pré-instaladas (entradas instaladas) e as entradas de terceiros.
• As implementações de dispositivos NÃO DEVEM exibir as entradas de terceiros a mais do que uma única ação de navegação fora do app para TV (ou seja, expandir uma lista de entradas de terceiros no app para TV).

O Android Open Source Project oferece uma implementação do app para TV que atende aos requisitos acima.

3.12.1.1 Guia eletrônico da programação

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

• [C-1-1] PRECISA mostrar uma sobreposição informativa e interativa, que PRECISA incluir um guia eletrônico da programação (EPG, na sigla em inglês) gerado a partir dos valores nos campos TvContract.Programs.
• [C-1-2] Na mudança de canal, as implementações de dispositivos PRECISAM exibir dados do EPG para o programa em execução no momento.
• [SR] O EPG é MUITO RECOMENDADO para mostrar as entradas instaladas e de terceiros com o mesmo destaque. O EPG NÃO DEVE exibir as entradas de terceiros mais do que uma única ação de navegação longe das entradas instaladas no EPG.
• O EPG DEVE exibir informações de todas as entradas instaladas e de terceiros.
• O EPG PODE fornecer separação visual entre as entradas instaladas e as de terceiros.

3.12.1.2. Navegação

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

• [C-1-1] PRECISA permitir a navegação para as seguintes funções usando os botões direcionais, "Voltar" e "Home" nos dispositivos de entrada do dispositivo Android Television (ou seja, controle remoto, app de controle remoto ou controle de jogo):

  • Como mudar canais de TV
  • Abrindo o EPG
  • Configurar e ajustar entradas baseadas em TIF de terceiros (se essas entradas forem compatíveis)
  • Abrindo o menu "Configurações"

• DEVE transmitir eventos de tecla para entradas HDMI pelo CEC.

3.12.1.3 Vinculação ao app de entrada de TV

As implementações de dispositivos Android Television DEVEM oferecer suporte à vinculação de apps de entrada de TV, que permite que todas as entradas forneçam links de atividades da atividade atual para outra (ou seja, um link de programação ao vivo para conteúdo relacionado). O app de TV DEVE mostrar links para o app de entrada de TV quando fornecido.

3.12.1.4 Mudança de horário

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

• [SR] MUITO RECOMENDADO para oferecer suporte à mudança de tempo, o que permite que o usuário pause e retome o conteúdo ao vivo.
• DEVE fornecer ao usuário uma maneira de pausar e retomar o programa em execução no momento, se a mudança de horário para esse programa estiver disponível.

3.12.1.5 Gravação de TV

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

• [SR] MUITO RECOMENDADO para oferecer suporte à gravação na TV.
• Se a entrada de TV for compatível com a gravação e a gravação de um programa não for proibida, o EPG poderá oferecer uma maneira de gravar um programa.

3,13 Configurações rápidas

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

Se as implementações de dispositivos incluírem um componente de interface para Configurações rápidas, elas:

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

3,14 Interface de mídia

Se as implementações de dispositivos incluírem o framework da interface compatível com apps de terceiros que dependem de MediaBrowser e MediaSession , elas:

• [C-1-1] PRECISA mostrar os ícones MediaItem e de notificação sem mudanças.
• [C-1-2] PRECISA exibir esses itens conforme descrito pela MediaSession, por exemplo, metadados, ícones e imagens.
• [C-1-3] PRECISA mostrar o título do app.
• [C-1-4] PRECISA ter uma gaveta para apresentar a hierarquia MediaBrowser.
• [C-1-5] PRECISA considerar o toque duplo de KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent.

3,15 Instant Apps

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

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

3,16 Pareamento de dispositivo complementar

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

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

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

4. Compatibilidade do empacotamento de aplicativos

Implementações de dispositivos:

• [C-0-1] PRECISA instalar e executar arquivos ".apk" do Android conforme gerado pela ferramenta "aapt" incluída no SDK oficial do Android.
• Como o requisito acima pode ser desafiador, as implementações de dispositivos são RECOMENDADAS para usar as implementações de systemDevice de gerenciamento de pacotes da implementação de referência do AOSP.
• [C-0-2] PRECISA oferecer suporte à verificação de arquivos ".apk" usando o Esquema de assinatura de APK v2 e a Assinatura JAR.
• [C-0-3] NÃO PODE estender os formatos de bytecode .apk, Manifesto do Android, Bytecode Dalvik ou RenderScript de forma a impedir que esses arquivos sejam instalados e executados corretamente em outros dispositivos compatíveis.
• [C-0-4] NÃO É POSSÍVEL permitir que outros apps além do "instalador registro" atual do pacote desinstalem silenciosamente o app sem receber uma solicitação, conforme documentado no SDK da permissão DELETE_PACKAGE. As únicas exceções são o app verificador de pacote do sistema que processa a intent PACKAGE_NEEDS_VERIFICATION e o app gerenciador de armazenamento que processa a intent ACTION_MANAGE_STORAGE.

As implementações de dispositivos NÃO PODEM instalar pacotes de apps de fontes desconhecidas, a menos que o app que solicita a instalação atenda a todos os requisitos a seguir:

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

As implementações de dispositivos PRECISAM ter uma atividade para processar a intent android.settings.MANAGE_UNKNOWN_APP_SOURCES. Eles DEVEM fornecer uma funcionalidade ao usuário para conceder/revogar a permissão de instalação de apps de fontes desconhecidas por app, mas PODEM optar por implementar isso como um ambiente autônomo e retornar RESULT_CANCELED para startActivityForResult(), se a implementação do dispositivo não permitir que os usuários tenham essa opção. No entanto, mesmo nesses casos, eles DEVEM indicar ao usuário por que essa opção não é apresentada.

5. Compatibilidade multimídia

Implementações de dispositivos:

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

Implementações de dispositivos:

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

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

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

5.1. Codecs de mídia

5.1.1. Codificação de áudio

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

Se as implementações de dispositivos declararem android.hardware.microphone, elas PRECISAM ser compatíveis com a seguinte codificação de áudio:

• [C-1-1] PCM/WAVE

5.1.2. Decodificação de áudio

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

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

• [C-1-1] Perfil AAC MPEG-4 (AAC LC)
• [C-1-2] Perfil MPEG-4 HE AAC (AAC+)
• [C-1-3] Perfil MPEG-4 HE AACv2 (AAC+ aprimorado)
• [C-1-4] AAC ELD (AAC aprimorado com atraso baixo)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vórbis
• [C-1-9] PCM/WAVE
• [C-1-10] Opus

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

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

5.1.3. Detalhes dos codecs de áudio

Formato/Codec	Detalhes	Tipos de arquivos/formatos de contêiner compatíveis
Perfil AAC MPEG-4 (AAC LC)	Suporte a conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS AAC bruto (.aac, ADIF não compatíveis) MPEG-TS (.ts, não pesquisável)
Perfil MPEG-4 HE AAC (AAC+)	Suporte a conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.
Perfil MPEG-4 HE AACv2 (AAC+ aprimorado)	Suporte a conteúdo mono/estéreo/5.0/5.1 com taxas de amostragem padrão de 16 a 48 kHz.
AAC ELD (AAC aprimorado com atraso baixo)	Suporte a conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.
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
FLAC	Mono/estéreo (sem multicanal). Taxas de amostragem de até 48 kHz (mas até 44,1 kHz são RECOMENDADAS em dispositivos com saída de 44,1 kHz, já que o redutor de 48 a 44,1 kHz não inclui um filtro de passagem baixa). 16 bits RECOMENDADO; nenhum pontilhamento aplicado para 24 bits.	Somente FLAC (.flac)
MP3	Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8 a 320 Kbps	MP3 (.mp3)
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) Matroska (.mkv, Android 4.0+)
PCM/WAVE	PCM linear de 16 bits (taxas até o limite do hardware). Os dispositivos PRECISAM ser compatíveis com taxas de amostragem para gravação em PCM bruto em frequências 8.000, 11.025, 16.000 e 44.100 Hz.	WAVE (.wav)
Opus		Matroska (.mkv), Ogg(.ogg)

5.1.4. Codificação de imagem

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

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

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

5.1.5 Decodificação de imagem

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

As implementações de dispositivos PRECISAM ser compatíveis com a codificação da seguinte decodificaçã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

5.1.6. Detalhes dos codecs de imagem

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

5.1.7. Codecs de vídeo

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

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

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

• [C-1-2] Codificadores e decodificadores de vídeo PRECISAM ser compatíveis com o formato de cor flexível YUV420 (COLOR_FormatYUV420 HTTP).

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

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

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

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

5.1.8. Lista de codecs de vídeo

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

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H-264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

• DEVE oferecer suporte à gravação de arquivos Matroska WebM.

5,3 Decodificação de vídeo

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

• [C-1-1] PRECISA oferecer suporte à resolução dinâmica de vídeo e à troca de frame rate pelas APIs padrão do Android no mesmo stream para todos os codecs VP8, VP9, H.264 e H.265 em tempo real e até a resolução máxima aceita por cada codec no dispositivo.

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

• [C-1-1] PRECISA oferecer suporte aos perfis de referência de nível 30 e 45.

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

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

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

5,4. Gravação em áudio

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

5.4.1. Captura de áudio bruto

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

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

• Formato: PCM linear, 16 bits

• Taxas de amostragem: 8000, 11025, 16.000, 44.100 Hz

• Canais: mono

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

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

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

• Formato: PCM linear, 16 bits

• Taxas de amostragem: 22.050, 48.000 Hz
• Canais: estéreo

Se as implementações de dispositivos permitirem a captura de conteúdo de áudio bruto com qualidade de rádio AM e DVD, elas:

• [C-2-1] PRECISA capturar sem aumento de amostragem em qualquer proporção maior que 16.000:22.050 ou 44.100:48.000.
• [C-2-2] PRECISA incluir um filtro anti-aliasing adequado para cada aumento ou redução de amostragem.

5.4.2. Captura para reconhecimento de voz

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

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

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

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

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

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

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

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

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

5,5. Reprodução de áudio

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

5.5.1. Reprodução de áudio bruto

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

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

  • Formato: PCM linear, 16 bits
  • Taxas de amostragem: 8000, 11025, 16000, 22050, 32000, 44100
  • Canais: mono, estéreo

• DEVE permitir a reprodução de conteúdo de áudio bruto com as seguintes características:

  • Taxas de amostragem: 24.000, 48.000

5.5.2. Efeitos de áudio

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

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

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

5.5.3. Volume de saída de áudio

Implementações de dispositivos automotivos:

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

5,6. Latência de áudio

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

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

• latência de saída. É o intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e quando o som correspondente é apresentado ao ambiente em um transdutor ou sinal sai do dispositivo por uma porta e pode ser observado externamente.
• latência de saída a frio. A latência de saída para o primeiro frame, quando o sistema de saída de áudio esteve inativo e desligado antes da solicitação.
• latência de saída contínua. A latência de saída para os frames subsequentes, depois que o dispositivo está reproduzindo áudio.
• latência de entrada. É o intervalo entre o momento em que um som é apresentado pelo ambiente para o dispositivo em um transdutor ou sinal que entra no dispositivo por uma porta e quando um aplicativo lê o frame correspondente de dados codificados em PCM.
• entrada perdida. A parte inicial de um sinal de entrada que não pode ser usado ou está indisponível.
• latência de entrada a frio. A soma do tempo de entrada perdido e da latência de entrada para o primeiro frame, quando o sistema de entrada de áudio esteve inativo e desligado antes da solicitação.
• latência de entrada contínua. A latência de entrada para frames subsequentes, enquanto o dispositivo está capturando áudio.
• instabilidade na saída a frio. A variabilidade entre medições separadas de valores de latência de saída frio.
• instabilidade de entrada a frio. A variabilidade entre medições separadas de valores de latência de entrada a frio.
• latência de ida e volta contínua. A soma da latência de entrada contínua mais a latência de saída contínua mais um período de buffer. O período de buffer permite que o app processe o indicador e tempo para reduzir a diferença de fase entre os fluxos de entrada e saída.
• API OpenSL ES PCM da fila de buffer. O conjunto de APIs OpenSL ES relacionadas a PCM no Android NDK.
• API Native Audio da AAudio. O conjunto de APIs AAudio no Android NDK.

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

• [SR] Latência de saída a frio de 100 milissegundos ou menos
• [SR] Latência de saída contínua de 45 milissegundos ou menos
• [SR] Minimizar a instabilidade da saída a frio

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

• [SR] É RECOMENDADO que você informe o áudio de baixa latência declarando a flag de recurso android.hardware.audio.low_latency.
• [SR] RECOMENDADO ALTAMENTE que também atenda aos requisitos de áudio de baixa latência pela API AAudio.

Se as implementações de dispositivos não atenderem aos requisitos de áudio de baixa latência por meio da API de fila de buffer de PCM do OpenSL ES, elas:

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

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

• [SR] Latência de entrada a frio de 100 milissegundos ou menos
• [SR] Latência de entrada contínua de 30 milissegundos ou menos
• [SR] Latência de ida e volta contínua de 50 milissegundos ou menos
• [SR] Minimize a instabilidade da entrada a frio

5,7. Protocolos de rede

As implementações de dispositivos PRECISAM ser compatíveis com os protocolos de rede de mídia para reprodução de áudio e vídeo, conforme especificado na documentação do SDK do Android.

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

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

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

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

Formatos de segmento de mídia

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

RTSP (RTP, SDP)

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

5,8. Mídia segura

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

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

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

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

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

• [C-3-1] PRECISA oferecer suporte a HDCP 1.2 ou mais recente para todas as telas externas com fio.

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

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

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

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

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

5,10 Áudio profissional

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

• [C-1-1] PRECISA relatar a compatibilidade com o recurso android.hardware.audio.low_latency.
• [C-1-2] PRECISA ter latência de ida e volta contínua de áudio, conforme definido na seção 5.6 Latência de áudio, PRECISA ser de 20 milissegundos ou menos e DEVE ser de 10 milissegundos ou menos em pelo menos um caminho compatível.
• [C-1-3] PRECISA incluir portas USB compatíveis com o modo host USB e o modo de periférico USB.
• [C-1-4] PRECISA relatar a compatibilidade com o recurso android.software.midi.
• [C-1-5] PRECISA atender aos requisitos de latência e áudio USB usando a API de fila de buffer de PCM do OpenSL ES.
• [SR] É MUITO RECOMENDADO para fornecer um nível consistente de desempenho da CPU enquanto o áudio está ativo e a carga da CPU varia. Isso precisa ser testado usando a confirmação SimpleSynth 1bd6391. O app SimpleSynth precisa ser executado com os parâmetros abaixo e não pode ter underruns após 10 minutos:
  • Ciclos de trabalho: 200.000
  • Carga variável: ATIVADA (alterna entre 100% e 10% do valor dos ciclos de trabalho a cada dois segundos e foi projetada para testar o comportamento do controlador de CPU)
  • Carga estabilizada: DESATIVADA
• DEVE minimizar a imprecisão e o desvio do relógio de áudio em relação ao horário padrão.
• DEVE minimizar a variação do relógio de áudio em relação ao CLOCK_MONOTONIC da CPU quando ambos estiverem ativos.
• DEVE minimizar a latência de áudio em transdutores no dispositivo.
• DEVE minimizar a latência de áudio no áudio digital USB.
• DEVE documentar as medições de latência de áudio em todos os caminhos.
• DEVE minimizar a instabilidade nos tempos de entrada do callback para conclusão do buffer de áudio, já que isso afeta a porcentagem utilizável da largura de banda total da CPU pelo callback.
• DEVE fornecer zero underruns (saída) ou excessos (entrada) de áudio em condições normais de uso na latência informada.
• DEVE fornecer zero diferença de latência entre os canais.
• DEVE minimizar a latência média de MIDI em todos os transportes.
• DEVE minimizar a variabilidade de latência MIDI sob carga (instabilidade) em todos os transportes.
• DEVE fornecer carimbos de data/hora MIDI precisos em todos os transportes.
• DEVE minimizar o ruído do sinal de áudio nos transdutores do dispositivo, incluindo o período imediatamente após a inicialização a frio.
• DEVE fornecer zero diferença de relógio de áudio entre os lados de entrada e saída dos endpoints correspondentes, quando ambos estiverem ativos. Exemplos de endpoints correspondentes incluem o microfone e o alto-falante do dispositivo ou a entrada e a saída da entrada e saída de áudio.
• DEVE lidar com callbacks de conclusão de buffer de áudio para os lados de entrada e saída dos endpoints correspondentes no mesmo thread quando ambos estiverem ativos e inserir o callback de saída imediatamente após o retorno do callback de entrada. Ou, se não for viável processar os callbacks na mesma linha de execução, insira o callback de saída logo após a entrada para permitir que o aplicativo tenha um tempo consistente dos lados de entrada e saída.
• DEVE minimizar a diferença de fase entre o buffer de áudio HAL para os lados de entrada e saída dos endpoints correspondentes.
• DEVE minimizar a latência de toque.
• DEVE minimizar a variabilidade da latência de toque sob carga (instabilidade).

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

• [SR] É RECOMENDADO que você informe o suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager.

Se as implementações de dispositivos atenderem aos requisitos pela API de fila de buffer de PCM do OpenSL ES, elas:

• [SR] RECOMENDADO que também é necessário atender aos mesmos requisitos pela API AAudio.

Se as implementações do dispositivo incluírem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

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

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

• [C-3-1] PRECISA implementar a classe de áudio USB.
• [C-3-2] PRECISA ter uma latência de ida e volta contínua de áudio de 20 milissegundos ou menos na porta do modo de host USB usando a classe de áudio USB.
• A latência de ida e volta contínua do áudio DEVE ser de 10 milissegundos ou menos na porta do modo host USB usando a classe de áudio USB.

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

• [C-4-1] PRECISA oferecer suporte à saída em estéreo e oito canais em profundidade de 20 ou 24 bits e 192 kHz sem perda ou reamostragem de profundidade de bits.

5,11. Capturar para não processados

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

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

• [C-1-1] PRECISA informar o suporte pela propriedade PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED do android.media.AudioManager.

• [C-1-2] PRECISA exibir características de amplitude x frequência aproximadamente planas no intervalo de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz para cada microfone usado para gravar a fonte de áudio não processada.

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

• [C-1-4] PRECISA exibir níveis de amplitude na faixa de alta frequência: especificamente de ±30 dB de 7.000 Hz a 22 KHz, em comparação com a faixa média de cada microfone usado para gravar a fonte de áudio não processada.

• [C-1-5] PRECISA definir a sensibilidade à entrada de áudio de modo que uma fonte de tom senoidal de 1.000 Hz, reproduzida a 94 dB, o nível de pressão sonora (SPL, na sigla em inglês) gere uma resposta com RMS de 520 para amostras de 16 bits (ou escala completa de -36 dB para fontes de áudio de ponto flutuante/precisão dupla) para cada microfone não processado usado para gravar o microfone não processado.

• [C-1-6] PRECISA ter uma proporção sinal-ruído (SNR, na sigla em inglês) de 60 dB ou mais para cada microfone usado para gravar a fonte de áudio não processada. (enquanto o SNR é medido como a diferença entre SPL de 94 dB e SPL equivalente de ruído próprio, com peso A).

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

• Não É NECESSÁRIO ter nenhum outro processamento de sinal no caminho (por exemplo, controle automático de ganho, filtro de alta frequência ou cancelamento de eco) no caminho além de um multiplicador para levar o nível para a faixa desejada. Resumindo:

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

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

Se as implementações de dispositivos declararem android.hardware.microphone, mas não forem compatíveis com fontes de áudio não processadas, elas:

• [C-2-1] PRECISA retornar null para o método de API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) para indicar corretamente a falta de suporte.
• [SR] ainda é FORTEMENTE RECOMENDADO para atender ao maior número possível dos requisitos de caminho de indicador da origem de gravação não processada.

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

6.1. Ferramentas para desenvolvedores

Implementações de dispositivos:

• [C-0-1] PRECISA ser compatível com as Ferramentas para desenvolvedores do Android fornecidas no SDK do Android.

• Android Debug Bridge (adb)

  • [C-0-2] PRECISA oferecer suporte a todas as funções adb, conforme documentado no SDK do Android, incluindo dumpsys.
  • [C-0-3] NÃO PODE alterar o formato ou o conteúdo de eventos do sistema do dispositivo (batterystats , Diskstats, impressões digitais, gráficosstats, netstats, notificação, procstats) registrados via dumpsys.
  • [C-0-4] PRECISA fazer com que o daemon do adb do lado do dispositivo fique inativo por padrão e PRECISA haver um mecanismo acessível ao usuário para ativar o Android Debug Bridge.
  • [C-0-5] PRECISA oferecer suporte ao adb seguro. O Android inclui compatibilidade com o adb seguro. O adb seguro permite o uso do adb em hosts autenticados conhecidos.

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

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

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

  • [C-0-7] PRECISA oferecer suporte a todos os recursos de ddms, conforme documentado no SDK do Android. Como o ddms usa o adb, o suporte para ddms PRECISA estar inativo por padrão, mas PRECISA ser compatível sempre que o usuário ativar o Android Debug Bridge, conforme descrito acima.
• Monkey
  • [C-0-8] PRECISA incluir o framework Monkey e disponibilizá-lo para uso dos aplicativos.
• SysTrace (em inglês)
  • [C-0-9] PRECISA oferecer suporte à ferramenta Systrace, conforme documentado no SDK do Android. O Systrace precisa estar inativo por padrão e deve haver um mecanismo acessível ao usuário para ativá-lo.

6.2. Opções do desenvolvedor

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

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

• [C-0-1] PRECISA respeitar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar as configurações relacionadas ao desenvolvimento de aplicativos. A implementação upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários abram as "Opções do desenvolvedor" depois de pressionar sete (7) vezes no item de menu Settings > About Device > Build Number.
• [C-0-2] PRECISA ocultar as Opções do desenvolvedor por padrão e oferecer um mecanismo para ativá-las sem a necessidade de uma lista de permissões especial.
• PODE limitar temporariamente o acesso ao menu "Opções do desenvolvedor" ocultando ou desativando visualmente o menu para evitar distrações em cenários em que a segurança do usuário seja preocupante.

7. Compatibilidade de hardware

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

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

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

• [C-0-2] As definições de classe completas (conforme documentado pelo SDK) para as APIs do componente PRECISAM ser apresentadas.
• [C-0-3] Os comportamentos da API PRECISAM ser implementados como ambiente autônomo de maneira razoável.
• [C-0-4] Os métodos da API PRECISAM retornar valores nulos quando permitido pela documentação do SDK.
• [C-0-5] Os métodos da API PRECISAM retornar implementações independentes de classes em que valores nulos não são permitidos pela documentação do SDK.
• [C-0-6] Os métodos da API NÃO PODEM gerar exceções não documentadas pela documentação do SDK.
• [C-0-7] As implementações de dispositivos PRECISAM relatar informações precisas de configuração de hardware de maneira consistente usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para a mesma impressão digital do build.

Um exemplo típico de cenário em que esses requisitos se aplicam é a API de telefonia. Mesmo em dispositivos não telefônicos, essas APIs precisam ser implementadas como um ambiente autônomo razoável.

7.1. Tela e gráficos

O Android inclui instalações que ajustam automaticamente os recursos de aplicativos e os layouts da interface de forma adequada para o dispositivo, a fim de garantir que aplicativos de terceiros funcionem bem em diversas configurações de hardware. Os dispositivos PRECISAM implementar corretamente essas APIs e comportamentos, conforme detalhado nesta seção.

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

• tamanho diagonal físico. A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
• pontos por polegada (dpi). O número de pixels abrangidos por um intervalo linear horizontal ou vertical de 1". Quando os valores de dpi estão listados, os dpi horizontal e vertical precisam estar dentro do intervalo.
• proporção. A proporção entre os pixels da dimensão maior e da menor da tela. Por exemplo, uma tela de 480 x 854 pixels seria 854/480 = 1,779, ou aproximadamente “16:9”.
• pixel de densidade independente (dp, na sigla em inglês). A unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como: pixels = dps * (densidade/160).

7.1.1. Configuração da tela

7.1.1.1 Tamanho da tela

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

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

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

• [C-0-2] As implementações de dispositivos PRECISAM respeitar corretamente o suporte declarado dos aplicativos para tamanhos de tela pelo atributo <supports-screens> no AndroidManifest.xml, conforme descrito na documentação do SDK do Android.

7.1.1.2 Proporção da tela

Embora não haja restrições ao valor da proporção da tela física, a proporção da tela lógica em que os apps de terceiros são renderizados, como 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 o Configuration.uiMode definido como UI_MODE_TYPE_NORMAL PRECISAM ter um valor de proporção entre 1,3333 (4:3) e 1,86 (aproximadamente 16:9), a menos que o app possa ser considerado pronto para ser estendido por mais tempo atendendo a uma destas condições:

  • O app declarou que oferece suporte a uma proporção de tela maior usando o valor de metadados android.max_aspect.
  • O app declara que é redimensionável usando o atributo android:resizeableActivity.
  • O app é direcionado ao nível 26 da API ou mais recente e não declara um android:MaxAspectRatio que restrinja a proporção permitida.

• [C-0-2] As implementações de dispositivos com Configuration.uiMode definido como UI_MODE_TYPE_WATCH PRECISAM ter um valor de proporção definido como 1,0 (1:1).

7.1.1.3 Densidade da tela

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

• [C-0-1] Por padrão, as implementações do dispositivo PRECISAM informar apenas uma das seguintes densidades de framework lógica do Android usando a API DENSITY_DEVICE_STABLE, e esse valor NÃO PODE mudar a qualquer momento. No entanto, o dispositivo PODE informar uma densidade arbitrária diferente de acordo com as mudanças de configuração de tela feitas pelo usuário (por exemplo, tamanho da tela) definidas após a inicialização inicial.

  • 120 dpi (ldpi)
  • 160 dpi (mdpi)
  • 213 dpi (tvdpi)
  • 240 dpi (hdpi)
  • 260 dpi (260dpi)
  • 280 dpi (280dpi)
  • 300 dpi (300dpi)
  • 320 dpi (xhdpi)
  • 340 dpi (340dpi)
  • 360 dpi (360dpi)
  • 400 dpi (400dpi)
  • 420 dpi (420dpi)
  • 480 dpi (xxhdpi)
  • 560 dpi (560dpi)
  • 640 dpi (xxxhdpi)

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

Se houver uma affordance para mudar o tamanho de exibição do dispositivo:

• [C-1-1] O tamanho de exibição NÃO PODE ser dimensionado maior que 1,5 vez a densidade nativa nem produzir uma dimensão mínima efetiva menor que 320 dp (equivalente ao qualificador de recurso sw320dp), o que ocorrer primeiro.
• [C-1-2] O tamanho de exibição NÃO PODE ser dimensionado menor que 0,85 vezes a densidade nativa.
• Para garantir boa usabilidade e tamanhos de fonte consistentes, é RECOMENDADO que as seguintes opções de dimensionamento de exibição nativa sejam fornecidas (obedecendo aos limites especificados acima)
• Pequeno: 0,85x
• Padrão: 1x (escala de display nativa)
• Grande: 1,15x
• Maior: 1,3x
• Maior 1,45x

7.1.2. Métricas de display

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

• [C-1-1] PRECISA informar os valores corretos de todas as métricas de display definidas na API android.util.DisplayMetrics.

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

• [C-2-1] PRECISA informar valores razoáveis de todas as métricas de exibição definidas 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. Por exemplo, um dispositivo com uma tela de orientação paisagem fixa, como uma televisão ou um laptop, DEVE informar apenas android.hardware.screen.landscape.
• [C-0-2] PRECISA informar o valor correto para a orientação atual do dispositivo sempre que consultado por android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.

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

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

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

OpenGL ES 7.1.4.1

Implementações de dispositivos:

• [C-0-1] PRECISA identificar corretamente as versões do OpenGL ES com suporte (1.1, 2.0, 3.0, 3.1, 3.2) usando as APIs gerenciadas (como o método GLES10.getString()) e as APIs nativas.
• [C-0-2] PRECISA incluir suporte para todas as APIs gerenciadas e nativas correspondentes para cada versão do OpenGL ES que ela identificou com suporte.

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

• [C-1-1] PRECISA oferecer suporte ao OpenGL ES 1.0 e 2.0, conforme incorporado e detalhado na documentação do SDK do Android.
• [SR] é MUITO RECOMENDADO para oferecer suporte ao OpenGL ES 3.0.
• DEVE oferecer suporte a OpenGL ES 3.1 ou 3.2.

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

• [C-2-1] PRECISA gerar relatórios pelas APIs gerenciadas e nativas do OpenGL ES sobre qualquer outra extensão do OpenGL ES implementada e NÃO PRECISA informar strings de extensão incompatíveis.
• [C-2-2] PRECISA oferecer suporte às extensões EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage e EGL_ANDROID_recordable.
• [SR] é FORTEMENTE RECOMENDADO para oferecer suporte a EGL_KHR_partial_update.
• DEVE gerar relatórios com precisão usando o método getString(), qualquer formato de compactação de textura compatível, que geralmente é específico do fornecedor.

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

• [C-3-1] PRECISA exportar os símbolos de função correspondentes para essas versões, além dos símbolos de função do OpenGL ES 2.0 na biblioteca libGLESv2.so.

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

• [C-4-1] PRECISA ser compatível com o pacote de extensão OpenGL ES para Android na íntegra.

Se as implementações de dispositivos oferecerem suporte integral ao Pacote de extensões para Android (link em inglês) do OpenGL ES, elas:

• [C-5-1] PRECISA identificar o suporte pela flag de recurso android.hardware.opengles.aep.

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

• [C-6-1] também PRECISA oferecer suporte à extensão EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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

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

• [SR] É FORTEMENTE RECOMENDADO a inclusão de suporte para Vulkan 1.0 .

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

• DEVE incluir suporte para Vulkan 1.0.

Implementações de dispositivos, caso incluam suporte ao Vulkan 1.0:

• [C-1-1] PRECISA informar o valor inteiro correto com as flags de recurso android.hardware.vulkan.level e android.hardware.vulkan.version.
• [C-1-2] PRECISA enumerar pelo menos um VkPhysicalDevice para a API nativa do Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] PRECISA implementar totalmente as APIs do Vulkan 1.0 para cada VkPhysicalDevice enumerado.
• [C-1-4] PRECISA enumerar as camadas, contidas em bibliotecas nativas chamadas libVkLayer*.so, no diretório da biblioteca nativa do pacote do app, usando as APIs nativas do Vulkan vkEnumerateInstanceLayerProperties() e vkEnumerateDeviceLayerProperties() .
• [C-1-5] NÃO É POSSÍVEL enumerar as camadas fornecidas por bibliotecas fora do pacote do aplicativo nem fornecer outras maneiras de rastrear ou interceptar a API Vulkan, a menos que o aplicativo tenha o atributo android:debuggable definido como true.
• [C-1-6] PRECISA informar todas as strings de extensão compatíveis com as APIs nativas do Vulkan e, por outro lado, NÃO PODE reportar strings de extensão que não têm suporte correto.

Implementações de dispositivos, se não houver suporte para Vulkan 1.0:

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

7.1.4.3 RenderScript

• [C-0-1] As implementações de dispositivos PRECISAM ser compatíveis com o Android RenderScript, conforme detalhado na documentação do SDK do Android.

7.1.4.4 Aceleração gráfica 2D

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

Implementações de dispositivos:

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

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

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

Telas de ampla gama 7.1.4.5

Se as implementações de dispositivos alegarem suporte a telas de ampla gama usando o Display.isWideColorGamut() , elas:

• [C-1-1] PRECISA ter uma tela calibrada por cores.
• [C-1-2] PRECISA ter uma tela cuja gama cubra toda a gama de cores sRGB no espaço xyY de CIE 1931.
• [C-1-3] PRECISA ter uma tela com uma gama de pelo menos 90% da área NTSC 1953 no espaço xyY CIE 1931.
• [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.0, 3.1 ou 3.2 e informar corretamente.
• [C-1-5] PRECISA anunciar o suporte para as extensões EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_colorspace_scrgb_linear e EGL_GL_colorspace_display_p3.
• [SR] É ALTAMENTE RECOMENDADO para oferecer suporte a GL_EXT_sRGB.

Por outro lado, se as implementações de dispositivos não forem compatíveis com telas de ampla gama, elas:

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

7.1.5. Modo de compatibilidade de aplicativo legado

O Android especifica um "modo de compatibilidade" em que o framework opera em um modo equivalente ao tamanho de tela "normal" (320 dp de largura) em benefício de aplicativos legados não desenvolvidos para versões antigas do Android que são anteriores à independência de tamanho de tela.

7.1.6. Tecnologia da tela

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

Implementações de dispositivos:

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

7.1.7. Telas secundárias

O Android inclui suporte a tela secundária 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 de tela adicional incorporada, elas:

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

7.2. Dispositivos de entrada

Implementações de dispositivos:

• [C-0-1] PRECISA incluir um mecanismo de entrada, como uma tela touchscreen ou navegação sem toque, para navegar entre os elementos da interface.

7.2.1. Teclado

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

• [C-1-1] PRECISA declarar a flag de recurso android.software.input_methods.
• [C-1-2] PRECISA implementar totalmente Input Management Framework
• [C-1-3] PRECISA ter um teclado de software pré-carregado.

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

7.2.2. Navegação sem toque

O Android oferece suporte a botões direcional, trackball e wheel como mecanismos para navegação sem toque.

Implementações de dispositivos:

• [C-0-1] PRECISA informar o valor correto para android.content.res.Configuration.navigation.

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

• [C-1-1] PRECISA fornecer um mecanismo de interface do usuário alternativo razoável para a seleção e edição de texto, compatível com os Mecanismos de gerenciamento de entradas. A implementação upstream de código aberto do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação sem toque.

7.2.3. Teclas de navegação

As funções Home, Recents e Voltar, normalmente fornecidas por uma interação com um botão físico dedicado ou uma parte distinta da tela touchscreen, são essenciais para o paradigma de navegação do Android e, portanto, as implementações de dispositivos:

• [C-0-1] PRECISA oferecer uma funcionalidade do usuário para iniciar apps instalados que tenham uma atividade com a <intent-filter> definida com ACTION=MAIN e CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER para implementações de dispositivos de televisão. A função Home DEVE ser o mecanismo para essa funcionalidade do usuário.
• DEVE fornecer botões para as funções Recentes e Voltar.

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

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

Implementações de dispositivos:

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

Se as implementações de dispositivos fornecerem a função de menu, elas:

• [C-2-1] PRECISA exibir o botão flutuante de ação sempre que o pop-up desse menu não estiver vazio e a barra de ações estiver visível.
• [C-2-2] NÃO É POSSÍVEL modificar a posição do pop-up de estouro de ação exibido ao selecionar o botão flutuante na barra de ações. No entanto, PODE renderizar o pop-up de ação flutuante em uma posição modificada na tela quando ele é exibido selecionando a função "Menu".

Se as implementações de dispositivos não fornecerem a função Menu, para compatibilidade com versões anteriores, elas:

• [C-3-1] PRECISA disponibilizar a função de menu para os aplicativos quando targetSdkVersion for menor que 10, seja por um botão físico, uma tecla de software ou gestos. Essa função de menu deve ser acessível, a menos que esteja oculta com outras funções de navegação.

Se as implementações de dispositivos fornecerem a função Assistente, elas:

• [C-4-1] PRECISA tornar a função Assistente acessível com uma única ação (por exemplo, tocar, clicar duas vezes ou fazer um gesto) quando outras teclas de navegação estiverem acessíveis.
• [SR] É RECOMENDADO usar a função "HOME" e mantê-la pressionada como essa interação designada.

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

• [C-5-1] As teclas de navegação PRECISAM usar uma parte distinta da tela, não disponível para aplicativos, e NÃO PODEM obscurecer ou interferir na parte da tela disponível para aplicativos.
• [C-5-2] PRECISA disponibilizar uma parte da tela para aplicativos que atendam aos requisitos definidos na seção 7.1.1.
• [C-5-3] PRECISA respeitar as flags definidas pelo app com o método View.setSystemUiVisibility() da API para que essa parte distinta da tela (também conhecida como a barra de navegação) fique ocultada, conforme documentado no SDK.

7.2.4. Entrada por tela touch

O Android é compatível com diversos sistemas de entrada de ponteiro, como touchscreens, touchpads e dispositivos de entrada por toque falsos. As implementações de dispositivos baseadas em touchscreen são associadas a uma tela para que o usuário tenha a impressão de manipular diretamente os itens na tela. Como o usuário está diretamente tocando na tela, o sistema não requer affordances adicionais para indicar os objetos que estão sendo manipulados.

Implementações de dispositivos:

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

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

• [C-1-1] É NECESSÁRIO informar TOUCHSCREEN_FINGER no campo da API Configuration.touchscreen.
• [C-1-2] É NECESSÁRIO informar as flags de recursos android.hardware.touchscreen e android.hardware.faketouch

Se as implementações de dispositivos incluírem uma tela touchscreen que possa rastrear mais de um único toque, elas:

• [C-2-1] PRECISA informar as flags de recurso apropriadas android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand correspondentes ao tipo de tela touchscreen específica do dispositivo.

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

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

7.2.5. Entrada de toque falsa

A interface de toque simulada fornece um sistema de entrada do usuário que se aproxima de um subconjunto de recursos da tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela faz uma aproximação do toque, mas exige que o usuário aponte ou concentre-se primeiro e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse baseado em giroscópio, ponteiro com giroscópio, joystick e trackpad multitoque, podem oferecer suporte a interações de toque falsas. O Android inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada de alta fidelidade sem toque (baseado no ponteiro), como um mouse ou trackpad que pode emular adequadamente a entrada baseada em toque (incluindo suporte básico a gestos) e indica que o dispositivo oferece suporte a um subconjunto emulado da funcionalidade de tela touchscreen.

Se as implementações de dispositivos não incluírem uma tela sensível ao toque, mas incluírem outro sistema de entrada de ponteiro que querem disponibilizar, elas:

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

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

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

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

• [C-2-1] PRECISA declarar compatibilidade com android.hardware.faketouch.
• [C-2-2] PRECISA oferecer suporte ao rastreamento distinto de duas ou mais entradas de ponteiro independentes.

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

• [C-3-1] PRECISA declarar compatibilidade com android.hardware.faketouch.
• [C-3-2] PRECISA oferecer suporte ao rastreamento distinto de cinco (rastreamento de uma mão de dedos) ou mais entradas de ponteiro de forma totalmente independente.

7.2.6. Suporte a controles de jogos

7.2.6.1. Mapeamentos de botões

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

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

Botão	Uso de HID^2	Botão do Android
R^1	0x09 0x0001	KEYCODE_BOT_A (96)
B^1	0x09 0x0002	KEYCODE_BOT_B (97)
X^1	0x09 0x0004	KEYCODE_BOT_X (99)
A^1	0x09 0x0005	KEYCODE_BOT_Y (100)
Botão direcional para cima^1 Botão direcional para baixo^1	0x01 0x0039^3	Eixo_HAT_Y^4
Botão direcional à esquerda1 Botão direcional à direita^1	0x01 0x0039^3	Eixo_HAT_X^4
Botão do ombro esquerdo^1	0x09 0x0007	KEYCODE_Button_L1 (102)
Botão do ombro direito^1	0x09 0x0008	KEYCODE_Botão_R1 (103)
Clique com o botão esquerdo do mouse^1	0x09 0x000E	KEYCODE_BOT_THUMBL (106)
Clique com o botão direito do mouse^1	0x09 0x000F	KEYCODE_Button_THUMBR (107)
Página inicial^1	0x0c 0x0223	KEYCODE_HOME (3)
Voltar^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Os usos de HID acima precisam ser declarados em uma CA de Gamepad (0x01 0x0005).

3 Este uso deve ter um Mínimo Lógico de 0, um Máximo Lógico de 7, um Mínimo Físico de 0, um Máximo Físico de 315, Unidades em Graus e um Tamanho de Relatório de 4. O valor lógico é definido como a rotação no sentido horário longe do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima está sendo pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e para a esquerda estão sendo pressionadas.

4 MotionEvent

Controles analógicos^1	Uso de HID	Botão do Android
Gatilho esquerdo	0x02 0x00C5	AXIS_LTRIGGER
Gatilho correto	0x02 0x00C4	EIXO_RTRIGGER
Joystick esquerdo	0x01 0x0030 0x01 0x0031	Eixo_X Eixo_Y
Joystick direito	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

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

7,3 Sensores

Se as implementações do dispositivo incluírem um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, a implementação do dispositivo PRECISA implementar essa API, conforme descrito na documentação do SDK do Android e na documentação do Android Open Source sobre sensores.

Implementações de dispositivos:

• [C-0-1] PRECISA informar com precisão a presença ou ausência de sensores de acordo com a classe android.content.pm.PackageManager.
• [C-0-2] PRECISA retornar uma lista precisa de sensores com suporte usando SensorManager.getSensorList() e métodos semelhantes.
• [C-0-3] PRECISA se comportar de maneira razoável com todas as outras APIs de sensores. Por exemplo, retornar true ou false conforme apropriado quando os aplicativos tentarem registrar listeners, não chamar listeners quando os sensores correspondentes não estiverem presentes etc.

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

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

• [SR] DEVE informar a hora do evento em nanossegundos, conforme definido na documentação do SDK do Android, representando a hora em que o evento aconteceu e sincronizado com o relógio SystemClock.elapsedRealtimeNano(). É altamente RECOMENDADO que dispositivos Android novos e existentes atendam a esses requisitos para que possam fazer upgrade para as próximas versões da plataforma, em que esse pode se tornar um componente OBRIGATÓRIO. O erro de sincronização DEVE ser inferior a 100 milissegundos.

• [C-1-7] Para que qualquer API indicada pela documentação do SDK do Android seja um sensor contínuo, as implementações de dispositivos PRECISAM fornecer continuamente amostras de dados periódicas que DEVEM ter uma instabilidade inferior a 3%. Nesse caso, a instabilidade é definida como o desvio padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.

• [C-1-8] PRECISA garantir que o fluxo de eventos do sensor NÃO possa impedir que a CPU do dispositivo entre em um estado de suspensão ou desperte desse estado.

• Quando vários sensores estiverem ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia relatado de cada sensor individual.

A lista acima não é abrangente. O comportamento documentado do SDK do Android e da documentação de código aberto do Android em sensores é considerado oficial.

Alguns tipos de sensores são compostos, o que significa que podem ser derivados de dados fornecidos por um ou mais sensores. (Os exemplos incluem o sensor de orientação e o sensor de aceleração linear.)

Implementações de dispositivos:

• DEVE implementar esses tipos de sensores quando incluem os pré-requisitos de sensores físicos, conforme descrito nos tipos de sensor.

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

• [C-2-1] PRECISA implementar o sensor, conforme descrito na documentação do Android Open Source sobre sensores compostos.

7.3.1. Acelerômetro

• As implementações de dispositivos DEVEM incluir um acelerômetro de três eixos.

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

• [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
• [C-1-2] PRECISA implementar e informar o sensor TYPE_ACCELEROMETER.
• [C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android.
• [C-1-4] PRECISA ser capaz de medir a queda livre até quatro vezes a gravidade(4g) ou mais em qualquer eixo.
• [C-1-5] PRECISA ter uma resolução de pelo menos 12 bits.
• [C-1-6] PRECISA ter um desvio padrão não superior a 0,05 m/s^, em que o desvio padrão deve ser calculado por eixo, em amostras coletadas durante um período de pelo menos 3 segundos com a taxa de amostragem mais rápida.
• [SR] são altamente RECOMENDADOS para implementar o sensor composto TYPE_SIGNIFICANT_MOTION.
• [SR] É RECOMENDADO que você implemente o sensor TYPE_ACCELEROMETER_UNCALIBRATED se a calibração do acelerômetro on-line estiver disponível.
• Implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER, conforme descrito no documento do SDK do Android.
• DEVE relatar eventos de até pelo menos 200 Hz.
• DEVE ter uma resolução de pelo menos 16 bits.
• DEVE ser calibrado durante o uso se as características mudarem ao longo do ciclo de vida e compensadas, além de preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• DEVE ser compensado por temperatura.
• Também DEVE implementar o sensor TYPE_ACCELEROMETER_UNCALIBRATED.

Se as implementações do dispositivo incluírem um acelerômetro de três eixos e qualquer um dos sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER forem implementados:

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

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

• [C-3-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• DEVE implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.
• [SR] Dispositivos Android novos e já existentes são RECOMENDADOS PARA implementar o sensor TYPE_GAME_ROTATION_VECTOR.

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

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

7.3.2. Magnetômetro

• As implementações de dispositivos DEVEM incluir um magnetômetro (bússola) de três eixos.

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

• [C-1-1] PRECISA implementar o sensor TYPE_MAGNETIC_FIELD.
• [C-1-2] PRECISA relatar eventos com uma frequência de pelo menos 10 Hz e DEVE relatar eventos de até 50 Hz.
• [C-1-3] PRECISA obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android.
• [C-1-4] PRECISA ser capaz de medir entre -900 μT e +900 μT em cada eixo antes da saturação.
• [C-1-5] PRECISA ter um valor de compensação do ferro rígido menor que 700 μT e PRECISA ter um valor abaixo de 200 μT. Para isso, o magnetômetro precisa ficar longe dos campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímãs).
• [C-1-6] PRECISA ter uma resolução igual ou mais densa que 0,6 μT.
• [C-1-7] PRECISA oferecer suporte à calibragem on-line e à compensação da polarização de ferro rígido e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• [C-1-8] PRECISA ter a compensação de ferro suave aplicada. A calibração pode ser feita durante o uso ou durante a produção do dispositivo.
• [C-1-9] PRECISA ter um desvio padrão, calculado por eixo, em amostras coletadas durante um período de pelo menos 3 segundos com a taxa de amostragem mais rápida, não superior a 1,5 μT. DEVE ter um desvio padrão menor que 0,5 μT.
• DEVE implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] Dispositivos Android novos e já existentes são RECOMENDADOS PARA implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

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

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

• PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

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

7.3.3. GPS

Implementações de dispositivos:

• DEVE incluir um receptor GPS/GNSS.

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

• [C-1-1] PRECISA oferecer suporte a saídas de local a uma taxa de pelo menos 1 Hz quando solicitado por LocationManager#requestLocationUpdate.
• [C-1-2] PRECISA determinar o local em condições de céu aberto (sinais fortes, multicaminho insignificante, HDOP < 2) em até 10 segundos (tempo rápido para a primeira correção) quando conectado a uma conexão de Internet com velocidade de dados de 0,5 Mbps ou mais rápida. Esse requisito normalmente é atendido com o uso de alguma forma de técnica de GPS/GNSS assistido ou previsto para minimizar o tempo de bloqueio do GPS/GNSS (os dados de assistência incluem horário de referência, localização de referência e efêmeras/relógios de satélite).
  • [SR] Depois de fazer esse cálculo de localização, é FORTEMENTE RECOMENDADO que o dispositivo possa determinar a localização, em céu aberto, dentro de 10 segundos, quando as solicitações de localização forem reiniciadas, até uma hora após o cálculo inicial da localização, mesmo quando a solicitação subsequente for feita sem uma conexão de dados e/ou após um ciclo de energia.

• Em condições de céu aberto após determinar o local, enquanto está estacionário ou em movimento com menos de 1 metro por segundo ao quadrado de aceleração:

  • [C-1-3] PRECISA determinar a localização dentro de 20 metros e a velocidade dentro de 0, 5 metro por segundo, pelo menos 95% do tempo.
  • [C-1-4] PRECISA rastrear e informar simultaneamente por GnssStatus.Callback pelo menos oito satélites de uma constelação.
  • DEVE ser capaz de rastrear simultaneamente pelo menos 24 satélites, de várias constelações (por exemplo, GPS + pelo menos um Glonass, Beidou, Galileo).
  • [C-1-5] PRECISA informar a geração da tecnologia GNSS pela API de teste "getGnssYearOfHardware".
  • [SR] Continuar a enviar saídas de localização de GPS/GNSS normais durante uma chamada de emergência.
  • [SR] Informa medições GNSS de todas as constelações rastreadas (conforme relatado nas mensagens GnssStatus), exceto SBAS.
  • [SR] O relatório AGC e a frequência de medição do GNSS.
  • [SR] Informe todas as estimativas de precisão (incluindo rolamento, velocidade e vertical) como parte de cada localização GPS.
  • [SR] É RECOMENDADO que você atenda ao maior número possível de requisitos obrigatórios adicionais para dispositivos que informam o ano "2016" ou "2017" usando a API Test LocationManager.getGnssYearOfHardware().

Se as implementações de dispositivos incluírem um receptor GPS/GNSS e informarem a capacidade aos aplicativos pela flag de recurso android.hardware.location.gps e a API de teste LocationManager.getGnssYearOfHardware() informar o ano "2016" ou mais recente, elas:

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

Se as implementações de dispositivos incluírem um receptor GPS/GNSS e informarem a capacidade aos aplicativos pela flag de recurso android.hardware.location.gps e a API de teste LocationManager.getGnssYearOfHardware() informar o ano "2017" ou mais recente, elas:

• [C-3-1] PRECISA continuar a fornecer saídas de localização de GPS/GNSS normais durante uma chamada de emergência.
• [C-3-2] PRECISA informar as medições de GNSS de todas as constelações rastreadas (conforme relatado nas mensagens de GnssStatus), com exceção do SBAS.
• [C-3-3] PRECISA informar o AGC e a frequência de medição do GNSS.
• [C-3-4] PRECISA informar todas as estimativas de precisão (incluindo rolamento, velocidade e vertical) como parte de cada localização GPS.

7.3.4. Giroscópio

Implementações de dispositivos:

• DEVE incluir um giroscópio (sensor de mudança angular).
• NÃO DEVE 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, elas:

• [C-1-1] PRECISA relatar eventos com uma frequência de pelo menos 50 Hz.
• [C-1-2] PRECISA implementar o sensor TYPE_GYROSCOPE e também DEVE implementar o sensor TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-3] PRECISA ser capaz de medir mudanças de orientação de até 1.000 graus por segundo.
• [C-1-4] PRECISA ter uma resolução de 12 bits ou mais e DEVE ter uma resolução de 16 bits ou mais.
• [C-1-5] PRECISA ser compensado pela temperatura.
• [C-1-6] PRECISA ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• [C-1-7] PRECISA ter uma variação não superior a 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar de acordo com a taxa de amostragem, mas PRECISA ser limitada por esse valor. Em outras palavras, se você medir a variância do giroscópio a uma taxa de amostragem de 1 Hz, ela DEVE ser no máximo 1e-7 rad^2/s^2.
• [SR] Dispositivos Android novos e já existentes são RECOMENDADOS PARA implementar o sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• [SR] O erro de calibração é RECOMENDADO tanto que seja menor que 0,01 rad/s quando o dispositivo estiver parado na temperatura ambiente.
• DEVE relatar eventos de até pelo menos 200 Hz.

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

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

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

• [C-3-1] PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION.
• [SR] Dispositivos Android novos e já existentes são RECOMENDADOS PARA implementar o sensor TYPE_GAME_ROTATION_VECTOR.
• DEVE implementar o sensor composto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

• As implementações de dispositivos DEVEM incluir um barômetro (sensor de pressão do ar ambiente).

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

• [C-1-1] PRECISA implementar e informar o sensor TYPE_PRESSURE.
• [C-1-2] PRECISA entregar eventos com frequência de 5 Hz ou mais.
• [C-1-3] PRECISA ser compensado pela temperatura.
• [SR] FORTEMENTE RECOMENDADO para informar medições de pressão no intervalo de 300 hPa a 1.100 hPa.
• DEVE ter uma precisão absoluta de 1hPa.
• DEVE ter uma precisão relativa de 0,12 hPa em uma faixa de 20 hPa (equivalente a uma precisão de ~1 m em uma mudança de ~200 m no nível do mar).

7.3.6. Termômetro

Implementações de dispositivos: Pode incluir um termômetro ambiente (sensor de temperatura). PODE, mas NÃO DEVE incluir um sensor de temperatura da CPU.

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

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

O tipo de sensor SENSOR_TYPE_TEMPERATURE foi descontinuado no Android 4.0.

7.3.7. Fotômetro

• As implementações de dispositivos PODEM incluir um fotômetro (sensor de luz ambiente).

7.3.8. Sensor de proximidade

• As implementações de dispositivos podem incluir um sensor de proximidade.

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

• [C-1-1] PRECISA medir a proximidade de um objeto na mesma direção que a tela. Ou seja, o sensor de proximidade PRECISA estar orientado para detectar objetos próximos à tela, já que a intenção principal desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se as implementações do dispositivo incluírem um sensor de proximidade com qualquer outra orientação, ele NÃO poderá ser acessado por essa API.
• [C-1-2] PRECISA ter 1 bit de precisão ou mais.

7.3.9. Sensores de alta fidelidade

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

• [C-1-1] PRECISA identificar o recurso pela flag de recurso android.hardware.sensor.hifi_sensors.

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

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

  • PRECISA ter um intervalo de medição entre pelo menos -8 g e +8 g.
  • PRECISA ter uma resolução de medição de pelo menos 1024 LSB/G.
  • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais.
  • PRECISA ter um ruído de medição não superior a 400 uG/cioneHz.
  • PRECISA implementar uma forma sem ativação deste sensor, com uma capacidade de armazenamento em buffer de pelo menos 3.000 eventos de sensor.
  • PRECISA ter um consumo de energia em lote não inferior a 3 mW.
  • DEVE ter uma estabilidade de viés de ruído estacionário de \<15 μg ≧Hz do conjunto de dados estático de 24 horas.
  • DEVE ter uma mudança de viés em comparação à temperatura ≤ +/- 1 mg / °C.
  • DEVE ter uma não linearidade de linha com melhor ajuste de ≤ 0,5%, e a mudança de sensibilidade x temperatura de ≤ 0,03%/C°.
  • DEVE ter espectro de ruído branco para garantir a qualificação adequada da integridade de ruído do sensor.

• [C-2-2] PRECISA ter um TYPE_ACCELEROMETER_UNCALIBRATED com os mesmos requisitos de qualidade do TYPE_ACCELEROMETER.

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

  • PRECISA ter um intervalo de medição entre -1.000 e +1.000 dps.
  • PRECISA ter uma resolução de medida de pelo menos 16 LSB/dps.
  • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 400 Hz ou mais.
  • PRECISA ter um ruído de medição não superior a 0,014°/s/concordate.
  • DEVE ter uma estabilidade de viés estacionária de < 0,0002 °/s cioneHz para o conjunto de dados estático de 24 horas.
  • DEVE ter uma mudança de viés x temperatura ≤ +/- 0,05 °/ s / °C.
  • DEVE ter uma mudança de sensibilidade x temperatura de ≤ 0,02% / °C.
  • DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,2%.
  • DEVE ter uma densidade de ruído menor ou igual a 0,007 °/s/shaped Hz.
  • DEVE ter espectro de ruído branco para garantir a qualificação adequada da integridade de ruído do sensor.
  • DEVE ter um erro de calibração inferior a 0,002 rad/s na faixa de temperatura de 10 ~ 40 °C quando o dispositivo estiver parado.

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

• [C-2-5] PRECISA ter um sensor TYPE_GEOMAGNETIC_FIELD que:
  • PRECISA ter um intervalo de medição entre -900 e +900 uT.
  • PRECISA ter uma resolução de medida de pelo menos 5 LSB/uT.
  • PRECISA ter uma frequência de medição mínima de 5 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 50 Hz ou mais.
  • PRECISA ter um ruído de medição menor que 0,5 uT.
• [C-2-6] PRECISA ter um TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade de TYPE_GEOMAGNETIC_FIELD, além de:
  • PRECISA implementar uma forma sem ativação deste sensor, com uma capacidade de armazenamento em buffer de pelo menos 600 eventos de sensor.
  • DEVE ter espectro de ruído branco para garantir a qualificação adequada da integridade de ruído do sensor.
• [C-2-7] PRECISA ter um sensor TYPE_PRESSURE que:
  • PRECISA ter um intervalo de medição entre 300 e 1.100 hPa.
  • PRECISA ter uma resolução de medida de pelo menos 80 LSB/hPa.
  • PRECISA ter uma frequência de medição mínima de 1 Hz ou menos.
  • PRECISA ter uma frequência de medição máxima de 10 Hz ou mais.
  • PRECISA ter um ruído de medição não superior a 2 Pa/cioneHz.
  • PRECISA implementar uma forma sem ativação deste sensor, com uma capacidade de armazenamento em buffer de pelo menos 300 eventos de sensor.
  • PRECISA ter um consumo de energia em lote não inferior a 2 mW.
• [C-2-8] PRECISA ter um sensor TYPE_GAME_ROTATION_VECTOR que:
  • PRECISA implementar uma forma sem ativação deste sensor, com uma capacidade de armazenamento em buffer de pelo menos 300 eventos de sensor.
  • PRECISA ter um consumo de energia em lote não inferior a 4 mW.
• [C-2-9] PRECISA ter um sensor TYPE_SIGNIFICANT_MOTION que:
  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.
• [C-2-10] PRECISA ter um sensor TYPE_STEP_DETECTOR que:
  • PRECISA implementar uma forma sem ativação deste sensor, com uma capacidade de armazenamento em buffer de pelo menos 100 eventos de sensor.
  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.
  • PRECISA ter um consumo de energia em lote não inferior a 4 mW.
• [C-2-11] PRECISA ter um sensor TYPE_STEP_COUNTER que:
  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.
• [C-2-12] PRECISA ter um sensor TILT_DETECTOR que:
  • PRECISA ter um consumo de energia não inferior a 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando ele estiver em movimento.
• [C-2-13] O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro, o sensor do giroscópio e o magnetômetro PRECISA estar a no máximo 2,5 milissegundos um do outro.
• [C-2-14] PRECISA ter carimbos de data/hora do evento do sensor do giroscópio na mesma base de horário que o subsistema da câmera e em 1 milissegundo de erro.
• [C-2-15] PRECISA entregar as amostras aos aplicativos em até cinco milissegundos a partir do momento em que os dados estão disponíveis em qualquer um dos sensores físicos acima para o aplicativo.
• [C-2-16] Não pode ter um consumo de energia maior que 0,5 mW quando o dispositivo está estático e 2,0 mW quando o dispositivo está em movimento quando qualquer combinação dos seguintes sensores está ativada:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] PODE ter um sensor TYPE_PROXIMITY, mas, se presente, PRECISA ter uma capacidade mínima de buffer de 100 eventos de sensor.

Observe que todos os requisitos de consumo de energia nesta seção não incluem o consumo de energia do processador do aplicativo. Ela inclui a potência puxada por toda a cadeia do sensor: o sensor, qualquer circuito de suporte, qualquer sistema de processamento de sensor dedicado etc.

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

• [C-3-1] PRECISA declarar corretamente o suporte aos tipos de canal direto e às taxas de subordinados diretos com as APIs isDirectChannelTypeSupported e getHighestDirectReportRateLevel.
• [C-3-2] PRECISA oferecer suporte a pelo menos um dos dois tipos de canal direto do sensor para todos os sensores que declaram suporte ao canal direto do sensor.
• TYPE_HARDWARE_BUFFER
• TYPE_MEMORY_FILE
• DEVE oferecer suporte a relatórios de eventos pelo canal direto do sensor para o sensor principal (variante sem ativação) dos seguintes tipos:
• TYPE_ACCELEROMETER
• TYPE_ACCELEROMETER_UNCALIBRATED
• TYPE_GYROSCOPE
• TYPE_GYROSCOPE_UNCALIBRATED
• TYPE_MAGNETIC_FIELD
• TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensor de impressão digital

Se as implementações de dispositivos incluírem uma tela de bloqueio segura, elas:

• DEVE incluir um sensor de impressão digital.

Se as implementações do dispositivo incluírem um sensor de impressão digital e disponibilizarem o sensor para apps de terceiros, elas:

• [C-1-1] PRECISA declarar suporte ao recurso android.hardware.fingerprint.
• [C-1-2] PRECISA implementar totalmente a API correspondente, conforme descrito na documentação do SDK do Android.
• [C-1-3] PRECISA ter uma taxa de aceitação falsa menor que 0,002%.
• [SR] É MUITO RECOMENDADO que tenham uma taxa de aceitação de impostor e de spoofing não superior a 7%.
• [C-1-4] DEVE divulgar que esse modo pode ser menos seguro que um PIN, padrão ou senha fortes e enumerar claramente os riscos de ativá-lo, se as taxas de aceitação de spoofing e impostores forem superiores a 7%.
• [C-1-5] OBRIGATÓRIO as tentativas de limite de taxa por pelo menos 30 segundos após cinco testes falsos para a verificação de impressão digital.
• [C-1-6] PRECISA ter uma implementação de keystore protegido por hardware e realizar a correspondência de impressão digital em um ambiente de execução confiável (TEE) ou em um chip com um canal seguro para o TEE.
• [C-1-7] PRECISA ter todos os dados de impressão digital identificáveis criptografados e autenticados criptograficamente para que não possam ser adquiridos, lidos ou alterados fora do ambiente de execução confiável (TEE), conforme documentado nas diretrizes de implementação no site do Android Open Source Project.
• [C-1-8] PRECISA evitar a adição de uma impressão digital sem antes estabelecer uma cadeia de confiança, pedindo para o usuário confirmar a existência ou adicionar uma nova credencial do dispositivo (PIN/padrão/senha) protegida pelo TEE. A implementação do Android Open Source Project fornece o mecanismo no framework para fazer isso.
• [C-1-9] NÃO PODE permitir que aplicativos de terceiros façam distinção entre impressões digitais individuais.
• [C-1-10] PRECISA respeitar a flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• [C-1-11] , quando atualizado de uma versão anterior ao Android 6.0, PRECISA ter os dados de impressão digital migrados com segurança para atender aos requisitos acima ou removidos.
• [SR] É RECOMENDADO que tenham uma taxa de rejeição falsa menor que 10%, conforme medida no dispositivo.
• [SR] É FORTEMENTE RECOMENDADO que tenham uma latência inferior a 1 segundo, medida a partir do momento em que o sensor de impressão digital é tocado até a tela ser desbloqueada, para um dedo registrado.
• DEVE usar o ícone de impressão digital do Android fornecido no Android Open Source Project.

7.3.11. Sensores exclusivos do Android Automotive

Sensores específicos para automóveis são definidos no android.car.CarSensorManager API.

7.3.11.1. Engrenagem atual

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

7.3.11.2. Modo dia/noite

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

7.3.11.3. Status de condução

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

7.3.11.4. Velocidade da roda

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

7.3.12. Sensor de posição

Implementações de dispositivos:

• PODE suportar o sensor de pose com 6 graus de liberdade.

Se as implementações de dispositivos oferecerem suporte a sensores de posição com 6 graus de liberdade, elas:

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

7,4. Conectividade de dados

7.4.1. Telefonia

A "telefonia", conforme usada pelas APIs do Android, e neste documento, se refere especificamente ao hardware relacionado à realização de chamadas de voz e ao envio de mensagens SMS por uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ter comutação por pacote, elas são para fins do Android consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade de “telefonia” do Android e as APIs referem-se especificamente a chamadas de voz e SMS. Por exemplo, implementações de dispositivos que não podem fazer chamadas ou enviar/receber mensagens SMS não são consideradas dispositivos de telefonia, independentemente de usarem uma rede celular para conectividade de dados.

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

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

• [C-1-1] PRECISA declarar a flag de recurso android.hardware.telephony e outras flags de recursos secundários de acordo com a tecnologia.
• [C-1-2] PRECISA implementar o suporte completo da API para essa tecnologia.

Se as implementações de dispositivos não incluírem hardware de telefonia, elas:

• [C-2-1] PRECISA implementar as APIs completas como ambiente autônomo.

7.4.1.1 Compatibilidade com bloqueio de número

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

• [C-1-1] PRECISA incluir suporte para bloqueio de número
• [C-1-2] PRECISA implementar totalmente o BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.
• [C-1-3] PRECISA bloquear todas as chamadas e mensagens de um número de telefone em "BlockedNumberProvider" sem nenhuma interação com apps. A única exceção é quando o bloqueio de números é temporariamente suspenso, conforme descrito na documentação do SDK.
• [C-1-4] NÃO PODE gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada.
• [C-1-5] NÃO É POSSÍVEL gravar uma mensagem bloqueada no provedor de telefonia.
• [C-1-6] PRECISA implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada pelo método TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NÃO PODE permitir que usuários secundários acessem ou editem os números bloqueados no dispositivo, porque a plataforma Android pressupõe que o usuário principal tem controle total dos serviços de telefonia, uma única instância, no dispositivo. Todas as IUs relacionadas ao bloqueio PRECISAM ser ocultadas para usuários secundários e a lista de bloqueio PRECISA ser respeitada.
• DEVE migrar os números bloqueados para o provedor quando um dispositivo for atualizado para o Android 7.0.

7.4.1.2 API Telecom

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

• [C-SR] É MUITO RECOMENDADO para processar os eventos KEYCODE_MEDIA_PLAY_PAUSE e KEYCODE_HEADSETHOOK do fone de ouvido para as APIs android.telecom, conforme mostrado abaixo:
  • Chame Connection.onDisconnect() quando um toque curto do evento de tecla for detectado durante uma chamada em andamento.
  • Chame Connection.onAnswer() quando um toque curto do evento de tecla for detectado durante uma ligação recebida.
  • Chame Connection.onReject() quando um evento de tecla for pressionado durante uma ligação recebida.
  • Ativar ou desativar o som de CallAudioState

7.4.2. IEEE 802.11 (Wi-Fi)

Implementações de dispositivos:

• DEVE incluir suporte para uma ou mais formas de 802.11.

Se as implementações de dispositivos incluírem suporte para 802.11 e exporem a funcionalidade a um aplicativo de terceiros, elas

• [C-1-1] PRECISA implementar a API do Android correspondente.
• [C-1-2] PRECISA informar a flag de recurso de hardware android.hardware.wifi.
• [C-1-3] PRECISA implementar a API multicast, conforme descrito na documentação do SDK.
• [C-1-4] PRECISA oferecer suporte a multicast DNS (mDNS) e NÃO PODE filtrar pacotes mDNS (224.0.0.251) em qualquer momento de operação, incluindo:
  • Mesmo quando a tela não está ativa.
  • Para implementações de dispositivos Android Television, mesmo quando em espera.
• DEVE randomizar o endereço MAC de origem e o número de sequência dos frames de solicitação de sondagem, uma vez no início de cada verificação, enquanto o STA estiver desconectado.
  • Cada grupo de frames de solicitação de sondagem que compreende uma verificação deve usar um endereço MAC consistente (NÃO DEVE randomizar o endereço MAC no meio da verificação).
  • O número de sequência da solicitação de sondagem deve iterar normalmente (sequencialmente) entre as solicitações de sondagem em uma verificação
  • O número da sequência da solicitação da sondagem deve ser aleatório entre a última solicitação de sondagem de uma verificação e a primeira solicitação de sondagem da próxima verificação
• DEVE permitir apenas os seguintes elementos de informação nos frames de solicitação de sondagem enquanto o STA estiver desconectado:
  • Conjunto de parâmetros do SSID (0)
  • Conjunto de parâmetros do DS (3)

7.4.2.1. Wi-Fi Direct

Implementações de dispositivos:

• DEVE incluir suporte para Wi-Fi Direct (Wi-Fi ponto a ponto).

Se as implementações de dispositivos forem compatíveis com Wi-Fi Direct, elas:

• [C-1-1] PRECISA implementar a API Android correspondente, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA informar o recurso de hardware android.hardware.wifi.direct.
• [C-1-3] PRECISA permitir o funcionamento normal do Wi-Fi.
• DEVE oferecer suporte a operações de Wi-Fi e Wi-Fi Direct simultaneamente.

7.4.2.2. Configuração de link direto encapsulado Wi-Fi

Implementações de dispositivos:

• DEVE incluir suporte à Configuração de link direto com túnel de Wi-Fi (TDLS, na sigla em inglês), conforme descrito na Documentação do SDK do Android.

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

• [C-1-1] PRECISA declarar suporte a TDLS por meio de WifiManager.isTdlsSupported.
• DEVE usar TDLS apenas quando for possível E benéfico.
• DEVE ter alguma heurística e NÃO usar TDLS quando seu desempenho for pior do que passar pelo ponto de acesso Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementações de dispositivos:

• DEVE incluir compatibilidade com o Wi-Fi Aware.

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

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

7.4.2.4. Passpoint do Wi-Fi

Implementações de dispositivos:

• DEVE incluir suporte para o Passpoint de Wi-Fi.

Se as implementações de dispositivos forem compatíveis com Passpoint do Wi-Fi, elas:

• [C-1-1] PRECISA implementar as APIs WifiManager relacionadas ao Passpoint, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA oferecer suporte ao padrão IEEE 802.11u, especificamente relacionado à descoberta e seleção de rede, como o Generic Publicidade Service (GAS) e o Access Network Query Protocol (ANQP).

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

• [C-2-1] A implementação das APIs WifiManager relacionadas ao Passpoint PRECISA gerar uma UnsupportedOperationException.

7.4.3. Bluetooth

Se as implementações de dispositivos oferecerem suporte ao perfil de áudio Bluetooth, elas:

• DEVE oferecer suporte a codecs de áudio avançados e codecs de áudio Bluetooth (por exemplo, LDAC).

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

• [C-1-1] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia.

Se as implementações de dispositivos incluírem suporte para Bluetooth e Bluetooth Low Energy, elas:

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

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

• [C-3-1] PRECISA declarar o recurso de hardware android.hardware.bluetooth_le.
• [C-3-2] PRECISA ativar as APIs Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e em android.bluetooth.
• [C-3-3] PRECISA informar o valor correto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar se a lógica de filtragem das classes da API ScanFilter está implementada.
• [C-3-4] PRECISA informar o valor correto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar se a publicidade de baixa energia é compatível.
• DEVE oferecer suporte ao descarregamento da lógica de filtragem para o chipset Bluetooth ao implementar a API ScanFilter.
• DEVE oferecer suporte ao descarregamento da leitura em lote para o chipset Bluetooth.

• DEVE ser compatível com vários anúncios com pelo menos quatro espaços.

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

7.4.4. Comunicação a curta distância (NFC, na sigla em inglês)

Implementações de dispositivos:

• DEVE incluir um transceptor e hardware relacionado para comunicação a curta distância (NFC, na sigla em inglês).
• [C-0-1] PRECISA implementar as APIs android.nfc.NdefMessage e android.nfc.NdefRecord, mesmo que não incluam suporte a NFC ou declarem o recurso android.hardware.nfc, já que as classes representam um formato de representação de dados independente de protocolo.

Se as implementações de dispositivos incluírem hardware NFC e planejam disponibilizá-lo para apps de terceiros, elas:

• [C-1-1] PRECISA informar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature().
• PRECISA ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões NFC, conforme mostrado abaixo:
• [C-1-2] PRECISA ser capaz de atuar como leitor/gravador do NFC Forum (conforme definido pela especificação técnica NFCForum-TS-Digital Protocol-1.0) do NFC Forum pelos seguintes padrões NFC:
• NfcA (ISO14443-3A)
• NfcB (ISO14443-3B)
• NfcF (JIS X 6.319-4)
• IsoDep (ISO 14443-4)
• Tipos de tag do fórum NFC 1, 2, 3, 4, 5 (definidos pelo fórum NFC)

• [SR] FORTEMENTE RECOMENDADO que seja capaz de ler e gravar mensagens NDEF, além de dados brutos, usando os seguintes padrões NFC. Observe que, embora os padrões NFC sejam indicados como FORTEMENTE RECOMENDADOS, a definição de compatibilidade para uma versão futura pretende alterá-los para PRECISA. Esses padrões são opcionais nesta versão, mas serão necessários em versões futuras. Recomendamos que os dispositivos atuais e novos que executam essa versão do Android atendam a esses requisitos agora para poderem fazer upgrade para as próximas versões da plataforma.

• [C-1-3] PRECISA ser capaz de transmitir e receber dados pelos seguintes padrões e protocolos ponto a ponto:

• ISO 18092
• LLCP 1.2 (definido pelo fórum de NFC)
• SDP 1.0 (definido pelo fórum de NFC)
• Protocolo push NDEF
• SNEP 1.0 (definido pelo fórum de NFC)
• [C-1-4] PRECISA incluir suporte para o Android Beam e DEVE ativar o Android Beam por padrão.
• [C-1-5] PRECISA ser capaz de enviar e receber usando o Android Beam, quando o Android Beam está ativado ou outro modo NFC P2p reservado está ativado.
• [C-1-6] PRECISA implementar o servidor padrão SNEP. Mensagens NDEF válidas recebidas pelo servidor SNEP padrão PRECISAM ser enviadas aos aplicativos usando o intent android.nfc.ACTION_NDEF_DISCOVERED. A desativação do Android Beam nas configurações NÃO PODE desativar o envio de mensagens NDEF recebidas.
• [C-1-7] PRECISA respeitar a intent android.settings.NFCSHARING_SETTINGS para mostrar as configurações de compartilhamento de NFC.
• [C-1-8] PRECISA implementar o servidor NPP. As mensagens recebidas pelo servidor NPP PRECISAM ser processadas da mesma forma que o servidor padrão SNEP.
• [C-1-9] PRECISA implementar um cliente SNEP e tentar enviar o NDEF P2P de saída ao servidor SNEP padrão quando o Android Beam estiver ativado. Se nenhum servidor SNEP padrão for encontrado, o cliente DEVE tentar enviar para um servidor NPP.
• [C-1-10] PRECISA permitir que as atividades em primeiro plano definam a mensagem NDEF P2P de saída usando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback e android.nfc.NfcAdapter.enableForegroundNdefPush.
• DEVE usar um gesto ou confirmação na tela, como "Tocar para enviar", antes de enviar mensagens NDEF P2P.
• [C-1-11] PRECISA oferecer suporte à transferência de conexão NFC para Bluetooth quando o dispositivo tiver suporte ao perfil de push de objeto Bluetooth.
• [C-1-12] PRECISA oferecer suporte à transferência de conexão para Bluetooth ao usar o android.nfc.NfcAdapter.setBeamPushUris, implementando as especificações "Transferência de conexão versão 1.2" e "Pareamento simples Bluetooth seguro usando NFC versão 1.0" do fórum sobre NFC. Essa implementação PRECISA implementar o serviço LLCP de transferência com o nome de serviço “urn:nfc:sn:handover” para trocar os registros de solicitação/seleção de entrega por NFC e PRECISA usar o perfil de push de objeto Bluetooth para a transferência de dados Bluetooth real. Por motivos legados (para permanecer compatível com dispositivos Android 4.1), a implementação ainda DEVE aceitar solicitações GET SNEP para trocar a solicitação de entrega/registros selecionados por NFC. No entanto, uma implementação em si NÃO DEVE enviar solicitações SNEP GET para realizar a transferência de conexão.
• [C-1-13] PRECISA pesquisar todas as tecnologias compatíveis no modo de descoberta NFC.
• DEVE estar no modo de descoberta NFC enquanto o dispositivo estiver ativado com a tela ativa e a tela de bloqueio desbloqueada.
• DEVE ser capaz de ler o código de barras e o URL (se codificado) de produtos Thinfilm NFC Barcode.

(Observe que links disponíveis publicamente não estão disponíveis para as especificações JIS, ISO e NFC Forum citadas acima.)

O Android inclui suporte ao modo de emulação de cartão host de NFC (HCE, na sigla em inglês).

Se as implementações do dispositivo incluírem um chipset de controlador NFC capaz de HCE (para NfcA e/ou NfcB) e oferecerem suporte ao roteamento de ID do aplicativo (AID), elas:

• [C-2-1] PRECISA informar a constante de recurso android.hardware.nfc.hce.
• [C-2-2] PRECISA oferecer suporte às APIs NFC HCE, conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem um chipset controlador NFC capaz de HCE para NfcF e implementarem o recurso para aplicativos de terceiros, elas:

• [C-3-1] PRECISA informar a constante de recurso android.hardware.nfc.hcef.
• [C-3-2] PRECISA implementar as APIs de emulação de cartão NfcF, conforme definido no SDK do Android.

Se as implementações de dispositivos incluírem suporte geral a NFC conforme descrito nesta seção e forem compatíveis com tecnologias MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF no MIFARE Classic) na função de leitor/gravador, elas:

• [C-4-1] PRECISA implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
• [C-4-2] É NECESSÁRIO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). Esse não é um recurso padrão do Android e, portanto, não aparece como uma constante na classe android.content.pm.PackageManager.

7.4.5. Capacidade mínima de rede

Implementações de dispositivos:

• [C-0-1] PRECISA incluir suporte para uma ou mais formas de rede de dados. Especificamente, as implementações de dispositivos PRECISAM incluir suporte a pelo menos um padrão de dados com capacidade de 200 Kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN etc.
• [C-0-2] PRECISA incluir uma pilha de rede IPv6 e oferecer suporte à comunicação IPv6 usando as APIs gerenciadas, como java.net.Socket e java.net.URLConnection, além das APIs nativas, como soquetes AF_INET6.
• [C-0-3] PRECISA ativar o IPv6 por padrão.
• PRECISA garantir que a comunicação com o IPv6 seja tão confiável quanto com o IPv4, por exemplo.
• [C-0-4] PRECISA manter a conectividade IPv6 no modo Soneca.
• [C-0-5] A limitação de taxa NÃO PODE fazer o dispositivo perder conectividade IPv6 em qualquer rede compatível com IPv6 que use ciclos de vida de RA de pelo menos 180 segundos.
• Também DEVE incluir suporte para pelo menos um padrão de dados sem fio comum, como 802.11 (Wi-Fi), quando um padrão de rede física (como Ethernet) for a conexão de dados principal
• PODE implementar mais de uma forma de conectividade de dados.

O nível obrigatório de suporte a IPv6 depende do tipo de rede, da seguinte maneira:

Se as implementações de dispositivos forem compatíveis com redes 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 oferecerem suporte a redes Ethernet, elas:

• [C-2-1] PRECISA oferecer suporte à operação de pilha dupla na Ethernet.

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

• [C-3-1] PRECISA atender simultaneamente a esses requisitos em cada rede a que está conectado quando um dispositivo está conectado simultaneamente a mais de uma rede (por exemplo, Wi-Fi e dados móveis).
• DEVE oferecer suporte à operação IPv6 (somente IPv6 e possivelmente de pilha dupla) nos dados da rede celular.

7.4.6. Configurações de sincronização

Implementações de dispositivos:

• [C-0-1] PRECISA manter a configuração de sincronização automática principal ativada por padrão para que o método getMasterSyncAutomatically() retorne "true".

7.4.7. Economia de dados

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

• [SR] RECOMENDADO FORTEMENTE para fornecer o modo de Economia de dados.

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

• [C-1-1] PRECISA oferecer suporte a todas as APIs na classe ConnectivityManager, conforme descrito na documentação do SDK.
• [C-1-2] PRECISA fornecer uma interface do usuário nas configurações que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, permitindo que os usuários adicionem ou removam aplicativos da lista de permissões.

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

• [C-2-1] PRECISA retornar o valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().
• [C-2-2] NÃO PODE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] PRECISA ter uma atividade que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mas PODE a implementar como um ambiente autônomo.

7,5. Câmeras

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

• [C-1-1] PRECISA declarar a flag de recurso android.hardware.camera.any.
• [C-1-2] PRECISA ser possível para um aplicativo alocar simultaneamente 3 bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo sensor da câmera de maior resolução no dispositivo, enquanto a câmera está aberta para fins de visualização básica e captura.

7.5.1. Câmera traseira

Uma câmera traseira é uma câmera localizada na lateral do dispositivo oposta à tela, ou seja, ela captura cenas no outro lado do dispositivo, como uma câmera tradicional.

Implementações de dispositivos:

• DEVE incluir uma câmera traseira.

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

• [C-1-1] PRECISA informar a flag de recurso android.hardware.camera e android.hardware.camera.any.
• [C-1-2] PRECISA ter uma resolução de pelo menos 2 megapixels.
• DEVE ter foco automático por hardware ou por software implementado no driver da câmera (transparente ao software do aplicativo).
• PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida).
• PODE incluir um flash.

Se a Câmera incluir um flash:

• [C-2-1] A lâmpada NÃO PODE ser acesa enquanto uma instância android.hardware.Camera.PreviewCallback tiver sido registrada em uma superfície de visualização da Câmera, a menos que o app tenha ativado explicitamente o flash ativando os atributos FLASH_MODE_AUTO ou FLASH_MODE_ON de um objeto Camera.Parameters. Essa restrição não se aplica ao aplicativo integrado de câmera do sistema do dispositivo, apenas a aplicativos de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela, ou seja, uma câmera normalmente usada para imagens do usuário, por exemplo, para videoconferências e aplicativos semelhantes.

Implementações de dispositivos:

• PODE incluir uma câmera frontal

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

• [C-1-1] PRECISA informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
• [C-1-2] PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
• [C-1-3] NÃO PODE usar uma câmera frontal como padrão para a API Camera nem configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera no dispositivo.
• [C-1-5] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo quando o aplicativo atual tiver solicitado explicitamente que a tela da câmera seja girada por meio de uma chamada para o método android.hardware.Camera.setDisplayOrientation(). Por outro lado, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo quando o aplicativo atual não solicita explicitamente que a tela da câmera seja girada com uma chamada para o método android.hardware.Camera.setDisplayOrientation().
• [C-1-6] NÃO É POSSÍVEL espelhar os streams finais de vídeo ou imagem estática capturados que foram retornados para callbacks do aplicativo nem confirmados para armazenamento de mídia.
• [C-1-7] PRECISA espelhar a imagem mostrada pela pós-visualização da mesma forma que o stream de imagem de visualização da câmera.
• PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.

Se as implementações do dispositivo puderem ser giradas pelo usuário (por exemplo, automaticamente por meio de um acelerômetro ou manualmente por entrada do usuário):

• [C-2-1] A visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação atual do dispositivo.

7.5.3. Câmera externa

Implementações de dispositivos:

• PODE incluir suporte para uma câmera externa que nem sempre está conectada.

Se as implementações de dispositivos forem compatíveis com uma câmera externa, elas:

• [C-1-1] PRECISA declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
• [C-1-2] PRECISA oferecer suporte à classe de vídeo USB (UVC 1.0 ou mais recente) se a câmera externa se conectar pela porta USB.
• DEVE oferecer suporte a compactação de vídeo, como MJPEG, para permitir a transferência de streams de alta qualidade não codificados (ou seja, streams de imagens brutos ou comprimidos de forma independente).
• PODE oferecer suporte a várias câmeras.
• PODE oferecer suporte à codificação de vídeo baseada em câmera. Se compatível, um stream MJPEG simultâneo não codificado (QVGA ou resolução superior) PRECISA estar acessível na implementação do dispositivo.

7.5.4. Comportamento da API Camera

O Android inclui dois pacotes de API para acessar a câmera, a API android.hardware.camera2 mais recente expõe o controle de câmera de nível inferior ao app, incluindo fluxos eficientes de burst/streaming de cópia zero e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, remoção de ruído, nitidez e muito mais.

O pacote de API mais antigo, android.hardware.Camera, está marcado como descontinuado no Android 5.0, mas ainda deve estar disponível para uso dos apps. As implementações de dispositivos Android PRECISAM garantir o suporte contínuo da API, conforme descrito nesta seção e no SDK do Android.

As implementações de dispositivos PRECISAM implementar os seguintes comportamentos para as APIs relacionadas à câmera em todas as câmeras disponíveis. Implementações de dispositivos:

• [C-0-1] PRECISA usar android.hardware.PixelFormat.YCbCr_420_SP para dados de visualização fornecidos aos callbacks de aplicativos quando um aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] PRECISA estar ainda no formato de codificação NV21 quando um aplicativo registra uma instância android.hardware.Camera.PreviewCallback e o sistema chama o método onPreviewFrame() e o formato de visualização é YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame(). Ou seja, NV21 PRECISA ser o padrão.
• [C-0-3] PRECISA oferecer suporte ao formato YV12, conforme indicado pela constante android.graphics.ImageFormat.YV12, para visualizações da câmera frontal e traseira para android.hardware.Camera. O codificador de vídeo do hardware e a câmera podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA ser compatível com a conversão para YV12.
• [C-0-4] PRECISA oferecer suporte aos formatos android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG como saídas pela API android.media.ImageReader para dispositivos android.hardware.camera2 que anunciam o recurso REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE no android.request.availableCapabilities.
• [C-0-5] Ainda PRECISA implementar a API Camera completa incluída na documentação do SDK do Android, independente de o dispositivo incluir foco automático de hardware ou outros recursos. Por exemplo, câmeras que não têm foco automático PRECISAM chamar instâncias android.hardware.Camera.AutoFocusCallback registradas, mesmo que isso não seja relevante para câmeras sem foco automático. Observe que isso se aplica a câmeras frontais. Por exemplo, mesmo que a maioria das câmeras frontais não tenha suporte ao autofoco, os retornos de chamada da API ainda devem ser “falsos”, conforme descrito.
• [C-0-6] PRECISA reconhecer e respeitar cada nome de parâmetro definido como uma constante na classe android.hardware.Camera.Parameters. Por outro lado, as implementações de dispositivos NÃO PODEM respeitar ou reconhecer constantes de string transmitidas ao método android.hardware.Camera.setParameters() além das documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos PRECISAM oferecer suporte a todos os parâmetros padrão de Câmera, se o hardware permitir, e NÃO PODEM oferecer suporte a tipos personalizados de parâmetros de Câmera. Por exemplo, as implementações de dispositivos que oferecem suporte à captura de imagens usando técnicas de geração de imagens de High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera Camera.SCENE_MODE_HDR.
• [C-0-7] PRECISA informar o nível adequado de suporte com a propriedade android.info.supportedHardwareLevel, conforme descrito no SDK do Android, e informar as sinalizações de recurso do framework adequadas.
• [C-0-8] Também PRECISA declarar os recursos individuais da câmera de android.hardware.camera2 pela propriedade android.request.availableCapabilities e declarar as flags de recursos adequadas. É NECESSÁRIO definir a flag de recurso se algum dos dispositivos de câmera conectados oferecer suporte ao recurso.
• [C-0-9] PRECISA transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada dela tiver sido adicionada ao armazenamento de mídia.
• [C-0-10] PRECISA transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da imagem tiver sido adicionada ao armazenamento de mídia.

7.5.5. Orientação da câmera

Se as implementações do dispositivo tiverem uma câmera frontal ou traseira, tais câmeras:

• [C-1-1] PRECISA estar orientada para que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é mantido na orientação paisagem, as câmeras PRECISAM capturar imagens na orientação paisagem. Isso se aplica independentemente da orientação natural do dispositivo, ou seja, é aplicado a dispositivos com modo paisagem e modo retrato principal.

7,6. Memória e armazenamento

7.6.1. Mínimo de memória e armazenamento

Implementações de dispositivos:

• [C-0-1] PRECISA incluir um Gerenciador de downloads que os aplicativos possam usar para fazer o download de arquivos de dados. Além disso, PRECISAM ser capazes de fazer o download de arquivos individuais com pelo menos 100 MB no local padrão de "cache".

7.6.2. Armazenamento compartilhado do aplicativo

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer armazenamento para ser compartilhado por aplicativos, também conhecido como "armazenamento externo compartilhado", "armazenamento compartilhado do aplicativo" ou pelo caminho do Linux "/sdcard" no qual está montado.
• [C-0-2] PRECISA ser configurado com o armazenamento compartilhado montado por padrão, ou seja, "fora da caixa", independentemente de o armazenamento ser implementado em um componente de armazenamento interno ou em um meio de armazenamento removível (por exemplo, slot de cartão Secure Digital).
• [C-0-3] É NECESSÁRIO montar o armazenamento compartilhado do aplicativo diretamente no caminho sdcard do Linux ou incluir um link simbólico do Linux de sdcard para o ponto de montagem real.
• [C-0-4] PRECISA aplicar a permissão android.permission.WRITE_EXTERNAL_STORAGE nesse armazenamento compartilhado, conforme documentado no SDK. O armazenamento compartilhado PRECISA ser gravável por qualquer aplicativo que receba essa permissão.

As implementações de dispositivos PODEM atender aos requisitos acima usando:

• um armazenamento removível acessível ao usuário, como um slot para cartão SD (Secure Digital).
• uma parte do armazenamento interno (não removível), conforme implementado no Android Open Source Project (AOSP).

Se as implementações de dispositivos usarem o armazenamento removível para atender aos requisitos acima, elas:

• [C-1-1] PRECISA implementar uma interface do usuário de aviso ou pop-up alertando o usuário quando não há mídia de armazenamento inserida no slot.
• [C-1-2] PRECISA incluir uma mídia de armazenamento com formato FAT (por exemplo, cartão SD) ou mostrar na caixa e em outros materiais disponíveis no momento da compra. Esses materiais precisam ser comprados separadamente.

Se as implementações de dispositivos usarem uma proporção do armazenamento não removível para atender aos requisitos acima, elas:

• DEVE usar a implementação do AOSP do armazenamento compartilhado interno do app.
• PODE compartilhar o espaço de armazenamento com os dados privados do aplicativo.

Se as implementações do dispositivo incluírem vários caminhos de armazenamento compartilhado (como um slot para cartão SD e armazenamento interno compartilhado), elas:

• [C-3-1] PRECISA permitir que apenas apps Android pré-instalados e privilegiados com a permissão WRITE_EXTERNAL_STORAGE façam gravações no armazenamento externo secundário, exceto ao gravar nos diretórios específicos do pacote ou no URI retornado pelo disparo da intent ACTION_OPEN_DOCUMENT_TREE.

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

• [C-3-1] PRECISA fornecer um mecanismo para acessar os dados no armazenamento compartilhado do aplicativo em um computador host.
• DEVE expor o conteúdo dos dois caminhos de armazenamento de forma transparente usando o serviço de verificação de mídia do Android e o android.provider.MediaStore.
• PODE usar armazenamento USB em massa, mas DEVE usar o Media Transfer Protocol para atender a esse requisito.

Se as implementações de dispositivos tiverem uma porta USB com modo de periférico USB e aceitarem o protocolo de transferência de mídia, elas:

• DEVE ser compatível com o host de referência do Android MTP, a Transferência de arquivos do Android.
• DEVE informar uma classe de dispositivo USB de 0x00.
• DEVE informar um nome de interface USB de "MTP".

7.6.3. Armazenamento adotável

Se se espera que o dispositivo seja de natureza móvel, diferentemente da televisão, as implementações de dispositivo são:

• [SR] RECOMENDADO ALTAMENTE a implementação do armazenamento adotável em um local estável de longo prazo, já que desconectá-los acidentalmente pode causar perda/corrupção de dados.

Se a porta do dispositivo de armazenamento removível estiver em um local estável a longo prazo, como dentro do compartimento da bateria ou de outra tampa protetora, as implementações do dispositivo serão:

• [SR] RECOMENDADO ALTAMENTE a implementação do armazenamento adotável.

7,7. USB

Se as implementações de dispositivos tiverem uma porta USB, elas:

• DEVE oferecer suporte ao modo de periférico USB e DEVE oferecer suporte ao modo host USB.

7.7.1. Modo USB periférico

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo de periféricos:

• [C-1-1] A porta PRECISA estar conectada a um host USB que tenha uma porta USB padrão tipo A ou tipo C.
• [C-1-2] PRECISA informar o valor correto de iSerialNumber no descritor de dispositivo USB padrão usando android.os.Build.SERIAL.
• [C-1-3] PRECISA detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão da resistência Type-C e PRECISA detectar alterações no anúncio caso eles ofereçam suporte a USB Type-C.
• [SR] A porta DEVE usar o formato USB micro-B, micro-AB ou tipo C. É altamente RECOMENDADO que dispositivos Android novos e existentes atendam a esses requisitos para que possam fazer upgrade para as próximas versões da plataforma.
• [SR] A porta DEVE estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação da tela do software para todos os apps (inclusive a tela inicial), para que a tela mostre corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É altamente RECOMENDADO que dispositivos Android novos e existentes atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
• [SR] DEVE implementar suporte para acionar corrente de 1,5 A durante o sinal de luz HS e o tráfego, conforme especificado na Especificação de carregamento de bateria USB, revisão 1.2. É altamente RECOMENDADO que dispositivos Android novos e existentes atendam a esses requisitos para que possam fazer upgrade para as próximas versões da plataforma.
• [SR] RECOMENDADO NÃO oferecer suporte a métodos de carregamento proprietários que modifiquem a tensão do Vbus além dos níveis padrão ou alterem as funções do coletor/fonte. Isso pode resultar em problemas de interoperabilidade com os carregadores ou dispositivos compatíveis com os métodos padrão de fornecimento de energia USB. Embora isso seja chamado de "Fortemente RECOMENDADO", em versões futuras do Android, poderemos EXIGIR que todos os dispositivos type-C ofereçam suporte total à interoperabilidade com carregadores padrão tipo C.
• [SR] FORTEMENTE RECOMENDADO para oferecer suporte ao Power Delivery para troca de papéis de energia e dados quando houver suporte para o modo host USB e USB Type-C.
• DEVE oferecer suporte ao Power Delivery para carregamento de alta tensão e suporte a Modos Alternativos, como saída de tela.
• DEVE implementar a API e a especificação do Android Open Accessory (AOA), conforme documentado na documentação do SDK do Android.

Se as implementações de dispositivos, incluindo uma porta USB, forem implementadas:

• [C-2-1] PRECISA declarar suporte ao recurso de hardware android.hardware.usb.accessory.
• [C-2-2] A classe de armazenamento em massa USB PRECISA incluir a string "android" no fim da string iInterface de descrição da interface do armazenamento USB em massa.

7.7.2. Modo host USB

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

• [C-1-1] PRECISA implementar a API de host USB do Android, conforme documentado no SDK do Android, e PRECISA declarar suporte ao recurso de hardware android.hardware.usb.host.
• [C-1-2] PRECISA implementar o suporte para conectar periféricos USB padrão. Em outras palavras, é NECESSÁRIO:
  • Ter uma porta tipo C no dispositivo ou enviar com cabos adaptando uma porta proprietária no dispositivo a uma porta USB-C padrão (dispositivo USB-C).
  • Ter um dispositivo do tipo A ou enviar com cabos adaptando uma porta proprietária no dispositivo a uma porta USB tipo A padrão.
  • Ter uma porta micro-AB no dispositivo, que DEVE ser enviada com um cabo que se adapta a uma porta padrão tipo A.
• [C-1-3] NÃO PODE enviar com um adaptador que converta de portas USB tipo A ou micro-AB para uma porta tipo C (receptáculo).
• [SR] É MUITO RECOMENDADO implementar a classe de áudio USB, conforme documentado na documentação do SDK do Android.
• DEVE oferecer suporte ao carregamento do dispositivo periférico USB conectado no modo host, divulgando uma fonte de corrente de pelo menos 1,5 A, conforme especificado na seção "Parâmetros de terminação" da Revisão 1.2 do cabo e da especificação do conector USB-C para conectores USB-C ou usando o intervalo atual de saída da porta de encaminhamento de carregamento(CDP, na sigla em inglês), conforme especificado nas Especificações de carregamento de bateria USB-AB, revisão 1.2.
• DEVE implementar e oferecer suporte aos padrões USB-C.

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

• [C-2-1] PRECISA oferecer suporte à classe HID USB.
• [C-2-2] PRECISA oferecer suporte à detecção e ao mapeamento dos seguintes campos de dados HID especificados nas Tabelas de uso de HID USB e a Solicitação de uso do Voice Command para as constantes KeyEvent, conforme mostrado abaixo:
  • ID de uso da página de uso (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • ID de uso da página de uso (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • ID de uso da página de uso (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • ID de uso da página de uso (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Se as implementações de dispositivos incluírem uma porta USB compatível com o modo host e o Framework de acesso ao armazenamento (SAF, na sigla em inglês), elas:

• [C-3-1] PRECISA reconhecer qualquer dispositivo MTP (protocolo de transferência de mídia) conectado remotamente e tornar o conteúdo acessível pelas intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT. .

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

• [C-4-1] PRECISA implementar a funcionalidade Dual Role Port (Porta de função dupla), conforme definido pela especificação USB-C (seção 4.5.1.3.3).
• [SR] MUITO RECOMENDADO para oferecer suporte ao DisplayPort, oferecer suporte a taxas de dados USB SuperSpeed e ser MUITO RECOMENDADO para oferecer suporte ao Power Delivery para troca de funções de dados e energia.
• [SR] RECOMENDADO NÃO oferecer suporte ao modo de acessório do adaptador de áudio, conforme descrito no Apêndice A da Revisão 1.2 das especificações do conector e cabo USB-C.
• DEVE implementar o modelo Try.* mais adequado para o formato do dispositivo. Por exemplo, um dispositivo portátil DEVE implementar o modelo Try.SNK.

7,8. Áudio

7.8.1. Microfone

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

• [C-1-1] PRECISA informar a constante de recurso android.hardware.microphone.
• [C-1-2] PRECISA atender aos requisitos de gravação de áudio da seção 5.4.
• [C-1-3] PRECISA atender aos requisitos de latência de áudio da seção 5.6.
• [SR] FORTEMENTE RECOMENDADO para oferecer suporte à gravação quase ultrassônica, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos omitirem um microfone, elas:

• [C-2-1] NÃO PODE informar a constante de recurso android.hardware.microphone.
• [C-2-2] PRECISA implementar a API de gravação de áudio pelo menos como ambiente autônomo, de acordo com a seção 7.

7.8.2. Saída de áudio

Se as implementações do dispositivo incluírem um alto-falante ou uma porta de saída de áudio/multimídia para um periférico de saída de áudio, como uma entrada de áudio de 3 condutores de 3,5 mm ou uma porta de modo host USB usando classe de áudio USB, elas:

• [C-1-1] PRECISA informar a constante de recurso android.hardware.audio.output.
• [C-1-2] PRECISA atender aos requisitos de reprodução de áudio da seção 5.5.
• [C-1-3] PRECISA atender aos requisitos de latência de áudio da seção 5.6.
• [SR] FORTEMENTE RECOMENDADO para oferecer suporte à reprodução quase ultrassom, conforme descrito na seção 7.8.3.

Se as implementações de dispositivos não incluírem uma porta de saída de áudio ou alto-falante, elas:

• [C-2-1] NÃO É POSSÍVEL informar o recurso android.hardware.audio.output.
• [C-2-2] PRECISA implementar as APIs relacionadas à saída de áudio como um ambiente autônomo.

Para os fins desta seção, uma "porta de saída" é uma interface física, como uma entrada de áudio de 3,5 mm, HDMI ou porta de modo de host USB com classe de áudio USB. O suporte para saída de áudio por protocolos baseados em rádio, como Bluetooth, Wi-Fi ou rede celular, não se qualifica como uma "porta de saída".

7.8.2.1. Portas de áudio analógico

Para ser compatível com os fones de ouvido e outros acessórios de áudio que usam o plugue de áudio de 3,5 mm em todo o ecossistema Android, se a implementação de um dispositivo incluir uma ou mais portas de áudio analógico, pelo menos uma delas DEVE ser uma entrada para fone de ouvido de 3,5 mm com quatro condutores.

Se as implementações do dispositivo tiverem uma entrada para fone de ouvido de 3,5 mm com quatro condutores, elas:

• [C-1-1] PRECISA oferecer suporte à reprodução de áudio para fones de ouvido estéreo ou fones de ouvido estéreo com microfone.
• [C-1-2] PRECISA oferecer suporte a plugues de áudio TRRS com a ordem de pinagem CTIA.
• [C-1-3] PRECISA oferecer suporte à detecção e ao mapeamento dos códigos de tecla para os três intervalos de impedância equivalentes entre o microfone e os condutores de terra no plugue de áudio:
  • 70 ohm ou menos: KEYCODE_HEADSETHOOK
  • 210–290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] PRECISA acionar o ACTION_HEADSET_PLUG na inserção do plugue, mas somente depois que todos os contatos no plugue estiverem tocando nos segmentos relevantes na entrada.
• [C-1-5] PRECISA ser capaz de operar com pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohm.
• [C-1-6] PRECISA ter uma tensão de polarização de microfone entre 1,8 V e 2,9 V.
• [SR] MUITO RECOMENDADO para detectar e mapear o código de tecla para o seguinte intervalo de impedância equivalente entre o microfone e os condutores de aterramento no plugue de áudio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• DEVE oferecer suporte a plugues de áudio com a ordem de pin-out OMTP.
• DEVE oferecer suporte à gravação de áudio de fones de ouvido estéreo com microfone.

Se as implementações do dispositivo tiverem uma entrada de áudio de 3, 5 mm com quatro condutores e forem compatíveis com um microfone e transmitirem android.intent.action.HEADSET_PLUG com o microfone de valor extra definido como 1, elas:

• [C-2-1] PRECISA oferecer suporte à detecção de microfone no acessório de áudio conectado.

7.8.3. Quase ultrassom

O áudio quase ultrassom é a banda de 18,5 kHz a 20 kHz.

Implementações de dispositivos:

• É NECESSÁRIO informar corretamente o suporte à capacidade de áudio quase ultrassom pela API AudioManager.getProperty da seguinte forma:

Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND for "true", os requisitos a seguir PRECISAM ser atendidos pelas fontes de áudio VOICE_RECOGNITION e UNPROCESSED:

• [C-1-1] A resposta de potência média do microfone na faixa de 18,5 kHz a 20 kHz PRECISA estar no máximo 15 dB abaixo da resposta a 2 kHz.
• [C-1-2] A proporção não ponderada do microfone para ruído acima de 18,5 kHz a 20 kHz para um tom de 19 kHz a -26 dBFS PRECISA ser inferior a 50 dB.

Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND for "true":

• [C-2-1] A resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser inferior a 40 dB abaixo da resposta a 2 kHz.

7,9. Realidade virtual

O Android inclui APIs e instalações para criar aplicativos de "Realidade virtual" (RV), incluindo experiências de RV de alta qualidade para dispositivos móveis. As implementações de dispositivos PRECISAM implementar corretamente essas APIs e esses comportamentos, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

O Android é compatível com o Modo RV, um recurso que processa a renderização estereoscópica de notificações e desativa componentes monoculares da interface do sistema enquanto um aplicativo de RV tem o foco do usuário.

7.9.2. Alto desempenho de realidade virtual

Se as implementações de dispositivos identificarem o suporte à RV de alto desempenho para períodos mais longos de usuários usando a flag de recurso android.hardware.vr.high_performance, elas:

• [C-1-1] PRECISA ter pelo menos dois núcleos físicos.
• [C-1-2] PRECISA declarar android.software.vr.mode feature.
• [C-1-3] PRECISA oferecer suporte ao modo de desempenho sustentado.
• [C-1-4] PRECISA oferecer suporte ao OpenGL ES 3.2.
• [C-1-5] PRECISA oferecer suporte ao hardware do Vulkan de nível 0 e DEVE oferecer suporte ao hardware de nível 1 do Vulkan.
• [C-1-6] PRECISA implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority e EGL_EXT_protected_content e expor as extensões na lista de extensões EGL disponíveis.
• [C-1-7] A GPU e a tela PRECISAM sincronizar o acesso ao buffer frontal compartilhado para que a renderização de olho alternada do conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de ruptura visíveis.
• [C-1-8] PRECISA implementar GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures, GL_EXT_EGL_image_array e GL_EXT_external_buffer e expor as extensões na lista de extensões GL disponíveis.
• [C-1-9] PRECISA implementar o suporte às flags AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER e AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, conforme descrito no NDK.
• [C-1-10] PRECISA implementar suporte para AHardwareBuffers em mais de uma camada.
• [C-1-11] PRECISA oferecer suporte à decodificação H.264 de pelo menos 3.840 x 2.160 a 30 fps a 40 Mbps (equivalente a quatro instâncias de 1920 x 1080 a 30 fps a 10 Mbps ou duas instâncias de 1920 x 1080 a 60 fps a 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 a 10 Mbps e DEVE ser capaz de decodificar 3840 x 2160 a 30 fps a 20 Mbps (equivalente a 4 instâncias de 1920 Mbps-108).
• [C-1-13] PRECISA oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
• [C-1-14] PRECISA ter uma tela incorporada, e a resolução dela PRECISA ser no mínimo Full HD(1080p) e RECOMENDADO QUE É POSITIVO RECOMENDADO PARA SER QuadHD (1440p) ou superior.
• [C-1-15] A tela PRECISA ser atualizada para pelo menos 60 Hz no modo RV.
• [C-1-16] A latência de exibição (conforme medida no tempo de alternância de cinza para cinza, branco para preto e preto para branco) PRECISA ser ≤ 6 milissegundos.
• [C-1-17] A tela PRECISA ser compatível com um modo de baixa persistência com persistência de ≤ 5 milissegundos. A persistência é definida como o período pelo qual um pixel está emitindo luz.
• [C-1-18] PRECISA oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados Bluetooth LE seção 7.4.3.
• [C-1-19] PRECISA oferecer suporte e informar corretamente o Direct Channel Type para todos os seguintes tipos de sensor padrão:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-1-20] PRECISA oferecer suporte ao tipo de canal direto TYPE_HARDWARE_BUFFER em todos os tipos listados acima.
• [SR] É ALTAMENTE RECOMENDADO para oferecer suporte ao recurso android.hardware.sensor.hifi_sensors e PRECISA atender aos requisitos relacionados ao giroscópio, acelerômetro e magnetômetro do android.hardware.hifi_sensors.
• PODE fornecer um núcleo exclusivo para o aplicativo em primeiro plano e pode oferecer suporte à API Process.getExclusiveCores para retornar os números dos núcleos de CPU exclusivos do aplicativo de primeiro plano superior. Se o núcleo exclusivo for suportado, o núcleo PRECISA não permitir que nenhum outro processo do espaço do usuário seja executado nele (exceto drivers de dispositivo usados pelo aplicativo), mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

8. Desempenho e potência

Alguns critérios mínimos de desempenho e potência são essenciais para a experiência do usuário e afetam as suposições básicas que os desenvolvedores teriam ao desenvolver um app.

8.1. Consistência da experiência do usuário

Uma interface de usuário tranquila pode ser fornecida ao usuário final se houver determinados requisitos mínimos para garantir um frame rate e tempos de resposta consistentes para aplicativos e jogos. As implementações de dispositivos, dependendo do tipo, podem ter requisitos mensuráveis de latência da interface do usuário e troca de tarefas, conforme descrito na seção 2.

8.2. Desempenho do acesso a E/S de arquivos

Fornecer um valor de referência comum para um desempenho consistente de acesso a arquivos no armazenamento de dados particulares do aplicativo (partição /data) permite que os desenvolvedores de apps definam uma expectativa adequada que ajudaria o design do software. Implementações de dispositivos, dependendo do tipo, PODEM ter determinados requisitos descritos na seção 2 para as seguintes operações de leitura e gravação:

• Desempenho de gravação sequencial. Medida por gravação de um arquivo de 256 MB usando buffer de gravação de 10 MB.
• Desempenho de gravação aleatória. Medida por gravação de um arquivo de 256 MB usando buffer de gravação de 4 KB.
• Desempenho de leitura sequencial. Medida pela leitura de um arquivo de 256 MB com um buffer de gravação de 10 MB.
• Desempenho de leitura aleatória. Medida por meio da leitura de um arquivo de 256 MB usando um buffer de gravação de 4 KB.

8.3. Modos de economia de energia

O Android inclui os modos de economia de energia App em espera e Soneca para otimizar o uso da bateria. [SR] Todos os apps isentos desses modos são FORTEMENTE RECOMENDADOS para que fiquem visíveis para o usuário final. [SR] Os algoritmos de acionamento, manutenção, ativação e o uso das configurações de sistema global desses modos de economia de energia são ALTAMENTE RECOMENDADOS para NÃO se desviarem do Android Open Source Project.

Além dos modos de economia de energia, as implementações de dispositivos Android PODEM implementar qualquer um ou todos os quatro estados de energia de suspensão, conforme definido pela Interface de Energia e Configuração Avançada (ACPI).

Se as implementações de dispositivos implementarem estados de energia S3 e S4 conforme definido pela ACPI, elas:

• [C-1-1] PRECISA inserir esses estados somente ao fechar uma tampa que faça parte física do dispositivo.

8.4. Contabilidade de consumo de energia

Uma contabilidade e relatórios mais precisos do consumo de energia fornecem ao desenvolvedor do aplicativo os incentivos e as ferramentas para otimizar o padrão de uso de energia do aplicativo.

Implementações de dispositivos:

• [SR] MUITO RECOMENDADO que você forneça um perfil de energia por componente que defina o valor de consumo atual de cada componente de hardware e o consumo aproximado de bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Android Open Source Project.
• [SR] É RECOMENDADO que você informe todos os valores de consumo de energia em milissegundos por hora (mAh).
• [SR] RECOMENDADO MUITOMENTE para informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
• [SR] É RECOMENDADO disponibilizar esse uso de energia pelo comando do shell do adb shell dumpsys batterystats para o desenvolvedor do app.
• DEVE ser atribuído ao próprio componente de hardware se não for possível atribuir o uso de energia do componente de hardware a um aplicativo.

8.5. Desempenho consistente

Em apps de alto desempenho e longa duração, o desempenho pode variar muito, seja por outros apps sendo executados em segundo plano ou por conta da limitação de CPU devido aos limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo for compatível, o aplicativo em primeiro plano poderá solicitar que o sistema otimize a alocação dos recursos para lidar com essas flutuações.

Implementações de dispositivos:

• [C-0-1] PRECISA informar o suporte ao Modo de desempenho sustentado com precisão usando o método PowerManager.isSustainedPerformanceModeSupported() da API.

• DEVE oferecer suporte ao modo de desempenho sustentado.

Se as implementações de dispositivos relatarem suporte ao modo de desempenho sustentado, elas:

• [C-1-1] PRECISA fornecer ao aplicativo em primeiro plano um nível consistente de desempenho por pelo menos 30 minutos, quando solicitado pelo app.
• [C-1-2] PRECISA respeitar a API Window.setSustainedPerformanceMode() e outras APIs relacionadas.

Se as implementações de dispositivos incluírem dois ou mais núcleos de CPU, elas:

• DEVE fornecer pelo menos um núcleo exclusivo que possa ser reservado pelo aplicativo em primeiro plano.

Se as implementações de dispositivos oferecerem suporte à reserva de um núcleo exclusivo para o aplicativo principal em primeiro plano, elas:

• [C-2-1] PRECISA informar, pelo método de API Process.getExclusiveCores(), os números de ID dos núcleos exclusivos que podem ser reservados pelo aplicativo em primeiro plano.
• [C-2-2] NÃO PODE permitir nenhum processo de espaço do usuário, exceto os drivers de dispositivo usados pelo aplicativo para serem executados nos núcleos exclusivos, mas PODE permitir que alguns processos do kernel sejam executados conforme necessário.

Se as implementações de dispositivos não oferecerem suporte a um núcleo exclusivo, elas:

• [C-3-1] PRECISA retornar uma lista vazia usando o método de API Process.getExclusiveCores().

9. Compatibilidade do modelo de segurança

Implementações de dispositivos:

• [C-0-1] PRECISA implementar um modelo de segurança consistente com o da Plataforma Android, conforme definido no documento de referência de segurança e permissões das APIs na documentação do desenvolvedor Android.

• [C-0-2] PRECISA oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades. Especificamente, os dispositivos compatíveis PRECISAM ser compatíveis com os mecanismos de segurança descritos nas subseções a seguir.

9,1. Permissões

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao modelo de permissões do Android, conforme definido na documentação do desenvolvedor Android. Especificamente, eles PRECISAM aplicar cada permissão definida conforme descrito na documentação do SDK. Nenhuma permissão pode ser omitida, alterada ou ignorada.

• PODE adicionar outras permissões, desde que as novas strings de ID de permissão não estejam no namespace android.\*.

• [C-0-2] As permissões com um protectionLevel de PROTECTION_FLAG_PRIVILEGED PRECISAM ser concedidas apenas a apps pré-carregados nos caminhos privilegiados da imagem do sistema e no subconjunto de permissões explicitamente permitidas para cada app. A implementação do AOSP atende a esse requisito, lendo e respeitando as permissões da lista de permissões para cada app dos arquivos no caminho etc/permissions/ e usando o caminho system/priv-app como o caminho privilegiado.

Permissões com um nível de proteção perigoso são as permissões de execução. Aplicativos com targetSdkVersion > 22 as solicitam no momento da execução.

Implementações de dispositivos:

• [C-0-3] PRECISA mostrar uma interface dedicada para o usuário decidir se vai conceder as permissões de execução solicitadas e também fornecer uma interface para o usuário gerenciar essas permissões.
• [C-0-4] PRECISA ter apenas uma implementação das duas interfaces do usuário.
• [C-0-5] NÃO PODE conceder permissões de execução a apps pré-instalados, a menos que:
• o consentimento do usuário pode ser obtido antes de o aplicativo usá-lo
• As permissões de execução são associadas a um padrão de intent para o qual o aplicativo pré-instalado é definido como o gerenciador padrão

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

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

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

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

9,2. UID e isolamento de processos

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao modelo de sandbox do aplicativo Android, no qual cada aplicativo é executado como um UID Unixstyle exclusivo e em um processo separado.
• [C-0-2] PRECISA oferecer suporte à execução de vários aplicativos com o mesmo ID de usuário do Linux, desde que os aplicativos sejam assinados e construídos corretamente, conforme definido na Referência de segurança e permissões.

9,3 Permissões do sistema de arquivos

Implementações de dispositivos:

• [C-0-1] PRECISA oferecer suporte ao modelo de permissões de acesso a arquivos do Android, conforme definido na Referência de segurança e permissões.

9,4. Ambientes de execução alternativos

As implementações de dispositivos PRECISAM manter a consistência do modelo de permissão e segurança do Android, mesmo que incluam ambientes de execução que executam aplicativos usando outro software ou tecnologia que não o Dalvik Executable Format ou o código nativo. Resumindo:

• [C-0-1] Os tempos de execução alternativos PRECISAM ser aplicativos Android e respeitar o modelo de segurança padrão do Android, conforme descrito em outra seção da seção 9.

• [C-0-2] Ambientes de execução alternativos NÃO PODEM ter acesso a recursos protegidos por permissões que não foram solicitadas no arquivo AndroidManifest.xml do ambiente de execução pelo mecanismo <uses-permission>.

• [C-0-3] Tempos de execução alternativos NÃO PODEM permitir que aplicativos façam uso de recursos protegidos por permissões do Android restritas a aplicativos do sistema.

• [C-0-4] Tempos de execução alternativos PRECISAM respeitar o modelo de sandbox do Android, e os aplicativos instalados que usam um tempo de execução alternativo NÃO PODEM reutilizar o sandbox de nenhum outro aplicativo instalado no dispositivo, exceto por meio dos mecanismos padrão do Android para ID de usuário compartilhado e certificado de assinatura.

• [C-0-5] Ambientes de execução alternativos NÃO PODEM iniciar com, conceder ou receber acesso às sandboxes correspondentes a outros aplicativos Android.

• [C-0-6] Ambientes de execução alternativos NÃO PODEM ser iniciados, concedidos ou concedidos a outros aplicativos os privilégios do superusuário (raiz) ou de qualquer outro ID de usuário.

• [C-0-7] Quando os arquivos .apk de ambientes de execução alternativos são incluídos na imagem do sistema das implementações do dispositivo, eles PRECISAM ser assinados com uma chave diferente da usada para assinar outros apps incluídos nas implementações do dispositivo.

• [C-0-8] Ao instalar aplicativos, ambientes de execução alternativos PRECISAM receber o consentimento do usuário para as permissões do Android usadas pelo aplicativo.

• [C-0-9] Quando um aplicativo precisa usar um recurso de dispositivo para o qual há uma permissão correspondente do Android (como Câmera, GPS etc.), o tempo de execução alternativo PRECISA informar ao usuário que o aplicativo poderá acessar esse recurso.

• [C-0-10] Quando o ambiente de execução não registra os recursos do aplicativo dessa maneira, ele PRECISA listar todas as permissões mantidas pelo próprio ambiente de execução ao instalar qualquer aplicativo que use esse ambiente.

• Ambientes de execução alternativos DEVEM instalar apps pelo PackageManager em sandboxes separadas do Android (IDs de usuário do Linux etc.).

• Tempos de execução alternativos PODEM fornecer uma única sandbox do Android compartilhada por todos os aplicativos que usam o tempo de execução alternativo.

9,5 Suporte a multiusuário

O Android inclui suporte para vários usuários e permite isolamento total de usuários.

• As implementações de dispositivos PODEM, mas NÃO DEVERÃO ativar o recurso multiusuário se usarem mídia removível para armazenamento externo principal.

Se as implementações de dispositivos incluírem vários usuários, elas:

• [C-1-1] PRECISA atender aos seguintes requisitos relacionados ao suporte multiusuário.
• [C-1-2] PRECISA, para cada usuário, implementar um modelo de segurança consistente com o da Plataforma Android, conforme definido no documento de referência de segurança e permissões das APIs.
• [C-1-3] PRECISA ter diretórios de armazenamento compartilhado de aplicativos separados e isolados (também conhecido como /sdcard) para cada instância de usuário.
• [C-1-4] PRECISA garantir que os aplicativos pertencentes e executados em nome de um determinado usuário não possam listar, ler nem gravar nos arquivos de outro usuário, mesmo que os dados de ambos os usuários estejam armazenados no mesmo volume ou sistema de arquivos.
• [C-1-5] PRECISA criptografar o conteúdo do cartão SD quando o multiusuário estiver ativado usando uma chave armazenada somente em mídia não removível, acessível somente ao sistema se as implementações do dispositivo usarem mídia removível para as APIs de armazenamento externo. Como isso torna a mídia ilegível para um PC host, será necessário que as implementações de dispositivos mudem para o MTP ou um sistema similar para fornecer aos PCs host o acesso aos dados do usuário atual.

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

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

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

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

9,6. Aviso de SMS premium

O Android inclui suporte para avisar os usuários sobre qualquer mensagem SMS premium enviada. As mensagens SMS premium são mensagens de texto enviadas a um serviço registrado em uma operadora que podem ser cobradas do usuário.

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

• [C-1-1] PRECISA avisar os usuários antes de enviar uma mensagem SMS para números identificados por expressões regulares definidas no arquivo /data/misc/sms/codes.xml no dispositivo. O Android Open Source Project upstream fornece uma implementação que atende a esse requisito.

9,7. Recursos de segurança do kernel

O Android Sandbox inclui recursos que usam o sistema de controle de acesso obrigatório (MAC, na sigla em inglês) do Security-Enhanced Linux (SELinux), o sandbox seccomp e outros recursos de segurança no kernel do Linux. Implementações de dispositivos:

• [C-0-1] PRECISA manter a compatibilidade com os aplicativos atuais, mesmo quando o SELinux ou qualquer outro recurso de segurança for implementado abaixo do framework do Android.
• [C-0-2] NÃO PODE ter uma interface do usuário visível quando uma violação de segurança for detectada e bloqueada pelo recurso de segurança implementado abaixo do framework do Android, mas PODE ter uma interface do usuário visível quando uma violação de segurança desbloqueada ocorrer e resultar em uma exploração bem-sucedida.
• [C-0-3] NÃO PODE configurar o SELinux ou qualquer outro recurso de segurança implementado abaixo do framework do Android configurável pelo usuário ou desenvolvedor do app.
• [C-0-4] NÃO PODE permitir que um aplicativo que possa afetar outro por uma API (como uma Device Administration API) configure uma política que viole a compatibilidade.
• [C-0-5] PRECISA dividir o framework de mídia em vários processos para que seja possível conceder acesso mais restrito a cada processo, conforme descrito no site do Android Open Source Project.
• [C-0-6] PRECISA implementar um mecanismo de sandbox do aplicativo do kernel que permita a filtragem de chamadas do sistema usando uma política configurável de programas com várias linhas de execução. O Android Open Source Project upstream atende a esse requisito ativando o seccomp-BPF com sincronização de grupo de encadeamentos (TSYNC), conforme descrito na seção de configuração do kernel de source.android.com.

Os recursos de integridade e autoproteção do kernel são essenciais para a segurança do Android. Implementações de dispositivos:

• [C-0-7] PRECISA implementar proteções contra estouro de buffer de pilha do kernel (por exemplo, CONFIG_CC_STACKPROTECTOR_STRONG).
• [C-0-8] PRECISA implementar proteções rigorosas de memória do kernel em que o código executável é somente leitura, dados somente leitura não são executáveis nem graváveis e dados graváveis não são executáveis (por exemplo, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
• [SR] FORTEMENTE RECOMENDADO para manter os dados do kernel que são gravados apenas durante a inicialização marcados como somente leitura após a inicialização (por exemplo, __ro_after_init).
• [SR} RECOMENDADO fortemente para implementar a verificação de limites de tamanho de objetos estáticos e dinâmicos, verificando as cópias entre o espaço do usuário e o espaço do kernel (por exemplo, CONFIG_HARDENED_USERCOPY).
• [SR] FORTEMENTE RECOMENDADO que nunca execute a memória do espaço do usuário ao executar no kernel (por exemplo, hardware PXN ou emulado via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN).
• [SR] É RECOMENDADO nunca ler ou gravar memória do espaço do usuário no kernel fora das APIs normais de acesso a usercopy (por exemplo, PAN de hardware ou emulada via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN).
• [SR] MUITO RECOMENDADO para randomizar o layout do código e da memória do kernel e evitar exposições que possam comprometer essa ordem (por exemplo, CONFIG_RANDOMIZE_BASE com entropia do carregador de inicialização usando /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

Se as implementações de dispositivos usarem um kernel do Linux, elas:

• [C-1-1] PRECISA implementar o SELinux.
• [C-1-2] PRECISA configurar o SELinux para o modo de aplicação global.
• [C-1-3] PRECISA configurar todos os domínios no modo de aplicação. Não são permitidos domínios de modo permissivo, incluindo domínios específicos de um dispositivo/fornecedor.
• [C-1-4] NÃO PODE modificar, omitir ou substituir as regras de nunca permitir presentes na pasta do sistema/sepolicy fornecida no Android Open Source Project (AOSP) upstream, e a política PRECISA ser compilada com todas as regras Nunca permitir presentes, para domínios SELinux do AOSP e domínios específicos do dispositivo/fornecedor.
• DEVE manter a política SELinux padrão fornecida na pasta system/sepolicy do Android Open Source Project upstream e só incrementar essa política para a própria configuração específica do dispositivo.

Se as implementações de dispositivos usarem um kernel diferente do Linux, elas:

• [C-2-1] PRECISA usar um sistema de controle de acesso obrigatório equivalente ao SELinux.

9,8. Privacidade

9.8.1. Histórico de uso

O Android armazena o histórico de escolhas do usuário e o gerencia pelo UsageStatsManager.

Implementações de dispositivos:

• [C-1-1] PRECISA manter um período de retenção razoável desse histórico de usuário.
• [SR] É RECOMENDADO manter o período de armazenamento de 14 dias conforme configurado por padrão na implementação do AOSP.

9.8.2. Gravações

Se as implementações do dispositivo incluírem uma funcionalidade no sistema que capture o conteúdo exibido na tela e/ou grave o stream de áudio reproduzido no dispositivo, elas:

• [C-1-1] PRECISA manter sempre uma notificação ao usuário sempre que essa funcionalidade estiver ativada e que estiver capturando/gravando ativamente.

Se as implementações do dispositivo incluírem um componente habilitado e pronto para uso, capaz de gravar áudio do ambiente para inferir informações úteis sobre o contexto do usuário:

• [C-2-1] NÃO PODE armazenar no armazenamento persistente no dispositivo nem transmitir para fora do dispositivo o áudio bruto gravado ou qualquer formato que possa ser convertido de volta ao áudio original ou a um fax, exceto com o consentimento explícito do usuário.

9.8.3. Conectividade

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

• [C-1-1] PRECISA apresentar uma interface do usuário solicitando o consentimento do usuário antes de permitir o acesso ao conteúdo do armazenamento compartilhado pela porta USB.

9.8.4. Tráfego de rede

Implementações de dispositivos:

• [C-0-1] É NECESSÁRIO pré-instalar os mesmos certificados raiz do repositório da autoridade de certificação (CA) confiável, conforme fornecido no Android Open Source Project.
• [C-0-2] PRECISA enviar com um repositório de CAs raiz de usuário vazio.
• [C-0-3] PRECISA exibir um aviso ao usuário indicando que o tráfego de rede pode ser monitorado quando uma CA raiz do usuário for adicionada.

Se o tráfego do dispositivo for roteado por uma VPN, as implementações do dispositivo:

• [C-1-1] PRECISA mostrar um aviso ao usuário indicando:
  • Esse tráfego de rede pode ser monitorado.
  • Esse tráfego de rede está sendo roteado pelo aplicativo de VPN específico que fornece a VPN.

Se as implementações de dispositivos tiverem um mecanismo, ativado e pronto para uso por padrão, que roteie o tráfego de dados de rede por um servidor proxy ou gateway de VPN (por exemplo, pré-carregar um serviço de VPN com android.permission.CONTROL_VPN concedido), elas:

• [C-2-1] PRECISA solicitar o consentimento do usuário antes de ativar esse mecanismo, a menos que a VPN seja ativada pelo controlador de política de dispositivo pelo DevicePolicyManager.setAlwaysOnVpnPackage(). Nesse caso , o usuário não precisa fornecer um consentimento separado, mas PRECISA ser notificado.

Se as implementações de dispositivos implementarem uma funcionalidade do usuário para ativar a função "VPN sempre ativa" de um app de VPN de terceiros, elas:

• [C-3-1] É NECESSÁRIO desativar essa funcionalidade do usuário para apps que não são compatíveis com o serviço de VPN sempre ativada no arquivo AndroidManifest.xml definindo o atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON como false.

9,9. Criptografia do armazenamento de dados

Se as implementações de dispositivos forem compatíveis com uma tela de bloqueio segura, conforme descrito na seção 9.11.1, elas:

• [C-1-1] PRECISA oferecer suporte à criptografia de armazenamento de dados particulares do aplicativo (/data partition), bem como à partição de armazenamento compartilhado do aplicativo (/sdcard partition), se ela for uma parte permanente e não removível do dispositivo.

Se as implementações de dispositivos forem compatíveis com uma tela de bloqueio segura, conforme descrito na seção 9.11.1, e tiverem suporte à criptografia de armazenamento de dados com desempenho de criptografia com padrão de criptografia avançada (AES) acima de 50 MiB/s, elas:

• [C-2-1] PRECISA ativar a criptografia do armazenamento de dados por padrão quando o usuário tiver concluído a configuração pronta. Se as implementações de dispositivos já tiverem sido lançadas em uma versão anterior do Android com a criptografia desativada por padrão, esse dispositivo não vai poder atender ao requisito com uma atualização de software do sistema e, portanto, poderá ser isento.

• DEVE atender ao requisito de criptografia de armazenamento de dados acima implementando a criptografia baseada em arquivos (FBE, na sigla em inglês).

9.9.1. Inicialização direta

Implementações de dispositivos:

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

• [C-0-2] As intents ACTION_LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED ainda PRECISAM ser transmitidas para sinalizar aos apps com reconhecimento de inicialização direta que os locais de armazenamento criptografado pelo dispositivo (DE) e criptografado por credencial (CE) estão disponíveis para o usuário.

9.9.2. Criptografia baseada em arquivos

Se as implementações de dispositivos oferecerem suporte à FBE, elas:

• [C-1-1] PRECISA inicializar sem solicitar credenciais ao usuário e permitir que apps com reconhecimento de inicialização direta acessem o armazenamento criptografado do dispositivo depois que a mensagem ACTION_LOCKED_BOOT_COMPLETED for transmitida.
• [C-1-2] PRECISA permitir o acesso ao armazenamento criptografado por credenciais (CE, na sigla em inglês) somente depois que o usuário desbloquear o dispositivo informando as credenciais dele (por exemplo, senha, PIN, padrão ou impressão digital) e a mensagem ACTION_USER_UNLOCKED for transmitida.
• [C-1-3] NÃO PODE oferecer nenhum método para desbloquear o armazenamento protegido por CE sem as credenciais fornecidas pelo usuário.
• [C-1-4] PRECISA oferecer suporte à Inicialização verificada e garantir que as chaves DE sejam vinculadas criptograficamente à raiz de confiança do hardware do dispositivo.
• [C-1-5] PRECISA oferecer suporte à criptografia de conteúdos de arquivos usando AES com um comprimento de chave de 256 bits no modo XTS.

• [C-1-6] PRECISA oferecer suporte à criptografia do nome do arquivo usando AES com um comprimento de chave de 256 bits no modo CBC-CTS.

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

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

• [C-1-8] As chaves CE PRECISAM estar vinculadas às credenciais da tela de bloqueio de um usuário.
• [C-1-9] As chaves CE PRECISAM ser vinculadas a uma senha padrão quando o usuário não especifica as credenciais da tela de bloqueio.

• [C-1-10] PRECISA ser única e distinta, ou seja, nenhuma chave CE ou DE do usuário corresponde a nenhuma chave CE ou DE de outro usuário.

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

• PODE oferecer suporte a criptografias alternativas, comprimentos e modos de chave para criptografia de conteúdo de arquivos e de nome de arquivo, mas PRECISA usar as criptografias, os comprimentos e os modos compatíveis obrigatoriamente por padrão.

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

9.9.3. Criptografia de disco completo

Se as implementações de dispositivos forem compatíveis com a criptografia de disco completo (FDE, na sigla em inglês), elas:

• [C-1-1] PRECISA usar o AES com uma chave de 128 bits (ou superior) e um modo projetado para armazenamento (por exemplo, AES-XTS, AES-CBC-ESSIV).
• [C-1-2] PRECISA usar uma senha padrão para encapsular a chave de criptografia e NÃO PODE gravá-la no armazenamento a qualquer momento sem que ela seja criptografada.
• [C-1-3] O AES PRECISA criptografar a chave de criptografia por padrão, a menos que o usuário desative essa opção explicitamente, exceto quando ela estiver em uso ativo, com as credenciais da tela de bloqueio esticadas usando um algoritmo de alongamento lento (por exemplo, PBKDF2 ou scrypt).
• [C-1-4] O algoritmo padrão de aumento de senha acima PRECISA ser vinculado criptograficamente a esse keystore quando o usuário não tiver especificado uma credencial de tela de bloqueio ou tiver desativado o uso da senha para criptografia e o dispositivo fornecer um keystore protegido por hardware.
• [C-1-5] NÃO PODE enviar a chave de criptografia para fora do dispositivo, mesmo quando encapsulada com a senha do usuário e/ou chave vinculada por hardware.

O projeto upstream do Android Open Source oferece uma implementação preferencial desse recurso, com base no recurso dm-crypt 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] PRECISA informar corretamente, pelo método PersistentDataBlockManager.getFlashLockState() da API do sistema, se o estado do carregador de inicialização permite a atualização da imagem do sistema. O estado FLASH_LOCK_UNKNOWN é reservado para implementações de dispositivos que fizeram upgrade de uma versão anterior do Android, em que esse novo método de API do sistema não existia.

A Inicialização verificada é um recurso que garante a integridade do software do dispositivo. Se uma implementação de dispositivo oferecer suporte ao recurso:

• [C-1-1] PRECISA declarar a flag de recurso da plataforma android.software.verified_boot.
• [C-1-2] PRECISA fazer a verificação em todas as sequências de inicialização.
• [C-1-3] PRECISA iniciar a verificação usando uma chave de hardware imutável que é a raiz de confiança e ir até a partição do sistema.
• [C-1-4] PRECISA implementar cada estágio da verificação para conferir a integridade e a autenticidade de todos os bytes no estágio seguinte antes de executar o código na etapa seguinte.
• [C-1-5] PRECISA usar algoritmos de verificação tão fortes quanto as recomendações atuais do NIST para algoritmos de hash (SHA-256) e tamanhos de chave pública (RSA-2048).
• [C-1-6] NÃO PODE permitir que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário autorize a inicialização mesmo assim. Nesse caso, os dados de blocos de armazenamento não verificados não PODEM ser usados.
• [C-1-7] NÃO PODE permitir que partições verificadas no dispositivo sejam modificadas, a menos que o usuário tenha desbloqueado explicitamente o carregador de inicialização.
• [SR] Se houver vários chips distintos no dispositivo (por exemplo, rádio, processador de imagem especializado), o processo de inicialização de cada um deles será RECOMENDADO PARA verificar cada estágio na inicialização.
• [SR] RECOMENDADO FORTEMENTE para usar armazenamento à prova de adulterações: para quando o carregador de inicialização estiver desbloqueado. Um armazenamento à prova de adulterações significa que o carregador de inicialização pode detectar se o armazenamento foi adulterado no sistema operacional de alto nível (HLOS, na sigla em inglês).
• [SR] RECOMENDADO FORTEMENTE para solicitar ao usuário durante o uso do dispositivo e exigir confirmação física antes de permitir uma transição do modo bloqueado do carregador de inicialização para o modo desbloqueado.
• [SR] FORTEMENTE RECOMENDADO para implementar a proteção contra reversão para HLOS (por exemplo, inicialização, partições do sistema) e usar armazenamento à prova de adulterações para armazenar os metadados usados para determinar a versão mínima permitida do SO.
• DEVE implementar proteção contra reversão para qualquer componente com firmware persistente (por exemplo, modem, câmera) e DEVE usar armazenamento à prova de adulterações para armazenar os metadados usados para determinar a versão mínima permitida.

O Android Open Source Project oferece uma implementação preferencial desse recurso no repositório external/avb/, que pode ser integrado ao carregador de inicialização usado para carregar o Android.

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

• [C-2-1] PRECISA oferecer suporte à inicialização verificada para garantir a integridade do dispositivo.

Se uma implementação de dispositivo já tiver sido iniciada em uma versão anterior do Android sem suporte à inicialização verificada, esse dispositivo não poderá adicionar suporte a esse recurso com uma atualização de software do sistema e, portanto, estará isento da exigência.

9,11. Chaves e credenciais

O sistema Android Keystore permite que os desenvolvedores de apps armazenem chaves criptográficas em um contêiner e as usem em operações criptográficas com a API KeyChain ou a API Keystore. Implementações de dispositivos:

• [C-0-1] PRECISA permitir, pelo menos, a importação de mais de 8.192 chaves.
• [C-0-2] A autenticação da tela de bloqueio PRECISA ter tentativas de limite de taxa e um algoritmo de espera exponencial. Após 150 tentativas com falha, o atraso PRECISA ser de pelo menos 24 horas por tentativa.
• Não devem limitar o número de chaves que podem ser geradas

Quando a implementação do dispositivo é compatível com uma tela de bloqueio segura, ela:

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

Se uma implementação de dispositivo já tiver sido lançada em uma versão anterior do Android, esse dispositivo está isento da exigência de ter um keystore protegido por hardware, a menos que declare o recurso android.hardware.fingerprint, que exige um keystore protegido por hardware.

9.11.1. Proteger a tela de bloqueio

Se as implementações do dispositivo tiverem uma tela de bloqueio segura e incluírem um ou mais agentes de confiança, que implementam a API TrustAgentService do sistema, elas:

• [C-1-1] PRECISA indicar o usuário na interface do usuário nas Configurações e na tela de bloqueio quando o bloqueio automático da tela é adiado ou ele pode ser desbloqueado pelo agente de confiança. O AOSP atende ao requisito mostrando uma descrição em texto para os menus "Bloquear automaticamente a configuração" e "O botão liga/desliga bloqueia instantaneamente as configurações" e um ícone distinguível na tela de bloqueio.
• [C-1-2] PRECISA respeitar e implementar totalmente todas as APIs do agente de confiança na classe DevicePolicyManager, como a constante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-1-3] NÃO PODE implementar totalmente a função TrustAgentService.addEscrowToken() em um dispositivo usado como dispositivo pessoal principal (por exemplo, portátil), mas PODE implementar totalmente a função nas implementações de dispositivo normalmente compartilhadas.
• [C-1-4] PRECISA criptografar os tokens adicionados por TrustAgentService.addEscrowToken() antes de armazená-los no dispositivo.
• [C-1-5] NÃO PODE armazenar a chave de criptografia no dispositivo.
• [C-1-6] PRECISA informar o usuário sobre as implicações de segurança antes de ativar o token de garantia para descriptografar o armazenamento de dados.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio, para que esse método seja tratado como uma maneira segura de bloquear a tela, elas:

• [C-2-1] PRECISA ser o método de autenticação do usuário, conforme descrito em Exigir autenticação do usuário para o uso de chaves.
• [C-2-2] É NECESSÁRIO desbloquear todas as chaves de um app de desenvolvedor terceirizado quando o usuário desbloqueia a tela de bloqueio segura. Por exemplo, todas as chaves PRECISAM estar disponíveis para um app de desenvolvedor terceirizado usando APIs relevantes, como createConfirmDeviceCredentialIntent e setUserAuthenticationRequired.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio se estiverem baseados em um segredo conhecido, para que esse método de autenticação seja tratado como uma maneira segura de bloquear a tela, elas:

• [C-3-1] A entropia do menor comprimento permitido das entradas PRECISA ser maior que 10 bits.
• [C-3-2] A entropia máxima de todas as entradas possíveis PRECISA ser maior que 18 bits.
• [C-3-3] não PODE substituir nenhum dos métodos de autenticação existentes (PIN,padrão, senha) implementados e fornecidos no AOSP.
• [C-3-4] PRECISA ser desativado quando o aplicativo Device Policy Controller (DPC) define a política de qualidade de senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_SOMETHING.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio se forem baseados em um token físico ou no local, para que esse método de autenticação seja tratado como uma maneira segura de bloquear a tela, elas:

• [C-4-1] PRECISA ter um mecanismo de fallback para usar um dos métodos principais de autenticação, que é baseado em um secret conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
• [C-4-2] PRECISA ser desativada e só permitir que a autenticação principal desbloqueie a tela quando o app Device Policy Controller (DPC) tiver definido a política com o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva que PASSWORD_QUALITY_UNSPECIFIED.
• [C-4-3] O usuário PRECISA ser desafiado quanto à autenticação principal (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 72 horas ou menos.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio com base na biometria, para que esse método de autenticação seja tratado como uma forma segura de bloquear a tela, elas:

• [C-5-1] PRECISA ter um mecanismo de fallback para usar um dos métodos principais de autenticação, que é baseado em um secret conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
• [C-5-2] PRECISA ser desativado e só permite que a autenticação principal desbloqueie a tela quando o aplicativo do controlador de política de dispositivo (DPC) tiver definido a política de recurso keguard chamando o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
• [C-5-3] PRECISA ter uma taxa de aceitação falsa igual ou maior do que a exigida para um sensor de impressão digital, conforme descrito na seção 7.3.10. Também PRECISA ser desativada e só permitir que a autenticação principal desbloqueie a tela quando o aplicativo Device Policy Controller (DPC) tiver definido a política de qualidade de senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [SR] É FORTEMENTE RECOMENDADO que tenham taxas de aceitação de impostor e de spoofing iguais ou maiores do que o necessário para um sensor de impressão digital, conforme descrito na seção 7.3.10.

Se as taxas de aceitação de spoofing e impostores não forem iguais ou maiores que o necessário para um sensor de impressão digital, conforme descrito na seção 7.3.10 e o aplicativo Device Policy Controller (DPC) tiver definido a política de qualidade de senha por meio do método DevicePolicyManager.setPasswordQuality() com uma qualidade de qualidade mais restritiva do que PASSWORD_QUALITY_BIOMETRIC_WEAK:

• [C-6-1] PRECISA desativar esses métodos biométricos e permitir que apenas a autenticação principal desbloqueie a tela.
• [C-6-2] PRECISA desafiar o usuário quanto à autenticação principal (por exemplo, PIN, padrão, senha) pelo menos uma vez a cada 72 horas ou menos.

Se as implementações do dispositivo adicionarem ou modificarem os métodos de autenticação para desbloquear a tela de bloqueio e esse método de autenticação for usado para desbloquear a proteção, mas não forem tratados como uma tela de bloqueio segura, elas:

• [C-7-1] PRECISA retornar false para os métodos KeyguardManager.isKeyguardSecure() e KeyguardManager.isDeviceSecure().
• [C-7-2] PRECISA ser desativado quando o aplicativo Device Policy Controller (DPC) define a política de qualidade de senha pelo método DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_UNSPECIFIED.
• [C-7-3] NÃO É POSSÍVEL redefinir os timers de expiração da senha definidos por DevicePolicyManager.setPasswordExpirationTimeout().
• [C-7-4] NÃO PODERÁ autenticar o acesso a keystores se o aplicativo tiver chamado KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).

9,12 Exclusão de dados

Todas as implementações de dispositivos:

• [C-0-1] PRECISA fornecer aos usuários um mecanismo para realizar uma "redefinição para configuração original".
• [C-0-2] PRECISA excluir todos os dados gerados pelo usuário. Ou seja, todos os dados, exceto:
  • A imagem do sistema
  • Quaisquer arquivos do sistema operacional exigidos pela imagem do sistema
• [C-0-3] PRECISA excluir os dados para atender aos padrões relevantes do setor, como o NIST SP800-88.
• [C-0-4] PRECISA acionar o processo de "redefinição para configuração original" acima quando a API DevicePolicyManager.wipeData() é chamada pelo app Device Policy Controller do usuário principal.
• PODE fornecer uma opção rápida de limpeza de dados que conduz apenas uma limpeza lógica de dados.

9,13 Modo de inicialização segura

O Android oferece o modo de inicialização segura, que permite aos usuários inicializar de um modo em que apenas apps pré-instalados do sistema podem ser executados e todos os apps de terceiros são desativados. Esse modo, conhecido como "modo de inicialização segura", oferece ao usuário a capacidade de desinstalar apps de terceiros potencialmente nocivos.

As implementações de dispositivos são:

• [SR] RECOMENDADO FORTEMENTE para implementar o modo de inicialização segura.

Se as implementações de dispositivos implementarem o modo de inicialização segura, elas:

• [C-1-1] PRECISA oferecer ao usuário uma opção para entrar no modo de inicialização segura de forma ininterrupta em apps de terceiros instalados no dispositivo, exceto quando o app for um controlador de política do dispositivo e tiver definido a flag UserManager.DISALLOW_SAFE_BOOT como verdadeira.

• [C-1-2] PRECISA oferecer ao usuário a capacidade de desinstalar apps de terceiros no modo de segurança.

• DEVE fornecer ao usuário a opção de entrar no modo de inicialização segura no menu de inicialização usando um fluxo de trabalho diferente do de uma inicialização normal.

9,14 Isolamento de sistemas veiculares automotivos

Os dispositivos Android Automotive precisam trocar dados com subsistemas críticos do veículo usando a HAL do veículo para enviar e receber mensagens por redes de veículos, como o barramento CAN.

A troca de dados pode ser protegida implementando recursos de segurança abaixo das camadas da estrutura do Android para evitar interações maliciosas ou não intencionais com esses subsistemas.

10. Teste de compatibilidade de software

As implementações de dispositivos PRECISAM ser aprovadas em todos os testes descritos nesta seção.

No entanto, observe que nenhum pacote de teste de software é totalmente abrangente. Por esse motivo, é altamente RECOMENDADO que os implementadores de dispositivos façam o número mínimo de mudanças possível na referência e na implementação preferencial do Android disponível no Android Open Source Project. Isso vai minimizar o risco de introduzir bugs que criam incompatibilidades que exigem retrabalho e possíveis atualizações do dispositivo.

10.1 Conjunto de teste de compatibilidade

As implementações de dispositivos PRECISAM passar no conjunto de teste de compatibilidade (CTS) do Android, disponível no Android Open Source Project, usando o software de envio final no dispositivo. Além disso, os implementadores de dispositivos DEVEM usar a implementação de referência na árvore de código aberto do Android o máximo possível e DEVEM garantir a compatibilidade em casos de ambiguidade no CTS e para reimplementações de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. A versão do CTS será controlada independentemente dessa definição de compatibilidade, e várias revisões do CTS poderão ser lançadas para o Android 8.1. As implementações de dispositivos PRECISAM passar pela versão mais recente do CTS disponível no momento em que o software do dispositivo for concluído.

10,2 Verificador do CTS

As implementações de dispositivos PRECISAM executar corretamente todos os casos aplicáveis no verificador do CTS. O verificador do CTS está incluído no conjunto de teste de compatibilidade e foi projetado para ser executado por um operador humano para testar funcionalidades que não podem ser testadas por um sistema automatizado, como o funcionamento correto de uma câmera e sensores.

O CTS Verifier tem testes para muitos tipos de hardware, inclusive alguns opcionais. As implementações de dispositivos PRECISAM passar em todos os testes de hardware que têm. Por exemplo, se um dispositivo tiver um acelerômetro, ele PRECISA executar corretamente o caso de teste do acelerômetro no CTS Verifier. Os casos de teste para recursos marcados como opcionais por este Documento de definição de compatibilidade podem ser ignorados ou omitidos.

Todos os dispositivos e builds PRECISAM executar corretamente o CTS Verifier, conforme mencionado acima. No entanto, como muitos builds são muito semelhantes, não é esperado que os implementadores de dispositivos executem explicitamente o CTS Verifier em builds que diferem apenas de maneiras triviais. Especificamente, implementações de dispositivos que diferem de uma implementação que passou no verificador do CTS apenas pelo conjunto de localidades incluídas, branding etc. PODEM omitir o teste do verificador do CTS.

11. Software atualizável

As implementações de dispositivos PRECISAM incluir um mecanismo para substituir todo o software do sistema. O mecanismo não precisa realizar atualizações “em tempo real”, ou seja, pode ser necessário reiniciar o dispositivo.

Qualquer método pode ser usado, desde que possa substituir todo o software pré-instalado no dispositivo. Por exemplo, qualquer uma das abordagens a seguir atenderá a esse requisito:

• Downloads “over-the-air” (OTA) com atualização off-line por reinicialização.
• Atualizações "vinculadas" via USB de um PC host.
• Atualizações “off-line” por meio de uma reinicialização e atualização de um arquivo no armazenamento removível.

No entanto, se a implementação do dispositivo incluir suporte a uma conexão de dados ilimitada, como 802.11 ou perfil Bluetooth PAN (rede de área pessoal), ela PRECISA oferecer suporte a downloads OTA com atualização off-line por meio de reinicialização.

O mecanismo de atualização usado PRECISA ser compatível com as atualizações sem excluir permanentemente os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados privados e os dados compartilhados do aplicativo. O software Android upstream inclui um mecanismo de atualização que atende a esse requisito.

Para implementações de dispositivos que forem lançadas com o Android 6.0 e versões posteriores, o mecanismo de atualização DEVE oferecer suporte à verificação de que a imagem do sistema é binária idêntica ao resultado esperado após uma atualização OTA. A implementação OTA baseada em blocos no Android Open Source Project upstream, adicionada desde o Android 5.1, atende a esse requisito.

Além disso, as implementações de dispositivos DEVEM oferecer suporte às atualizações do sistema A/B. O AOSP implementa esse recurso usando a HAL de controle de inicialização.

Se um erro for encontrado em uma implementação de dispositivo após seu lançamento, mas dentro do ciclo de vida razoável do produto que for determinado em consulta com a Equipe de Compatibilidade do Android para afetar a compatibilidade de aplicativos de terceiros, o implementador do dispositivo PRECISA corrigir o erro por meio de uma atualização de software disponível que possa ser aplicada de acordo com o mecanismo recém-descrito.

O Android inclui recursos que permitem que o aplicativo Proprietário do dispositivo (se houver) controle a instalação de atualizações do sistema. Para facilitar, o subsistema de atualização do sistema para dispositivos que informam "android.software.device_admin" PRECISA implementar o comportamento descrito na classe SystemUpdatePolicy.

12. Registro de alterações do documento

Para ver um resumo das mudanças na definição de compatibilidade nesta versão:

• Registro de alterações do documento

Para um resumo das alterações nas seções de indivíduos:

1. Introdução
2. Tipos de dispositivo
3. Software
4. Pacote de aplicativos
5. Multimídia
6. Ferramentas e opções para desenvolvedores
7. Compatibilidade de hardware
8. Desempenho e potência
9. Modelo de segurança
10. Teste de compatibilidade de software
11. Software atualizável
12. Registro de alterações do documento
13. Entre em contato

12,1. Dicas de visualização do registro de alterações

As mudanças são marcadas da seguinte maneira:

• CDD
  Mudanças significativas nos requisitos de compatibilidade.

• Documentos
  Alterações estéticas ou relacionadas ao build.

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

13. Entre em contato

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