1. Introdução

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

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

Para serem consideradas compatíveis com o Android 7.0, 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.

2. Tipos de dispositivo

Embora o Android Open Source Project tenha sido usado na implementação de vários tipos e formatos de dispositivos, muitos aspectos dos requisitos de arquitetura e compatibilidade foram otimizados para dispositivos portáteis. A partir do Android 5.0, o Android Open Source Project visa abranger uma maior variedade de tipos de dispositivos, conforme descrito nesta seção.

Dispositivo portátil Android: uma implementação de dispositivo Android normalmente usada segurando-o na mão, como players de mp3, smartphones e tablets. Implementações de dispositivos portáteis Android:

• PRECISA ter uma tela touchscreen incorporada no dispositivo.
• PRECISA ter uma fonte de energia que ofereça mobilidade, como uma bateria.

Dispositivo Android Television: refere-se 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 "relaxante" ou "3 metros"). Dispositivos Android Television:

• PRECISA ter uma tela incorporada OU incluir uma porta de saída de vídeo, como VGA, HDMI ou uma porta sem fio para vídeo.
• PRECISA declarar os recursos android.software.DNN e android.hardware.type.television.

Um dispositivo Android Watch é uma implementação de dispositivo Android destinada a ser usado no corpo, talvez no pulso, e:

• PRECISA ter uma tela com o comprimento diagonal físico de 1,1 a 2,5 polegadas.
• PRECISA declarar o recurso android.hardware.type.watch.
• PRECISA oferecer suporte a uiMode = UI_MODE_TYPE_WATCH.

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. Implementações do Android Automotive:

• PRECISA ter uma tela com comprimento diagonal igual ou maior que 6 polegadas.
• PRECISA declarar o recurso android.hardware.type.automotive.
• PRECISA ser compatível com uiMode = UI_MODE_TYPE_CAR.
• As implementações do Android Automotive PRECISAM oferecer suporte a todas as APIs públicas no namespace android.car.*.

Todas as implementações de dispositivos Android que não se encaixam em nenhum dos tipos acima PRECISAM atender a todos os requisitos neste documento para serem compatíveis com o Android 7.0, a menos que o requisito seja descrito explicitamente como aplicável apenas a um tipo específico de dispositivo Android mencionado acima.

2.1 Configurações do dispositivo

Este é um resumo das principais diferenças na configuração de hardware por tipo de dispositivo. (Células vazias indicam "MAY"). Nem todas as configurações são abordadas nesta tabela. consulte as seções de hardware relevantes para mais detalhes.

Categoria	Recurso	Seção	Filmagem manual	Televisão	Assista	Automóveis	Outro
Entrada	Botão direcional	7.2.2. navegação sem toque		OBRIGATÓRIO
	Tela touchscreen	7.2.4. entrada com tela touch	OBRIGATÓRIO		OBRIGATÓRIO		DEVE
	Microfone	7.8.1. Microfone	OBRIGATÓRIO	DEVE	OBRIGATÓRIO	OBRIGATÓRIO	DEVE
Sensores	Acelerômetro	7.3.1 Acelerômetro	DEVE		DEVE		DEVE
	GPS	7.3.3. GPS	DEVE			DEVE
Conectividade	Wi-Fi	7.4.2. IEEE 802.11	DEVE	DEVE		DEVE	DEVE
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	DEVE	DEVE			DEVE
	Bluetooth	7.4.3. Bluetooth	DEVE	OBRIGATÓRIO	OBRIGATÓRIO	OBRIGATÓRIO	DEVE
	Bluetooth de baixa energia	7.4.3. Bluetooth	DEVE	OBRIGATÓRIO	DEVE	DEVE	DEVE
	Rádio celular	7.4.5. Capacidade mínima de rede				DEVE
	Modo host/periférico USB	7.7. USB	DEVE			DEVE	DEVE
Saída	Portas de saída de alto-falante e/ou áudio	7.8.2. saída de áudio	OBRIGATÓRIO	OBRIGATÓRIO		OBRIGATÓRIO	OBRIGATÓRIO

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

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

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.

Essa definição de compatibilidade permite que alguns tipos de hardware em que o Android inclui APIs sejam omitidos pelas implementações do dispositivo. Nesses casos, as APIs PRECISAM ainda estar presentes e se comportar de maneira razoável. 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. 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

Os implementadores de dispositivos PRECISAM oferecer suporte e aplicar todas as constantes de permissão, conforme documentado pela 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. 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 7.0.
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 7.0, esse campo PRECISA ter o valor inteiro 7.0_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 7.0, esse campo PRECISA ter o valor inteiro 7.0_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 desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”. Esse nome do dispositivo NÃO PODE ser alterado durante a vida útil do produto.
IMPRESSORA	Uma string que identifica exclusivamente este build. Ele DEVE ser legível por humanos. Ele PRECISA seguir este modelo: $(MARCA)/$(PRODUTO)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Exemplo: acme/meuproduto/ mydevice:7.0/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 desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
MODEL	Um valor escolhido pelo implementador do dispositivo contendo o nome do dispositivo conhecido pelo usuário final. Esse DEVE ser o mesmo nome usado para divulgar e vender o dispositivo aos usuários finais. Não há requisitos para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
PRODUTO	Um valor escolhido pelo implementador do dispositivo contendo o nome de desenvolvimento ou o codinome do produto específico (SKU) que PRECISA ser exclusivo na mesma marca. PRECISA ser legível, mas não se destina necessariamente à visualização dos usuários finais. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^[a-zA-Z0-9_-]+$”. Este nome de produto NÃO PODE ser alterado durante a vida útil do produto.
SÉRIE	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 deste 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 ("").

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. Os principais aplicativos Android são:

• Relógio de mesa
• Navegador
• Agenda
• Contatos
• Galeria
• Pesquisa global
• Tela de início
• Música
• Configurações

As implementações de dispositivos PRECISAM incluir os principais apps Android, conforme apropriado, ou um componente que implemente os mesmos padrões de intent definidos por todos os componentes de atividade ou serviço desses principais apps Android expostos a outros apps, implícita ou explicitamente, pelo atributo android:exported.

3.2.3.2. Resolução de intents

Como o Android é uma plataforma extensível, as implementações de dispositivos PRECISAM permitir que cada padrão de intent mencionado na seção 3.2.3.1 seja substituído por aplicativos de terceiros. A implementação upstream de código aberto do Android permite isso por padrão. implementadores de dispositivos NÃO PODEM anexar privilégios especiais aos aplicativos do sistema uso desses padrões de intent ou evitar que aplicativos de terceiros se vinculem a esses padrões e assumam o controle deles. Essa proibição inclui especificamente, mas não se limita a desativar a interface de usuário do "Seletor", que permite ao usuário escolher entre vários aplicativos que processam o mesmo padrão de intent.

As implementações de dispositivos PRECISAM fornecer uma interface para que os usuários modifiquem a atividade padrão das 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:

• 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 upstream.
• PRECISA tentar validar os filtros de intent durante a instalação do aplicativo e definir todos os filtros de intent de UIR validados com sucesso 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:
  • O usuário PRECISA ser capaz de substituir de forma holística o comportamento dos links de app padrão para que um app seja: sempre aberto, sempre perguntar ou nunca abrir, o que precisa se aplicar a todos os filtros de intent de URI candidatos igualmente.
  • O usuário PRECISA poder 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.
  • A implementação do dispositivo PRECISA fornecer 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

As implementações de dispositivos NÃO PODEM incluir componentes do Android que respeitem novos padrões de intent ou de transmissão usando uma ACTION, CATEGORY ou outra string de chave no Android. ou com.android.. Os implementadores de dispositivos NÃO PODEM incluir componentes do Android que respeitem novos padrões de intent ou de intent de transmissão usando uma ACTION, CATEGORY ou outra string de chave em um espaço de pacote pertencente a outra organização. Os implementadores de dispositivos NÃO PODEM alterar nem estender nenhum dos padrões de intent usados pelos apps principais listados na seção 3.2.3.1. As implementações de dispositivos PODEM incluir padrões de intent usando namespaces 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. Os dispositivos compatíveis com o Android PRECISAM transmitir as intents de transmissão pública em resposta aos eventos apropriados do sistema. As intents de transmissão são descritas 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.

Implementações de dispositivos:

• PRECISA respeitar a intent android.settings.HOME_CONFIG para mostrar um menu padrão de configurações do app para a tela inicial se a implementação do dispositivo informar android.software.home_screen.
• É NECESSÁRIO fornecer um menu de configurações que chame a intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para exibir uma caixa de diálogo e alterar o aplicativo de SMS padrão se a implementação do dispositivo informar android.hardware.telephony.
• PRECISA respeitar a intent android.settings.NFC_PAYMENT_CONFIG para mostrar um menu de configurações padrão do app para o recurso "tocar e pagar" se a implementação do dispositivo informar android.hardware.nfc.hce.
• PRECISA respeitar a intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar uma caixa de diálogo que permita ao usuário mudar o app Telefone padrão, se a implementação do dispositivo informar android.hardware.telephony .

3.3. Compatibilidade com API nativa

A compatibilidade do código nativo é desafiadora. Por esse motivo, é altamente RECOMENDADO que os implementadores de dispositivos usem 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 adequada. 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. As implementações de dispositivos PRECISAM ser compatíveis com uma ou mais ABIs definidas e PRECISAM implementar compatibilidade com o Android NDK, conforme mostrado abaixo.

Se a implementação de um dispositivo oferecer suporte a uma ABI do Android, ela:

• É NECESSÁRIO incluir suporte para que o código em execução no ambiente gerenciado chame código nativo, usando a semântica padrão da Java Native Interface (JNI).
• 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.
• PRECISA oferecer suporte à ABI equivalente de 32 bits, se houver ABI de 64 bits com suporte.
• É NECESSÁRIO 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 separadas por vírgula.
• 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 compatibilidade com a extensão SIMD avançado (também conhecida como NEON).
• 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. Se uma implementação de dispositivo não for compatível com uma ABI predefinida já existente, ela NÃO PODERÁ informar suporte para nenhuma ABIs.

As seguintes APIs de código nativo PRECISAM estar disponíveis para apps que incluem código nativo:

• 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
• Suporte a OpenGL, conforme descrito abaixo

Para as bibliotecas nativas listadas acima, a implementação do dispositivo NÃO PODE adicionar nem remover as funções públicas.

Bibliotecas nativas não listadas acima, mas implementadas e fornecidas no AOSP, já que as bibliotecas do sistema são reservadas e NÃO PODEM ser expostas a apps de terceiros destinados ao nível 24 da API ou mais recente.

As implementações de dispositivos PODEM adicionar bibliotecas que não sejam do AOSP e as expor diretamente como uma API para apps de terceiros, mas as outras bibliotecas DEVEM estar em /vendor/lib ou /vendor/lib64 e PRECISAM ser listadas em /vendor/etc/public.libraries.txt .

As implementações de dispositivos PRECISAM incluir o libGLESv3.so e, por sua vez, PRECISAM exportar todos os símbolos de função do OpenGL ES 3.1 e do Android Extension Pack, conforme definido na versão android-24 do NDK. Embora todos os símbolos precisem estar presentes, apenas as funções correspondentes para versões e extensões do OpenGL ES realmente compatíveis com o dispositivo precisam ser totalmente implementadas.

3.3.1.1 Bibliotecas gráficas

Vulkan é uma API multiplataforma de baixa sobrecarga para gráficos 3D de alto desempenho. As implementações de dispositivos, mesmo que não incluam suporte para as APIs do Vulkan, PRECISAM atender aos seguintes requisitos:

• Ela PRECISA sempre fornecer uma biblioteca nativa chamada libvulkan.so, que exporta símbolos de função para a API principal do Vulkan 1.0, bem como as extensões VK_KHR_surface, VK_KHR_android_surface e VK_KHR_swapchain.

Implementações de dispositivos, se houver suporte para APIs do Vulkan:

• PRECISA informar, um ou mais VkPhysicalDevices pela chamada de vkEnumeratePhysicalDevices.
• Cada VkPhysicalDevices enumerado PRECISA implementar totalmente a API do Vulkan 1.0.
• É NECESSÁRIO informar as flags de recurso PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL e PackageManager#FEATURE_VULKAN_HARDWARE_VERSION corretas.
• É NECESSÁRIO enumerar as camadas, contidas em bibliotecas nativas chamadas libVkLayer*.so, no diretório da biblioteca nativa do pacote do app, usando as funções vkEnumerateInstanceLayerProperties e vkEnumerateDeviceLayerProperties em libvulkan.so.
• NÃO É POSSÍVEL enumerar camadas fornecidas por bibliotecas fora do pacote do aplicativo nem fornecer outras maneiras de rastrear ou interceptar a API do Vulkan, a menos que o aplicativo tenha o atributo android:debuggable=”true”.

Implementações de dispositivos, se não incluir suporte às APIs do Vulkan:

• PRECISA informar 0 VkPhysicalDevices pela chamada de vkEnumeratePhysicalDevices.
• NÃO É NECESSÁRIO declarar nenhuma das flags de recurso do Vulkan PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL e PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.

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

A arquitetura ARMv8 suspendeu o uso de várias operações de CPU, incluindo algumas operações usadas no código nativo existente. Em dispositivos ARM de 64 bits, as seguintes operações descontinuadas PRECISAM continuar disponíveis para o código ARM nativo de 32 bits, seja pela compatibilidade nativa com a CPU ou pela emulação de software:

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

As versões legadas do Android NDK usavam /proc/cpuinfo para descobrir recursos de CPU do código nativo ARM de 32 bits. Para compatibilidade com aplicativos criados com este NDK, os dispositivos PRECISAM incluir as seguintes linhas em /proc/cpuinfo quando são lidos por aplicativos ARM de 32 bits:

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

Esses requisitos só se aplicam quando /proc/cpuinfo é lido por aplicativos ARM de 32 bits. Os dispositivos não DEVEM alterar o /proc/cpuinfo quando lidos por aplicativos ARM de 64 bits ou não ARM.

3,4 Compatibilidade com a Web

3.4.1. Compatibilidade com WebView

O recurso de plataforma android.software.webview PRECISA ser informado em qualquer dispositivo que ofereça uma implementação completa da API android.webkit.WebView. Além disso, NÃO PODE ser informado em dispositivos que não tenham uma implementação completa da API. A implementação de código aberto do Android usa o código do projeto Chromium para implementar o android.webkit.WebView. Como não é viável desenvolver um pacote de testes abrangente para um sistema de renderização da Web, os implementadores de dispositivos PRECISAM usar o build upstream específico do Chromium na implementação da WebView. Especificamente:

• As implementações do android.webkit.WebView do dispositivo PRECISAM ser baseadas no build do Chromium do Android Open Source Project para Android 7.0. Essa versão inclui um conjunto específico de funcionalidades e correções de segurança para a WebView.

• 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

O navegador autônomo PODE ser baseado em uma tecnologia de navegador diferente do WebKit. No entanto, mesmo que um aplicativo de navegador alternativo seja usado, o componente android.webkit.WebView fornecido para apps de terceiros PRECISA ser baseado no WebKit, conforme descrito na seção 3.4.1.

As implementações PODEM enviar uma string de user agent personalizada no aplicativo Navegador autônomo.

O aplicativo Navegador autônomo (seja com base no aplicativo WebKit Navegador ou em um substituto de terceiros) DEVE incluir suporte para a maior quantidade possível de HTML5. No mínimo, as implementações de dispositivos PRECISAM oferecer suporte a cada uma destas APIs associadas ao HTML5:

• cache do app/operação off-line
• <vídeo> tag
• geolocalização

Além disso, as implementações de dispositivos DEVEM ser compatíveis com a API Webstorage de HTML5/W3C e com a API IndexedDB de 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.

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:

• Os dispositivos NÃO PODEM mudar o comportamento ou a semântica de uma intent padrão.
• Os dispositivos NÃO PODEM alterar o ciclo de vida ou a semântica do ciclo de vida de um tipo específico de componente do sistema (como Service, Activity, ContentProvider etc.).
• Os dispositivos NÃO PODEM mudar a semântica de uma permissão padrão.

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 reimplementar 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.*
• sol.*
• A versão android.*
• com.android.*

As modificações proibidas incluem :

• Implementações de dispositivos NÃO PODEM modificar as APIs expostas publicamente na plataforma Android mudando qualquer método ou assinatura de classe ou removendo classes ou campos de classe.
• Os implementadores de dispositivos PODEM modificar a implementação subjacente das APIs, mas essas modificações NÃO PODEM afetar o comportamento declarado e a assinatura na linguagem Java de nenhuma API exposta publicamente.
• Os implementadores de dispositivos NÃO PODEM adicionar elementos expostos publicamente (como classes ou interfaces, ou campos ou métodos a classes ou interfaces existentes) às APIs 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. Em outras palavras, os implementadores de dispositivos NÃO PODEM expor novas APIs nem alterar as APIs existentes nos namespaces mencionados acima. Os implementadores de dispositivos PODEM fazer modificações somente para uso interno, mas essas modificações NÃO PODEM ser anunciadas nem expostas aos desenvolvedores.

Os implementadores de dispositivos PODEM adicionar APIs personalizadas, mas essas APIs NÃO PODEM estar em um namespace de propriedade ou referente a outra organização. Por exemplo, os implementadores de dispositivos NÃO PODEM adicionar APIs ao namespace com.google.* ou semelhante: somente o Google pode fazer isso. Da mesma forma, o Google NÃO PODE adicionar APIs a serviços os namespaces. Além disso, se uma implementação de dispositivo incluir APIs personalizadas fora do namespace padrão do Android, essas APIs PRECISAM ser empacotadas em uma biblioteca compartilhada do Android para que apenas os aplicativos 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), o implementador DEVE acessar source.android.com e iniciar o processo para contribuir com alterações e código, de acordo com as informações nesse site.

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

3,7 Compatibilidade de ambiente de execução

As implementações de dispositivos PRECISAM oferecer suporte ao formato completo do Dalvik Executable (DEX) e à especificação e semântica de bytecode Dalvik. Os implementadores de dispositivos DEVEM usar o 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.

As implementações de dispositivos PRECISAM 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. 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). As implementações de dispositivos que permitem que aplicativos de terceiros substituam a tela inicial do dispositivo PRECISAM declarar o recurso de plataforma android.software.home_screen.

3.8.2. Widgets

O Android define 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, um recurso MUITO RECOMENDADO para oferecer suporte a implementações de dispositivos portáteis. As implementações de dispositivos com suporte à incorporação de widgets na tela inicial PRECISAM atender aos seguintes requisitos e declarar suporte ao recurso android.software.app_widgets da plataforma.

• Os inicializadores do dispositivo PRECISAM incluir suporte integrado para AppWidgets e expor recursos da interface do usuário para adicionar, configurar, visualizar e remover AppWidgets diretamente do acesso rápido.
• As implementações de dispositivos PRECISAM ser capazes 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 ver mais detalhes.
• As implementações de dispositivos que incluem suporte à tela de bloqueio podem ser compatíveis com widgets de aplicativos na tela de bloqueio.

3.8.3. Notificações

O Android inclui APIs que permitem que os desenvolvedores notifiquem os usuários sobre eventos importantes usando recursos de hardware e software do dispositivo.

Algumas APIs permitem que os aplicativos realizem notificações ou atraiam atenção usando hardware, especificamente som, vibração e luz. As implementações de dispositivos PRECISAM ser compatíveis com 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.

Além disso, a implementação 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, que, no caso de um dispositivo Android Television, inclui a possibilidade de não mostrar as notificações. Os implementadores de dispositivos PODEM oferecer uma experiência de usuário alternativa para as notificações além da fornecida pela implementação de referência do Android Open Source. No entanto, esses sistemas alternativos de notificação PRECISAM ser compatíveis com os recursos de notificação existentes, como mostrado acima.

O Android oferece suporte a várias notificações, como:

• Notificações avançadas . Visualizações interativas para notificações contínuas.
• Notificações de alerta . Os usuários das visualizações interativas podem agir ou dispensar sem sair do aplicativo atual.
• Notificações da tela de bloqueio . Notificações mostradas em uma tela de bloqueio com controle granular sobre a visibilidade.

As implementações de dispositivos Android, quando essas notificações ficam visíveis, PRECISAM executar corretamente as notificações avançadas e de alerta e incluir o título/nome, ícone e texto, conforme documentado nas APIs do Android.

O Android inclui APIs de serviço de listener de notificações que permitem que os apps (quando ativados explicitamente pelo usuário) recebam uma cópia de todas as notificações à medida que são postadas ou atualizadas. As implementações de dispositivos PRECISAM enviar notificações completas e prontamente a todos os serviços de listener instalados e ativados pelo usuário, incluindo todos os metadados anexados ao objeto Notification.

As implementações de dispositivos compatíveis com o recurso Não perturbe PRECISAM atender aos seguintes requisitos:

• 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 ao app o acesso às configurações da política de Não perturbe.
• Quando a implementação do dispositivo fornece uma maneira de o usuário conceder ou negar o acesso de apps de terceiros à configuração da política de Não perturbe, é NECESSÁRIO mostrar as regras automáticas de Não perturbe criadas pelos aplicativos junto com as regras predefinidas e criadas pelo usuário.
• É NECESSÁRIO respeitar os valores suppressedVisualEffects transmitidos pela NotificationManager.Policy. Se um app tiver definido uma das flags SuppPRESSED_EF_SCREEN_OFF ou supPRESSED_EF_SCREEN_ON, ele 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. As implementações de dispositivos DEVEM implementar as APIs que permitem aos desenvolvedores reutilizar a interface do usuário para oferecer pesquisa nos próprios aplicativos. As implementações de dispositivos que implementam a interface de pesquisa global PRECISAM 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 forem instalados aplicativos de terceiros que usem essa funcionalidade, o comportamento padrão DEVE ser exibir sugestões e resultados de mecanismos de pesquisa na web.

As implementações de dispositivos Android DEVEM, assim como as do Android Automotive, implementar um assistente no dispositivo para processar a Ação de assistência.

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. As implementações de dispositivos que oferecem suporte à ação de assistência PRECISAM indicar claramente para o usuário final quando o contexto é compartilhado exibindo uma luz branca ao redor das bordas da tela. Para garantir uma visibilidade clara para o usuário final, a indicação PRECISA corresponder ou exceder a duração e o brilho da implementação do Android Open Source Project.

3.8.5. 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. As implementações de dispositivos PRECISAM exibir avisos dos aplicativos para os usuários finais de maneira de alta visibilidade.

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" como um conjunto de estilos definidos que os desenvolvedores de apps usam se quiserem combinar com a aparência do tema Holo, conforme definido pelo SDK do Android. As implementações de dispositivos NÃO PODEM alterar nenhum dos atributos de tema Holo expostos a aplicativos.

O Android inclui uma família de temas “Material” como um conjunto de estilos definidos para os desenvolvedores de aplicativos usarem se quiserem combinar com a aparência do tema de design em uma grande variedade de tipos de dispositivos Android. As implementações de dispositivos PRECISAM ser compatíveis com a família de temas "Material" e NÃO podem mudar os atributos de tema do Material Design ou os recursos 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. Portanto, as implementações de dispositivos Android PRECISAM 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 indique um status problemático ou que um app solicite uma barra de status clara usando a sinalização SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Quando um app solicita uma barra de status clara, as implementações de dispositivos Android PRECISAM mudar a cor dos ícones de status do sistema para preto. Para mais detalhes, consulte R.style.

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 são exibidos como um plano de fundo atrás de outros aplicativos.

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

Implementações de dispositivos capazes de executar planos de fundo interativos de forma confiável, conforme descrito acima, DEVEM implementar planos de fundo interativos e, quando implementadas, DEVEM 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, mas PRECISAM atender aos seguintes requisitos:

• PRECISA oferecer suporte a pelo menos até seis atividades exibidas.
• DEVE exibir pelo menos o título de quatro atividades por vez.
• PRECISA implementar o comportamento de fixação de 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
• PODE exibir recentes afiliadas como um grupo que é movido em conjunto.
• 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.

É RECOMENDADO que as implementações de dispositivos usem 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. As implementações de dispositivos que permitem aos usuários usar métodos de entrada de terceiros no dispositivo PRECISAM declarar o recurso android.software.input_methods da plataforma e oferecer suporte a APIs do IME, conforme definido na documentação do SDK do Android.

As implementações de dispositivos que declaram o recurso android.software.input_methods PRECISAM fornecer um mecanismo acessível ao usuário para adicionar e configurar métodos de entrada de terceiros. As implementações de dispositivos PRECISAM mostrar a interface de configurações em resposta à intent android.settings.INPUT_method_CONFIG.

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. As implementações de dispositivos que oferecem suporte a uma tela de bloqueio, a menos que uma implementação do Android Automotive ou do Watch, PRECISAM mostrar as notificações da tela de bloqueio, incluindo o modelo de notificação de mídia.

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

Quando um dispositivo tem um sensor de hardware (por exemplo, GPS) capaz de fornecer as coordenadas de localização, 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 9.0 (link em inglês). Todas as implementações de dispositivos DEVEM ser capazes de renderizar esses caracteres de emoji em glifo de cor e, quando as implementações de dispositivos Android incluem um IME, ele DEVE fornecer um método de entrada para o usuário desses caracteres de emoji.

Os dispositivos portáteis Android DEVEM ser compatíveis com o tom de pele e os diversos emojis de família, conforme especificado no Relatório técnico Unicode no 51.

O Android é compatível com a fonte Roboto 2 com diferentes pesos: Sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light, que PRECISAM ser incluídos para os idiomas disponíveis no dispositivo e cobertura completa em Unicode 7.0 de símbolos latinos, grego e cirílico estendidos, incluindo blocos latinos, grego e cirílico estendidos e cirílicos com alfabeto latino, grego e cirílico.

3.8.14. Várias janelas

Uma implementação de dispositivo PODE escolher não implementar nenhum modo de várias janelas. No entanto, se ela puder mostrar várias atividades ao mesmo tempo, ela PRECISA implementar esses modos de várias janelas de acordo com os comportamentos do aplicativo e as APIs descritos na documentação de suporte do modo de várias janelas do SDK do Android e atender aos seguintes requisitos:

• Os aplicativos podem indicar se são capazes de operar no modo de várias janelas no arquivo AndroidManifest.xml, seja explicitamente com o atributo android:resizeableActivity ou implicitamente com a targetSdkVersion > 24. Os apps que definem explicitamente esse atributo como "false" no manifesto não podem ser iniciados no modo de várias janelas. Apps que não definem o atributo no arquivo de manifesto (targetSdkVersion < 24) podem ser iniciados no modo de várias janelas, mas o sistema PRECISA enviar avisos de que o app pode não funcionar como esperado nesse modo.
• As implementações de dispositivos NÃO PODEM oferecer o modo de tela dividida ou formato livre se a altura e a largura da tela forem inferiores a 440 dp.
• As implementações de dispositivos com tamanho de tela xlarge DEVEM ser compatíveis com o modo de forma livre.
• As implementações de dispositivos Android Television PRECISAM oferecer suporte ao modo picture-in-picture (PIP) de várias janelas e colocar esse modo no canto superior direito quando o PIP estiver ATIVADO.
• As implementações de dispositivos compatíveis com várias janelas no modo PIP PRECISAM alocar pelo menos 240 x 135 dp para a janela do PIP.
• Se o modo de várias janelas do PIP for compatível, a chave KeyEvent.KEYCODE_WINDOW PRECISA ser usada para controlar a janela do PIP. Caso contrário, a chave PRECISA estar disponível para a atividade em primeiro plano.

3,9. Administração do dispositivo

O Android inclui recursos que permitem que aplicativos com reconhecimento de segurança executem funções de administração de dispositivos no nível do sistema, como aplicar políticas de senha ou realizar a limpeza remota, usando a API Android Device Administration. As implementações de dispositivos PRECISAM fornecer uma implementação da classe DevicePolicyManager. As implementações de dispositivos compatíveis com uma tela de bloqueio segura PRECISAM implementar todas as políticas de administração de dispositivos definidas na documentação do SDK do Android e informar o recurso da plataforma android.software.device_admin.

3.9.1 Provisionamento de dispositivos

3.9.1.1 Provisionamento do proprietário do dispositivo

Se uma implementação de dispositivo declarar o recurso android.software.device_admin, ela PRECISA implementar o provisionamento do app Proprietário do dispositivo de um aplicativo de cliente de política do dispositivo (DPC), conforme indicado abaixo:

• Quando a implementação do dispositivo ainda não tem dados do usuário configurados, ela:
  • PRECISA informar true para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  • PRECISA registrar o aplicativo DPC como o app Proprietário do dispositivo em resposta à ação da intent android.app.action.PROVISION_MANAGED_DEVICE.
  • PRECISA registrar o aplicativo de DPC como o app do 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:
  • É NECESSÁRIO informar false para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  • NÃO É POSSÍVEL mais registrar nenhum aplicativo de DPC como o app Proprietário do dispositivo.

As implementações de dispositivos PODEM ter um aplicativo pré-instalado que executa funções de administração do dispositivo, mas esse aplicativo NÃO PODE ser definido como o app Proprietário do dispositivo sem o consentimento explícito ou a ação do usuário ou do administrador do dispositivo.

3.9.1.2 Provisionamento de perfil gerenciado

Se uma implementação de dispositivo declarar o android.software.managed_users, será NECESSÁRIO registrar um aplicativo Device Policy Controller (DPC) como proprietário de um novo perfil gerenciado.

A experiência do usuário do processo de provisionamento de perfil gerenciado (o fluxo iniciado por android.app.action.PROVISION_MANAGED_PROFILE) PRECISA estar alinhado à implementação do AOSP.

As implementações de dispositivos PRECISAM fornecer as seguintes affordances na interface do usuário das 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

Os dispositivos compatíveis com perfis gerenciados são aqueles que:

• Declare android.software.device_admin (consulte a seção 3.9 Administração do dispositivo).
• Não sejam dispositivos com pouca RAM (consulte a seção 7.6.1).
• Aloque o armazenamento interno (não removível) como compartilhado (consulte a seção 7.6.2).

Os dispositivos compatíveis com perfis gerenciados PRECISAM:

• Declare a flag de recurso da plataforma android.software.managed_users .
• Oferecer suporte a perfis gerenciados por meio das APIs android.app.admin.DevicePolicyManager.
• Permita que apenas um perfil gerenciado seja criado.
• Use um selo de ícone (semelhante ao de trabalho upstream do AOSP) para representar os aplicativos e widgets gerenciados e outros elementos de interface com selo, como Recentes e Notificações.
• Mostre um ícone de notificação (semelhante ao selo de trabalho upstream do AOSP) para indicar quando o usuário está em um aplicativo de perfil gerenciado.
• Mostre 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.
• Quando houver um perfil gerenciado, mostre 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.
• Quando houver um perfil gerenciado, exponha as seguintes affordances de usuário para o usuário principal e o perfil gerenciado:
  • Contabilização separada do uso de bateria, localização, dados móveis e armazenamento para o usuário principal e o perfil gerenciado.
  • Gerenciamento independente de apps de VPN instalados no usuário principal ou no perfil gerenciado.
  • Gerenciamento independente de apps instalados no usuário principal ou no perfil gerenciado.
  • Gerenciamento independente de contas no perfil gerenciado ou do usuário principal.
• Verifique se o discador, os contatos e os aplicativos de mensagens pré-instalados podem pesquisar e procurar informações do autor da chamada no perfil gerenciado (se houver), além das informações do perfil principal, se o controlador de política do dispositivo permitir. Quando os contatos do perfil gerenciado aparecem no registro de chamadas pré-instalado, na IU em chamada, nas notificações de chamadas perdidas e em andamento, nos contatos e nos apps de mensagens, eles DEVEM receber um selo com o mesmo selo usado para indicar os apps do perfil gerenciado.
• 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.
• Ofereça 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.

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ços de acessibilidade recebam callbacks para eventos do usuário e do sistema e gerem mecanismos de feedback alternativos, como conversão de texto em voz, retorno tátil e navegação por trackball/botão direcional.

As implementações de dispositivos incluem os seguintes requisitos:

• As implementações do Android Automotive DEVEM oferecer uma implementação do framework de acessibilidade do Android consistente com a implementação padrão do Android.
• As implementações de dispositivos (exceto Android Automotive) PRECISAM fornecer uma implementação do framework de acessibilidade do Android consistente com a implementação padrão do Android.
• As implementações de dispositivos (exceto Android Automotive) PRECISAM oferecer suporte a implementações de serviços de acessibilidade de terceiros usando as APIs android.accessibilityservice.
• As implementações de dispositivos (exceto Android Automotive) PRECISAM gerar AccessibilityEvents e entregar esses eventos a todas as implementações de AccessibilityService registradas de maneira consistente com a implementação padrão do Android.

• Implementações de dispositivos (dispositivos Android Automotive e Android Watch sem saída de áudio excluída) PRECISAM fornecer um mecanismo acessível ao usuário para ativar e desativar os serviços de acessibilidade e PRECISAM exibir essa interface em resposta à intent android.provider.Settings.ACTION_ACCESSIBILITY_CONFIG.

• As implementações de dispositivos Android com saída de áudio são FORTEMENTE RECOMENDADAS para fornecer implementações de serviços de acessibilidade no dispositivo comparáveis ou que excedam a funcionalidade dos serviços de acessibilidade TalkBack** e acesso com interruptor (https://github.com/google/talkback).

• Os dispositivos Android Watch com saída de áudio DEVEM fornecer implementações de um serviço de acessibilidade no dispositivo comparável ou superior à funcionalidade do serviço de acessibilidade TalkBack (https://github.com/google/talkback).
• As implementações de dispositivos DEVEM 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.

** Para idiomas compatíveis com a conversão de texto em voz.

Além disso, se houver um serviço de acessibilidade pré-carregado, ele PRECISA ser um app {directBootAware} com reconhecimento de inicialização direta se o dispositivo tiver armazenamento criptografado que usa a criptografia baseada em arquivos (FBE, na sigla em inglês).

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. As implementações de dispositivos que informam o recurso android.hardware.audio.output PRECISAM atender a esses requisitos relacionados ao framework de TTS do Android.

Implementações do Android Automotive:

• PRECISA oferecer suporte às APIs do framework de TTS do Android.
• PODE oferecer suporte à instalação de mecanismos TTS de terceiros. Se compatível, os parceiros PRECISAM fornecer uma interface acessível ao usuário que permita selecionar um mecanismo de TTS para uso no sistema.

Todas as outras implementações de dispositivos:

• PRECISA oferecer suporte às APIs do framework de TTS do Android e DEVE incluir um mecanismo TTS que ofereça suporte aos idiomas disponíveis no dispositivo. Observe que o software de código aberto upstream do Android inclui uma implementação completa do mecanismo TTS.
• PRECISA ser compatível com a instalação de mecanismos TTS de terceiros.
• PRECISA fornecer uma interface acessível ao usuário que permita selecionar um mecanismo TTS para uso no 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. As implementações de dispositivos Android Television PRECISAM oferecer suporte ao TV Input Framework.

As implementações de dispositivos com suporte ao TIF PRECISAM declarar o recurso da plataforma android.software.live_tv.

3.12.1. App de TV

Qualquer implementação de dispositivo que declare suporte para TV ao vivo PRECISA ter um aplicativo de TV instalado (app de TV). O Android Open Source Project oferece uma implementação do app de TV.

O app de TV PRECISA oferecer recursos para instalar e usar canais de TV e atender aos seguintes requisitos:

• As implementações de dispositivos PRECISAM 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 PODEM 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).

3.12.1.1 Guia eletrônico da programação

As implementações de dispositivos Android Television PRECISAM mostrar uma sobreposição informativa e interativa, que PRECISA incluir um guia eletrônico da programação (EPG, na sigla em inglês) gerado com base nos valores nos campos TvContract.Programs. O EPG PRECISA atender aos seguintes requisitos:

• O EPG PRECISA mostrar 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.
• O EPG é FORTEMENTE RECOMENDADO para exibir as entradas instaladas e de terceiros com o mesmo destaque. O EPG NÃO PODE exibir as entradas de terceiros a mais do que uma única ação de navegação fora das entradas instaladas no EPG.
• Na mudança de canal, as implementações de dispositivos PRECISAM exibir dados de EPG para o programa em execução no momento.

3.12.1.2. Navegação

O app de TV 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, aplicativo de controle remoto ou controle de jogo):

• Como mudar canais de TV
• Abrindo o EPG
• Como configurar e ajustar entradas de terceiros baseadas em TIF
• Abrindo o menu "Configurações"

O app de TV DEVE transmitir eventos de teclas para entradas HDMI pelo CEC.

3.12.1.3 Vinculação ao app de entrada de TV

As implementações de dispositivos Android Television PRECISAM oferecer suporte à vinculação de apps de entrada de TV, o 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 PRECISA mostrar o link do app de entrada de TV quando fornecido.

3.12.1.4 Mudança de horário

As implementações de dispositivos Android Television PRECISAM oferecer suporte à mudança de horário, que permite ao usuário pausar e retomar o conteúdo ao vivo. As implementações de dispositivos PRECISAM oferecer 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

As implementações de dispositivos Android Television são FORTEMENTE RECOMENDADAS para oferecer suporte à gravação na TV. Se a entrada de TV for compatível com gravação, o EPG PODE oferecer uma maneira de gravar um programa caso a gravação de tal programa não seja proibida. As implementações de dispositivos DEVEM fornecer uma interface do usuário para reproduzir programas gravados.

3,13 Configurações rápidas

As implementações em dispositivos Android DEVEM incluir um componente de interface para Configurações rápidas que permita o acesso rápido a ações usadas com frequência ou urgentes.

O Android inclui a API quicksettings, que permite que apps de terceiros implementem blocos que podem ser adicionados pelo usuário junto com os blocos fornecidos pelo sistema no componente de interface "Configurações rápidas". Se a implementação de um dispositivo tiver um componente de interface para Configurações rápidas, ela:

• PRECISA permitir que o usuário adicione ou remova blocos de um app de terceiros nas Configurações rápidas.
• NÃO É POSSÍVEL adicionar automaticamente um bloco de um app de terceiros diretamente às Configurações rápidas.
• 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 APIs de interface do veículo

3.14.1. Interface de mídia do veículo

Qualquer implementação de dispositivo que declare suporte automotivo PRECISA incluir um framework de interface para oferecer suporte a apps de terceiros que usem as APIs MediaBrowser e MediaSession.

A estrutura de interface do usuário compatível com aplicativos de terceiros que dependem do MediaBrowser e do MediaSession tem os seguintes requisitos visuais:

• É NECESSÁRIO exibir os ícones de MediaItem e os ícones de notificação sem mudanças.
• PRECISA exibir esses itens conforme descrito pelo MediaSession, por exemplo, metadados, ícones e imagens.
• PRECISA mostrar o título do app.
• PRECISA ter uma gaveta para apresentar a hierarquia MediaBrowser.

4. Compatibilidade do empacotamento de aplicativos

As implementações de dispositivos PRECISAM instalar e executar arquivos ".apk" do Android conforme gerado pela ferramenta "aapt" incluída no SDK oficial do Android. Por esse motivo, as implementações de dispositivos DEVEM usar o sistema de gerenciamento de pacotes da implementação de referência.

O gerenciador de pacotes PRECISA oferecer suporte à verificação de arquivos ".apk" usando o esquema de assinatura de APK v2 e a assinatura JAR.

As implementações de dispositivos NÃO PODEM 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.

5. Compatibilidade multimídia

5.1. Codecs de mídia

Implementações de dispositivos:

• PRECISA ser compatível com os principais formatos de mídia especificados na documentação do SDK do Android, exceto quando explicitamente permitido neste documento.

• PRECISA ser compatível com os formatos de mídia, codificadores, decodificadores, tipos de arquivo e formatos de contêiner definidos nas tabelas abaixo e informados por MediaCodecList.

• também PRECISA ser capaz de decodificar todos os perfis reportados no respectivo CamcorderProfile.

• PRECISA ser capaz de decodificar todos os formatos que pode codificar. Isso inclui todos os bitstreams gerados pelos codificadores.

Os codecs DEVEM visar a latência mínima do codec, ou seja, os codecs—

• NÃO DEVE consumir e armazenar buffers de entrada e retornar buffers de entrada somente quando 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 tabela 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.1. Codecs de áudio

Formato/Codec	Codificador	Decodificador	Detalhes	Tipos de arquivos/formatos de contêiner compatíveis
Perfil AAC para MPEG-4 (AAC LC)	OBRIGATÓRIO 1	REQUIRED	Compatível com conteúdo mono/estéreo/5.0/5.1 2 com taxas de amostragem padrão de 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS AAC bruto (.aac, decodificação no Android 3.1+, codificar no Android 4.0+, ADIF indisponível) MPEG-TS (.ts, não pesquisável, Android 3.0+)
Perfil MPEG-4 HE AAC (AAC+)	OBRIGATÓRIO 1 (Android 4.1 ou superior)	REQUIRED	Suporte a conteúdo mono/estéreo/5.0/5.1 2 com taxas de amostragem padrão de 16 a 48 kHz.
MPEG-4 HE AACv2 Perfil (AAC+ otimizado)		REQUIRED	Suporte a conteúdo mono/estéreo/5.0/5.1 2 com taxas de amostragem padrão de 16 a 48 kHz.
AAC ELD (AAC aprimorado com atraso baixo)	OBRIGATÓRIO 1 (Android 4.1 ou superior)	OBRIGATÓRIO (Android 4.1 ou superior)	Suporte a conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.
AMR-NB	OBRIGATÓRIO 3	OBRIGATÓRIO 3	4,75 a 12,2 kbps com amostragem a 8 kHz.	3GPP (.3gp)
AMR-WB	OBRIGATÓRIO 3	OBRIGATÓRIO 3	9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz
FLAC		OBRIGATÓRIO (Android 3.1 ou superior)	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 passa-baixa). 16 bits RECOMENDADO; sem pontilhamento aplicado a 24 bits.	Somente FLAC (.flac)
MP3		REQUIRED	Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8 a 320 Kbps	MP3 (.mp3)
MIDI		REQUIRED	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		REQUIRED		Ogg (.ogg) Matroska (.mkv, Android 4.0+)
PCM/WAVE	OBRIGATÓRIO 4 (Android 4.1 ou superior)	REQUIRED	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		OBRIGATÓRIO (Android 5.0 ou superior)		Matroska (.mkv), Ogg(.ogg)

1 Obrigatório para implementações de dispositivos que definem android.hardware.microphone, mas opcional para implementações de dispositivos do Android Watch.

2 A gravação ou reprodução PODE ser feita em mono ou estéreo, mas a decodificação de buffers de entrada AAC de streams multicanal (ou seja, mais de dois canais) para PCM usando o decodificador de áudio AAC padrão na API android.media.MediaCodec PRECISA ser compatível:

• a decodificação é realizada sem downmix (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 para seis canais de PCM),
• Metadados de intervalo dinâmico, conforme definido em "Controle de intervalo dinâmico (DRC)" no ISO/IEC 14496-3, e as chaves de 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

3 Obrigatório para implementações de dispositivos Android portáteis.

4 Obrigatório para implementações de dispositivos que definem android.hardware.microphone, incluindo implementações de dispositivos Android Watch.

5.1.2. Codecs de imagem

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

5.1.3. Codecs de vídeo

• Codecs que promovem o suporte ao perfil HDR PRECISAM oferecer suporte à análise e processamento de metadados estáticos HDR.

• Se um codec de mídia anunciar suporte a atualizações intra, ele PRECISA oferecer suporte aos períodos de atualização no intervalo de 10 a 60 quadros e operar com precisão dentro de 20% do período de atualização configurado.

• Os codecs de vídeo PRECISAM oferecer suporte a tamanhos de buffer de bytes de saída e entrada que acomodem o maior frame compactado viável e descompactado conforme determinado pelo padrão e pela configuração, mas também sem alocação excessiva.

• Codificadores e decodificadores de vídeo PRECISAM ser compatíveis com o formato de cor flexível YUV420 (COLOR_FormatYUV420 streaming).

Formato/Codec	Codificador	Decodificador	Detalhes	Tipos de arquivos compatíveis/ Formatos de contêiner
H.263	MAI	MAI		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	OBRIGATÓRIO 2	OBRIGATÓRIO 2	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		OBRIGATÓRIO 5	Consulte detalhes na seção 5.3	MPEG-4 (.mp4)
MPEG-2		FORTEMENTE RECOMENDADO 6	Perfil principal	MPEG2-TS
MPEG-4 SP		OBRIGATÓRIO 2		3GPP (.3gp)
VP8 3	OBRIGATÓRIO 2 (Android 4.3 ou superior)	OBRIGATÓRIO 2 (Android 2.3.3+)	Consulte as seções 5.2 e 5.3 para mais detalhes	WebM (.webm) Matroska (.mkv, Android 4.0+) 4
VP9		OBRIGATÓRIO 2 (Android 4.4 ou superior)	Consulte detalhes na seção 5.3	WebM (.webm) Matroska (.mkv, Android 4.0+) 4

1 Obrigatório para implementações de dispositivos que incluem hardware da câmera e definem android.hardware.camera ou android.hardware.camera.front.

2 Obrigatório para implementações de dispositivos, exceto dispositivos Android Watch.

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

4 As implementações de dispositivos DEVEM ser compatíveis com a gravação de arquivos Matroska WebM.

5 FORTEMENTE RECOMENDADO para o Android Automotive, opcional para o Android Watch e obrigatório para todos os outros tipos de dispositivos.

6 Aplicável apenas a implementações de dispositivos Android Television.

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

Codificadores de vídeo H.264, VP8, VP9 e HEVC—

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

Os codificadores de vídeo H.263 e MPEG-4 DEVEM oferecer suporte a taxas de bits configuráveis de forma dinâmica.

Todos os codificadores de vídeo DEVEM atender aos seguintes objetivos de taxa de bits em duas janelas deslizantes:

• Ela DEVE ser no máximo cerca de 15% acima da taxa de bits entre os intervalos intraframe (I-frame).
• Ela DEVE ser no máximo cerca de 100% acima da taxa de bits em uma janela deslizante de um segundo.

5.2.1. H.263

As implementações de dispositivos Android com codificadores H.263 PRECISAM oferecer suporte ao perfil de referência de nível 45.

5.2.2. H-264

Implementações de dispositivos Android compatíveis com o codec H.264:

• 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.
• PRECISA ser compatível com os 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.
• Além disso, os dispositivos Android Television são FORTEMENTE RECOMENDADOS a codificar vídeos em HD de 1080p a 30 fps.

	SD (baixa qualidade)	SD (alta qualidade)	HD de 720p 1	HD de 1080p 1
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

1 Quando compatível com hardware, mas FORTEMENTE RECOMENDADO para dispositivos Android Televisão.

5.2.3. VP8

As implementações de dispositivos Android com suporte ao codec VP8 PRECISAM oferecer suporte aos perfis de codificação de vídeo SD e DEVEM oferecer suporte aos seguintes perfis de codificação de vídeo em HD (alta definição).

	SD (baixa qualidade)	SD (alta qualidade)	HD de 720p 1	HD de 1080p 1
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

1 Quando compatível com o hardware.

5,3 Decodificação de vídeo

Implementações de dispositivos:

• PRECISA ser compatível com a resolução dinâmica de vídeo e a alternância 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.

• Implementações compatíveis com o decodificador Dolby Vision

• É NECESSÁRIO fornecer um extrator compatível com Dolby Vision.

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

• As implementações que oferecem um extrator compatível com Dolby Vision PRECISAM definir o índice de faixa das camadas de base compatíveis com versões anteriores (se houver) para que seja igual ao índice de faixa da camada Dolby Vision combinada.

5.3.1. MPEG-2

As implementações de dispositivos Android com decodificadores MPEG-2 precisam oferecer suporte ao alto nível do perfil principal.

5.3.2. H.263

As implementações de dispositivos Android com decodificadores H.263 PRECISAM oferecer suporte ao perfil de referência de nível 30 e 45.

5.3.3. MPEG-4

As implementações de dispositivos Android com decodificadores MPEG-4 PRECISAM ser compatíveis com Simple Profile de nível 3.

5.3.4. H.264

Implementações de dispositivos Android com decodificadores H.264:

• PRECISA ser compatível com o perfil principal de nível 3.1 e o 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.
• 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.
• Além disso, os dispositivos Android Television,
  • PRECISA ser compatível com High Profile Level 4.2 e perfil de decodificação de 1080p60 de alta definição 1080p60.
  • PRECISA ser capaz de decodificar vídeos com os dois perfis HD, conforme indicado na tabela a seguir e codificado com o perfil de referência, o perfil principal ou o nível alto 4.2.

	SD (baixa qualidade)	SD (alta qualidade)	HD de 720p 1	HD de 1080p 1
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 2 )
Taxa de bits do vídeo	800 Kbps	2 Mbps	8 Mbps	20 Mbps

1 OBRIGATÓRIO para quando a altura relatada pelo método Display.getsupportedModes() for igual ou maior que a resolução do vídeo.

2 OBRIGATÓRIO para implementações de dispositivos Android Television.

5.3.5. H.265 (HEVC)

Implementações de dispositivos Android, quando compatíveis com o codec H.265, conforme descrito na seção 5.1.3:

• PRECISA ser compatível com o perfil principal de nível 3 e perfis de decodificação de vídeo em SD, conforme indicado na tabela a seguir.
• DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.
• PRECISA oferecer suporte aos perfis de decodificação de HD, conforme indicado na tabela a seguir, se houver um decodificador de hardware.
• Além disso, os dispositivos Android Television:
• PRECISA ser compatível com o perfil de decodificação de 720p em HD.
• MUITO RECOMENDADO para oferecer suporte ao perfil de decodificação de 1080p em HD. Se o perfil de decodificação de 1080p HD for compatível, ele PRECISA ser compatível com o nível principal do perfil principal de nível 4.1.
• DEVE oferecer suporte ao perfil de decodificação UHD. Se o perfil de decodificação UHD for suportado, o codec DEVE oferecer suporte ao perfil de nível principal Main10 Nível 5.

	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 fps (60 fps 1 )	60 qps
Taxa de bits do vídeo	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 OBRIGATÓRIO para implementações de dispositivos Android Television com decodificação de hardware H.265.

5.3.6. VP8

Implementações de dispositivos Android compatíveis com o codec VP8, conforme descrito na seção 5.1.3:

• PRECISA ser compatível com os perfis de decodificação de SD na tabela a seguir.
• DEVE oferecer suporte aos perfis de decodificação de HD na tabela a seguir.
• Os dispositivos Android Television PRECISAM ser compatíveis com o perfil de decodificação de 1080p60 em HD.

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

1 OBRIGATÓRIO para quando a altura relatada pelo método Display.getsupportedModes() for igual ou maior que a resolução do vídeo.

2 OBRIGATÓRIO para implementações de dispositivos Android Television.

5.3.7. VP9

Implementações de dispositivos Android compatíveis com o codec VP9, conforme descrito na seção 5.1.3:

• PRECISA ser compatível com os perfis de decodificação de vídeo em SD, conforme indicado na tabela a seguir.
• DEVE oferecer suporte aos perfis de decodificação de HD conforme indicado na tabela a seguir.
• PRECISA oferecer suporte aos perfis de decodificação de HD, conforme indicado na tabela a seguir, se houver um decodificador de hardware.

• Além disso, os dispositivos Android Television:

  • PRECISA ser compatível com o perfil de decodificação de 720p em HD.
  • MUITO RECOMENDADO para oferecer suporte ao perfil de decodificação de 1080p em HD.
  • DEVE oferecer suporte ao perfil de decodificação UHD. Se o perfil de decodificação de vídeo UHD for compatível, ele PRECISA ser compatível com a profundidade de cores de 8 bits e PRECISA ser compatível com VP9 Profile 2 (10 bits).

	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 1 )	60 qps
Taxa de bits do vídeo	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 OBRIGATÓRIO para implementações de dispositivos Android Television com decodificação de hardware VP9.

5,4. Gravação em áudio

Embora alguns dos requisitos descritos nesta seção sejam declarados como DEVEM desde o Android 4.3, a definição de compatibilidade para uma versão futura está planejada para alterá-los para OBRIGATÓRIO. Dispositivos Android novos e existentes são VALMENTE RECOMENDADOS para atender a esses requisitos definidos como DEVEEM. Caso contrário, eles não serão compatíveis com o Android quando forem atualizados para a versão futura.

5.4.1. Captura de áudio bruto

As implementações de dispositivos que declaram android.hardware.microphone PRECISAM permitir a captura de conteúdo de áudio bruto com as seguintes características:

• Formato : PCM linear de 16 bits
• Taxas de amostragem : 8000, 11025, 16000, 44100
• Canais : mono

A captura das taxas de amostragem acima PRECISA ser feita sem aumento de amostragem, e qualquer redução de amostragem PRECISA incluir um filtro anti-aliasing adequado.

As implementações de dispositivos que declaram android.hardware.microphone DEVEM permitir a captura de conteúdo de áudio bruto com as seguintes características:

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

Se a captura para as taxas de amostragem acima for suportada, ela PRECISA ser feita sem aumento de amostragem em qualquer proporção maior que 16000:22050 ou 44100:48000. Qualquer aumento ou redução de amostragem PRECISA incluir um filtro anti-aliasing adequado.

5.4.2. Captura para reconhecimento de voz

A fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION PRECISA oferecer suporte à captura em uma das taxas de amostragem, 44100 e 48000.

Além das especificações de gravação acima, quando um app começar a gravar um stream de áudio usando a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

• O dispositivo DEVE exibir características de amplitude versus frequência aproximadamente planas: especificamente, ±3 dB, de 100 Hz a 4.000 Hz.
• A sensibilidade à entrada de áudio DEVE ser 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.
• Os níveis de amplitude do PCM DEVEM rastrear linearmente as mudanças de SPL de entrada em pelo menos uma faixa de 30 dB, de -18 dB a +12 dB re 90 dB SPL no microfone.
• A distorção harmônica total DEVE ser inferior a 1% para 1 kHz em um nível de entrada de SPL de 90 dB no microfone.
• O processamento de redução de ruído, se presente, PRECISA ser desativado.
• O controle automático de ganho, se presente, PRECISA ser desativado.

Se a plataforma for compatível com tecnologias de supressão de ruído ajustadas para reconhecimento de fala, o efeito PRECISA ser controlável pela API android.media.audiofx.NoiseSuppressor. Além disso, o campo UUID do descritor de efeito do supressor de ruído PRECISA identificar de forma exclusiva cada implementação da tecnologia de supressão de ruído.

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. Os dispositivos que declaram android.hardware.audio.output PRECISAM 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 possa capturar uma combinação de todos os streams de áudio, exceto:

• TRANSMISSÕES AO VIVO
• ALARM_STREAM
• NOTIFICAÇÃO DE TRANSMISSÕES

5,5. Reprodução de áudio

As implementações de dispositivos que declaram android.hardware.audio.output PRECISAM estar em conformidade com os requisitos desta seção.

5.5.1. Reprodução de áudio bruto

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

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

O dispositivo 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. Implementações de dispositivo que declaram o recurso android.hardware.audio.output:

• É NECESSÁRIO oferecer suporte às implementações EF_TYPE_EQUALIZER e EF_TYPE_LOUDNESS_ENHANCER controláveis pelas subclasses AudioEffect Equalizer, LoudnessEnhancer.
• É NECESSÁRIO oferecer suporte à implementação da API do visualizador, controlável pela classe Visualizer.
• DEVE oferecer suporte às implementações EF_TYPE_BASS_BOOST, EF_TYPE_ENV_REVERB, EF_TYPE_PRESET_REVERB e EF_TYPE_VIRTUALIZER controláveis pelas subclasses AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.

5.5.3. Volume de saída de áudio

As implementações de dispositivos Android Television PRECISAM 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 compactada, em que nenhuma decodificação de áudio é feita no dispositivo.

As implementações de dispositivos Android Automotive DEVEM permitir o ajuste do volume de áudio separadamente em cada stream de áudio usando o tipo ou o uso do conteúdo, conforme definido pelos AudioAttributes, e o uso de áudio do carro, conforme definido publicamente em android.car.CarAudioManager .

5,6. Latência de áudio

A latência de áudio é o atraso 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 do dispositivo 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 na 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.

As implementações de dispositivos que declaram android.hardware.audio.output são RECOMENDADAS ALTAMENTE para atender ou exceder estes requisitos de saída de áudio:

• latência de saída a frio de 100 milissegundos ou menos
• latência de saída contínua de 45 milissegundos ou menos
• minimizar a instabilidade na saída a frio

Se uma implementação de dispositivo atender aos requisitos desta seção 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 fria em pelo menos um dispositivo de saída de áudio compatível, é MUITO RECOMENDADO informar a compatibilidade com áudio de baixa latência informando o recurso android.hardware.audio.low_hyperparameter pela classe android.content.pm.PackageManager. Por outro lado, se a implementação do dispositivo não atender a esses requisitos, ela NÃO PODERÁ informar suporte para áudio de baixa latência.

Implementações de dispositivos que incluem android.hardware.microphone são RECOMENDADAS para atender a estes requisitos de entrada de áudio:

• latência de entrada a frio de 100 milissegundos ou menos
• latência de entrada contínua de 30 milissegundos ou menos
• latência contínua de ida e volta de 50 milissegundos ou menos
• minimizar a instabilidade na entrada a frio

5,7. Protocolos de rede

Os 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. Especificamente, os dispositivos PRECISAM oferecer suporte aos seguintes protocolos de rede de mídia:

• Streaming progressivo HTTP(S)
  Todos os codecs e formatos de contêiner necessários na seção 5.1 PRECISAM ser suportados por HTTP(S)

• Protocolo de rascunho de HTTP Live Streaming, versão 7
  Os seguintes formatos de segmento de mídia PRECISAM ser compatíveis:

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)

  O seguinte perfil de áudio vídeo RTP e os codecs relacionados PRECISAM ser compatíveis. Para conferir as exceções, consulte as notas de rodapé da tabela na seção 5.1.

Nome do perfil	Referências	Compatibilidade necessária com o codec
H264 AVC	RFC 6184 (link em inglês)	Consulte a seção 5.1.3 para ver detalhes sobre o H264 AVC
MP4A-LATM	RFC 6416 (em inglês)	Consulte a seção 5.1.1 para saber detalhes sobre o AAC e as variantes dele.
H263-1998	RFC 3551 (link em inglês) RFC 4629 (link em inglês) RFC 2190	Consulte a seção 5.1.3 para 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

As implementações de dispositivos que oferecem suporte à saída de vídeo segura e podem oferecer suporte a superfícies seguras PRECISAM declarar compatibilidade com Display.FLAG_SECURE. As implementações de dispositivos que declararem suporte a Display.FLAG_SECURE, se oferecerem suporte a um protocolo de display sem fio, PRECISAM proteger o link com um mecanismo com criptografia forte, como HDCP 2.x ou mais recente, para telas sem fio Miracast. Da mesma forma, se elas oferecerem suporte a uma tela externa com fio, as implementações dos dispositivos PRECISAM oferecer suporte à HDCP 1.2 ou mais recente. As implementações de dispositivos Android Television PRECISAM oferecer suporte a HDCP 2.2 para dispositivos com resolução 4K e HDCP 1.4 ou mais recente para resoluções mais baixas. A implementação upstream de código aberto do Android inclui suporte para telas sem fio (Miracast) e com fio (HDMI) que atendem a esse requisito.

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

Se a implementação de um dispositivo oferecer suporte ao transporte de software MIDI entre apps (dispositivos MIDI virtuais) e a MIDI a todos os seguintes transportes de hardware compatíveis com MIDI para os quais oferece conectividade não MIDI genérica, é FORTEMENTE RECOMENDADO informar a compatibilidade com o recurso android.software.midi pela classe android.content.pm.PackageManager.

Os transportes de hardware compatíveis com MIDI são:

• Modo host USB (seção 7.7 USB)
• Modo de periférico USB (seção 7.7 USB)
• MIDI sobre Bluetooth LE atuando na função central (seção 7.4.3 Bluetooth)

Por outro lado, se a implementação do dispositivo fornecer conectividade não MIDI genérica em um determinado transporte de hardware compatível com MIDI listado acima, mas não oferecer suporte a MIDI nesse transporte de hardware, NÃO será possível informar a compatibilidade com o recurso android.software.midi.

5,10 Áudio profissional

Se uma implementação de dispositivo atender a todos os requisitos a seguir, é FORTEMENTE RECOMENDADO informar o suporte ao recurso android.hardware.audio.pro pela classe android.content.pm.PackageManager.

• A implementação do dispositivo PRECISA relatar a compatibilidade com o recurso android.hardware.audio.low_delay.
• A latência de ida e volta contínua do á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.
• Se o dispositivo tiver uma entrada para fone de ouvido de 3, 5 mm com quatro condutores, a latência de ida e volta contínua do áudio PRECISA ser de 20 milissegundos ou menos no caminho da entrada de áudio e 10 milissegundos ou menos no caminho da entrada de áudio.
• A implementação do dispositivo PRECISA incluir portas USB compatíveis com o modo de host USB e o modo de periférico USB.
• O modo de host USB PRECISA implementar a classe de áudio USB.
• Se o dispositivo incluir uma porta HDMI, a implementação do dispositivo PRECISA oferecer suporte à saída em estéreo e oito canais com profundidade de 20 ou 24 bits e 192 kHz sem perda ou reamostragem de profundidade de bits.
• A implementação do dispositivo PRECISA relatar a compatibilidade com o recurso android.software.midi.
• Se o dispositivo incluir uma entrada para fone de ouvido de 3,5 mm com quatro condutores, a implementação do dispositivo será RECOMENDADA para obedecer à seção Especificações para dispositivos móveis (fones de ouvido) da Especificação de fones de ouvido com fio (v1.1).

Latências e requisitos de áudio USB PRECISAM ser atendidos usando a API de fila de buffer de PCM do OpenSL ES.

Além disso, uma implementação de dispositivo que informe suporte para esse recurso DEVE:

• Proporcione um nível sustentável de desempenho da CPU enquanto o áudio está ativo.
• Minimizar a imprecisão e o desvio do relógio de áudio em relação ao horário padrão.
• Minimize o deslocamento do relógio de áudio em relação ao CLOCK_MONOTONIC da CPU quando ambos estiverem ativos.
• Minimizar a latência de áudio em transdutores no dispositivo.
• Minimize a latência de áudio em áudio digital USB.
• Documente as medições de latência de áudio em todos os caminhos.
• Minimize 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.
• Não fornece underruns (saída) ou overruns (entrada) de áudio em condições normais de uso na latência relatada.
• não forneça diferença de latência entre canais.
• Minimizar a latência média de MIDI em todos os transportes.
• Minimizar a variabilidade de latência MIDI sob carga (instabilidade) em todos os transportes.
• Forneça carimbos de data/hora MIDI precisos em todos os transportes.
• Minimize o ruído do sinal de áudio nos transdutores do dispositivo, incluindo o período imediatamente após a inicialização a frio.
• Não há diferença de relógio de áudio entre os lados de entrada e saída dos endpoints correspondentes, quando ambos estão ativos. Exemplos de 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.
• Processe os callbacks de conclusão do buffer de áudio para os lados de entrada e saída dos endpoints correspondentes na mesma linha de execução quando ambos estiverem ativos e insira 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.
• Minimize a diferença de fase entre o armazenamento em buffer de áudio da HAL para os lados de entrada e saída dos endpoints correspondentes.
• Minimize a latência de toque.
• Minimize a variabilidade de latência de toque sob carga (instabilidade).

5,11. Capturar para não processados

A partir do Android 7.0, uma nova origem de gravação foi adicionada. Ele pode ser acessado usando a fonte de áudio android.media.MediaRecorder.AudioSource.UNPROCESSED. No OpenSL ES, ele pode ser acessado com a predefinição de gravação SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Um dispositivo PRECISA atender a todos os requisitos a seguir para informar a compatibilidade com a fonte de áudio não processada usando a propriedade android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED:

• O dispositivo PRECISA exibir características de amplitude em relação à frequência aproximadas planas no intervalo de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz.

• O dispositivo PRECISA exibir níveis de amplitude no intervalo de baixa frequência, especificamente de ±20 dB de 5 Hz a 100 Hz em comparação com o intervalo de frequência média.

• O dispositivo PRECISA exibir níveis de amplitude no intervalo de alta frequência, especificamente de ±30 dB de 7.000 Hz a 22 KHz em comparação com o intervalo de frequência média.

• A sensibilidade à entrada de áudio PRECISA ser definida para que uma fonte de tom senoidal de 1.000 Hz, reproduzida a 94 dB, com 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 amostras de ponto flutuante/precisão dupla).

• SNR > 60 dB (diferença entre 94 dB SPL e SPL equivalente de ruído próprio, ponderado em A).

• A distorção harmônica total PRECISA ser menor que 1% para 1 kHZ em um nível de entrada de SPL de 90 dB no microfone.

• O único processamento de sinal permitido no caminho é um multiplicador para levar o nível até o intervalo desejado. Esse multiplicador de nível NÃO PODE introduzir atraso ou latência no caminho do sinal.

• Nenhum outro processamento de sinal é permitido no caminho, como Controle automático de ganho, Filtro de passagem alta ou Cancelamento de eco. Se, por qualquer motivo, algum processamento de sinal estiver presente na arquitetura, ele PRECISA ser desativado e introduzir efetivamente zero atraso ou latência extra 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.

É MUITO RECOMENDADO que um dispositivo atenda ao maior número possível de requisitos de caminho de sinal para a origem de gravação não processada. No entanto, um dispositivo precisa atender a todos esses requisitos, listados acima, caso seja compatível com a fonte de áudio não processada.

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

6.1. Ferramentas para desenvolvedores

As implementações de dispositivos PRECISAM ser compatíveis com as Ferramentas para desenvolvedores do Android fornecidas no SDK do Android. Os dispositivos Android PRECISAM ser compatíveis com:

• Android Debug Bridge (adb)
  • As implementações de dispositivos PRECISAM ser compatíveis com todas as funções do adb, conforme documentado no SDK do Android, incluindo o dumpsys.
  • O daemon do adb do lado do dispositivo PRECISA estar inativo por padrão e PRECISA haver um mecanismo acessível ao usuário para ativar o Android Debug Bridge. Se uma implementação de dispositivo omitir o modo de periférico USB, ela PRECISA implementar o Android Debug Bridge na rede local (como Ethernet ou 802.11).
  • O Android oferece suporte ao adb seguro. O adb seguro permite o uso do adb em hosts autenticados conhecidos. As implementações de dispositivos PRECISAM oferecer suporte ao adb seguro.
• Serviço de monitoramento de depuração Dalvik (ddms)
  • As implementações de dispositivos PRECISAM 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.
• As implementações de dispositivos Monkey PRECISAM incluir o framework Monkey e disponibilizá-lo para uso dos aplicativos.
• SysTrace (em inglês)
  • As implementações de dispositivos PRECISAM 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.
  • A maioria dos sistemas baseados em Linux e sistemas Apple Macintosh reconhece dispositivos Android usando as ferramentas padrão do SDK do Android, sem suporte adicional. No entanto, os sistemas Microsoft Windows normalmente exigem um driver para novos dispositivos Android. Por exemplo, novos IDs de fornecedor e, às vezes, novos IDs de dispositivos exigem drivers USB personalizados para sistemas Windows.
  • Se a implementação de um dispositivo não for reconhecida pela ferramenta adb, conforme fornecido no SDK padrão do Android, os implementadores de dispositivos PRECISAM fornecer drivers do Windows que permitam que os desenvolvedores se conectem ao dispositivo usando o protocolo adb. Esses drivers PRECISAM ser fornecidos para o Windows XP, Windows Vista, Windows 7, Windows 8 e Windows 10 nas versões de 32 e 64 bits.

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 respeitar a intent android.settings.APPLICATION_DEVELOPMENT_CONFIG para mostrar configurações relacionadas ao desenvolvimento do aplicativo. Por padrão, a implementação upstream do Android oculta o menu "Opções do desenvolvedor" e permite que os usuários abram as "Opções do desenvolvedor" depois de pressionarem sete (7) vezes em Configurações > Sobre o dispositivo > Item de menu Número da versão. As implementações de dispositivos PRECISAM fornecer uma experiência consistente para as Opções do desenvolvedor. Especificamente, as implementações de dispositivos PRECISAM ocultar as Opções do desenvolvedor por padrão e fornecer um mecanismo para ativar as Opções do desenvolvedor consistente com a implementação upstream do Android.

7. Compatibilidade de hardware

Se um dispositivo incluir um componente de hardware 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. 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:

• As definições de classe completas (conforme documentado pelo SDK) para as APIs do componente PRECISAM ser apresentadas.
• Os comportamentos da API PRECISAM ser implementados como ambiente autônomo de maneira razoável.
• Os métodos da API PRECISAM retornar valores nulos quando permitido pela documentação do SDK.
• Os métodos da API PRECISAM retornar implementações de ambiente autônomo de classes em que valores nulos não são permitidos pela documentação do SDK.
• Os métodos da API NÃO PODEM gerar exceções não documentadas pela documentação do SDK.

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.

As implementações de dispositivos PRECISAM relatar, de maneira consistente, informações precisas de configuração de hardware pelos métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para a mesma impressão digital do build.

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) . 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 tela e permite que os aplicativos consultem o tamanho da tela do dispositivo (também conhecido como "layout da tela") usando android.content.res.Configuration.screenLayout com SCREENLAYOUT_SIZE_MASK. As implementações de dispositivos PRECISAM informar o tamanho de tela correto, conforme definido na documentação do SDK do Android e determinado pela plataforma Android upstream. Especificamente, as implementações de dispositivos PRECISAM informar o tamanho correto da tela, de acordo com as seguintes dimensões de tela em pixels de densidade independente (dp, na sigla em inglês).

• Os dispositivos PRECISAM ter telas de pelo menos 426 dp x 320 dp ("pequena"), a menos que sejam dispositivos Android Watch.
• Os dispositivos que informam tamanho de tela "normal" PRECISAM ter tamanhos de tela de pelo menos 480 dp x 320 dp.
• Os dispositivos que informam o tamanho de tela "grande" PRECISAM ter um tamanho de tela de pelo menos 640 dp x 480 dp.
• Os dispositivos que informam o tamanho de tela "xlarge" PRECISAM ter um tamanho de tela de pelo menos 960 dp x 720 dp.

Além disso:

• Os dispositivos Android Watch PRECISAM ter uma tela com o tamanho diagonal físico de 1,1 a 2,5 polegadas.
• Os dispositivos Android Automotive PRECISAM ter uma tela com o tamanho físico da diagonal maior ou igual a 6 polegadas.
• Os dispositivos Android Automotive PRECISAM ter um tamanho de tela de pelo menos 750 dp x 480 dp.
• Outros tipos de implementações de dispositivos Android, com uma tela fisicamente integrada, PRECISAM ter uma tela com pelo menos 5,5 centímetros de tamanho diagonal.

Os dispositivos NÃO PODEM mudar o tamanho da tela informado a qualquer momento.

Os aplicativos podem indicar com quais tamanhos de tela eles oferecem suporte por meio de <supports-screens> no arquivo AndroidManifest.xml. As implementações de dispositivos PRECISAM respeitar corretamente as metas afirmou o suporte a telas pequenas, normais, grandes e extragrandes, 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 em que os apps de terceiros são renderizados e que pode ser derivada dos valores informados por DisplayMetrics PRECISA atender aos seguintes requisitos:

• Se uiMode estiver configurado como UI_MODE_TYPE_WATCH, o valor de proporção PODE ser definido como 1.0 (1:1).
• Se o app de terceiros indicar que é redimensionável usando o atributo android:resizeableActivity, não haverá restrições para o valor da proporção.
• Em todos os outros casos, a proporção PRECISA ser um valor entre 1,3333 (4:3) e 1,86 (aproximadamente 16:9), a menos que o app tenha indicado explicitamente que oferece suporte a uma proporção de tela maior usando o valor de metadados maxAspectRatio.

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. As implementações de dispositivos PRECISAM informar apenas uma das densidades de estrutura lógica do Android a seguir usando as APIs android.util.DisplayMetrics. Além disso, PRECISAM executar aplicativos nessa densidade padrão e NÃO PODEM mudar o valor a qualquer momento para a exibição padrão.

• 120 dpi (ldpi)
• 160 dpi (mdpi)
• 213 dpi (tvdpi)
• 240 dpi (hdpi)
• 280 dpi (280dpi)
• 320 dpi (xhdpi)
• 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.

As implementações de dispositivos são MUITO RECOMENDADAS para oferecer aos usuários uma configuração para mudar o tamanho da tela. Se houver uma implementação para mudar o tamanho da tela do dispositivo, ela PRECISA estar alinhada à implementação do AOSP, conforme indicado abaixo:

• O tamanho de exibição NÃO PODE ser 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.
• O tamanho de exibição NÃO PODE ser dimensionado com menos de 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

As implementações de dispositivos PRECISAM informar os valores corretos de todas as métricas de exibição definidas em android.util.DisplayMetrics e PRECISAM informar os mesmos valores, independentemente de a tela incorporada ou externa ser usada como a exibição padrão.

7.1.3. Orientação da tela

Os dispositivos PRECISAM informar quais orientações de tela são compatíveis (android.hardware.screen.portrait e/ou android.hardware.screen.landscape) e pelo menos uma orientação compatível. 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.

Os dispositivos que informam as duas orientações de tela PRECISAM oferecer suporte à orientação dinâmica dos aplicativos para a orientação retrato ou paisagem. Ou seja, o dispositivo precisa respeitar a solicitação do aplicativo para uma orientação de tela específica. As implementações de dispositivos PODEM selecionar a orientação retrato ou paisagem como padrão.

Os dispositivos PRECISAM informar o valor correto da orientação atual sempre que consultados usando android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.

Os dispositivos NÃO PODEM mudar o tamanho ou a densidade da tela informada ao mudar a orientação.

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

As implementações de dispositivos PRECISAM ser compatíveis com o OpenGL ES 1.0 e 2.0, conforme incorporado e detalhado nas documentações do SDK do Android. As implementações de dispositivos DEVEM ser compatíveis com OpenGL ES 3.0, 3.1 ou 3.2 em dispositivos compatíveis. As implementações de dispositivos também PRECISAM ser compatíveis com o Android RenderScript, conforme detalhado na documentação do SDK do Android.

As implementações de dispositivos também PRECISAM identificar-se corretamente como compatíveis com OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1 ou OpenGL 3.2. Isto é:

• As APIs gerenciadas (por exemplo, por meio do método GLES10.getString()) PRECISAM informar a compatibilidade com OpenGL ES 1.0 e OpenGL ES 2.0.
• As APIs C/C++ OpenGL nativas (APIs disponíveis para apps via libGLES_v1CM.so, libGLES_v2.so ou libEGL.so) PRECISAM informar a compatibilidade com OpenGL ES 1.0 e 2.0.
• As implementações de dispositivos que declaram suporte ao OpenGL ES 3.0, 3.1 ou 3.2 PRECISAM oferecer suporte às APIs gerenciadas correspondentes e incluir suporte a APIs C/C++ nativas. Em implementações de dispositivos que declaram suporte ao OpenGL ES 3.0, 3.1 ou 3.2, o libGLESv2.so PRECISA exportar os símbolos de função correspondentes, além dos símbolos de função do OpenGL ES 2.0.

O Android oferece um pacote de extensão do OpenGL ES com interfaces Java e suporte nativo para funcionalidades gráficas avançadas, como tesselação e o formato de compactação de textura ASTC. As implementações de dispositivos Android PRECISAM ser compatíveis com o pacote de extensão se o dispositivo oferecer suporte ao OpenGL ES 3.2. Caso contrário, TÊM suporte para ele. Se o pacote de extensão tiver suporte integral, o dispositivo PRECISA identificar o suporte pela flag de recurso android.hardware.opengles.aep.

Além disso, as implementações de dispositivos PODEM implementar qualquer extensão OpenGL ES desejada. No entanto, as implementações de dispositivos PRECISAM informar por meio das APIs nativas e gerenciadas do OpenGL ES todas as strings de extensão compatíveis e, por outro lado, NÃO PODEM informar strings de extensão incompatíveis.

O Android inclui suporte para que os aplicativos especifiquem que exigem formatos de compactação de textura OpenGL específicos. Esses formatos normalmente são específicos do fornecedor. O Android não exige implementações de dispositivos para implementar nenhum formato de compactação de textura específico. No entanto, eles DEVEM informar com precisão todos os formatos de compactação de textura compatíveis, por meio do método getString() na API OpenGL.

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.

As implementações de dispositivos PRECISAM 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.

Além disso, as implementações de dispositivos PRECISAM exibir 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. As implementações de dispositivos PRECISAM ser compatíveis com a API TextureView e PRECISAM exibir um comportamento consistente com a implementação upstream do Android.

O Android inclui suporte ao EGL_ANDROID_RECORDABLE, um atributo EGLConfig que indica se o EGLConfig oferece suporte à renderização para uma ANativeWindow que grava imagens em um vídeo. As implementações de dispositivos PRECISAM oferecer suporte à extensão EGL_ANDROID_RECORDABLE.

7.1.5. Modo de compatibilidade de aplicativo legado

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

• O Android Automotive não oferece suporte ao modo de compatibilidade legado.
• Todas as outras implementações de dispositivos PRECISAM incluir suporte ao modo de compatibilidade do aplicativo legado, conforme implementado pelo código-fonte aberto 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.

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.

• Os dispositivos PRECISAM oferecer suporte a telas capazes de renderizar gráficos coloridos de 16 bits e DEVEM oferecer suporte a telas com gráficos coloridos de 24 bits.
• Os dispositivos PRECISAM ser compatíveis com telas capazes de renderizar animações.
• A tecnologia de exibição usada PRECISA ter uma proporção de pixels (PAR) entre 0,9 e 1,15. Ou seja, a proporção em pixels PRECISA ser próxima do quadrado (1,0) com uma tolerância de 10 a 15%.

7.1.7. Telas secundárias

O Android inclui suporte a tela secundária para ativar recursos de compartilhamento de mídia e APIs de desenvolvedor para acessar telas externas. Se um dispositivo for compatível com uma tela externa por meio de uma conexão com fio, sem fio ou de uma tela adicional incorporada, a implementação do dispositivo PRECISA implementar a API do gerenciador de exibição, conforme descrito na documentação do SDK do Android.

7.2. Dispositivos de entrada

Os dispositivos PRECISAM ser compatíveis com touchscreen ou atender aos requisitos listados em 7.2.2 para navegação sem toque.

7.2.1. Teclado

Implementações de dispositivos:

• PRECISA incluir suporte para o Input Management Framework (que permite que desenvolvedores terceirizados criem Editores de método de entrada, por exemplo, teclado de software), conforme detalhado em http://developer.android.com.
• PRECISA fornecer pelo menos uma implementação de teclado de software (independentemente da presença de um teclado físico), exceto para dispositivos Android Watch em que o tamanho da tela torna menos razoável ter um teclado virtual.
• PODE incluir outras implementações de teclado de software.
• PODE incluir um teclado físico.
• 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).

7.2.2. Navegação sem toque

Implementações de dispositivos:

• PODE omitir uma opção de navegação sem toque (trackball, botão direcional ou roda) se a implementação do dispositivo não for um dispositivo Android Television.
• PRECISA informar o valor correto para android.content.res.Configuration.navigation.
• 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 Back (mapeadas para os eventos principais KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK, respectivamente) são essenciais para o paradigma de navegação do Android. Portanto:

• As implementações de dispositivos portáteis Android PRECISAM fornecer as funções Home, Recents e Back.
• As implementações de dispositivos Android Television PRECISAM fornecer as funções Home e Back.
• As implementações de dispositivos Android Watch PRECISAM ter a função Home disponível para o usuário e a função "Voltar", exceto quando ela está em UI_MODE_TYPE_WATCH .
• As implementações de dispositivos Android Watch, e nenhum outro tipo de dispositivo Android, PODEM consumir o evento de tocar e manter pressionado no evento de tecla KEYCODE_BACK e omitir que ele seja enviado ao app em primeiro plano.
• As implementações do Android Automotive PRECISAM fornecer a função Home e PODEM fornecer as funções Back e Recent.
• Todos os outros tipos de implementações de dispositivos PRECISAM fornecer as funções Home e Back.

Essas funções PODEM ser implementadas por meio de botões físicos dedicados (como botões de toque mecânicos ou capacitivos) ou podem ser implementadas usando teclas de software dedicadas em uma parte distinta da tela, gestos, painel de toque etc. O Android suporta as duas implementações. Todas essas funções PRECISAM ser acessíveis com uma única ação (por exemplo, toque, clique duplo ou gesto) quando visíveis.

A função Recentes, se fornecida, PRECISA ter um botão ou ícone visível, a menos que esteja oculta com outras funções de navegação no modo de tela cheia. Isso não se aplica a dispositivos que fizeram upgrade de versões anteriores do Android que tenham botões físicos para navegação e nenhuma tecla recente.

As funções Home e Back, se fornecidas, PRECISAM ter um botão ou ícone visível, a menos que estejam ocultas com outras funções de navegação no modo de tela cheia ou quando uiMode UI_MODE_TYPE_MASK está definido como UI_MODE_TYPE_WATCH.

A função Menu foi descontinuada e substituída pela barra de ações desde o Android 4.0. Portanto, as novas implementações de dispositivo enviadas com o Android 7.0 e versões posteriores NÃO PODEM implementar um botão físico dedicado para a função de menu. Implementações mais antigas de dispositivos NÃO DEVEM implementar um botão físico dedicado para a função Menu, mas se o botão de menu físico for implementado e o dispositivo estiver executando aplicativos com targetSdkVersion > 10, a implementação do dispositivo:

• PRECISA mostrar o botão flutuante na barra de ações quando ele estiver visível e quando a ação resultante não estiver vazia. Para uma implementação de dispositivo lançada antes do Android 4.4, mas atualizando para o Android 7.0, esta opção é RECOMENDADA.
• NÃO É POSSÍVEL modificar a posição do pop-up flutuante de ação exibido ao selecionar o botão flutuante na barra de ações.
• Poderá renderizar o pop-up flutuante de ação em uma posição modificada na tela quando ele for exibido, selecionando o botão físico de menu.

Para compatibilidade com versões anteriores, as implementações de dispositivos PRECISAM disponibilizar a função Menu para os aplicativos quando a targetSdkVersion é menor que 10, seja por um botão físico, uma tecla de software ou gestos. Essa função de menu deve ser apresentada, a menos que esteja oculta com outras funções de navegação.

As implementações de dispositivos Android compatíveis com a ação de assistência e/ou VoiceInteractionService PRECISAM iniciar um app de assistência com uma única interação (por exemplo, toque, clique duplo ou gesto) quando outras teclas de navegação estiverem visíveis. É FORTEMENTE RECOMENDADO usar a ação de tocar e manter pressionado no início como essa interação. A interação designada PRECISA iniciar o app assistivo selecionado pelo usuário. Em outras palavras, o app que implementa um VoiceInteractionService ou uma atividade que processa a intent ACTION_ASSIST.

As implementações de dispositivos PODEM usar uma parte distinta da tela para exibir as teclas de navegação, mas, nesse caso, PRECISAM atender a estes requisitos:

• As teclas de navegação para implementação no dispositivo 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.
• As implementações de dispositivos PRECISAM disponibilizar uma parte da tela para aplicativos que atendam aos requisitos definidos na seção 7.1.1.
• As implementações de dispositivos PRECISAM mostrar as teclas de navegação quando os aplicativos não especificam um modo de interface do sistema ou especificam SYSTEM_UI_FLAG_VISIBLE.
• As implementações de dispositivos PRECISAM apresentar as teclas de navegação em um modo discreto (por exemplo, esmaecido) quando os aplicativos especificam SYSTEM_UI_FLAG_LOW_PROFILE.
• As implementações de dispositivos PRECISAM ocultar as teclas de navegação quando os aplicativos especificam SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Entrada por tela touch

As implementações de dispositivos DEVEM ter um sistema de entrada de ponteiro de algum tipo (semelhante ao mouse ou ao toque). No entanto, se a implementação de um dispositivo não oferecer suporte a um sistema de entrada de ponteiro, ela NÃO PODE relatar a constante de recurso android.hardware.touchscreen ou android.hardware.faketouch. Implementações de dispositivos que incluem um sistema de entrada de ponteiro:

• Se o sistema de entrada do dispositivo oferecer suporte a vários ponteiros, DEVE oferecer suporte a ponteiros totalmente rastreados de forma independente.
• É NECESSÁRIO informar o valor de android.content.res.Configuration.touchscreen correspondente ao tipo de tela touchscreen específica do dispositivo.

O Android é compatível com várias 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. Por outro lado, uma interface de toque simulada fornece um sistema de entrada do usuário que se aproxima de um subconjunto de recursos de 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. As implementações de dispositivos que declaram o recurso de toque falso PRECISAM atender aos requisitos da seção 7.2.5.

As implementações de dispositivos PRECISAM informar o recurso correto correspondente ao tipo de entrada usado. As implementações de dispositivos que incluem uma tela touchscreen (de toque único ou superior) PRECISAM informar a constante android.hardware.touchscreen da plataforma. As implementações de dispositivos que informam a constante de recurso da plataforma "android.hardware.touchscreen" também precisam informar a constante "android.hardware.faketouch" do recurso da plataforma. Implementações de dispositivos que não incluem tela touchscreen (e dependem apenas de um dispositivo ponteiro) NÃO PODEM informar nenhum recurso de touchscreen e PRECISAM informar apenas android.hardware.faketouch se atenderem aos requisitos de toque falso na seção 7.2.5.

7.2.5. Entrada de toque falsa

Implementações de dispositivo que declaram suporte a android.hardware.faketouch:

• É NECESSÁRIO informar as posições absolutas X e Y da tela da localização do ponteiro e mostrar um ponteiro visual na tela.
• 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.
• É NECESSÁRIO 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.
• PRECISA oferecer suporte ao recurso de ponteiro para baixo, para cima, para baixo e para cima no mesmo lugar de um objeto na tela dentro de um limite de tempo, o que permite aos usuários emular toques duplos em um objeto na tela.
• PRECISA ser compatível com o ponteiro para baixo em um ponto arbitrário da tela, com o movimento do ponteiro para qualquer outro ponto arbitrário na tela, seguido por um ponteiro para cima, o que permite que os usuários simulem uma ação de arrastar por toque.
• 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.

Os dispositivos que declaram suporte a android.hardware.faketouch.multitouch.distinct PRECISAM atender aos requisitos de faketouch acima e oferecer suporte ao rastreamento distinto de duas ou mais entradas de ponteiro independentes.

7.2.6. Suporte a controles de jogos

As implementações de dispositivos Android Television PRECISAM oferecer suporte a mapeamentos de botões para controles de jogos, conforme listado abaixo. A implementação upstream do Android inclui a implementação para controles de jogos que atendem a esse requisito.

7.2.6.1. Mapeamentos de botões

As implementações de dispositivos Android Television PRECISAM oferecer suporte aos seguintes mapeamentos de teclas:

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 esquerdo 1 Botão direcional direito 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)
Clicar com o botão direito do mouse 1	0x09 0x000F	KEYCODE_Button_THUMBR (107)
Início 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 na direção oposta do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima está sendo pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e para a esquerda estão sendo pressionadas.

4 MotionEvent

Controles analó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	Eixo Z AXIS_RZ

1 MotionEvent

7.2.7. Controle remoto

As implementações de dispositivos Android Television DEVEM fornecer um controle remoto para permitir que os usuários acessem a interface da TV. O controle remoto PODE ser físico ou baseado em software e pode ser acessado de um celular ou tablet. O controle remoto PRECISA atender aos requisitos definidos abaixo.

• Acessibilidade de pesquisa . As implementações de dispositivos PRECISAM disparar KEYCODE_SEARCH quando o usuário invocar a pesquisa por voz no controle remoto físico ou baseado em software.
• Navegação . Todos os controles remotos do Android PRECISAM incluir os botões "Voltar", "Início" e "Selecionar" e suporte a eventos com botões direcional.

7,3 Sensores

O Android inclui APIs para acessar diversos tipos de sensores. Geralmente, as implementações de dispositivos podem omitir esses sensores, conforme previsto nas subseções a seguir. Se um dispositivo incluir 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. Por exemplo, implementações de dispositivos:

• PRECISA informar com precisão a presença ou ausência de sensores de acordo com a classe android.content.pm.PackageManager.
• PRECISA retornar uma lista precisa de sensores compatíveis com SensorManager.getSensorList() e métodos semelhantes.
• PRECISA se comportar de maneira razoável com todas as outras APIs de sensores (por exemplo, retornar verdadeiro ou falso conforme apropriado quando os aplicativos tentarem registrar listeners, não chamar listeners de sensores quando os sensores correspondentes não estiverem presentes etc.).
• PRECISA informar todas as medições do sensor usando os valores do Sistema Internacional de Unidades (métrica) relevante para cada tipo de sensor, conforme definido na documentação do SDK do Android.
• 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.
• É NECESSÁRIO 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 estiver ativo. Esse atraso não inclui atrasos de filtragem.
• PRECISA informar a primeira amostra do sensor dentro de 400 milissegundos + 2 * sample_time do sensor que está sendo ativado. É aceitável que essa amostra tenha uma precisão de 0.

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.) As implementações de dispositivos DEVEM implementar esses tipos de sensor, quando incluem os sensores físicos de pré-requisito, conforme descrito nos Tipos de sensor. Se a implementação de um dispositivo incluir um sensor composto, ela PRECISA fazer a implementação, conforme descrito na documentação do Android Open Source sobre sensores compostos.

Alguns sensores do Android são compatíveis com um modo de acionador "contínuo", que retorna dados de forma contínua. Para que qualquer API indicada pela documentação do SDK do Android seja um sensor contínuo, as implementações do dispositivo PRECISAM fornecer continuamente amostras de dados periódicas que DEVEM ter uma instabilidade abaixo de 3%, em que a instabilidade é definida como o desvio padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.

As implementações do dispositivo PRECISAM 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.

Por fim, quando vários sensores forem ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia informado por cada sensor.

7.3.1. Acelerômetro

As implementações de dispositivos DEVEM incluir um acelerômetro de três eixos. Dispositivos Android portáteis, implementações Android Automotive e Android Watch são MUITO RECOMENDADOS a incluir esse sensor. Se a implementação de um dispositivo incluir um acelerômetro de três eixos, ela:

• PRECISA implementar e informar o sensor TYPE_ACCELEROMETER.
• PRECISA relatar eventos com uma frequência de pelo menos 50 Hz para dispositivos Android Watch. Esses dispositivos têm uma restrição de energia mais rígida e 100 Hz para todos os outros tipos de dispositivo.
• DEVE relatar eventos de até pelo menos 200 Hz.
• PRECISA obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android. As implementações do Android Automotive PRECISAM obedecer ao sistema de coordenadas do sensor de carro do Android.
• PRECISA ser capaz de medir a queda livre até quatro vezes a gravidade (4g) ou mais em qualquer eixo.
• PRECISA ter uma resolução de pelo menos 12 bits e DEVE ter uma resolução de no mínimo 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.
• PRECISA ter um desvio padrão não superior a 0,05 m/s^, no qual o desvio padrão deve ser calculado por eixo em amostras coletadas durante um período de pelo menos 3 segundos com a taxa de amostragem mais rápida.
• DEVE implementar os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER, conforme descrito no documento do SDK do Android. Dispositivos Android novos e já existentes são STRONGLY RECOMMENDED para implementar o sensor composto TYPE_SIGNIFICANT_MOTION. Se algum desses sensores for implementado, a soma do consumo de energia PRECISA ser sempre menor que 4 mW e que cada um deles PRECISA ser menor que 2 mW e 0,5 mW quando o dispositivo estiver em uma condição dinâmica ou estática.
• Se um sensor de giroscópio estiver incluído, PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e DEVE implementar o sensor composto TYPE_GAME_ROTATION_VECTOR. É altamente RECOMENDADO implementar o sensor TYPE_GAME_ROTATION_VECTOR em dispositivos Android novos e já existentes.
• PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR se um sensor de giroscópio e um sensor de magnetômetro também estiverem incluídos.

7.3.2. Magnetômetro

As implementações de dispositivos DEVEM incluir um magnetômetro (bússola) de três eixos. Se um dispositivo incluir um magnetômetro de três eixos, ele:

• PRECISA implementar o sensor TYPE_MAGNETIC_FIELD e também DEVE implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED. É altamente RECOMENDADO que dispositivos Android novos e existentes implementem o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• PRECISA relatar eventos com até uma frequência de pelo menos 10 Hz e DEVE relatar eventos de até 50 Hz.
• PRECISA obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android.
• PRECISA ser capaz de medir entre -900 μT e +900 μT em cada eixo antes da saturação.
• PRECISA ter um valor de compensação de ferro rígido menor que 700 μT e 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).
• PRECISA ter uma resolução igual ou mais densa que 0,6 μT e DEVE ter uma resolução igual ou mais densa que 0,2 μT.
• DEVE ser compensado por temperatura.
• PRECISA oferecer suporte à calibragem on-line e à compensação da polarização rígida de ferro, além de preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• 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.
• DEVE 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 0,5 μT.
• PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR se um sensor de acelerômetro e um sensor de giroscópio também estiverem incluídos.
• PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR se um sensor de acelerômetro também for implementado. No entanto, se implementada, ela PRECISA consumir menos de 10 mW e 3 mW quando o sensor estiver registrado para o modo de lote a 10 Hz.

7.3.3. GPS

As implementações de dispositivos DEVEM incluir um receptor GPS/GNSS. Se a implementação de um dispositivo incluir um receptor GPS/GNSS e informar a capacidade aos aplicativos pela flag de recurso android.hardware.location.gps:

• É FORTEMENTE RECOMENDADO que o dispositivo continue a entregar saídas de GPS/GNSS normais para aplicativos durante uma chamada telefônica de emergência e que essa saída de local não seja bloqueada durante uma chamada telefônica de emergência.
• Ele PRECISA ser compatível com saídas de local a uma taxa de pelo menos 1 Hz quando solicitado por LocationManager#requestLocationUpdate .
• Ele 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).
  • Depois de fazer esse cálculo de localização, é FORTEMENTE RECOMENDADO que o dispositivo possa determinar sua 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 de localização, mesmo quando a solicitação subsequente for feita sem uma conexão de dados e/ou após um ciclo de energia.
• Em condições de céu aberto após determinar o local, enquanto está estacionário ou em movimento com menos de 1 metro por segundo ao quadrado de aceleração:
  • Ele PRECISA determinar a localização dentro de 20 metros e a velocidade dentro de 0, 5 metro por segundo, pelo menos 95% do tempo.
  • Ele PRECISA rastrear e informar simultaneamente por GnssStatus.Callback pelo menos oito satélites de uma constelação.
  • Ele DEVE ser capaz de rastrear simultaneamente pelo menos 24 satélites, de várias constelações (por exemplo, GPS + pelo menos um de Glonass, Beidou, Galileo).
• É NECESSÁRIO informar a geração da tecnologia GNSS pela API de teste "getGnssYearOfHardware".
• É FORTEMENTE RECOMENDADO atender e PRECISO cumprir todos os requisitos abaixo se a geração da tecnologia GNSS for informada como o ano "2016" ou mais recente.
  • É NECESSÁRIO 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.
  • É NECESSÁRIO informar as pseudodistâncias e taxas de pseudodistância 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 metros por segundo, pelo menos 95% do tempo.

Embora alguns dos requisitos de GPS acima sejam indicados como FORTEMENTE RECOMENDADOS, a definição de compatibilidade para a próxima versão principal deve alterá-los para OBRIGATÓRIO.

7.3.4. Giroscópio

As implementações de dispositivos DEVEM incluir um giroscópio (sensor de mudança angular). Os dispositivos NÃO DEVEM incluir um sensor de giroscópio, a menos que um acelerômetro de três eixos também esteja incluído. Se a implementação de um dispositivo incluir um giroscópio:

• PRECISA implementar o sensor TYPE_GYROSCOPE e também DEVE implementar o sensor TYPE_GYROSCOPE_UNCALIBRATED. É altamente RECOMENDADO que dispositivos Android novos e existentes implementem o sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• PRECISA ser capaz de medir mudanças de orientação de até 1.000 graus por segundo.
• PRECISA relatar eventos com uma frequência de pelo menos 50 Hz para dispositivos Android Watch. Esses dispositivos têm uma restrição de energia mais rígida e 100 Hz para todos os outros tipos de dispositivo.
• DEVE relatar eventos de até pelo menos 200 Hz.
• PRECISA ter uma resolução de 12 bits ou mais e DEVE ter uma resolução de 16 bits ou mais.
• PRECISA ser compensado por temperatura.
• PRECISA ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
• PRECISA ter uma variação não maior do que 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 não deverá ser maior do que 1e-7 rad^2/s^2.
• PRECISA implementar um sensor composto TYPE_ROTATION_VECTOR se um sensor de acelerômetro e um sensor de magnetômetro também estiverem incluídos.
• Se um sensor de acelerômetro estiver incluído, PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e PRECISA implementar o sensor composto TYPE_GAME_ROTATION_VECTOR. É altamente RECOMENDADO implementar o sensor TYPE_GAME_ROTATION_VECTOR em dispositivos Android novos e já existentes.

7.3.5. Barômetro

As implementações de dispositivos DEVEM incluir um barômetro (sensor de pressão do ar ambiente). Se uma implementação de dispositivo incluir um barômetro, ela:

• PRECISA implementar e informar o sensor TYPE_PRESSURE.
• PRECISA entregar eventos com frequência de 5 Hz ou mais.
• PRECISA ter precisão adequada para permitir a estimativa de altitude.
• PRECISA ser compensado por temperatura.

7.3.6. Termômetro

As implementações de dispositivos PODEM incluir um termômetro ambiente (sensor de temperatura). Se presente, PRECISA ser definido como SENSOR_TYPE_AMBIENT_TEMPERATURE e medir a temperatura ambiente (ambiente) em graus Celsius.

As implementações de dispositivos PODEM, mas NÃO DEVEM incluir um sensor de temperatura da CPU. Se presente, ele PRECISA ser definido como SENSOR_TYPE_TEMPERATURE, medir a temperatura da CPU do dispositivo e 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. Os dispositivos que podem fazer chamadas de voz e indicar qualquer valor diferente de PHONE_TYPE_NONE em getPhoneType DEVEM incluir um sensor de proximidade. Se uma implementação de dispositivo incluir um sensor de proximidade, ela:

• 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 uma implementação de dispositivo incluir um sensor de proximidade com qualquer outra orientação, ele NÃO PODE SER acessível por essa API.
• PRECISA ter 1 bit de precisão ou mais.

7.3.9. Sensores de alta fidelidade

As implementações de dispositivos compatíveis com um conjunto de sensores de qualidade mais alta que podem atender a todos os requisitos listados nesta seção PRECISAM identificar o suporte pela flag de recurso android.hardware.sensor.hifi_sensors.

Um dispositivo que declara android.hardware.sensor.hifi_sensors PRECISA oferecer suporte a todos os tipos de sensor a seguir, atendendo aos requisitos de qualidade abaixo:

• ACELEROMETRO_TIPO DE SENSOR
  • 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°.

• GYROESCOPO_DE_SENSOR_TIPO DE SENSOR

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

• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade que SENSOR_TYPE_GYROSCOPE.

• CAMPO_DO_SENSOR_TYPE_GEOMAGNETIC
  • 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.
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED tem os mesmos requisitos de qualidade que SENSOR_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.
• SENSOR_TYPE_PRESSURE
  • 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.
• SENSOR_TYPE_GAME_ROTATION_VECTOR
  • 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.
• MOÇÃO DE SENSOR_TIPO 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.
• DETECTOR_DE_ETAPA_DE_SENSOR_TIPO_DE_SENSOR
  • 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.
• CONTADOR_DE_ETAPAS_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.
• DETECTOR_DE_SENSOR_TILT
  • 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.

Além disso, esses dispositivos PRECISAM atender aos seguintes requisitos de subsistema de sensores:

• O carimbo de data/hora do mesmo evento físico relatado pelo acelerômetro, o sensor do giroscópio e o magnetômetro PRECISA estar a no máximo 2,5 milissegundos um do outro.
• Os carimbos de data/hora dos eventos do sensor do giroscópio PRECISAM estar na mesma base de tempo que o subsistema da câmera e a 1 milissegundo de erro.
• Os sensores de alta fidelidade PRECISAM entregar amostras aos aplicativos em até 5 milissegundos a partir do momento em que os dados estão disponíveis no sensor físico para o aplicativo.
• O consumo de energia não pode ser maior do 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:
  • MOÇÃO DE SENSOR_TIPO DE SENSOR
  • DETECTOR_DE_ETAPA_DE_SENSOR_TIPO_DE_SENSOR
  • CONTADOR_DE_ETAPAS_DE_SENSOR
  • DETECTORS DE SENSOR_TILT

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.

Os tipos de sensor a seguir também PODEM ser compatíveis com uma implementação de dispositivo que declare android.hardware.sensor.hifi_sensors, mas, se esses tipos de sensor estiverem presentes, eles PRECISAM atender ao seguinte requisito mínimo de capacidade de armazenamento em buffer:

• SENSOR_TYPE_PROXIMITY: 100 eventos do sensor

7.3.10. Sensor de impressão digital

As implementações de dispositivos com uma tela de bloqueio segura DEVEM incluir um sensor de impressão digital. Se a implementação de um dispositivo incluir um sensor de impressão digital e tiver uma API correspondente para desenvolvedores terceirizados, ela:

• PRECISA declarar suporte ao recurso android.hardware.fingerprint.
• PRECISA implementar completamente a API correspondente, conforme descrito na documentação do SDK do Android.
• PRECISA ter uma taxa de aceitação falsa menor que 0,002%.
• É FORTEMENTE RECOMENDADO que tenha uma taxa de rejeição falsa menor que 10%, conforme medida no dispositivo.
• É FORTEMENTE RECOMENDADO que tenha 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.
• OBRIGATÓRIO as tentativas de limite de taxa por pelo menos 30 segundos após cinco testes falsos para a verificação com impressão digital.
• 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.
• 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.
• 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 oferece o mecanismo da estrutura para fazer isso.
• NÃO É POSSÍVEL permitir que aplicativos de terceiros diferenciem impressões digitais individuais.
• PRECISA respeitar a flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• Quando o upgrade for 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.
• 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

As implementações do Android Automotive DEVEM fornecer os equipamentos atuais como SENSOR_TYPE_GEAR.

7.3.11.2. Modo dia/noite

As implementações do Android Automotive PRECISAM oferecer suporte ao modo dia/noite definido como SENSOR_TYPE_NIGHT. O valor desta sinalização PRECISA ser consistente com o modo dia/noite do painel e deve ser baseado na entrada do sensor de luz ambiente. O sensor de luz ambiente subjacente PODE ser o mesmo do Photometer.

7.3.11.3. Status de condução

As implementações do Android Automotive PRECISAM 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.

7.3.11.4. Velocidade da roda

As implementações do Android Automotive PRECISAM informar a velocidade do veículo definida como SENSOR_TYPE_CAR_SPEED.

7.3.12. Sensor de posição

As implementações de dispositivos podem oferecer suporte a sensores de posição com 6 graus de liberdade. Os dispositivos portáteis Android são RECOMENDADOS para oferecer suporte a esse sensor. Se uma implementação de dispositivo suportar o sensor de pose com 6 graus de liberdade, ela:

• PRECISA implementar e informar o sensor TYPE_POSE_6DOF.
• 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 PODEM informar o recurso android.hardware.telephony ou quaisquer sub-recursos, 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. No entanto, se uma implementação de dispositivo incluir telefonia GSM ou CDMA, ela PRECISA implementar suporte completo para a API dessa tecnologia. Implementações de dispositivos que não incluem hardware de telefonia PRECISAM implementar as APIs completas como ambiente autônomo.

7.4.1.1 Compatibilidade com bloqueio de número

As implementações de dispositivos de Telefonia Android PRECISAM incluir compatibilidade com bloqueio de números e:

• PRECISA implementar totalmente o BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.
• PRECISA bloquear todas as chamadas e mensagens de um número de telefone em "BlockedNumberProvider". sem interação com apps. A única exceção é quando o bloqueio de números é temporariamente suspenso, conforme descrito na documentação do SDK.
• NÃO É POSSÍVEL gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada.
• NÃO É POSSÍVEL gravar no provedor de telefonia uma mensagem bloqueada.
• PRECISA implementar uma interface de gerenciamento de números bloqueados, que é aberta com a intent retornada pelo método TelecomManager.createManageBlockedNumbersIntent().
• NÃO É PERMITIDO que usuários secundários acessem ou editem os números bloqueados no dispositivo, já que a plataforma Android pressupõe que o usuário principal tem controle total dos serviços de telefonia, de 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.2. IEEE 802.11 (Wi-Fi)

Todas as implementações de dispositivos Android DEVEM incluir suporte para uma ou mais formas de 802.11. Se uma implementação de dispositivo incluir suporte para 802.11 e expor a funcionalidade a um aplicativo de terceiros, ela PRECISA implementar a API do Android correspondente e:

• É NECESSÁRIO informar a flag de recurso de hardware android.hardware.wifi.
• PRECISA implementar a API multicast conforme descrito na documentação do SDK.
• 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.

7.4.2.1. Wi-Fi Direct

As implementações de dispositivos DEVEM incluir suporte para Wi-Fi Direct (Wi-Fi ponto a ponto). Se uma implementação de dispositivo incluir suporte ao Wi-Fi Direct, ela PRECISA implementar a API Android correspondente, conforme descrito na documentação do SDK. Se a implementação de um dispositivo for compatível com Wi-Fi Direct, ela:

• É NECESSÁRIO informar o recurso de hardware android.hardware.wifi.direct.
• PRECISA ser compatível com o funcionamento normal do Wi-Fi.
• DEVE oferecer suporte à operação simultânea de Wi-Fi e Wi-Fi Direct.

7.4.2.2. Configuração de link direto encapsulado Wi-Fi

As implementações de dispositivos DEVEM 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 uma implementação de dispositivo incluir suporte para TDLS e TDLS for ativado pela API WiFiManager, o dispositivo:

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

As implementações de dispositivos com suporte ao recurso android.hardware.vr.high_performance PRECISAM oferecer suporte a Bluetooth 4.2 e à extensão de comprimento de dados do Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia. As implementações de dispositivos que incluem suporte a Bluetooth e Bluetooth de baixa energia (BLE) PRECISAM declarar os recursos da plataforma relevantes (android.hardware.bluetooth e android.hardware.bluetooth_le, respectivamente) e implementar as APIs da plataforma. As implementações de dispositivos DEVEM implementar perfis de Bluetooth relevantes, como A2DP, AVCP, OBEX etc., conforme apropriado para o dispositivo.

As implementações do Android Automotive DEVEM oferecer suporte ao Perfil de acesso a mensagens (MAP, na sigla em inglês). 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).

Implementações de dispositivos, incluindo suporte ao Bluetooth Low Energy:

• PRECISA declarar o recurso de hardware android.hardware.bluetooth_le.
• PRECISA ativar as APIs Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e em android.bluetooth.
• são FORTEMENTE RECOMENDADOS para implementar um tempo limite de endereço particular solucionável (RPA, na sigla em inglês) de até 15 minutos e alternar o endereço no tempo limite para proteger a privacidade do usuário.
• DEVE oferecer suporte ao descarregamento da lógica de filtragem para o chipset Bluetooth ao implementar a API ScanFilter, além de informar o valor correto do local em que a lógica de filtragem é implementada sempre que consultado pelo método android.bluetooth.BluetoothAdapter.isOffLoadedFilteringSupported().
• DEVE oferecer suporte ao descarregamento da verificação em lote para o chipset Bluetooth, mas, se não houver suporte, PRECISA informar "false" sempre que consultado pelo método android.bluetooth.BluetoothAdapter.isOffchargeScanBatchingSupported().
• DEVE oferecer suporte a várias publicidades com pelo menos quatro slots, mas se não houver suporte, PRECISA informar "false" sempre que consultado pelo método android.bluetooth.BluetoothAdapter.isMultiplePromotementSupported().

7.4.4. Comunicação a curta distância (NFC, na sigla em inglês)

As implementações de dispositivos DEVEM incluir um transceptor e hardware relacionado para comunicação a curta distância (NFC, na sigla em inglês). Se a implementação de um dispositivo incluir hardware NFC e planeja disponibilizá-lo para apps de terceiros, ela:

• É NECESSÁRIO 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:
  • PRECISA ser capaz de atuar como leitor/gravador do fórum NFC (conforme definido pela especificação técnica NFCForum-TS-Digital Protocol-1.0) do NFCForum-TS-Digital Protocol-1.0 por meio dos seguintes padrões NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6.319-4)
    • IsoDep (ISO 14443-4)
    • Tipos de tags do fórum NFC 1, 2, 3, 4 (definidos pelo fórum NFC)
  • FORTEMENTE RECOMENDADO para ler e gravar mensagens NDEF, além de dados brutos, por meio dos seguintes padrões NFC. Embora os padrões NFC abaixo sejam declarados como FORTEMENTE RECOMENDADOS, a definição de compatibilidade para uma versão futura deve 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.
    • NfcV (ISO 15693)
  • DEVE ser capaz de ler o código de barras e o URL (se codificado) de produtos Thinfilm NFC Barcode.
  • PRECISA ser capaz de transmitir e receber dados por meio dos 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)
  • PRECISA incluir suporte para o Android Beam.
  • PRECISA implementar o servidor padrão SNEP. Mensagens NDEF válidas recebidas pelo servidor SNEP padrão PRECISAM ser enviadas aos aplicativos usando a 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.
  • É NECESSÁRIO cumprir a intenção android.settings.NFCSHARING_SETTINGS para mostrar as configurações de compartilhamento de NFC.
  • PRECISA implementar o servidor NPP. As mensagens recebidas pelo servidor NPP PRECISAM ser processadas da mesma forma que o servidor padrão SNEP.
  • PRECISA implementar um cliente SNEP e tentar enviar o NDEF P2P de saída para o 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.
  • 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.
  • DEVE ativar o Android Beam por padrão e PRECISAR enviar e receber usando o Android Beam, mesmo quando outro modo NFC P2p reservado estiver ativado.
  • DEVE oferecer suporte à transferência da conexão NFC para Bluetooth quando o dispositivo tiver suporte ao perfil de push de objeto Bluetooth. As implementações de dispositivos PRECISAM oferecer suporte à transferência de conexão para Bluetooth ao usar android.nfc.NfcAdapter.setBeamPushUris com a implementação das especificações “Conexão Handover versão 1.2 e Pareamento simples e seguro Bluetooth usando NFC versão 1.0 do Fórum 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 DEVIA ainda aceitar solicitações GET do SNEP para trocar a solicitação de entrega/selecionar registros 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.
  • PRECISA verificar 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.

(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 a implementação de um dispositivo incluir um chipset de controlador NFC capaz de HCE (para NfcA e/ou NfcB) e oferecer suporte ao roteamento de ID do aplicativo (AID), ela:

• PRECISA informar a constante de recurso android.hardware.nfc.hce.
• PRECISA ser compatível com as APIs NFC HCE, conforme definido no SDK do Android.

Se a implementação de um dispositivo incluir um chipset controlador NFC capaz de HCE para NfcF e implementar o recurso para aplicativos de terceiros, ela:

• PRECISA informar a constante de recurso android.hardware.nfc.hcef.
• PRECISA implementar as APIs de emulação de cartão NfcF, conforme definido no SDK do Android.

Além disso, as implementações de dispositivos PODEM incluir suporte de leitor/gravador para as seguintes tecnologias MIFARE.

• MIFARE Classic
• MIFARE ultraleve
• NDEF no MIFARE Classic

Observe que o Android inclui APIs para esses tipos MIFARE. Se uma implementação de dispositivo suporta MIFARE na função de leitor/gravador, ela:

• PRECISA implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
• PRECISA informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). Esse não é um recurso padrão do Android e, portanto, não aparece como uma constante na classe android.content.pm.PackageManager.
• NÃO É POSSÍVEL implementar as APIs correspondentes do Android nem informar o recurso com.nxp.mifare, a menos que ele também implemente suporte geral para NFC, conforme descrito nesta seção.

Se uma implementação de dispositivo não incluir hardware NFC, ela NÃO DEVE declarar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature() e PRECISA implementar a API NFC do Android como ambiente autônomo.

Como as classes android.nfc.NdefMessage e android.nfc.NdefRecord representam um formato de representação de dados independente de protocolo, as implementações de dispositivos PRECISAM implementar essas APIs, mesmo que não incluam suporte para NFC ou declarem o recurso android.hardware.nfc.

7.4.5. Capacidade mínima de rede

As implementações de dispositivos PRECISAM 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.

As implementações de dispositivos em que um padrão de rede física (como Ethernet) é a conexão de dados principal DEVEM incluir suporte para pelo menos um padrão de dados sem fio comum, como 802.11 (Wi-Fi).

Os dispositivos podem implementar mais de uma forma de conectividade de dados.

Os dispositivos PRECISAM 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. O nível necessário de suporte a IPv6 depende do tipo de rede, da seguinte maneira:

• Os dispositivos com suporte a redes Wi-Fi PRECISAM ser compatíveis com operações de pilha dupla e somente IPv6 no Wi-Fi.
• Os dispositivos com suporte a redes Ethernet PRECISAM ser compatíveis com operação de pilha dupla na Ethernet.
• Os dispositivos compatíveis com dados móveis DEVEM ser compatíveis com a operação de IPv6 (somente IPv6 e possivelmente de pilha dupla) nos dados da rede celular.
• Quando um dispositivo está conectado simultaneamente a mais de uma rede (por exemplo, Wi-Fi e dados móveis), ele PRECISA atender a esses requisitos simultaneamente em cada rede a que estiver conectado.

O IPv6 PRECISA estar ativado por padrão.

Para garantir que a comunicação IPv6 seja tão confiável quanto com o IPv4, os pacotes IPv6 unicast enviados para o dispositivo NÃO PODEM ser descartados, mesmo quando a tela não estiver ativa. Pacotes IPv6 multicast redundantes, como anúncios de roteador idênticos repetidos, PODEM ter limitação de taxa em hardware ou firmware, se isso for necessário para economizar energia. Nesses casos, 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.

A conectividade IPv6 PRECISA ser mantida no modo Soneca.

7.4.6. Configurações de sincronização

As implementações de dispositivos PRECISAM ter a configuração de sincronização automática principal ativada por padrão para que o método getMasterSync Automatically() retorne "true".

7.4.7. Economia de dados

As implementações de dispositivos com uma conexão limitada são MUITO RECOMENDADAS para oferecer o modo de economia de dados.

Se uma implementação de dispositivo oferece o modo de economia de dados, ela:

• PRECISA ser compatível com todas as APIs na classe ConnectivityManager, conforme descrito na documentação do SDK.

• PRECISA incluir uma interface do usuário nas configurações para permitir que os usuários adicionem ou removam aplicativos da lista de permissões.

Por outro lado, se uma implementação de dispositivo não oferece o modo de economia de dados, ela:

• PRECISA retornar o valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().

• NÃO É NECESSÁRIO transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

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

As implementações de dispositivos DEVEM incluir uma câmera traseira e PODEM incluir uma câmera frontal. Uma câmera traseira é uma câmera localizada na lateral do dispositivo em frente à tela. ou seja, ela retrata cenas do outro lado do dispositivo, como uma câmera tradicional. Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela. ou seja, uma câmera geralmente usada para tirar fotos do usuário, como para videoconferências e aplicativos semelhantes.

Se uma implementação de dispositivo incluir pelo menos uma câmera, um aplicativo PRECISA 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 estiver aberta para fins de visualização básica e captura.

7.5.1. Câmera traseira

As implementações de dispositivos DEVEM incluir uma câmera traseira. Se a implementação de um dispositivo incluir pelo menos uma câmera traseira, ela:

• É NECESSÁRIO informar a flag de recurso android.hardware.camera e android.hardware.camera.any.
• 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, ele NÃO PODE ser aceso 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 de câmera integrado do sistema do dispositivo, mas apenas a aplicativos de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

As implementações de dispositivos PODEM incluir uma câmera frontal. Se a implementação de um dispositivo incluir pelo menos uma câmera frontal, ela:

• PRECISA informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
• PRECISA ter uma resolução de pelo menos VGA (640 x 480 pixels).
• NÃO É POSSÍVEL usar uma câmera frontal como padrão para a API Camera. A API da câmera no Android tem suporte específico para câmeras frontais, e as implementações de dispositivos NÃO PODEM configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que ela seja a única câmera no dispositivo.
• PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.
• PRECISA refletir horizontalmente (ou seja, espelhar) o stream exibido por um app em uma CameraPreview, da seguinte maneira:
  • Se a implementação do dispositivo puder ser girada pelo usuário (por exemplo, automaticamente por um acelerômetro ou manualmente por entrada), a visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação atual do dispositivo.
  • Se o aplicativo atual solicitar explicitamente que a tela da câmera seja girada por meio de uma chamada para o método android.hardware.Camera.setDisplayOrientation(), a visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo.
  • Caso contrário, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo.
• PRECISA espelhar a imagem mostrada pelo postview da mesma maneira que o stream de imagem de visualização da câmera. Se a implementação do dispositivo não oferecer suporte à pós-visualização, esse requisito obviamente não será aplicável.
• NÃO É POSSÍVEL espelhar os streams de vídeo ou imagem estática capturados finais retornados para callbacks de aplicativos ou comprometidos com o armazenamento de mídia.

7.5.3. Câmera externa

As implementações de dispositivos podem incluir suporte a câmeras externas que nem sempre estão conectadas. Se um dispositivo for compatível com uma câmera externa, ele:

• PRECISA declarar a flag de recurso da plataforma android.hardware.camera.external e android.hardware camera.any .
• PODE oferecer suporte a várias câmeras.
• DEVE 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 à 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 controles de câmera de nível inferior ao app, incluindo fluxos eficientes de burst/streaming de cópia zero e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, remoção de ruído, nitidez e muito mais.

O pacote de API mais antigo, android.hardware.Camera, está marcado como descontinuado no Android 5.0, mas, como ainda deve estar disponível para apps que usam implementações de dispositivos Android, PRECISA garantir o suporte contínuo à 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:

• Se um aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int), o dispositivo PRECISA usar android.hardware.PixelFormat.YCbCr_420_SP para dados de visualização fornecidos aos callbacks do aplicativo.
• Se um aplicativo registrar uma instância android.hardware.Camera.PreviewCallback e o sistema chamar o método onPreviewFrame() quando o formato de visualização for YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame() precisarão estar no formato de codificação NV21. Ou seja, NV21 PRECISA ser o padrão.
• Para android.hardware.Camera, as implementações de dispositivos PRECISAM oferecer suporte ao formato YV12 (conforme indicado pela constante android.graphics.ImageFormat.YV12) para visualizações de câmeras para as câmeras frontal e traseira. 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.
• Para android.hardware.camera2, as implementações de dispositivos precisam oferecer suporte aos formatos android.hardware.ImageFormat.YUV_420_888 e android.hardware.ImageFormat.JPEG como saídas pela API android.media.ImageReader.

As implementações de dispositivos ainda PRECISAM implementar a API Camera completa incluída na documentação do SDK do Android, mesmo que o dispositivo inclua foco automático de hardware ou outros recursos. Por exemplo, câmeras que não têm foco automático PRECISAM chamar qualquer instância registrada de android.hardware.Camera.AutoFocusCallback, mesmo que isso não seja relevante para câmeras sem foco automático. Observe que isso se aplica a câmeras frontais. por exemplo, mesmo que a maioria das câmeras frontais não tenha suporte para autofoco, os callbacks da API ainda devem ser “falsos”, conforme descrito.

As implementações de dispositivos PRECISAM reconhecer e respeitar cada nome de parâmetro definido como uma constante na classe android.hardware.Camera.Parameters se o hardware subjacente oferecer suporte ao recurso. Se o hardware do dispositivo não for compatível com um recurso, a API terá que se comportar conforme a documentação. Por outro lado, as implementações de dispositivos NÃO PODEM respeitar ou reconhecer constantes de string passadas para o método android.hardware.Camera.setParameters() além das documentadas como constantes em 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 em High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera Camera.SCENE_MODE_HDR.

Como nem todas as implementações de dispositivos oferecem suporte total a todos os recursos da API android.hardware.camera2, elas PRECISAM 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 apropriadas.

As implementações de dispositivos também PRECISAM declarar os recursos individuais de câmera de android.hardware.camera2 pela propriedade android.request.availableCapabilities e declarar as flags de recursos apropriadas. Um dispositivo precisa definir a flag de recurso se algum dos dispositivos de câmera conectados for compatível com o recurso.

As implementações de dispositivos PRECISAM transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada da foto for adicionada ao armazenamento de mídia.

As implementações de dispositivos PRECISAM 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

As câmeras frontal e traseira, se houver, DEVEM estar orientadas de modo que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é mantido na orientação paisagem, as câmeras PRECISAM capturar imagens na orientação paisagem. Isso se aplica independentemente da orientação natural do dispositivo. ou seja, aplica-se a dispositivos principais no modo paisagem e modo retrato.

7,6. Memória e armazenamento

7.6.1. Mínimo de memória e armazenamento

A memória disponível para o kernel e o espaço do usuário nas implementações do dispositivo PRECISA ser pelo menos igual ou maior que os valores mínimos especificados pela tabela a seguir. Consulte a seção 7.1.1 para ver as definições de tamanho e densidade da tela.

Densidade e tamanho da tela	Dispositivo de 32 bits	Dispositivo de 64 bits
Dispositivos Android Watch (devido às telas menores)	416MB	Não relevante
280 dpi ou menos em telas pequenas/normais Mdpi ou menor em telas grandes Ldpi ou menor em telas muito grandes	512 MB	816MB
xhdpi ou maior em telas pequenas/normais hdpi ou maior em telas grandes mdpi ou maior em telas muito grandes	608MB	944MB
400 dpi ou mais em telas pequenas/normais xhdpi ou maior em telas grandes tvdpi ou maior em telas muito grandes	896MB	1.280 MB
560 dpi ou mais em telas pequenas/normais 400 dpi ou mais em telas grandes xhdpi ou maior em telas muito grandes	1.344 MB	1.824 MB

Os valores mínimos de memória PRECISAM ser adicionados ao espaço de memória já dedicado a componentes de hardware, como rádio, vídeo e outros, que não esteja sob o controle do kernel.

Implementações de dispositivos com menos de 512 MB de memória disponível para o kernel e o espaço do usuário, a menos que um Android Watch PRECISA retornar o valor "true" para ActivityManager.isLowRamDevice().

Os dispositivos Android Television PRECISAM ter pelo menos 4 GB, e outras implementações de dispositivos PRECISAM ter pelo menos 3 GB de armazenamento não volátil disponível para dados privados de apps. Ou seja, a partição /data PRECISA ter pelo menos 4 GB para dispositivos Android Television e pelo menos 3 GB para outras implementações de dispositivos. As implementações de dispositivos que executam o Android são altamente RECOMENDADAS para ter pelo menos 4 GB de armazenamento não volátil para dados privados do aplicativo. Assim, elas poderão ser atualizadas para futuras versões da plataforma.

As APIs do Android incluem um Gerenciador de downloads que os aplicativos PODEM usar para fazer download de arquivos de dados. A implementação do Gerenciador de downloads PRECISA ser capaz de fazer o download de arquivos individuais de pelo menos 100 MB no local padrão de "cache".

7.6.2. Armazenamento compartilhado do aplicativo

As implementações de dispositivos PRECISAM oferecer armazenamento compartilhado para aplicativos, também conhecido como "armazenamento externo compartilhado".

As implementações de dispositivos PRECISAM ser configuradas com armazenamento compartilhado ativado por padrão. Se o armazenamento compartilhado não estiver montado no Linuxpath /sdcard, o dispositivo PRECISA incluir um link simbólico do Linux de /sdcard para o ponto de montagem real.

As implementações de dispositivos podem ter hardware para armazenamento removível acessível pelo usuário, como um slot para cartão SD. Se esse slot for usado para atender ao requisito de armazenamento compartilhado, a implementação do dispositivo vai:

• PRECISA implementar uma interface do usuário de aviso ou pop-up alertando o usuário quando não houver um cartão SD.
• PRECISA incluir um cartão SD com formato FAT de 1 GB ou mais OU apresentar na caixa e em outros materiais disponíveis no momento da compra. O cartão SD precisa ser adquirido separadamente.
• É NECESSÁRIO montar o cartão SD por padrão.

Como alternativa, as implementações de dispositivos PODEM alocar armazenamento interno (não removível) como armazenamento compartilhado para apps, conforme incluído no Android Open Source Project. dispositivos DEVEM usar essa configuração e implementação de software. Se uma implementação de dispositivo usar armazenamento interno (não removível) para atender ao requisito de armazenamento compartilhado, esse armazenamento PODE compartilhar espaço com dados privados do aplicativo, ele PRECISA ter pelo menos 1 GB de tamanho e estar montado em /sdcard (ou /sdcard PRECISA ser um link simbólico para o local físico se estiver montado em outro lugar).

As implementações de dispositivos PRECISAM aplicar conforme documentado a permissão android.permission.WRITE_EXTERNAL_STORAGE neste armazenamento compartilhado. O armazenamento compartilhado PRECISA ser gravável por qualquer aplicativo que receba essa permissão.

Implementações de dispositivos que incluem vários caminhos de armazenamento compartilhado (como um slot para cartão SD e armazenamento interno compartilhado) PRECISAM permitir somente o pré-instalado e o apps Android privilegiados com a permissão WRITE_EXTERNAL_STORAGE para gravar 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.

No entanto, as implementações de dispositivos DEVEM expor o conteúdo dos dois caminhos de armazenamento de forma transparente com o serviço de verificação de mídia do Android e o android.provider.MediaStore.

Independentemente da forma de armazenamento compartilhado usado, se a implementação do dispositivo tiver uma porta USB compatível com o modo de periférico USB, será NECESSÁRIO fornecer algum mecanismo para acessar o conteúdo do armazenamento compartilhado de um computador host. As implementações de dispositivos PODEM usar armazenamento USB em massa, mas DEVEM usar o Protocolo de transferência de mídia para atender a esse requisito. Se a implementação do dispositivo oferecer suporte ao protocolo de transferência de mídia, ela vai:

• 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

As implementações de dispositivos são RECOMENDADAS para implementar o armazenamento adotável se a porta do dispositivo de armazenamento removível estiver em um local estável de longo prazo, como dentro do compartimento da bateria ou de outra tampa protetora.

Implementações de dispositivos, como uma televisão, PODEM permitir a adoção por portas USB, pois se espera que o dispositivo seja estático e não móvel. Mas, para outras implementações de dispositivo de natureza móvel, é FORTEMENTE RECOMENDADO implementar o armazenamento adotável em um local estável de longo prazo, já que desconectá-las acidentalmente pode causar perda/corrupção de dados.

7,7. USB

As implementações de dispositivos DEVEM ser compatíveis com o modo de periférico USB e DEVEM ser compatíveis com o modo de host USB.

7.7.1. Modo USB periférico

Se a implementação de um dispositivo incluir uma porta USB compatível com o modo de periféricos:

• A porta PRECISA ser conectável a um host USB que tenha uma porta USB padrão tipo A ou tipo C.
• 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.
• 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 seja mostrada 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.
• Ele PRECISA permitir que um host USB conectado ao dispositivo Android acesse o conteúdo do volume de armazenamento compartilhado usando o armazenamento USB em massa ou o protocolo de transferência de mídia.
• Ele DEVE implementar a API e a especificação do Android Open Accessory (AOA), conforme documentado na documentação do SDK do Android. Se for um dispositivo portátil, ele PRECISA implementar a API AOA. Implementações de dispositivos que implementam a especificação de AOA:
  • PRECISA declarar compatibilidade com o recurso de hardware android.hardware.usb.accessory.
  • PRECISA implementar a classe de áudio USB, conforme documentado na documentação do SDK do Android.
  • A classe de armazenamento em massa USB PRECISA incluir a string "android" no final da descrição da interface iInterface string de armazenamento USB em massa
• Ele DEVE implementar suporte para puxar corrente de 1,5 A durante o sinal de emergência 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.
• Os dispositivos tipo C PRECISAM detectar carregadores de 1,5 A e 3,0 A de acordo com os padrões da resistência tipo C e precisam detectar mudanças no anúncio.
• Os dispositivos Type-C que também suportam o modo host USB são FORTEMENTE RECOMENDADOS para oferecer suporte ao Power Delivery para dados e troca de funções de energia.
• Os dispositivos tipo C DEVEM ser compatíveis com o Power Delivery para carregamento de alta tensão e suporte a Modos Alternativos, como saída de tela.
• O valor de iSerialNumber no descritor de dispositivo USB padrão PRECISA ser igual ao valor de android.os.Build.SERIAL.
• Os dispositivos Tipo C são FORTEMENTE RECOMENDADOS a não oferecer suporte a métodos de carregamento proprietários que modifiquem a tensão Vbus além dos níveis padrão ou alterem as funções do coletor/fonte, o que pode resultar em problemas de interoperabilidade com os carregadores ou dispositivos que oferecem suporte aos métodos padrão de fornecimento de energia USB. Embora isso seja 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.

7.7.2. Modo host USB

Se a implementação de um dispositivo incluir uma porta USB compatível com o modo host, ela:

• DEVE usar uma porta USB tipo C, se a implementação do dispositivo for compatível com USB 3.1.
• PODE usar um formato de porta não padrão, mas, nesse caso, DEVE enviar com um ou mais cabos adaptando a porta a uma porta USB padrão tipo A ou tipo C.
• PODE usar uma porta USB micro-AB, mas, nesse caso, DEVE enviar um ou mais cabos adaptando a porta a uma porta USB padrão tipo A ou tipo C.
• é altamente RECOMENDADO para implementar a classe de áudio USB, conforme documentado na documentação do SDK do Android.
• 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.
• DEVE oferecer suporte ao carregamento do dispositivo 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 da especificação do cabo e do conector USB-C] (http://www.usb.org/developers/docs/usb_31_021517.zip) para conectores USB-C ou usando as especificações de carregamento da porta USB-C(CDP, na sigla em inglês), revisão de saída de saída do carregador microUSB1.
• Os dispositivos USB-C são MUITO RECOMENDADOS para oferecer suporte ao DisplayPort, DEVEM oferecer suporte a taxas de dados USB SuperSpeed e MUITO RECOMENDADOS para oferecer suporte ao Power Delivery para troca de funções de dados e energia.
• Dispositivos com qualquer porta tipo A ou tipo AB NÃO PODEM ser enviados com um adaptador que converta essa porta em um receptáculo tipo C.
• É NECESSÁRIO 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 o framework de acesso ao armazenamento (SAF, na sigla em inglês) for compatível.
• PRECISA, se você usar uma porta USB tipo C e incluir suporte para modo periférico, implementar a funcionalidade de porta de função dupla conforme definido pela especificação USB-C (seção 4.5.1.3.3).
• Se a funcionalidade Dual Role Port for compatível, implemente 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

Implementações de dispositivos PODEM omitir um microfone. No entanto, se uma implementação de dispositivo omitir um microfone, ela NÃO PODE informar a constante de recurso android.hardware.microphone e PRECISA implementar a API de gravação de áudio pelo menos como ambiente autônomo, de acordo com a seção 7. Por outro lado, implementações de dispositivos que possuem um microfone:

• É NECESSÁRIO informar a constante de recurso "android.hardware.microphone".
• PRECISA atender aos requisitos de gravação de áudio na seção 5.4.
• PRECISA atender aos requisitos de latência de áudio na seção 5.6.
• FORTEMENTE RECOMENDADO para oferecer suporte à gravação quase ultrassônica, conforme descrito na seção 7.8.3.

7.8.2. Saída de áudio

Implementações de dispositivos, incluindo um alto-falante ou uma porta de saída de áudio/multimídia para um periférico de saída de áudio, como um fone de ouvido ou um alto-falante externo:

• É NECESSÁRIO informar a constante de recurso android.hardware.audio.output.
• PRECISA atender aos requisitos de reprodução de áudio na seção 5.5.
• PRECISA atender aos requisitos de latência de áudio na seção 5.6.
• FORTEMENTE RECOMENDADO para oferecer suporte à reprodução quase ultrassom, conforme descrito na seção 7.8.3.

Por outro lado, se a implementação de um dispositivo não incluir um alto-falante ou uma porta de saída de áudio, ela NÃO DEVE informar o recurso de saída android.hardware.audio e PRECISA implementar as APIs relacionadas à saída de áudio como ambiente autônomo.

A implementação de dispositivos Android Watch PODE, mas NÃO DEVE ter saída de áudio, mas outros tipos de implementações de dispositivos Android PRECISAM ter uma saída de áudio e declarar android.hardware.audio.output.

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 a implementação de um dispositivo tiver uma entrada para fone de ouvido de 3,5 mm com quatro condutores, ela:

• DEVE oferecer suporte à reprodução de áudio para fones de ouvido estéreo e fones de ouvido estéreo com microfone e DEVE oferecer suporte à gravação de áudio de fones de ouvido estéreo com microfone.
• DEVE oferecer suporte a plugues de áudio TRRS com a ordem de pinagem CTIA e DEVE oferecer suporte a plugues de áudio com a ordem de pinagem OMTP.
• PRECISA oferecer suporte à detecção de microfone no acessório de áudio conectado, se a implementação do dispositivo oferecer suporte a um microfone, e transmitir android.intent.action.HEADSET_PLUG com o microfone de valor extra definido como 1.
• 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
• FORTEMENTE 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 terra no plugue de áudio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• DEVE acionar ACTION_HEADSET_PLUG com a inserção de um plugue, mas somente depois que todos os contatos no plugue estiverem tocando seus segmentos relevantes no conector.
• PRECISA ser capaz de conduzir pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 Ohm.
• O microfone PRECISA ter uma tensão de polarização de microfone entre 1,8 V e 2,9 V.

7.8.3. Quase ultrassom

O áudio quase ultrassom é a banda de 18,5 kHz a 20 kHz. As implementações de dispositivos PRECISAM informar corretamente o suporte à capacidade de áudio quase ultrassom pela API AudioManager.getProperty da seguinte maneira:

• Se PROPERTY_SUPPORT_MIC_NEAR_ULTRAS for "true", os seguintes requisitos precisarão ser atendidos pelas fontes de áudio VOICE_RECOGNITION e UNPROCESSED:
  • 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.
  • A proporção não ponderada do sinal para ruído do microfone acima de 18,5 kHz a 20 kHz para um tom de 19 kHz a -26 dBFS PRECISA ser, no máximo, 50 dB.
• Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRAACTION for "true", a resposta média do locutor entre 18,5 kHz e 20 kHz PRECISA ser, no máximo, 40 dB abaixo da resposta a 2 kHz.

7,9. Realidade virtual

O Android inclui APIs e instalações para criar a "Realidade virtual" (RV) incluindo experiências de RV de alta qualidade para dispositivos móveis. As implementações de dispositivos PRECISAM implementar corretamente essas APIs e esses comportamentos, conforme detalhado nesta seção.

7.9.1. Modo de realidade virtual

As implementações de dispositivos portáteis Android que oferecem suporte a um modo para aplicativos de RV que processam a renderização estereoscópica de notificações e desativam componentes da interface do sistema monocular enquanto um aplicativo de RV tiver o foco do usuário PRECISAM declarar o recurso android.software.vr.mode. Os dispositivos que declaram esse recurso PRECISAM incluir um aplicativo que implemente android.service.vr.VrListenerService que possa ser ativado por apps de RV usando o android.app.Activity#setVrModeEnabled .

7.9.2. Alto desempenho de realidade virtual

As implementações de dispositivos portáteis Android PRECISAM identificar o suporte à realidade virtual de alto desempenho para períodos mais longos de usuários pela flag de recurso android.hardware.vr.high_performance e atender aos requisitos a seguir.

• As implementações de dispositivos PRECISAM ter pelo menos dois núcleos físicos.
• As implementações de dispositivos PRECISAM declarar o recurso android.software.vr.mode.
• As implementações de dispositivos PODEM fornecer um núcleo exclusivo para o aplicativo em primeiro plano e podem oferecer suporte à API Process.getExactCores para retornar os números dos núcleos de CPU exclusivos do aplicativo de primeiro plano principal. 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.
• As implementações de dispositivos PRECISAM oferecer suporte ao modo de desempenho sustentado.
• As implementações de dispositivos PRECISAM oferecer suporte ao OpenGL ES 3.2.
• As implementações de dispositivos PRECISAM oferecer suporte ao hardware do Vulkan de nível 0 e DEVEM oferecer suporte ao hardware de nível 1 do Vulkan.
• As implementações de dispositivos PRECISAM implementar EGL_KHR_mutable_render_buffer e EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync e EGL_KHR_wait_sync para que possam ser usadas para o modo de buffer compartilhado e expor as extensões na lista de extensões EGL disponíveis.
• A GPU e a tela PRECISAM ser capazes de sincronizar o acesso ao buffer frontal compartilhado de modo que a renderização de olhos alternados do conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de ruptura visíveis.
• As implementações de dispositivos PRECISAM implementar EGL_IMG_context_priority e expor a extensão na lista de extensões EGL disponíveis.
• As implementações de dispositivos PRECISAM implementar GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 e GL_OVR_multiview_multisampled_render_to_texture, além de expor as extensões na lista de extensões GL disponíveis.
• As implementações de dispositivos PRECISAM implementar EGL_EXT_extended_content e GL_EXT_protection_textures para que elas possam ser usadas na reprodução de vídeo de textura segura e expor as extensões na lista de extensões EGL e GL disponíveis.
• As implementações de dispositivos PRECISAM oferecer suporte à decodificação H.264 de pelo menos 3840 x 2160 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).
• As implementações de dispositivos PRECISAM ser compatíveis com HEVC e VP9, PRECISAM ser capazes de decodificar pelo menos 1920 x 1080 a 30 fps a 10 Mbps e DEVEM ser capazes de decodificar de 3840 x 2160 a 30 fps a 20 Mbps (equivalente a 4 instâncias de 1920 x 1080 a 30 Mbps-30Mbps).
• As implementações de dispositivos são RECOMENDADAS para oferecer suporte ao recurso android.hardware.sensor.hifi_sensors e PRECISAM atender aos requisitos relacionados a giroscópio, acelerômetro e magnetômetro para android.hardware.hifi_sensors.
• As implementações de dispositivos PRECISAM ser compatíveis com a API HardwarePropertiesManager.getDeviceTemperaturas e retornar valores precisos para a temperatura da pele.
• A implementação do dispositivo PRECISA ter uma tela incorporada, e a resolução PRECISA ser pelo menos FullHD(1080p) e RECOMENDADA ALTAMENTE PARA SER QuadHD (1440p) ou superior.
• A tela PRECISA medir entre 4,7" e 6" na diagonal.
• A tela PRECISA ser atualizada para pelo menos 60 Hz no modo RV.
• A latência de exibição no tempo de alternância de cinza para cinza, branco para preto e preto para branco PRECISA ser ≤ 3 ms.
• A tela PRECISA ser compatível com um modo de baixa persistência com persistência menor que 5 ms. Essa persistência é definida como a quantidade de tempo em que um pixel está emitindo luz.
• As implementações de dispositivos PRECISAM oferecer suporte à extensão de comprimento de dados Bluetooth 4.2 e Bluetooth LE seção 7.4.3.

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. Os dispositivos Android Watch DEVEM e outros tipos de implementação de dispositivos PRECISAM atender aos critérios a seguir.

8.1. Consistência da experiência do usuário

As implementações de dispositivos PRECISAM oferecer uma interface do usuário simples, garantindo um frame rate e tempos de resposta consistentes para aplicativos e jogos. As implementações de dispositivos PRECISAM atender aos seguintes requisitos:

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

8.2. Desempenho do acesso a E/S de arquivos

As implementações de dispositivos PRECISAM garantir a consistência no desempenho do acesso a arquivos no armazenamento interno para operações de leitura e gravação.

• Gravação sequencial . As implementações de dispositivos PRECISAM garantir um desempenho de gravação sequencial de pelo menos 5 MB/s para um arquivo de 256 MB usando buffer de gravação de 10 MB.
• Gravação aleatória . As implementações de dispositivos PRECISAM garantir um desempenho de gravação aleatória de pelo menos 0,5 MB/s para um arquivo de 256 MB usando um buffer de gravação de 4 KB.
• Leitura sequencial . As implementações de dispositivos PRECISAM garantir um desempenho de leitura sequencial de pelo menos 15 MB/s para um arquivo de 256 MB usando buffer de gravação de 10 MB.
• Leitura aleatória . As implementações de dispositivos PRECISAM garantir um desempenho de leitura aleatória de pelo menos 3,5 MB/s para um arquivo de 256 MB usando um buffer de gravação de 4 KB.

8.3. Modos de economia de energia

O Android 6.0 introduziu os modos de economia de energia App em espera e Soneca para otimizar o uso da bateria. Todos os apps isentos desses modos PRECISAM ficar visíveis para o usuário final. Além disso, os algoritmos de acionamento, manutenção, ativação e o uso das configurações globais do sistema desses modos de economia de energia não DEVEM ser diferentes 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, na sigla em inglês). No entanto, se implementar os estados de energia S3 e S4, elas só poderão inserir esses estados ao fechar uma tampa que faça parte fisicamente do dispositivo.

8.4. Contabilidade de consumo de energia

Uma contabilidade e relatórios mais precisos do consumo de energia fornecem ao desenvolvedor de aplicativos os incentivos e as ferramentas para otimizar o padrão de uso de energia do aplicativo. Portanto, as implementações de dispositivos:

• PRECISA ser capaz de acompanhar o uso de energia do componente de hardware e atribuí-lo a aplicativos específicos. Especificamente, as implementações:
  • PRECISA fornecer um perfil de energia por componente que defina o valor atual de consumo 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.
  • É NECESSÁRIO informar todos os valores de consumo de energia em miliamperes-hora (mAh).
  • 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.
  • PRECISA informar o consumo de energia da CPU pelo UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
• PRECISA disponibilizar esse uso de energia pelo comando do shell do adb shell dumpsys batterystats ao desenvolvedor do app.
• PRECISA respeitar a intent android.intent.action.POWER_USAGE_SUMMARY e exibir um menu de configurações que mostre esse uso da energia.

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.

As implementações de dispositivos DEVEM ser compatíveis com o modo de desempenho sustentado, que pode fornecer ao aplicativo em primeiro plano um nível consistente de desempenho por um período prolongado quando solicitado pelo método Window.setSustainedPerformanceMode() da API. Uma implementação de dispositivo PRECISA informar o suporte ao modo de desempenho sustentado com precisão usando o método PowerManager.isSustainedPerformanceModeSupported() da API.

As implementações de dispositivos com dois ou mais núcleos de CPU DEVEM fornecer pelo menos um núcleo exclusivo que possa ser reservado pelo aplicativo em primeiro plano. Se fornecidas, as implementações PRECISAM atender aos seguintes requisitos:

• As implementações PRECISAM 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.
• As implementações de dispositivos PRECISAM permitir que nenhum processo de espaço do usuário seja permitido, exceto os drivers de dispositivo usados pelo aplicativo para execução nos núcleos exclusivos, mas PODEM permitir que alguns processos do kernel sejam executados conforme necessário.

Se a implementação de um dispositivo não oferecer suporte a um núcleo exclusivo, ela PRECISA retornar uma lista vazia com o método de API Process.getExclusiveCores().

9. Compatibilidade do modelo de segurança

As implementações de dispositivos PRECISAM implementar um modelo de segurança consistente com o modelo de segurança da Plataforma Android, conforme definido no documento de referência de segurança e permissões das APIs na documentação do desenvolvedor Android. As implementações de dispositivos PRECISAM ser compatíveis com a instalação de aplicativos autoassinados, sem a necessidade de 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

As implementações de dispositivos PRECISAM ser compatíveis com o modelo de permissões do Android, conforme definido na documentação do desenvolvedor Android. Especificamente, as implementações PRECISAM aplicar cada permissão definida conforme descrito na documentação do SDK. nenhuma permissão pode ser omitida, alterada ou ignorada. As implementações podem adicionar outras permissões, desde que as novas strings de ID de permissão não estejam no namespace android.*.

As permissões com um protectionLevel de PROTECTION_FLAG_PRIVILEGED só PRECISAM ser concedidas a apps pré-carregados nos caminhos privilegiados da lista de permissões da imagem do sistema, como o caminho system/priv-app na implementação do AOSP.

Permissões com um nível de proteção perigoso são as permissões de execução. Apps com targetSdkVersion > 22 solicitá-las no ambiente de execução. Implementações de dispositivos:

• PRECISA mostrar uma interface dedicada para que o usuário decida se concede as permissões de execução solicitadas, além de fornecer uma interface para gerenciar essas permissões.
• PRECISA ter apenas uma implementação das duas interfaces do usuário.
• 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

9,2. UID e isolamento de processos

As implementações de dispositivos PRECISAM oferecer suporte ao modelo de sandbox do aplicativo Android, no qual cada aplicativo é executado como um UID de estilo Unix exclusivo e em um processo separado. As implementações de dispositivos PRECISAM ser compatíveis com a 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

As implementações de dispositivos PRECISAM ser compatíveis com o 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 podem incluir ambientes de execução que executam aplicativos usando outro software ou tecnologia que não o Dalvik Executable Format ou o código nativo. No entanto, esses ambientes de execução alternativos NÃO PODEM comprometer o modelo de segurança do Android nem a segurança dos aplicativos Android instalados, conforme descrito nesta seção.

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.

Os ambientes de execução alternativos NÃO PODEM ter acesso a recursos protegidos por permissões não solicitadas no arquivo AndroidManifest.xml do ambiente de execução por <uses-permission> mecanismo de atenção.

Tempos de execução alternativos NÃO PODEM permitir que os aplicativos usem recursos protegidos por permissões do Android restritas a aplicativos do sistema.

Os tempos de execução alternativos PRECISAM respeitar o modelo de sandbox do Android. Especificamente, ambientes de execução alternativos:

• DEVEM instalar os apps pelo PackageManager em sandboxes separadas do Android (IDs de usuário do Linux etc.).
• PODE fornecer uma única sandbox do Android compartilhada por todos os aplicativos que usam o tempo de execução alternativo.
• 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 Android padrão de ID de usuário compartilhado e certificado de assinatura.
• NÃO PODE iniciar com, conceder ou receber acesso às sandboxes correspondentes a outros aplicativos Android.
• NÃO PODE ser iniciado com, ser concedido ou conceder a outros aplicativos quaisquer privilégios do superusuário (raiz) ou de qualquer outro ID de usuário.

Os arquivos .apk de tempos de execução alternativos PODEM ser incluídos na imagem do sistema de uma implementação de dispositivo, mas DEVEM ser assinados com uma chave diferente da usada para assinar outros aplicativos incluídos na implementação do dispositivo.

Ao instalar aplicativos, ambientes de execução alternativos PRECISAM receber o consentimento do usuário para as permissões do Android usadas pelo aplicativo. Se um aplicativo precisar usar um recurso do dispositivo para o qual há uma permissão correspondente do Android (como Câmera, GPS etc.), o tempo de execução alternativo PRECISA informar ao usuário que o aplicativo poderá acessar esse recurso. Se o ambiente de execução não registrar 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 de execução.

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 permitir vários usuários, mas, quando ativadas, PRECISAM atender aos seguintes requisitos relacionados ao suporte multiusuário:

• As implementações de dispositivos Android Automotive com suporte multiusuário ativado PRECISAM 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.
• As implementações de dispositivos que não declaram a flag de recurso android.hardware.telephony PRECISAM 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.
• Por outro lado, as implementações de dispositivos que declaram o flag de recurso android.hardware.telephony NÃO podem ser compatíveis com perfis restritos, mas PRECISAM estar alinhadas à implementação de controles do AOSP para ativar ou desativar o acesso de outros usuários às chamadas de voz e SMS.
• As implementações de dispositivos PRECISAM, 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.
• Cada instância de usuário em um dispositivo Android PRECISA ter diretórios de armazenamento externo separados e isolados. As implementações de dispositivos podem armazenar dados no mesmo volume ou sistema de arquivos. No entanto, a implementação do dispositivo PRECISA garantir que os aplicativos pertencentes e executados em nome de um determinado usuário não possam listar, ler nem gravar dados de outro usuário. As mídias removíveis, como slots para cartão SD, podem permitir que um usuário acesse os dados de outro usando um PC host. Por esse motivo, as implementações de dispositivos que usam mídia removível para as APIs de armazenamento externo PRECISAM criptografar o conteúdo do cartão SD se o recurso multiusuário estiver ativado usando uma chave armazenada somente em mídia não removível acessível apenas pelo sistema. 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. Da mesma forma, 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.

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. As implementações de dispositivos que declaram suporte a android.hardware.telephony PRECISAM avisar os usuários antes de enviar mensagens 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. SELinux ou qualquer outro recurso de segurança implementado abaixo da estrutura do Android:

• PRECISA manter a compatibilidade com os aplicativos atuais.
• NÃO PODE ter uma interface do usuário visível quando uma violação de segurança for detectada e bloqueada, 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.
• NÃO DEVE ser configurável pelo usuário ou pelo desenvolvedor.

Se uma API para configuração de políticas for exposta a um aplicativo que possa afetar outro (como a API Device Administration), a API NÃO PODE permitir configurações que violem a compatibilidade.

Os dispositivos PRECISAM implementar o SELinux ou, se você estiver usando um kernel diferente do Linux, um sistema de controle de acesso obrigatório equivalente. Os dispositivos também PRECISAM atender aos requisitos a seguir, que são cumpridos pela implementação de referência no Android Open Source Project.

Implementações de dispositivos:

• É NECESSÁRIO definir o SELinux para o modo de aplicação global.
• PRECISA configurar todos os domínios no modo aplicado. Não são permitidos domínios de modo permissivo, incluindo domínios específicos de um dispositivo/fornecedor.
• NÃO É NECESSÁRIO modificar, omitir ou substituir as regras de bloqueio presentes na pasta system/sepolicy fornecida no Android Open Source Project (AOSP) upstream. Além disso, a política PRECISA ser compilada com todas as regras nunca permitir presentes para domínios SELinux do AOSP e domínios específicos do dispositivo/fornecedor.
• 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.

As implementações de dispositivos DEVEM manter a política SELinux padrão fornecida na pasta system/sepolicy do Android Open Source Project upstream e só incrementar esta política para a própria configuração específica do dispositivo. As implementações de dispositivos PRECISAM ser compatíveis com o Android Open Source Project upstream.

Os dispositivos PRECISAM implementar um mecanismo de sandbox para aplicativos 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.

9,8. Privacidade

Se o dispositivo implementar no sistema uma funcionalidade que capture o conteúdo mostrado na tela e/ou grave o stream de áudio reproduzido no dispositivo, ele PRECISA sempre notificar o usuário sempre que essa funcionalidade estiver ativada e estiver capturando/gravando.

Se uma implementação de dispositivo tiver um mecanismo que encaminha o tráfego de dados de rede por padrão por um servidor proxy ou gateway de VPN (por exemplo, pré-carregamento de um serviço de VPN com a permissão android.permission.CONTROL_VPN concedida), a implementação do dispositivo PRECISA solicitar o consentimento do usuário antes de ativar esse mecanismo, a menos que a VPN seja ativada pelo controlador de políticas de dispositivo via DevicePolicyManager.setAlwaysOnVpnPackage(). Nesse caso, o usuário não precisa fornecer um consentimento separado, mas PRECISA ser notificado.

As implementações de dispositivos PRECISAM ser enviadas com um repositório de autoridade de certificação (CA, na sigla em inglês) vazio adicionado pelo usuário e PRECISAM pré-instalar os mesmos certificados raiz do repositório de CAs confiáveis pelo sistema, conforme fornecido no Android Open Source Project.

Quando os dispositivos são roteados por uma VPN ou uma CA raiz do usuário está instalada, a implementação PRECISA exibir um aviso indicando que o tráfego de rede pode ser monitorado pelo usuário.

Se uma implementação de dispositivo tiver uma porta USB compatível com o modo de periférico USB, ela 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,9. Criptografia do armazenamento de dados

Se a implementação do dispositivo for compatível com uma tela de bloqueio segura, conforme descrito na seção 9.11.1, o dispositivo PRECISA ser compatível com a criptografia de armazenamento de dados dos dados privados do aplicativo (/partição de dados), bem como a partição de armazenamento compartilhado do aplicativo (partição /sdcard), se ela for uma parte permanente e não removível do dispositivo.

Para implementações de dispositivos compatíveis com criptografia de armazenamento de dados e com desempenho de criptografia do Padrão de criptografia avançada (AES) acima de 50 MiB/s, a criptografia do armazenamento de dados PRECISA estar ativada por padrão no momento em que o usuário concluir a configuração pronta. Se uma implementação de dispositivo já tiver sido lançada 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.

As implementações de dispositivos DEVEM 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

Todos os dispositivos PRECISAM implementar as APIs do modo de inicialização direta, mesmo que não sejam compatíveis com a criptografia de armazenamento. Especificamente, as intents LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED ainda precisam ser transmitidas para sinalizar aos aplicativos com reconhecimento de inicialização direta que os locais de armazenamento criptografados por dispositivo (DE) e criptografados por credencial (CE) estão disponíveis para o usuário.

9.9.2. Criptografia baseada em arquivos

Implementações de dispositivos compatíveis com FBE:

• PRECISA ser inicializado sem solicitar credenciais do usuário e permitir que apps com reconhecimento de inicialização direta acessem o armazenamento criptografado do dispositivo (DE) depois que a mensagem LOCKED_BOOT_COMPLETED for transmitida.
• 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 suas credenciais (por exemplo, senha, PIN, padrão ou impressão digital) e a mensagem ACTION_USER_UNLOCKED for transmitida. As implementações de dispositivos NÃO PODEM oferecer nenhum método para desbloquear o armazenamento protegido por CE sem as credenciais fornecidas pelo usuário.
• PRECISA oferecer suporte à Inicialização verificada e garantir que as chaves DE estejam vinculadas criptograficamente à raiz de confiança do hardware do dispositivo.
• PRECISA oferecer suporte à criptografia do conteúdo do arquivo usando AES com um comprimento de chave de 256 bits no modo XTS.
• PRECISA oferecer suporte à criptografia de nomes de arquivos usando AES com um comprimento de chave de 256 bits no modo CBC-CTS.
• 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 cifras, comprimentos e modos de chave obrigatoriamente compatíveis por padrão.
• DEVE tornar os apps essenciais pré-carregados (por exemplo, Alarme, Telefone, Messenger) com reconhecimento de inicialização direta.

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

• PRECISA estar vinculado criptograficamente a um Keystore protegido por hardware. As chaves CE precisam estar vinculadas às credenciais da tela de bloqueio do usuário. Se o usuário não tiver especificado nenhuma credencial para a tela de bloqueio, as chaves CE PRECISAM estar vinculadas a uma senha padrão.
• PRECISA ser exclusiva e distinta. Em outras palavras, nenhuma chave CE ou DE do usuário pode corresponder às chaves CE ou DE de qualquer outro usuário.

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

Implementações de dispositivos compatíveis com a criptografia de disco completo (FDE, na sigla em inglês). PRECISA usar o AES com uma chave de 128 bits (ou maior) e um modo projetado para armazenamento (por exemplo, AES-XTS, AES-CBC-ESSIV). A chave de criptografia NÃO PODE ser gravada no armazenamento em momento algum sem ser criptografada. A não ser quando estiver em uso ativo, a chave de criptografia DEVE ser criptografada em AES com as credenciais da tela de bloqueio estendidas usando um algoritmo de alongamento lento (por exemplo, PBKDF2 ou scrypt). Se o usuário não tiver especificado as credenciais da tela de bloqueio ou desativado o uso da senha para criptografia, o sistema DEVE usar uma senha padrão para encapsular a chave de criptografia. Se o dispositivo fornecer um keystore protegido por hardware, o algoritmo de alongamento de senha PRECISA ser vinculado criptograficamente a esse keystore. A chave de criptografia NÃO PODE ser enviada 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 que o status da integridade do dispositivo seja transparente.

As implementações de dispositivos PRECISAM 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, ela PRECISA:

• Declarar a flag de recurso da plataforma android.software.verificado_boot.
• Faça a verificação em cada sequência de inicialização.
• Inicie a verificação com uma chave de hardware imutável que é a raiz de confiança e vá até a partição do sistema.
• Implemente cada estágio da verificação para verificar a integridade e a autenticidade de todos os bytes no estágio seguinte antes de executar o código na etapa seguinte.
• Use 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).
• NÃO PODE permitir que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário concorde em tentar inicializar mesmo assim. Nesse caso, os dados de blocos de armazenamento não verificados não PODEM ser usados.
• 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.

O Android Open Source Project oferece uma implementação preferencial desse recurso com base no dm-verity do recurso do kernel do Linux.

A partir do Android 6.0, as implementações de dispositivos com desempenho de criptografia do Padrão de criptografia avançada (AES) acima de 50 MiB/segundos PRECISAM oferecer suporte à inicialização verificada para manter 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.

Todas as implementações de dispositivos Android PRECISAM atender aos seguintes requisitos:

• Não DEVE limitar o número de chaves que podem ser geradas e PRECISA permitir pelo menos permitir a importação de mais de 8.192 chaves.
• A autenticação da tela de bloqueio PRECISA ter um limite de taxa de tentativas e um algoritmo de espera exponencial. Após 150 tentativas com falha, o atraso PRECISA ser de pelo menos 24 horas por tentativa.
• Quando a implementação do dispositivo oferece suporte a uma tela de bloqueio segura, ela PRECISA fazer backup da implementação do keystore com hardware seguro e atender aos seguintes requisitos:
  • PRECISA ter implementações com suporte de hardware de algoritmos criptográficos RSA, AES, ECDSA e HMAC e funções de hash da família MD5, SHA1 e SHA-2 para oferecer suporte adequado aos algoritmos com suporte do sistema Android Keystore.
  • PRECISA executar a autenticação da tela de bloqueio no hardware protegido e permitir que as chaves vinculadas à autenticação sejam usadas somente quando bem-sucedida. O Android Open Source Project fornece a Camada de abstração de hardware (HAL) Gatekeeper, que pode ser usada para atender a esse requisito.

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

As implementações de dispositivos PODEM adicionar ou modificar os métodos de autenticação para desbloquear a tela de bloqueio, mas PRECISAM atender aos seguintes requisitos:

• O método de autenticação, se for baseado em um secret conhecido, NÃO PODE ser tratado como uma tela de bloqueio segura, a menos que atenda a todos os requisitos a seguir:
  • A entropia do menor comprimento permitido de entradas PRECISA ser maior que 10 bits.
  • A entropia máxima de todas as entradas possíveis PRECISA ser maior que 18 bits.
  • Não PODE substituir nenhum dos métodos de autenticação existentes (PIN, padrão, senha) implementados e fornecidos no AOSP.
  • PRECISA ser desativado 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 do que PASSWORD_QUALITY_SOMETHING .
• O método de autenticação, se baseado em um token físico ou no local, NÃO PODE ser tratado como uma tela de bloqueio segura, a menos que atenda a todos os requisitos a seguir:
  • Ela PRECISA ter um mecanismo de fallback para usar um dos métodos principais de autenticação, que é baseado em um segredo conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
  • Ela 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 com o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva do que PASSWORD_QUALITY_UNSPECIFIED .
• O método de autenticação, se baseado em biometria, NÃO PODE ser tratado como uma tela de bloqueio segura, a menos que atenda a todos os requisitos a seguir:
  • Ela PRECISA ter um mecanismo de fallback para usar um dos métodos principais de autenticação, que é baseado em um segredo conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
  • Ela PRECISA ser desativada e só permitir que a autenticação principal desbloqueie a tela quando o aplicativo do controlador de política de dispositivo (DPC) tiver definido a política do recurso de bloqueio chamando o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • Ela 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. Caso contrário, 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 do que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• Se o método de autenticação não puder ser tratado como uma tela de bloqueio segura, ele:
  • PRECISA retornar false para os métodos KeyguardManager.isKeyguardSecure() e KeyguardManager.isDeviceSecure().
  • PRECISA ser desativado 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 do que PASSWORD_QUALITY_UNSPECIFIED .
  • NÃO É POSSÍVEL redefinir os timers de expiração de senha definidos por DevicePolicyManager.setPasswordExpirationTimeout().
  • NÃO É POSSÍVEL autenticar o acesso a keystores se o aplicativo tiver chamado KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).
• Se o método de autenticação for baseado em um token físico, na localização ou biometria que tenha uma taxa de aceitação falsa maior do que o necessário para sensores de impressão digital, conforme descrito na seção 7.3.10:
  • NÃO É POSSÍVEL redefinir os timers de expiração de senha definidos por DevicePolicyManager.setPasswordExpirationTimeout().
  • NÃO É POSSÍVEL autenticar o acesso a keystores se o aplicativo tiver chamado KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).

9,12 Exclusão de dados

Os dispositivos DEVEM fornecer aos usuários um mecanismo para realizar uma "redefinição para configuração original" que permita a exclusão lógica e física de todos os dados, exceto:

• A imagem do sistema
• Quaisquer arquivos do sistema operacional exigidos pela imagem do sistema

Todos os dados gerados pelo usuário PRECISAM ser excluídos. Isso PRECISA satisfazer os padrões relevantes do setor para exclusão de dados, como o NIST SP800-88. Ele DEVE ser usado para a implementação da APIWipeData() (parte da API Android Device Administration) descrita na seção 3.9 Administração do dispositivo.

Os dispositivos PODEM fornecer uma exclusão rápida de dados que realiza uma limpeza lógica de dados.

9,13 Modo de inicialização segura

O Android oferece um modo 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.

É MUITO RECOMENDADO implementar o modo de inicialização segura e atender aos seguintes requisitos:

• As implementações de dispositivos DEVEM fornecer ao usuário uma opção para entrar no modo de inicialização segura a partir do menu de inicialização, que pode ser acessado por meio de um fluxo de trabalho diferente do de inicialização normal.

• As implementações de dispositivos PRECISAM oferecer ao usuário a opção de entrar no modo de inicialização segura de maneira ininterrupta em apps de terceiros instalados no dispositivo, exceto quando o app de terceiros for um controlador de política de dispositivo e tiver definido a flag UserManager.DISALLOW_SAFE_BOOT como verdadeira.

• As implementações de dispositivos PRECISAM oferecer ao usuário a capacidade de desinstalar apps de terceiros no modo de segurança.

9,14 Isolamento de sistemas veiculares automotivos

Os dispositivos Android Automotive precisam trocar dados com subsistemas essenciais do veículo, por exemplo, usando a HAL do veículo para enviar e receber mensagens por redes de veículos, como o barramento CAN. As implementações de dispositivos Android Automotive PRECISAM implementar recursos de segurança abaixo das camadas do framework do Android para evitar interações maliciosas ou não intencionais entre o framework do Android ou apps de terceiros e subsistemas do veículo. Estes são os recursos de segurança:

• Mensagens de bloqueio dos subsistemas de veículos do framework do Android, por exemplo, colocando tipos de mensagens e origens permitidos na lista de permissões.
• Watchdog 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.

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 7.0. 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 dele no Verificador do CTS. Os casos de teste para recursos marcados como opcionais por este Documento de definição de compatibilidade podem ser ignorados ou omitidos.

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

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 à criação.

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

13. Entre em contato

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