Definição de compatibilidade do Android 7.0 (N)

Índice

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 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” e “OPTIONAL” é conforme o padrão IETF definido na RFC2119.

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

Por esse motivo, o Android Open Source Project é a implementação de referência e preferida do Android. É ALTAMENTE RECOMENDÁVEL que os implementadores de dispositivos baseiem suas implementações o máximo possível no código-fonte "upstream" disponível no Projeto de código aberto do Android. Embora alguns componentes possam ser hipoteticamente substituídos por implementações alternativas, é ALTAMENTE RECOMENDADO não seguir essa prática, já que passar nos testes de software vai se tornar muito mais difícil. É responsabilidade do implementador garantir a compatibilidade comportamental total com a implementação padrão do Android, incluindo e além do conjunto de testes de compatibilidade. Por fim, observe que algumas substituições e modificações de componentes são explicitamente proibidas por este documento.

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

2. Tipos de dispositivo

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

Dispositivo portátil Android se refere a uma implementação de dispositivo Android que 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 integrada ao dispositivo.
  • PRECISA ter uma fonte de energia que ofereça mobilidade, como uma bateria.

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

  • PRECISA ter uma tela integrada OU incluir uma porta de saída de vídeo, como VGA, HDMI ou uma porta sem fio para exibição.
  • É PRECISO declarar os recursos android.software.leanback e android.hardware.type.television.

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

  • PRECISA ter uma tela com o comprimento físico diagonal na faixa 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 para parte ou toda a funcionalidade do sistema e/ou infoentretenimento. Implementações do Android Automotive:

  • DEVE ter uma tela com comprimento diagonal físico igual ou maior que 15,24 cm.
  • PRECISA declarar o recurso android.hardware.type.automotive.
  • PRECISA oferecer suporte a 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 de dispositivo acima ainda precisam atender a todos os requisitos deste 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 acima.

2.1 Configurações do dispositivo

Este é um resumo das principais diferenças na configuração de hardware por tipo de dispositivo. (As células vazias indicam um "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 por 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 de periférico/host USB 7.7. USB DEVE DEVE DEVE
Saída Alto-falantes e/ou portas de saída de áudio 7.8.2. Saída de áudio OBRIGATÓRIO OBRIGATÓRIO OBRIGATÓRIO OBRIGATÓRIO

3. Software

3.1. Compatibilidade com a API gerenciada

O ambiente de execução de bytecode Dalvik gerenciado é o veículo principal para aplicativos Android. A interface de programação do aplicativo (API) do Android é o conjunto de interfaces da plataforma Android expostas a aplicativos executados no ambiente de execução gerenciado. As implementações de dispositivo precisam fornecer implementações completas, incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo SDK do Android ou qualquer API decorada com o marcador "@SystemApi" no código-fonte do Android upstream.

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 de API, desviar do comportamento documentado ou incluir no-ops, exceto quando especificamente permitido por esta definição de compatibilidade.

Essa definição de compatibilidade permite que alguns tipos de hardware para os quais o Android inclui APIs sejam omitidos pelas implementações de dispositivos. Nesses casos, as APIs ainda precisam estar presentes e se comportar de maneira razoável. Consulte a seção 7 para ver os requisitos específicos deste cenário.

3.1.1. Extensões Android

O Android inclui suporte para estender as APIs gerenciadas mantendo a mesma versão do nível da API. As implementações de dispositivos Android PRECISAM carregar previamente a implementação do AOSP da biblioteca compartilhada ExtShared e dos serviços ExtServices com versões maiores ou iguais às versões mínimas permitidas para cada nível da API. Por exemplo, as implementações de dispositivos do Android 7.0 que executam o nível 24 da API precisam incluir pelo menos a versão 1.

3.2. Compatibilidade de API flexível

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

3.2.1. Permissões

Os implementadores de dispositivos precisam oferecer suporte e aplicar todas as constantes de permissão, conforme documentado na página de referência de permissões. A seção 9 lista outros requisitos relacionados ao modelo de segurança do Android.

3.2.2. Parâmetros do build

As APIs do Android incluem várias constantes na classe android.os.Build que têm como objetivo descrever o dispositivo atual. Para fornecer valores consistentes e significativos em todas as implementações de dispositivos, a tabela abaixo inclui outras restrições aos formatos desses valores, aos quais as implementações de dispositivos PRECISAM se conformar.

Parâmetro Detalhes
VERSION.RELEASE A versão do sistema Android em execução no momento, em formato legível por humanos. Esse 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 de aplicativos 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 de aplicativos de terceiros. Para o Android 7.0, esse campo PRECISA ter o valor inteiro 7.0_INT.
VERSION.INCREMENTAL Um valor escolhido pelo implementador do dispositivo que designa o build específico do sistema Android em execução no momento, em um formato legível por humanos. Esse valor NÃO PODE ser reutilizado para builds diferentes disponibilizados aos usuários finais. Um uso típico desse campo é indicar qual número de build ou identificador de mudança de controle de origem foi usado para gerar o build. Não há requisitos sobre 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 um formato legível por humanos. Um possível uso desse campo é indicar a revisão específica da placa que alimenta o dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$".
MARCA Um valor que reflete o nome da marca associado ao dispositivo, conhecido pelos usuários finais. PRECISA estar em um formato legível por humanos e 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_-]+$".
SUPPORTED_ABIS O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
SUPPORTED_32_BIT_ABIS O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade com a API nativa.
SUPPORTED_64_BIT_ABIS O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a seção 3.3. Compatibilidade 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 que contém o nome de desenvolvimento ou de código que identifica a configuração dos recursos de hardware e o design industrial do dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". O nome do dispositivo NÃO PODE mudar durante a vida útil do produto.
FINGERPRINT Uma string que identifica exclusivamente esse build. Ele DEVE ser razoavelmente legível por humanos. Ele PRECISA seguir este modelo:

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

Exemplo:

acme/myproduct/
    mydevice:7.0/LMYXX/3359:userdebug/test-keys

A impressão digital NÃO pode incluir caracteres de espaço em branco. Se outros campos incluídos no modelo acima tiverem caracteres de espaço em branco, eles PRECISAM ser substituídos no fingerprint do build por outro caractere, como o 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 razoavelmente 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_-]+$".
HOST Uma string que identifica de maneira exclusiva o host em que o build foi criado, em um formato legível por humanos. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
ID Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão específica em um formato legível por humanos. Esse campo pode ser o mesmo que android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficientemente significativo para que os usuários finais distingam entre builds de software. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9._-]+$".
FABRICANTE O nome comercial do fabricante de equipamento original (OEM) do produto. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
MODEL Um valor escolhido pelo implementador do dispositivo que contém o nome do dispositivo conhecido pelo usuário final. Ele DEVE ser o mesmo nome usado para comercializar e vender o dispositivo para os usuários finais. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
PRODUTO Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o nome de código do produto específico (SKU) que DEVE ser exclusivo na mesma marca. PRECISA ser legível por humanos, mas não necessariamente para visualização por usuários finais. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$". O nome do produto NÃO PODE mudar durante a vida útil do produto.
SERIAL Um número de série de hardware, que PRECISA estar disponível e ser exclusivo em todos os dispositivos com o mesmo MODELO e FABRICANTE. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^([a-zA-Z0-9]{6,20})$”.
TAGS Uma lista de tags separadas por vírgulas escolhidas pelo implementador do dispositivo que distinguem ainda mais o build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas de assinatura da plataforma Android: chaves de lançamento, chaves de desenvolvimento e chaves de teste.
HORÁRIO Um valor que representa o carimbo de data/hora de quando o build ocorreu.
MÁQUINA Um valor escolhido pelo implementador do dispositivo que especifica a configuração do ambiente de execução do build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas de 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 sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
SECURITY_PATCH Um valor que indica o nível do patch de segurança de um build. Ele PRECISA indicar que o build não está de forma alguma vulnerável a nenhum dos problemas descritos no boletim de segurança público do Android designado. Ele PRECISA estar no formato [AAAA-MM-DD], correspondendo a uma string definida documentada no Boletim de segurança público do Android ou no Aviso de segurança do Android, por exemplo, "2015-11-01".
BASE_OS Um valor que representa o parâmetro FINGERPRINT do build, que é idêntico a 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, informe uma string vazia ("").

3.2.3. Compatibilidade de intents

3.2.3.1. Intents principais do aplicativo

As intents do Android permitem que os componentes do aplicativo solicitem funcionalidades de outros componentes do Android. O projeto upstream do Android inclui uma lista de aplicativos considerados principais do Android, que implementam 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
  • GlobalSearch
  • Tela de início
  • Música
  • Configurações

As implementações de dispositivos precisam incluir os principais aplicativos 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 aplicativos Android expostos a outros aplicativos, implicitamente 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 referenciado na seção 3.2.3.1 seja substituído por aplicativos de terceiros. A implementação de código aberto upstream do Android permite isso por padrão. Os implementadores de dispositivos NÃO PODEM anexar privilégios especiais ao uso desses padrões de intent por aplicativos do sistema nem impedir que aplicativos de terceiros se associem a eles e assumam o controle. Essa proibição inclui especificamente, mas não se limita a, desativar a interface do usuário "Chooser", que permite que o usuário selecione entre vários aplicativos que processam o mesmo padrão de intent.

As implementações de dispositivos precisam fornecer uma interface do usuário para que os usuários modifiquem a atividade padrão para intents.

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

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

  • PRECISA tentar validar todos os filtros de intent executando as etapas de validação definidas na especificação de Digital Asset Links conforme implementado pelo gerenciador de pacotes no projeto upstream do Android Open Source.
  • DEVE 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 apps padrão para as UIRs.
  • PODE definir filtros de intent de URI específicos como gerenciadores de apps padrão para os URIs, se eles forem verificados, mas outros filtros de URI candidatos falharem na verificação. Se uma implementação de dispositivo fizer isso, ela PRECISA fornecer ao usuário as substituições de padrão por URI apropriado no menu de configurações.
  • DEVE fornecer ao usuário controles de Links do app por app nas Configurações da seguinte maneira:
    • O usuário PRECISA poder substituir de forma holística o comportamento padrão dos links de um app para que ele seja: sempre aberto, sempre perguntado ou nunca aberto, o que precisa se aplicar a todos os filtros de intent de URI candidatos de forma igual.
    • O usuário PRECISA ter acesso a uma lista dos filtros de intent de URI candidatos.
    • A implementação do dispositivo PODE permitir que o usuário substitua filtros de intent de URI de candidato específicos que foram verificados com sucesso, por filtro de intent.
    • A implementação do dispositivo PRECISA permitir que os usuários visualizem e substituam filtros de intent de URI de candidato específicos se a implementação do dispositivo permitir que alguns filtros de intent de URI de candidato tenham sucesso na verificação, enquanto outros podem falhar.

3.2.3.3. Namespaces de intent

As implementações de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou broadcast usando uma string de chave ACTION, CATEGORY ou outra no namespace android. ou com.android.. Os implementadores de dispositivos NÃO PODEM incluir componentes do Android que respeitem novos padrões de intent ou intent de transmissão usando uma string de ACTION, CATEGORY ou outra chave em um espaço de pacote pertencente a outra organização. Os implementadores de dispositivos NÃO PODEM alterar ou estender nenhum dos padrões de intent usados pelos apps principais listados na seção 3.2.3.1. As implementações de dispositivos PODEM incluir padrões de intent usando namespaces associados de forma clara e óbvia à própria organização. Essa proibição é análoga à especificada para classes de linguagem Java na seção 3.6.

3.2.3.4. Intents de transmissão

Os apps de terceiros dependem da plataforma para transmitir determinadas intents e receber notificações 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 do sistema apropriados. 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 a tela inicial ou SMS. Quando for apropriado, as implementações de dispositivos precisam fornecer um menu de configurações semelhante e ser compatível com o padrão de filtro de intent e os métodos de API descritos na documentação do SDK, conforme abaixo.

Implementações de dispositivos:

  • PRECISA honrar a intent android.settings.HOME_SETTINGS para mostrar um menu de configurações padrão 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 mostrar uma caixa de diálogo para mudar o app de SMS padrão, se a implementação do dispositivo informar android.hardware.telephony.
  • É PRECISO honrar a intent android.settings.NFC_PAYMENT_SETTINGS para mostrar um menu de configurações padrão do app para o Tap and Pay, se a implementação do dispositivo informar android.hardware.nfc.hce.
  • É PRECISO honrar a intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar uma caixa de diálogo que permita ao usuário mudar o app de telefone padrão, se a implementação do dispositivo informar android.hardware.telephony .

3.3. Compatibilidade com a API nativa

A compatibilidade com o código nativo é desafiadora. Por esse motivo, É ALTAMENTE RECOMENDADO que os implementadores de dispositivos usem as implementações das bibliotecas listadas abaixo do Projeto de código aberto do Android.

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. Como o código nativo é altamente dependente da tecnologia de processador, o Android define várias interfaces binárias de aplicativo (ABIs) no Android NDK. As implementações de dispositivos precisam ser compatíveis com uma ou mais ABIs definidas e precisam implementar a compatibilidade com o NDK do Android, conforme abaixo.

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

  • PRECISA incluir suporte para o código executado no ambiente gerenciado para chamar o código nativo usando a semântica padrão da Java Native Interface (JNI).
  • PRECISA ser compatível com a fonte (ou seja, compatível com o cabeçalho) e com o binário (para a ABI) com cada biblioteca necessária na lista abaixo.
  • PRECISA oferecer suporte à ABI de 32 bits equivalente se houver suporte para qualquer ABI de 64 bits.
  • PRECISA informar com precisão a interface binária de aplicativo nativa (ABI) aceita pelo dispositivo, usando os parâmetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS e android.os.Build.SUPPORTED_64_BIT_ABIS, cada um deles uma lista separada por vírgulas de ABIs ordenadas da mais para a menos preferida.
  • É PRECISO informar, pelos parâmetros acima, apenas as ABIs documentadas e descritas na versão mais recente da documentação de gerenciamento de ABI do Android NDK e incluir suporte para a extensão Advanced SIMD (também conhecida como NEON).
  • DEVEM ser criados usando o código-fonte e os arquivos de cabeçalho disponíveis no projeto de código aberto upstream do Android

Versões futuras do Android NDK podem oferecer suporte a outras ABIs. Se uma implementação de dispositivo não for compatível com uma ABI predefinida, ela NÃO PODERÁ informar suporte para nenhuma ABI.

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

  • libandroid.so (suporte nativo à atividade do Android)
  • libc (biblioteca C)
  • libcamera2ndk.so
  • libdl (vinculador dinâmico)
  • libEGL.so (gerenciamento de superfície OpenGL nativa)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (registro do Android)
  • libmediandk.so (suporte a APIs de mídia nativas)
  • libm (biblioteca matemática)
  • libOpenMAXAL.so (suporte ao OpenMAX AL 1.0.1)
  • libOpenSLES.so (suporte a áudio do OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (suporte mínimo para C++)
  • libvulkan.so (Vulkan)
  • libz (compactação Zlib)
  • Interface JNI
  • Suporte para OpenGL, conforme descrito abaixo

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

As bibliotecas nativas não listadas acima, mas implementadas e fornecidas no AOSP como bibliotecas do sistema, são reservadas e NÃO podem ser expostas a apps de terceiros com o nível 24 da API ou mais recente.

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

As implementações de dispositivos precisam incluir libGLESv3.so e, por sua vez, exportar todos os símbolos de função do OpenGL ES 3.1 e do Pacote de extensões do Android, 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 que realmente têm suporte do dispositivo precisam ser totalmente implementadas.

3.3.1.1. Bibliotecas gráficas

A 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 às APIs do Vulkan, precisam atender aos seguintes requisitos:

  • Ele SEMPRE precisa 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 incluir suporte às APIs do Vulkan:

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

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

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

A arquitetura ARMv8 descontinua várias operações de CPU, incluindo algumas usadas no código nativo atual. Em dispositivos ARM de 64 bits, as seguintes operações descontinuadas PRECISAM permanecer disponíveis para o código ARM nativo de 32 bits, seja por suporte nativo à CPU ou por emulação de software:

  • Instruções SWP e SWPB
  • Instrução SETEND
  • Operações de barreira 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 usando esse NDK, os dispositivos PRECISAM incluir as linhas abaixo em /proc/cpuinfo quando ele for lido por aplicativos ARM de 32 bits:

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

Esses requisitos se aplicam apenas quando /proc/cpuinfo é lido por aplicativos ARM de 32 bits. Os dispositivos NÃO devem alterar /proc/cpuinfo quando lidos por aplicativos ARM ou não ARM de 64 bits.

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView

Os dispositivos Android Watch podem, mas todas as outras implementações de dispositivo precisam fornecer uma implementação completa da API android.webkit.Webview.

O recurso da plataforma android.software.webview PRECISA ser informado em qualquer dispositivo que ofereça uma implementação completa da API android.webkit.WebView e NÃO pode ser informado em dispositivos sem uma implementação completa da API. A implementação do Android Open Source usa o código do Projeto Chromium para implementar o android.webkit.WebView. Como não é viável desenvolver um conjunto 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 de android.webkit.WebView do dispositivo precisam ser baseadas no build do Chromium do projeto Android Open Source upstream para o Android 7.0. Esse build inclui um conjunto específico de correções de segurança e funcionalidade para a WebView.

  • A string do agente do usuário informada pela WebView PRECISA estar neste formato:

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

    • O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
    • 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 projeto de código aberto do Android upstream.
    • As implementações de dispositivos PODEM omitir "Mobile" na string do user agent.

O componente WebView PRECISA incluir suporte para o maior número possível de recursos HTML5 e, se for compatível com o recurso, PRECISA estar em conformidade com a especificação HTML5.

3.4.2. Compatibilidade de navegadores

As implementações do Android TV, do relógio e do Android Automotive PODEM omitir um aplicativo de navegador, mas PRECISAM oferecer suporte aos padrões de intent públicos, conforme descrito na seção 3.2.3.1. Todos os outros tipos de implementações de dispositivos precisam incluir um aplicativo de navegador independente para navegação geral na Web.

O navegador independente 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 a aplicativos 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 de navegador independente.

O aplicativo de navegador independente (seja baseado no aplicativo de navegador WebKit upstream ou em uma substituição de terceiros) DEVE incluir suporte para o maior número possível de recursos do HTML5. No mínimo, as implementações de dispositivos precisam oferecer suporte a cada uma das APIs associadas ao HTML5:

Além disso, as implementações de dispositivos precisam oferecer suporte à API Web Storage do HTML5/W3C e à API IndexedDB do HTML5/W3C. Como os órgãos de padrões de desenvolvimento da Web estão fazendo a transição para favorecer o IndexedDB em vez do Web Storage, espera-se que o IndexedDB se torne um componente obrigatório em uma versão futura do Android.

3.5. Compatibilidade comportamental da API

O comportamento de cada um dos tipos de API (gerenciada, soft, nativa e da Web) precisa ser consistente com a implementação preferencial 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 serviço, atividade, 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 partes significativas da plataforma para compatibilidade comportamental, mas não todas. É responsabilidade do implementador garantir a compatibilidade comportamental com o Android Open Source Project. Por esse motivo, os implementadores de dispositivos PRECISAM usar o código-fonte disponível no Android Open Source Project sempre que possível, em vez de implementar novamente partes significativas do sistema.

3.6. Namespaces de API

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

  • java.*
  • javax.*
  • sol.*
  • android.*
  • com.android.*

As modificações proibidas incluem :

  • As implementações de dispositivos NÃO PODEM modificar as APIs expostas publicamente na plataforma Android mudando assinaturas de método ou 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 do idioma 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 para 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 do Android upstream. Em outras palavras, os implementadores de dispositivos NÃO PODEM expor novas APIs nem alterar as APIs atuais nos namespaces mencionados acima. Os implementadores de dispositivos PODEM fazer modificações apenas internas, mas essas modificações NÃO PODEM ser anunciadas ou expostas aos desenvolvedores.

Os implementadores de dispositivos PODEM adicionar APIs personalizadas, mas elas NÃO podem estar em um namespace de propriedade ou que se refira a outra organização. Por exemplo, os implementadores de dispositivos NÃO PODEM adicionar APIs ao namespace com.google.* ou semelhante: apenas o Google pode fazer isso. Da mesma forma, o Google NÃO PODE adicionar APIs aos namespaces de outras empresas. Além disso, se uma implementação de dispositivo incluir APIs personalizadas fora do namespace padrão do Android, elas PRECISAM ser empacotadas em uma biblioteca compartilhada do Android para que apenas os apps que as usam explicitamente (pelo mecanismo <uses-library>) sejam afetados pelo aumento do uso de memória dessas APIs.

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

As restrições acima correspondem a convenções padrão para nomear APIs na linguagem de programação Java. O objetivo desta seção é apenas reforçar essas convenções e torná-las obrigatórias com a inclusão nesta definição de compatibilidade.

3.7. Compatibilidade com o 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 do bytecode do Dalvik. Os implementadores de dispositivos precisam usar o ART, a implementação upstream de referência do formato executável Dalvik e o sistema de gerenciamento de pacotes da implementação de referência.

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 na 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 inicial (acesso rápido)

O Android inclui um aplicativo de acesso rápido (tela inicial) e suporte a apps de terceiros para substituir o acesso rápido do dispositivo (tela inicial). As implementações de dispositivos que permitem que apps de terceiros substituam a tela inicial do dispositivo PRECISAM declarar o recurso da plataforma android.software.home_screen.

3.8.2. Widgets

Os widgets são opcionais para todas as implementações de dispositivos Android, mas precisam ter suporte em dispositivos portáteis Android.

O Android define um tipo de componente e o ciclo de vida correspondente que permite que os aplicativos exponham um "AppWidget" ao usuário final, um recurso que é ALTAMENTE RECOMENDADO para implementações de dispositivos portáteis. As implementações de dispositivos que oferecem suporte à incorporação de widgets na tela inicial PRECISAM atender aos requisitos a seguir e declarar suporte ao recurso de plataforma android.software.app_widgets.

  • Os inicializadores de dispositivos precisam incluir suporte integrado a widgets de app e oferecer recursos de interface do usuário para adicionar, configurar, visualizar e remover widgets de app diretamente no inicializador.
  • As implementações de dispositivos precisam ser capazes de renderizar widgets de 4 x 4 no tamanho padrão da grade. Consulte as Diretrizes de design para widgets de app na documentação do SDK do Android para saber mais.
  • As implementações de dispositivos que incluem suporte para a tela de bloqueio PODEM oferecer suporte a widgets de apps na tela de bloqueio.

3.8.3. Notificações

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

Algumas APIs permitem que os aplicativos realizem notificações ou chamem a atenção usando hardware, especificamente som, vibração e luz. As implementações de dispositivos precisam oferecer suporte a notificações que usam recursos de hardware, conforme descrito na documentação do SDK, e na medida do possível com o hardware de implementação do dispositivo. Por exemplo, se uma implementação de dispositivo incluir um vibrador, ela PRECISA implementar corretamente as APIs de vibração. Se uma implementação de dispositivo não tiver hardware, as APIs correspondentes PRECISAM ser implementadas como no-ops. 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 ícones da barra de status/sistema, que, no caso de um dispositivo Android TV, inclui a possibilidade de não mostrar as notificações. Os implementadores de dispositivos PODEM oferecer uma experiência do usuário alternativa para notificações diferente da implementação de referência do Android Open Source. No entanto, esses sistemas de notificação alternativos PRECISAM oferecer suporte aos recursos de notificação existentes, conforme descrito acima.

As implementações do Android Automotive PODEM gerenciar a visibilidade e o tempo das notificações para reduzir a distração do motorista, mas PRECISAM mostrar notificações que usam o CarExtender quando solicitado pelos apps.

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

  • Notificações avançadas . Visualizações interativas para notificações em andamento.
  • Notificações de alerta . Os usuários de visualizações interativas podem agir ou dispensar sem sair do app atual.
  • Notificações na tela de bloqueio . Notificações mostradas sobre uma tela de bloqueio com controle granular de visibilidade.

As implementações de dispositivos Android, quando essas notificações são exibidas, PRECISAM executar corretamente as notificações Rich e Heads-up e incluir o título/nome, ícone e texto conforme documentado nas APIs do Android.

O Android inclui APIs do serviço de listener de notificações que permitem que os apps (uma vez 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 corretamente e rapidamente para 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 que oferecem suporte ao recurso Não perturbe precisam atender aos seguintes requisitos:

  • PRECISA implementar uma atividade que responda à intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, que, para implementações com UI_MODE_TYPE_NORMAL, PRECISA ser uma atividade em que o usuário possa conceder ou negar o acesso do app às configurações da política de DND.
  • É OBRIGATÓRIO, quando a implementação do dispositivo oferece uma forma de o usuário permitir ou negar que apps de terceiros acessem a configuração da política de DND, mostrar as regras automáticas de DND criadas por apps, além das regras predefinidas e criadas pelo usuário.
  • PRECISA honrar os valores suppressedVisualEffects transmitidos pelo NotificationManager.Policy e, se um app tiver definido qualquer uma das flags SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, ele PRECISA indicar ao usuário que os efeitos visuais foram suprimidos no menu de configurações do DND.

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

As implementações de dispositivos Android DEVEM incluir a pesquisa global, uma interface de usuário de pesquisa única, compartilhada e em todo o sistema, capaz de sugerir resultados em tempo real em resposta à entrada do usuário. As implementações de dispositivos devem implementar as APIs que permitem que os desenvolvedores reutilizem essa interface do usuário para oferecer a 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 nenhum aplicativo de terceiros que use essa funcionalidade estiver instalado, o comportamento padrão DEVE ser mostrar os resultados e as sugestões do mecanismo de pesquisa da Web.

As implementações de dispositivos Android DEVEM e as implementações do Android Automotive PRECISAM 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 Assist precisam indicar claramente ao usuário final quando o contexto é compartilhado, mostrando uma luz branca ao redor das bordas da tela. Para garantir uma visibilidade clara ao usuário final, a indicação PRECISA atender ou exceder a duração e o brilho da implementação do Projeto Android Open Source.

3.8.5. Avisos

Os aplicativos podem usar a API "Toast" para mostrar strings curtas não modais ao usuário final que desaparecem após um breve período. As implementações de dispositivos precisam mostrar os avisos dos aplicativos aos usuários finais de forma bem visível.

3.8.6. Temas

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

O Android inclui uma família de temas "Holo" como um conjunto de estilos definidos para que os desenvolvedores de aplicativos os usem para corresponder ao tema e aparência do Holo, conforme definido pelo SDK do Android. As implementações de dispositivos NÃO PODEM alterar nenhum dos atributos do tema Holo expostos aos aplicativos.

O Android inclui uma família de temas "Material" como um conjunto de estilos definidos para que os desenvolvedores de apps possam usar se quiserem combinar a aparência e a sensação do tema de design em uma ampla variedade de tipos de dispositivos Android. As implementações de dispositivos precisam oferecer suporte à família de temas "Material" e não podem alterar nenhum dos atributos do tema Material ou os recursos expostos aos aplicativos.

O Android também inclui uma família de temas "Padrão do dispositivo" como um conjunto de estilos definidos para que os desenvolvedores de apps possam usar se quiserem combinar a aparência e a sensação do tema do dispositivo, conforme definido pelo implementador do dispositivo. As implementações de dispositivos PODEM modificar os atributos do tema padrão do dispositivo expostos aos apps.

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 oferecer uma experiência consistente aos desenvolvedores nessa configuração, é importante manter o estilo do ícone da barra de status 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 um app solicite uma barra de status clara usando a flag 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. Os planos de fundo animados são animações, padrões ou imagens semelhantes com recursos de entrada limitados que aparecem como um plano de fundo, atrás de outros aplicativos.

O hardware é considerado capaz de executar papéis de parede animados de forma confiável se ele puder executar todos os papéis de parede animados, sem limitações de funcionalidade, a uma taxa de frames razoável sem efeitos adversos em outros aplicativos. Se as limitações do hardware causarem falhas em planos de fundo e/ou aplicativos, mal funcionamento, consumo excessivo de bateria ou CPU ou execução com taxas de frames inaceitáveis, o hardware será considerado incapaz de executar o plano de fundo em tempo real. Por exemplo, alguns planos de fundo animados podem usar um contexto OpenGL 2.0 ou 3.x para renderizar o conteúdo. O papel de parede animado não será executado de forma confiável em hardware que não oferece suporte a vários contextos OpenGL, porque o uso de um contexto OpenGL pode entrar em conflito com outros aplicativos que também usam um contexto OpenGL.

As implementações de dispositivos capazes de executar papéis de parede animados de forma confiável, conforme descrito acima, DEVEM implementar papéis de parede animados e, quando implementadas, DEVEM informar a flag de recurso da plataforma android.software.live_wallpaper.

3.8.8. Troca de atividades

Como a tecla de navegação de função recente é OPCIONAL, o requisito para implementar a tela de visão geral é OPCIONAL para implementações do Android Watch e do Android Automotive e RECOMENDADO para dispositivos Android TV. Ainda precisa haver um método para alternar entre atividades nas implementações do Android Automotive.

O código-fonte upstream do Android inclui a tela de visão geral, uma interface do usuário no nível do sistema para alternar tarefas e mostrar atividades e tarefas acessadas recentemente usando uma imagem em miniatura do estado gráfico do aplicativo no momento em que o usuário saiu dele pela última vez. As implementações de dispositivos que incluem a tecla de navegação de função recente, conforme detalhado na seção 7.2.3, PODEM alterar a interface, mas PRECISAM atender aos seguintes requisitos:

  • É PRECISO oferecer suporte a até 6 atividades exibidas.
  • DEVE mostrar 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 o recurso.
  • DEVE mostrar a cor, o ícone e o título da tela em destaques recentes.
  • DEVE mostrar um recurso de fechamento ("x"), mas PODE atrasar isso até que o usuário interaja com as telas.
  • DEVE implementar um atalho para alternar facilmente para a atividade anterior
  • PODE exibir afiliadas recentes como um grupo que se move junto.
  • DEVE acionar a ação de troca rápida entre os dois apps usados mais recentemente quando a tecla de função de apps recentes for tocada duas vezes.
  • DEVE acionar o modo de várias janelas de tela dividida, se houver suporte, quando a tecla de funções recentes for pressionada por muito tempo.

É ALTAMENTE RECOMENDÁVEL que as implementações de dispositivos usem a interface do usuário upstream do Android (ou uma interface semelhante baseada em miniaturas) para a tela de visão geral.

3.8.9. Gerenciamento de entrada

O Android inclui suporte para gerenciamento de entrada e editores de método de entrada de terceiros. As implementações de dispositivo que permitem que os usuários usem métodos de entrada de terceiros no dispositivo PRECISAM declarar o recurso da plataforma android.software.input_methods e oferecer suporte a APIs IME, conforme definido na documentação do SDK do Android.

As implementações de dispositivo 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_SETTINGS.

3.8.10. Controle de mídia na tela de bloqueio

A API de cliente de controle remoto foi descontinuada no Android 5.0 em favor do modelo de notificação de mídia, que permite que os aplicativos de mídia sejam integrados aos controles de reprodução exibidos na tela de bloqueio. As implementações de dispositivos que oferecem suporte a uma tela de bloqueio, a menos que sejam uma implementação do Android Automotive ou do relógio, PRECISAM mostrar as notificações da tela de bloqueio, incluindo o modelo de notificação de mídia.

3.8.11. Protetores de tela (antes chamados de Sonhos)

O Android inclui suporte a proteções de tela interativas, anteriormente chamadas de "Sonhos". Os protetores de tela permitem que os usuários interajam com aplicativos quando um dispositivo conectado a uma fonte de energia está ocioso ou acoplado em uma base de mesa. Os dispositivos Android Watch PODEM implementar protetores de tela, mas outros tipos de implementações de dispositivos PRECISAM incluir suporte a protetores de tela e oferecer uma opção de configurações para que os usuários configurem protetores de tela em resposta à intent android.settings.DREAM_SETTINGS.

3.8.12. Local

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 mostrados no menu "Localização" em "Configurações".

3.8.13. Unicode e fonte

O Android inclui suporte aos caracteres emoji definidos no Unicode 9.0. Todas as implementações de dispositivo precisam ser capazes de renderizar esses caracteres de emoji em glifos coloridos. Quando as implementações de dispositivo Android incluem um IME, ele precisa fornecer um método de entrada para esses caracteres de emoji.

Dispositivos portáteis Android precisam oferecer suporte a emojis de diferentes famílias e tons de pele, conforme especificado no Relatório técnico Unicode 51.

O Android inclui suporte para 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. Todos eles precisam ser incluídos para os idiomas disponíveis no dispositivo e para a cobertura completa do Unicode 7.0 em latim, grego e cirílico, incluindo os intervalos de latim estendido A, B, C e D e todos os glifos no bloco de símbolos de moeda do Unicode 7.0.

3.8.14. Várias janelas

Uma implementação de dispositivo PODE escolher não implementar nenhum modo de várias janelas, mas, se tiver a capacidade de mostrar várias atividades ao mesmo tempo, PRECISA implementar esses modos de acordo com os comportamentos do aplicativo e as APIs descritas na documentação de suporte ao 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, explicitamente pelo atributo android:resizeableActivity ou implicitamente com a targetSdkVersion > 24. Os apps que definem esse atributo como "falso" no manifesto não podem ser iniciados no modo de várias janelas. Os 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 emitir um aviso de que o app pode não funcionar conforme o esperado no modo de várias janelas.
  • As implementações de dispositivos NÃO PODEM oferecer o modo de tela dividida ou de forma livre se a altura e a largura da tela forem menores que 440 dp.
  • As implementações de dispositivos com tamanho de tela xlarge DEVEM oferecer suporte ao modo de formato livre.
  • As implementações de dispositivos Android TV precisam oferecer suporte ao modo picture-in-picture (PIP) de várias janelas e colocar o PIP de várias janelas no canto superior direito quando ele estiver ATIVADO.
  • As implementações de dispositivos com suporte a várias janelas no modo PIP precisam alocar pelo menos 240x135 dp para a janela PIP.
  • Se o modo de várias janelas do PIP tiver suporte, a chave KeyEvent.KEYCODE_WINDOW PRECISA ser usada para controlar a janela 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 segurança executem funções de administração de dispositivos no nível do sistema, como a aplicação de políticas de senha ou a exclusão remota, usando a API Android Device Administration. As implementações de dispositivo precisam fornecer uma implementação da classe DevicePolicyManager. As implementações de dispositivos que oferecem suporte a uma tela de bloqueio segura PRECISAM implementar o conjunto completo de 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 dispositivo

3.9.1.1 Provisionamento de proprietário do dispositivo

Se uma implementação de dispositivo declarar o recurso android.software.device_admin, ela PRECISA implementar o provisionamento do app de proprietário do dispositivo de um cliente de política do dispositivo (DPC, na sigla em inglês) conforme indicado abaixo:

As implementações de dispositivos PODEM ter um aplicativo pré-instalado que executa funções de administração do dispositivo, mas ele NÃO PODE ser definido como o app de proprietário do dispositivo sem o consentimento ou a ação explícita 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á POSSÍVEL registrar um aplicativo de controle de política de dispositivo (DPC) como o 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 alinhada com a implementação do AOSP.

As implementações de dispositivos precisam fornecer as seguintes características de uso na interface do usuário "Configurações" para indicar ao usuário quando uma função específica do sistema foi desativada pelo controlador de política de dispositivo (DPC):

  • Um ícone consistente ou outra característica de uso (por exemplo, o ícone de informações do AOSP upstream) para representar quando uma configuração específica é restrita por um administrador de dispositivos.
  • Uma breve mensagem explicativa, fornecida pelo administrador do dispositivo pelo setShortSupportMessage.
  • Ícone do aplicativo DPC.

3.9.2 Suporte a perfil gerenciado

Os dispositivos com suporte a perfis gerenciados:

Os dispositivos com suporte a perfis gerenciados precisam:

  • Declare a flag de recurso da plataforma android.software.managed_users .
  • Suporte a perfis gerenciados pelas APIs android.app.admin.DevicePolicyManager.
  • Permita que apenas um perfil gerenciado seja criado.
  • Use um selo de ícone (semelhante ao selo de trabalho upstream do AOSP) para representar os aplicativos e widgets gerenciados e outros elementos da IU com selo, como "Recentes" e "Notificações".
  • Mostrar 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 uma mensagem curta 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 característica visual no "Chooser" de intent para permitir que o usuário encaminhe a intent do perfil gerenciado para o usuário principal ou vice-versa, se permitido pelo Device Policy Controller.
  • Quando um perfil gerenciado existir, exponha as seguintes affordances do usuário para o usuário principal e o perfil gerenciado:
    • Contabilização separada para bateria, localização, dados móveis e uso de armazenamento do usuário principal e do perfil gerenciado.
    • Gerenciamento independente de aplicativos de VPN instalados no usuário principal ou no perfil gerenciado.
    • Gerenciamento independente de aplicativos instalados no usuário principal ou perfil gerenciado.
    • Gerenciamento independente de contas no perfil do usuário principal ou gerenciado.
  • Garanta que o discador, os contatos e os apps de mensagens pré-instalados possam pesquisar e consultar as informações do autor da chamada do perfil gerenciado (se houver) e do perfil principal, se o Device Policy Controller permitir. Quando os contatos do perfil gerenciado são mostrados no registro de chamadas pré-instalado, na interface de chamada, nas notificações de chamadas em andamento e perdidas, nos contatos e nos apps de mensagens, eles precisam ter o mesmo selo usado para indicar aplicativos de perfil gerenciado.
  • É necessário garantir que ele atenda a todos os requisitos de segurança aplicáveis a um dispositivo com vários usuários ativados (consulte a seção 9.5), mesmo que o perfil gerenciado não seja contado como outro usuário além do principal.
  • Suporte para especificar uma tela de bloqueio separada que atenda aos seguintes requisitos para conceder acesso a apps executados em um perfil gerenciado.
    • As implementações de dispositivos precisam respeitar a intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD e mostrar uma interface para configurar uma credencial de tela de bloqueio separada para o perfil gerenciado.
    • As credenciais da tela de bloqueio do perfil gerenciado PRECISAM usar os mesmos mecanismos de armazenamento e gerenciamento de credenciais do perfil pai, conforme documentado no site do projeto Android Open Source.
    • As políticas de senha do DPC precisam ser aplicadas apenas às credenciais da tela de bloqueio do perfil gerenciado, a menos que sejam chamadas pela instância DevicePolicyManager retornada por getParentProfileInstance.

3.10. Acessibilidade

O Android oferece uma camada de acessibilidade que ajuda usuários com deficiência a navegar pelos dispositivos com mais facilidade. Além disso, o Android oferece APIs da plataforma que permitem que as implementações de serviços de acessibilidade recebam callbacks para eventos do usuário e do sistema e gerem mecanismos de feedback alternativos, como texto para fala, feedback tátil e navegação por trackball/d-pad.

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

  • As implementações do 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 o 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 dispositivo (exceto o Android Automotive) precisam oferecer suporte a implementações de serviços de acessibilidade de terceiros usando as APIs android.accessibilityservice.
  • As implementações de dispositivo (exceto o Android Automotive) PRECISAM gerar eventos de acessibilidade e enviá-los a todas as implementações de AccessibilityService registradas de maneira consistente com a implementação padrão do Android

  • As 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 serviços de acessibilidade e mostrar essa interface em resposta à intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

  • 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 com funcionalidade semelhante ou superior aos serviços de acessibilidade do TalkBack** e do Switch Access (https://github.com/google/talkback).

  • Dispositivos Android Watch com saída de áudio DEVEM fornecer implementações de um serviço de acessibilidade no dispositivo com funcionalidade semelhante ou superior ao serviço de acessibilidade do TalkBack (https://github.com/google/talkback).
  • As implementações de dispositivos PRECISAM fornecer um mecanismo no fluxo de configuração pronto para uso para que os usuários ativem serviços de acessibilidade relevantes, além de opções para ajustar o tamanho da fonte, o tamanho da tela e os gestos de ampliação.

** Para idiomas com suporte à Text-to-Speech.

Além disso, se houver um serviço de acessibilidade pré-carregado, ele PRECISA ser um app compatível com a inicialização direta {directBootAware} se o dispositivo tiver armazenamento criptografado usando a criptografia baseada em arquivo (FBE).

3.11. Conversão de texto em voz

O Android inclui APIs que permitem que os aplicativos usem serviços de conversão de texto em voz (TTS) e que os provedores de serviços ofereçam implementações desses serviços. As implementações de dispositivos que informam o recurso android.hardware.audio.output PRECISAM atender a esses requisitos relacionados ao framework TTS do Android.

Implementações do Android Automotive:

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

Todas as outras implementações de dispositivo:

  • PRECISA oferecer suporte às APIs do framework TTS do Android e DEVE incluir um mecanismo TTS com suporte aos idiomas disponíveis no dispositivo. O software de código aberto upstream do Android inclui uma implementação de mecanismo de TTS com recursos completos.
  • PRECISA oferecer suporte à instalação de mecanismos de TTS de terceiros.
  • É PRECISO fornecer uma interface acessível ao usuário que permita a seleção de um mecanismo de TTS para uso no nível do sistema.

3.12. TV Input Framework

O Android TV Input Framework (TIF) simplifica o envio de conteúdo ao vivo para dispositivos Android TV. O TIF oferece uma API padrão para criar módulos de entrada que controlam dispositivos Android TV. As implementações de dispositivos Android TV precisam oferecer suporte ao TV Input Framework.

As implementações de dispositivos com suporte a 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 à TV ao vivo PRECISA ter um aplicativo de TV instalado. O Android Open Source Project fornece 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 de terceiros baseadas em TIF ( entradas de terceiros) sejam instaladas e gerenciadas.
  • As implementações de dispositivos PODEM fornecer uma 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 mostrar as entradas de terceiros mais do que uma única ação de navegação longe do app de TV (ou seja, expandir uma lista de entradas de terceiros do app de TV).

3.12.1.1. Guia de programação eletrônica

As implementações de dispositivos Android TV precisam mostrar uma sobreposição informativa e interativa, que precisa incluir um guia de programação eletrônica (EPG) gerado com base nos valores nos campos TvContract.Programs. A EPG PRECISA atender aos seguintes requisitos:

  • A EPG PRECISA mostrar informações de todas as entradas instaladas e de terceiros.
  • O EPG PODE fornecer uma separação visual entre as entradas instaladas e as entradas de terceiros.
  • A EPG RECOMENDA FORTEMENTE que as entradas instaladas e de terceiros sejam mostradas com a mesma importância. A EPG NÃO PODE mostrar as entradas de terceiros a mais de uma ação de navegação das entradas instaladas na EPG.
  • Na mudança de canal, as implementações de dispositivo precisam mostrar os dados do EPG para o programa que está sendo reproduzido.

3.12.1.2. Navegação

O app de TV PRECISA permitir a navegação para as seguintes funções usando as teclas direcional, "Voltar" e "Início" nos dispositivos de entrada do dispositivo Android TV (ou seja, controle remoto, aplicativo de controle remoto ou controle de jogos):

  • Como mudar de canal de TV
  • Abertura da EPG
  • Como configurar e ajustar entradas de terceiros com base em TIF
  • Como abrir o menu "Configurações"

O app de TV DEVE transmitir eventos de tecla para entradas HDMI por CEC.

3.12.1.3. Vinculação de apps de entrada de TV

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

3.12.1.4. Mudança de horário

As implementações de dispositivos Android TV precisam oferecer suporte ao time-shifting, que permite que o usuário pause e retome o conteúdo ao vivo. As implementações de dispositivos precisam oferecer ao usuário uma maneira de pausar e retomar o programa que está sendo reproduzido, se o deslocamento no tempo estiver disponível.

3.12.1.5. Gravação de TV

É ALTAMENTE RECOMENDÁVEL que as implementações de dispositivos Android TV ofereçam suporte à gravação de TV. Se a entrada de TV for compatível com a gravação, a EPG PODERÁ oferecer uma maneira de gravar um programa se a gravação desse programa não for proibida. As implementações de dispositivos precisam fornecer uma interface do usuário para reproduzir programas gravados.

3.13. Configurações rápidas

As implementações de dispositivos Android DEVEM incluir um componente de interface de configurações rápidas que permita o acesso rápido a ações usadas com frequência ou necessárias com urgência.

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 da IU das Configurações rápidas. Se uma implementação de dispositivo tiver um componente de interface de configurações rápidas, ele:

  • DEVE permitir que o usuário adicione ou remova blocos de um app de terceiros nas Configurações rápidas.
  • NÃO PODE 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ções rápidas fornecidos pelo sistema.

3.14. APIs da interface do veículo

3.14.1. Interface de mídia do veículo

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

O framework da interface que oferece suporte a apps de terceiros que dependem do MediaBrowser e do MediaSession tem os seguintes requisitos visuais:

  • PRECISA exibir os ícones de MediaItem e de notificação inalterados.
  • PRECISA mostrar esses itens conforme descrito pela MediaSession, por exemplo, metadados, ícones, imagens.
  • É OBRIGATÓRIO mostrar o título do app.
  • PRECISA ter uma gaveta para apresentar a hierarquia do MediaBrowser.

4. Compatibilidade de empacotamento de apps

As implementações de dispositivos precisam instalar e executar arquivos ".apk" do Android gerados 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 .apk, Android Manifest, bytecode Dalvik ou bytecode RenderScript de forma a impedir a instalação e execução correta desses arquivos em outros dispositivos compatíveis.

5. Compatibilidade com multimídia

5.1. Codecs de mídia

Implementações de dispositivos:

  • PRECISA oferecer suporte aos formatos de mídia principais especificados na documentação do SDK do Android, exceto quando expressamente permitido neste documento.

  • PRECISA oferecer suporte aos formatos de mídia, codificadores, decodificadores, tipos de arquivo e formatos de contêiner definidos nas tabelas abaixo e informados pela MediaCodecList.

  • DEVE também ser capaz de decodificar todos os perfis informados no CamcorderProfile.

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

Os codecs PRECISAM ter como objetivo a latência mínima do codec. Em outras palavras, os codecs:

  • NÃO deve consumir e armazenar buffers de entrada e retornar buffers de entrada apenas uma vez processados
  • NÃO DEVE manter buffers decodificados por mais tempo do que o especificado pelo padrão (por exemplo, SPS).
  • NÃO segure buffers codificados por mais tempo do que o necessário pela estrutura GOP.

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

Nem o Google nem a Open Handset Alliance representam que esses codecs estão livres de patentes de terceiros. Quem pretende usar esse código-fonte em produtos de hardware ou software deve saber que as implementações desse código, incluindo em software de código aberto ou shareware, podem exigir licenças de patente dos detentores relevantes.

5.1.1. Codecs de áudio

Formato/Codec Codificador Decodificador Detalhes Tipos de arquivo/formatos de contêiner compatíveis
Perfil MPEG-4 AAC
(AAC LC) 		OBRIGATÓRIO 1 REQUIRED Suporte a 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)
  • AAC bruto ADTS (.aac, decodificado no Android 3.1+, codificado no Android 4.0+, sem suporte a ADIF)
  • MPEG-TS (.ts, não pesquisável, Android 3.0+)
Perfil MPEG-4 HE AAC (AAC+) OBRIGATÓRIO 1
(Android 4.1+) 		REQUIRED Suporte a conteúdo mono/estéreo/5.0/5.1 2 com taxas de amostragem padrão de 16 a 48 kHz.
Perfil MPEG-4 HE AACv2
(AAC+ aprimorado) 		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+) 		OBRIGATÓRIO
(Android 4.1+) 		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+) 		Mono/estéreo (sem multicanal). Taxas de amostragem de até 48 kHz (mas o valor de até 44,1 kHz é RECOMENDADO em dispositivos com saída de 44,1 kHz, já que o redutor de 48 para 44,1 kHz não inclui um filtro passa baixa). RECOMENDADO 16 bits; sem pontilhamento aplicado para 24 bits. Somente FLAC (.flac)
MP3 REQUIRED Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8-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 mais recente) 		REQUIRED PCM linear de 16 bits (taxas até o limite de hardware). Os dispositivos PRECISAM oferecer suporte a taxas de amostragem para gravação PCM bruta em frequências de 8.000, 11.025, 16.000 e 44.100 Hz. WAVE (.wav)
Opus OBRIGATÓRIO
(Android 5.0+) 		Matroska (.mkv), Ogg(.ogg)

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

2 A gravação ou reprodução PODE ser realizada em mono ou estéreo, mas a decodificação de buffers de entrada AAC de streams multicanais (ou seja, mais de dois canais) para PCM pelo decodificador de áudio AAC padrão na API android.media.MediaCodec precisa ter suporte ao seguinte:

  • a decodificação é realizada sem downmix (por exemplo, um stream AAC 5.0 precisa ser decodificado para cinco canais de PCM, um stream AAC 5.1 precisa ser decodificado para seis canais de PCM),
  • metadados de faixa dinâmica, conforme definido em "Controle de faixa dinâmica (DRC)" na ISO/IEC 14496-3, e as chaves DRC android.media.MediaFormat para configurar os comportamentos relacionados ao alcance dinâmico do decodificador de áudio. As chaves AAC DRC foram introduzidas na API 21 e são: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL e KEY_AAC_ENCODED_TARGET_LEVEL.

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

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

5.1.2. Codecs de imagem

Formato/Codec Codificador Decodificador Detalhes Tipos de arquivo/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

  • Os codecs que anunciam suporte ao perfil HDR precisam oferecer suporte à análise e ao processamento de metadados estáticos HDR.

  • Se um codec de mídia anunciar suporte à atualização interna, ele PRECISA oferecer suporte aos períodos de atualização na faixa de 10 a 60 frames e operar com precisão em 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 possível compactado e descompactado, conforme determinado pelo padrão e pela configuração, mas sem alocar em excesso.

  • Os codificadores e decodificadores de vídeo precisam oferecer suporte ao formato de cores flexível YUV420 (COLOR_FormatYUV420Flexible).

Formato/Codec Codificador Decodificador Detalhes Tipos de arquivo/
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, AAC exclusivo de áudio, não pesquisável, Android 3.0+)
H.265 HEVC OBRIGATÓRIO 5 Consulte a seção 5.3 para mais detalhes. MPEG-4 (.mp4)
MPEG-2 ALTAMENTE RECOMENDADO 6 Perfil principal MPEG2-TS
MPEG-4 SP OBRIGATÓRIO 2 3GPP (.3gp)
VP8 3 OBRIGATÓRIO 2
(Android 4.3 ou mais recente) 		OBRIGATÓRIO 2
(Android 2.3.3+) 		Consulte as seções 5.2 e 5.3 para mais detalhes.
VP9 OBRIGATÓRIO 2
(Android 4.4+) 		Consulte a seção 5.3 para mais detalhes.

1 Obrigatório para implementações de dispositivos que incluem hardware de 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 uma qualidade aceitável de streaming de vídeo da Web e serviços de videoconferência, as implementações de dispositivos PRECISAM usar um codec VP8 de hardware que atenda aos requisitos.

4 As implementações de dispositivos precisam oferecer suporte à gravação de arquivos Matroska WebM.

5 ALTAMENTE RECOMENDADO para Android Automotive, opcional para Android Watch e obrigatório para todos os outros tipos de dispositivo.

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

5.2. Codificação de vídeo

Os codecs de vídeo são opcionais para implementações de dispositivos Android Watch.

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

  • PRECISA oferecer suporte a taxas de bits configuráveis dinamicamente.
  • DEVE oferecer suporte a taxas de frames variáveis, em que o codificador de vídeo PRECISA 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 nessa duração.

O codificador de vídeo H.263 e MPEG-4 DEVE oferecer suporte a taxas de bits configuráveis dinamicamente.

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

  • Ele NÃO DEVE ser mais de 15% sobre a taxa de bits entre intervalos intraframe (I-frame).
  • Ele NÃO deve ser maior que ~100% do bitrate em uma janela deslizante de 1 segundo.

5.2.1. H.263

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

5.2.2. H-264

Implementações de dispositivos Android com suporte ao codec H.264:

  • É PRECISO oferecer suporte ao perfil de referência de nível 3.
    No entanto, o suporte a ASO (ordenação arbitrária de fatias), FMO (ordenação flexível de macrobloqueio) e RS (fatias redundantes) é OPCIONAL. Além disso, para manter a compatibilidade com outros dispositivos Android, é RECOMENDÁVEL que os codificadores não usem ASO, FMO e RS para o perfil de referência.
  • PRECISA oferecer suporte aos perfis de codificação de vídeo SD (definição padrão) na tabela a seguir.
  • DEVE oferecer suporte ao nível 4 do perfil principal.
  • DEVE oferecer suporte aos perfis de codificação de vídeo em HD (alta definição), conforme indicado na tabela a seguir.
  • Além disso, é ALTAMENTE RECOMENDÁVEL que os dispositivos Android TV codifiquem vídeos HD 1080p a 30 fps.
SD (baixa qualidade) SD (alta qualidade) HD 720p 1 HD 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 tiver suporte de hardware, mas ALTAMENTE RECOMENDADO para dispositivos Android TV.

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 aos seguintes perfis de codificação de vídeo HD:

SD (baixa qualidade) SD (alta qualidade) HD 720p 1 HD 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 tiver suporte de hardware.

5.3. Decodificação de vídeo

Os codecs de vídeo são opcionais para implementações de dispositivos Android Watch.

Implementações de dispositivos:

  • É necessário oferecer suporte à resolução de vídeo dinâmica e à alternância de frame rate por meio das APIs padrão do Android no mesmo fluxo para todos os codecs VP8, VP9, H.264 e H.265 em tempo real e com a resolução máxima compatível com cada codec no dispositivo.

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

  • É PRECISO fornecer um extrator com tecnologia Dolby Vision.

  • PRECISA exibir corretamente o conteúdo do Dolby Vision na tela do dispositivo ou em uma porta de saída de vídeo padrão, como HDMI.

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

5.3.1. MPEG-2

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

5.3.2. H.263

As implementações de dispositivos Android com decodificadores H.263 precisam oferecer suporte aos níveis 30 e 45 do perfil de referência.

5.3.3. MPEG-4

As implementações de dispositivos Android com decodificadores MPEG-4 precisam oferecer suporte ao perfil simples de nível 3.

5.3.4. H.264

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

  • PRECISA oferecer suporte ao perfil principal de nível 3.1 e ao perfil de referência.
    O suporte a ASO (ordenação arbitrária de fatias), FMO (ordenação flexível de macrobloqueio) e RS (fatias 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 de alta definição, conforme indicado na tabela a seguir.
  • Além disso, os dispositivos Android TV:
    • É PRECISO oferecer suporte ao perfil de nível alto 4.2 e ao perfil de decodificação HD 1080p60.
    • PRECISA ser capaz de decodificar vídeos com os dois perfis de alta definição, conforme indicado na tabela a seguir, e codificados com o perfil de referência, o perfil principal ou o perfil de alta definição de nível 4.2
SD (baixa qualidade) SD (alta qualidade) HD 720p 1 HD 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 qps (60 qps 2)
Taxa de bits do vídeo 800 Kbps 2 Mbps 8 Mbps 20 Mbps

1 OBRIGATÓRIO para quando a altura informada 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 TV.

5.3.5. H.265 (HEVC)

Implementações de dispositivos Android, quando oferecem suporte ao codec H.265, conforme descrito na seção 5.1.3:

  • É PRECISO oferecer suporte ao nível principal do perfil principal de nível 3 e aos perfis de decodificação de vídeo SD, conforme indicado na tabela a seguir.
  • DEVE oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir.
  • É PRECISO oferecer suporte aos perfis de decodificação em HD, conforme indicado na tabela a seguir, se houver um decodificador de hardware.
  • Além disso, os dispositivos Android TV:
  • É necessário oferecer suporte ao perfil de decodificação HD 720p.
  • É ALTAMENTE RECOMENDADO oferecer suporte ao perfil de decodificação HD 1080p. Se o perfil de decodificação HD 1080p tiver suporte, 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 compatível, o codec PRECISA ser compatível com o 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 px 720 x 480 px 1.280 x 720 px 1.920 x 1.080 px 3840 x 2160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 qps (60 qps 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 TV com decodificação de hardware H.265.

5.3.6. VP8

Implementações de dispositivos Android, quando oferecem suporte ao codec VP8, conforme descrito na seção 5.1.3:

  • PRECISA oferecer suporte aos perfis de decodificação SD na tabela a seguir.
  • DEVE oferecer suporte aos perfis de decodificação em HD na tabela a seguir.
  • Os dispositivos Android TV precisam oferecer suporte ao perfil de decodificação HD 1080p60.
SD (baixa qualidade) SD (alta qualidade) HD 720p 1 HD 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 qps 2) 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 informada 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 TV.

5.3.7. VP9

Implementações de dispositivos Android, quando oferecem suporte ao codec VP9, conforme descrito na seção 5.1.3:

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

  • Além disso, os dispositivos Android TV:

    • É necessário oferecer suporte ao perfil de decodificação HD 720p.
    • É ALTAMENTE RECOMENDADO oferecer suporte ao perfil de decodificação HD 1080p.
    • DEVE oferecer suporte ao perfil de decodificação UHD. Se o perfil de decodificação de vídeo UHD tiver suporte, ele PRECISA ter suporte à profundidade de cor de 8 bits e DEVE ter suporte ao perfil VP9 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 3840 x 2160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 qps (60 qps 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 TV com decodificação de hardware VP9.

5.4. Gravação em áudio

Embora alguns dos requisitos descritos nesta seção sejam indicados como "DEVE" desde o Android 4.3, a definição de compatibilidade para uma versão futura vai mudar isso para "PRECISA". É ALTAMENTE RECOMENDÁVEL que os dispositivos Android atuais e novos atendam a esses requisitos indicados como "DEVE", caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

5.4.1. Captura de áudio bruto

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

  • Formato : PCM linear, 16 bits
  • Taxas de amostragem : 8.000, 11.025, 16.000, 44.100
  • Canais : mono

A captura para as taxas de amostragem acima PRECISA ser feita sem upsampling, e qualquer downsampling PRECISA incluir um filtro anti-aliasing adequado.

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

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

Se a captura para as taxas de amostragem acima for aceita, ela PRECISA ser feita sem upsampling em qualquer proporção maior que 16000:22050 ou 44100:48000. Qualquer amostragem de upsampling ou downsampling 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ça a gravar um stream de áudio usando a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

  • O dispositivo DEVE apresentar uma amplitude aproximadamente plana em relação às características de frequência: especificamente, ±3 dB, de 100 Hz a 4.000 Hz.
  • A sensibilidade da entrada de áudio PRECISA ser definida de modo que uma fonte de nível de potência sonora (SPL) de 90 dB a 1.000 Hz produza um RMS de 2.500 para amostras de 16 bits.
  • Os níveis de amplitude do PCM precisam acompanhar linearmente as mudanças de SPL de entrada em pelo menos uma faixa de 30 dB de -18 dB a +12 dB em relação a 90 dB SPL no microfone.
  • A distorção harmônica total DEVE ser menor que 1% para 1 kHz em 90 dB SPL de nível de entrada no microfone.
  • O processamento de redução de ruído, se presente, PRECISA ser desativado.
  • O controle de ganho automático, se presente, PRECISA ser desativado.

Se a plataforma oferecer suporte a 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ídos PRECISA identificar de forma exclusiva cada implementação da tecnologia de supressão de ruídos.

5.4.3. Captura para redirecionamento da 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 use a API android.media.AudioRecord para gravar dessa fonte de áudio, ele possa capturar uma mistura de todos os streams de áudio, exceto os seguintes:

  • STREAM_RING
  • STREAM_ALARM
  • STREAM_NOTIFICATION

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, 16 bits
  • Taxas de amostragem : 8.000, 11.025, 16.000, 22.050, 32.000, 44.100
  • 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 para efeitos de áudio para implementações de dispositivos. Implementações de dispositivos que declaram o recurso android.hardware.audio.output:

  • PRECISA oferecer suporte às implementações EFFECT_TYPE_EQUALIZER e EFFECT_TYPE_LOUDNESS_ENHANCER controláveis pelas subclasses AudioEffect Equalizer e LoudnessEnhancer.
  • PRECISA oferecer suporte à implementação da API do visualizador, controlável pela classe Visualizer.
  • DEVE oferecer suporte às implementações EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controláveis pelas subclasses BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer do AudioEffect.

5.5.3. Volume da saída de áudio

As implementações de dispositivos Android TV precisam incluir suporte para o Volume principal do sistema e a atenuação do volume de saída de áudio digital nas saídas compatíveis, exceto para a saída de passagem de áudio compactado (em que nenhuma decodificação de áudio é feita no dispositivo).

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

5.6. Latência de áudio

A latência de áudio é o tempo de atraso enquanto um sinal de áudio passa por um sistema. Muitas classes de aplicativos dependem de latências curtas para conseguir 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 o momento em que o som correspondente é apresentado ao ambiente em um transdutor no dispositivo ou o sinal sai do dispositivo por uma porta e pode ser observado externamente.
  • Latência de saída fria . A latência de saída do primeiro frame, quando o sistema de saída de áudio estava inativo e desligado antes da solicitação.
  • latência de saída contínua . A latência de saída para frames subsequentes, depois que o dispositivo está reproduzindo áudio.
  • latência de entrada . O intervalo entre o momento em que um som é apresentado pelo ambiente ao dispositivo em um transdutor no dispositivo ou o sinal entra no dispositivo por uma porta e o momento em que um aplicativo lê o frame correspondente de dados codificados em PCM.
  • Entrada perdida . A parte inicial de um sinal de entrada que está indisponível ou não pode ser usado.
  • Latência de entrada fria . A soma do tempo de entrada perdido e a latência de entrada do primeiro frame, quando o sistema de entrada de áudio estava inativo e desligado antes da solicitação.
  • latente de entrada contínua . A latência de entrada para frames subsequentes, enquanto o dispositivo está capturando áudio.
  • Jitter de saída fria . A variabilidade entre medições separadas de valores de latência de saída fria.
  • Jitter de entrada fria . A variabilidade entre medições separadas de valores de latência de entrada fria.
  • 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 sinal e mitigue a diferença de fase entre os streams de entrada e saída.
  • API da fila de buffer PCM do OpenSL ES . O conjunto de APIs OpenSL ES relacionadas ao PCM no Android NDK.

As implementações de dispositivos que declaram android.hardware.audio.output são ALTAMENTE RECOMENDADAS 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 o jitter de 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 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 com suporte, é ALTAMENTE RECOMENDÁVEL informar o suporte a áudio de baixa latência, informando o recurso android.hardware.audio.low_latency pela classe android.content.pm.PackageManager. Por outro lado, se a implementação do dispositivo não atender a esses requisitos, ele NÃO PODERÁ informar suporte para áudio de baixa latência.

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

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

5.7. Protocolos de rede

Os dispositivos precisam oferecer suporte aos protocolos de rede de mídia para reprodução de áudio e vídeo, conforme especificado na documentação do SDK do Android. Especificamente, os dispositivos precisam oferecer suporte aos seguintes protocolos de rede de mídia:

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

Codecs de áudio:

  • AAC
Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes dele.
AAC com enquadramento ADTS e tags ID3 ISO 13818-7 Consulte a seção 5.1.1 para saber mais sobre o AAC e as variantes
WebVTT WebVTT

  • RTSP (RTP, SDP)

    O perfil de áudio e vídeo RTP e os codecs relacionados a seguir precisam ter suporte. Para exceções, consulte as notas de rodapé da tabela na seção 5.1.

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

5.8. Secure Media

As implementações de dispositivos que oferecem suporte à saída de vídeo segura e podem oferecer suporte a superfícies seguras PRECISAM declarar suporte a Display.FLAG_SECURE. Implementações de dispositivos que declaram suporte para Display.FLAG_SECURE, se forem compatíveis com um protocolo de exibição sem fio, PRECISAM proteger o link com um mecanismo criptograficamente seguro, como HDCP 2.x ou mais recente para telas sem fio Miracast. Da mesma forma, se eles oferecem suporte a uma tela externa com fio, as implementações do dispositivo precisam oferecer suporte a HDCP 1.2 ou mais recente. As implementações de dispositivos Android TV precisam oferecer suporte à HDCP 2.2 para dispositivos com resolução de 4K e à HDCP 1.4 ou mais recente para resoluções mais baixas. A implementação de código aberto upstream do Android inclui suporte a telas sem fio (Miracast) e com fio (HDMI) que atendem a esse requisito.

5.9. Interface digital para instrumentos musicais (MIDI)

Se uma implementação de dispositivo oferece suporte ao transporte de software MIDI entre apps (dispositivos MIDI virtuais) e oferece suporte a MIDI por todos os seguintes transportes de hardware compatíveis com MIDI para os quais ele fornece conectividade genérica que não é MIDI, é ALTAMENTE RECOMENDÁVEL informar o suporte ao recurso android.software.midi pela classe android.content.pm.PackageManager.

Os transportes de hardware com capacidade MIDI são:

  • Modo de host USB (seção 7.7 USB)
  • Modo de periférico USB (seção 7.7 USB)
  • MIDI por Bluetooth LE atuando no papel central (seção 7.4.3 Bluetooth)

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

5.10. Áudio profissional

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

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

As latências e os requisitos de áudio USB precisam ser atendidos usando a API de fila de buffer PCM do OpenSL ES.

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

  • Ofereça um nível sustentável de desempenho da CPU enquanto o áudio estiver ativo.
  • Minimizar a imprecisão e a deriva do relógio de áudio em relação ao horário padrão.
  • Minimiza a deriva do relógio de áudio em relação à CLOCK_MONOTONIC da CPU quando ambos estão ativos.
  • Minimizar a latência de áudio em transdutores no dispositivo.
  • Minimizar a latência de áudio por áudio digital USB.
  • Documente as medições de latência do áudio em todos os caminhos.
  • Minimize o jitter nos tempos de entrada de callback de conclusão do buffer de áudio, porque isso afeta a porcentagem utilizável da largura de banda da CPU pelo callback.
  • Não apresentar áudio com underruns (saída) ou overruns (entrada) no uso normal com a latência informada.
  • Não há diferença de latência entre os canais.
  • Minimizar a latência média do MIDI em todos os transportes.
  • Minimizar a variabilidade da latência MIDI sob carga (jitter) em todos os transportes.
  • Forneça marcações de tempo MIDI precisas em todos os transportes.
  • Minimize o ruído do sinal de áudio em transdutores no dispositivo, incluindo o período imediatamente após a inicialização a frio.
  • Forneça zero diferença de relógio de áudio entre os lados de entrada e saída dos endpoints correspondentes, quando ambos estiverem ativos. Exemplos de pontos finais correspondentes incluem o microfone e o alto-falante no dispositivo ou a entrada e a saída do conector de áudio.
  • Processe callbacks de conclusão de 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 entre no 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 inserir o callback de entrada para permitir que o aplicativo tenha um tempo consistente dos lados de entrada e saída.
  • Minimizar a diferença de fase entre o buffer de áudio HAL para os lados de entrada e saída dos endpoints correspondentes.
  • Minimizar a latência de toque.
  • Minimizar a variabilidade da latência do toque sob carga (jitter).

5.11. Captura para "Não processado"

A partir do Android 7.0, uma nova fonte de gravação foi adicionada. Ele pode ser acessado usando a origem 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 o suporte à fonte de áudio não processada pela propriedade android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED:

  • O dispositivo PRECISA apresentar características aproximadamente planas de amplitude versus frequência na faixa de frequência média: especificamente ±10 dB de 100 Hz a 7.000 Hz.

  • O dispositivo PRECISA apresentar 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 média frequência.

  • O dispositivo PRECISA apresentar 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 da entrada de áudio PRECISA ser definida de modo que uma fonte de tom senoidal de 1.000 Hz reproduzida a 94 dB de nível de pressão sonora (SPL) produza uma resposta com RMS de 520 para amostras de 16 bits (ou -36 dB de escala completa para amostras de ponto flutuante/dupla precisão).

  • 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 90 dB SPL de nível de entrada no microfone.

  • O único processamento de indicador permitido no caminho é um multiplicador de nível para levar o nível ao 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 passa-alta ou cancelamento de eco. Se houver algum processamento de sinal na arquitetura por qualquer motivo, ele PRECISA ser desativado e introduzir 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.

Para várias configurações de microfone, esses requisitos se aplicam a cada microfone.

É ALTAMENTE RECOMENDÁVEL que um dispositivo atenda a tantos requisitos quanto possível para o caminho do sinal da fonte de gravação não processada. No entanto, um dispositivo precisa atender a todos os requisitos listados acima se ele afirma oferecer suporte à fonte de áudio não processada.

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

6.1. Ferramentas para desenvolvedores

As implementações de dispositivos precisam oferecer suporte às ferramentas para desenvolvedores do Android fornecidas no SDK do Android. Os dispositivos compatíveis com Android precisam ser compatíveis com:

  • Android Debug Bridge (adb)
    • As implementações de dispositivos precisam oferecer suporte a todas as funções do adb, conforme documentado no SDK do Android, incluindo dumpsys.
    • O daemon adb do dispositivo PRECISA estar inativo por padrão e PRECISA haver um mecanismo acessível ao usuário para ativar a ponte de depuração do Android. Se uma implementação de dispositivo omitir o modo de periférico USB, ela PRECISA implementar o Android Debug Bridge por uma rede local (como Ethernet ou 802.11).
    • O Android inclui suporte para adb seguro. O adb seguro ativa o adb em hosts autenticados conhecidos. As implementações de dispositivos precisam oferecer suporte ao adb seguro.
  • Serviço de monitoramento de depuração do Dalvik (ddms)
    • As implementações de dispositivos precisam oferecer suporte a todos os recursos do ddm, conforme documentado no SDK do Android.
    • Como o ddms usa o adb, o suporte a ele DEVE estar inativo por padrão, mas PRECISA ser compatível sempre que o usuário ativar a ponte de depuração do Android, como acima.
  • Monkey As implementações de dispositivo precisam incluir o framework Monkey e disponibilizá-lo para uso de aplicativos.
  • SysTrace
    • 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 é necessário ter um mecanismo acessível ao usuário para ativar o Systrace.
    • A maioria dos sistemas baseados em Linux e Apple Macintosh reconhecem dispositivos Android usando as ferramentas padrão do SDK Android, sem suporte adicional. No entanto, os sistemas Microsoft Windows geralmente exigem um driver para novos dispositivos Android. Por exemplo, novos IDs de fornecedor e, às vezes, novos IDs de dispositivo exigem drivers USB personalizados para sistemas Windows.
    • Se uma implementação de dispositivo não for reconhecida pela ferramenta adb conforme fornecido no SDK padrão do Android, os implementadores de dispositivo PRECISAM fornecer drivers do Windows que permitam que os desenvolvedores se conectem ao dispositivo usando o protocolo adb. Esses drivers precisam ser fornecidos para 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 configurem as configurações relacionadas ao desenvolvimento de apps. As implementações de dispositivos precisam respeitar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar as configurações relacionadas ao desenvolvimento do aplicativo. A implementação upstream do Android oculta o menu "Opções do desenvolvedor" por padrão e permite que os usuários iniciem as opções do desenvolvedor depois de pressionar sete (7) vezes no item de menu Configurações > Sobre o dispositivo > Número da versão. As implementações de dispositivos precisam oferecer 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 que seja consistente com a implementação upstream do Android.

As implementações do Android Automotive PODEM limitar o acesso ao menu "Opções do desenvolvedor" ocultando ou desativando o menu quando o veículo estiver em movimento.

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 (documentadas pelo SDK) para as APIs do componente ainda precisam ser apresentadas.
  • Os comportamentos da API precisam ser implementados como no-ops 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 sem operação 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 um cenário em que esses requisitos se aplicam é a API de telefonia: mesmo em dispositivos que não são smartphones, essas APIs precisam ser implementadas como no-ops razoáveis.

As implementações de dispositivos precisam informar de forma consistente informações precisas de configuração de hardware usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager para o mesmo impressão digital do build.

7.1. Tela e gráficos

O Android inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts da interface de forma adequada para o dispositivo, garantindo que os aplicativos de terceiros sejam executados corretamente em várias configurações de hardware. Os dispositivos precisam implementar essas APIs e comportamentos corretamente, conforme detalhado nesta seção.

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

  • tamanho físico diagonal . A distância em polegadas entre dois cantos opostos da parte iluminada da tela.
  • pontos por polegada (dpi) . O número de pixels englobados por uma extensão linear horizontal ou vertical de 1". Quando os valores de dpi são listados, tanto o dpi horizontal quanto o vertical precisam estar dentro do intervalo.
  • proporção . A proporção dos pixels da dimensão maior em relação à dimensão 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 * (density/160).

7.1.1. Configuração da tela

7.1.1.1. Tamanho da tela

Dispositivos Android Watch (detalhados na seção 2) PODEM ter tamanhos de tela menores, conforme descrito nesta seção.

O framework de interface do Android oferece suporte a vários tamanhos de tela diferentes 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 da tela correto, conforme definido na documentação do SDK do Android e determinado pela plataforma upstream do Android. Especificamente, as implementações de dispositivos precisam informar o tamanho correto da tela de acordo com as seguintes dimensões lógicas de tela (dp) independentes de densidade.

  • Os dispositivos precisam ter tamanhos de tela de pelo menos 426 dp x 320 dp (pequenos), a menos que sejam dispositivos Android Watch.
  • Os dispositivos que informam o tamanho da tela como "normal" PRECISAM ter tamanhos de tela de pelo menos 480 dp x 320 dp.
  • Os dispositivos que informam o tamanho da tela como "grande" precisam ter tamanhos de tela de pelo menos 640 dp x 480 dp.
  • Os dispositivos que informam o tamanho da tela "extra grande" precisam ter tamanhos de tela de pelo menos 960 dp x 720 dp.

Além disso:

  • Os dispositivos Android Watch precisam ter uma tela com o tamanho físico diagonal na faixa de 1,1 a 2,5 polegadas.
  • Os dispositivos Android Automotive precisam ter uma tela com tamanho de diagonal física igual ou superior a 15,24 cm.
  • Os dispositivos Android Automotive precisam ter uma 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 2,5 polegadas de tamanho físico na diagonal.

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

Os aplicativos podem indicar quais tamanhos de tela eles oferecem suporte pelo atributo <supports-screens> no arquivo AndroidManifest.xml. As implementações de dispositivos precisam respeitar corretamente o suporte declarado pelos aplicativos a telas pequenas, normais, grandes e extra grandes, conforme descrito na documentação do SDK do Android.

7.1.1.2. Proporção da tela

Embora não haja restrição ao valor da proporção da tela física, a proporção da tela da superfície em que os apps de terceiros são renderizados e que pode ser derivada dos valores informados pela DisplayMetrics PRECISA atender aos seguintes requisitos:

  • Se o uiMode estiver configurado como UI_MODE_TYPE_WATCH, o valor da proporção poderá ser definido como 1,0 (1:1).
  • Se o app de terceiros indicar que ele pode ser redimensionado pelo atributo android:resizeableActivity, não haverá restrições ao 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 pelo valor de metadados maxAspectRatio.

7.1.1.3. Densidade da tela

O framework de IU do Android define um conjunto de densidades lógicas padrão para ajudar os desenvolvedores a segmentar os recursos do aplicativo. As implementações de dispositivos PRECISAM informar apenas uma das seguintes densidades lógicas do framework Android pelas APIs android.util.DisplayMetrics, PRECISAM executar aplicativos nessa densidade padrão e PRECISAM não mudar o valor a qualquer momento para a tela 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 essa densidade lógica reduza o tamanho da tela informado abaixo do mínimo suportado. 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 do que o menor tamanho de tela compatível com suporte (largura de 320 dp), as implementações de dispositivo VÃO PRECISAR informar a próxima densidade padrão mais baixa do framework do Android.

É ALTAMENTE RECOMENDÁVEL que as implementações de dispositivos ofereçam 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 com a implementação do AOSP, conforme indicado abaixo:

  • O tamanho da tela NÃO PODE ser dimensionado em mais de 1,5 vezes a densidade nativa ou produzir uma dimensão mínima de tela menor que 320 dp (equivalente ao qualificador de recurso sw320dp), o que ocorrer primeiro.
  • O tamanho da tela NÃO pode ser dimensionado para menos de 0,85 vezes a densidade nativa.
  • Para garantir uma boa usabilidade e tamanhos de fonte consistentes, é RECOMENDÁVEL que as seguintes opções de escalonamento de tela nativa sejam fornecidas (atendendo aos limites especificados acima):
  • Pequeno: 0,85x
  • Padrão: 1x (escala de exibição nativa)
  • Grande: 1,15x
  • Maior: 1,3x
  • Maior: 1,45x

7.1.2. Métricas de tela

As implementações de dispositivos PRECISAM informar os valores corretos para todas as métricas de exibição definidas em android.util.DisplayMetrics e PRECISAM informar os mesmos valores, independentemente de a tela integrada ou externa ser usada como a tela 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 precisam informar pelo menos uma orientação compatível. Por exemplo, um dispositivo com uma tela no modo paisagem de orientação fixa, como uma televisão ou um laptop, DEVE informar apenas android.hardware.screen.landscape.

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

Os dispositivos precisam informar o valor correto para a orientação atual do dispositivo sempre que forem consultados por meio de 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 oferecer suporte ao OpenGL ES 1.0 e 2.0, conforme definido e detalhado na documentação do SDK do Android. As implementações de dispositivos PRECISAM oferecer suporte ao OpenGL ES 3.0, 3.1 ou 3.2 em dispositivos compatíveis. As implementações de dispositivos também precisam oferecer suporte ao Android RenderScript, conforme detalhado na documentação do SDK do Android.

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

  • As APIs gerenciadas (como pelo método GLES10.getString()) precisam informar suporte para o OpenGL ES 1.0 e o OpenGL ES 2.0.
  • As APIs OpenGL C/C++ nativas (disponíveis para apps por meio de libGLES_v1CM.so, libGLES_v2.so ou libEGL.so) PRECISAM informar suporte para o OpenGL ES 1.0 e o OpenGL ES 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 dispositivo 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ões do OpenGL ES com interfaces Java e suporte nativo para funcionalidades gráficas avançadas, como tessellation e o formato de compactação de textura ASTC. As implementações de dispositivos Android precisam oferecer suporte ao pacote de extensão se o dispositivo for compatível com o OpenGL ES 3.2 e PODEM oferecer suporte caso contrário. Se o pacote de extensão tiver suporte total, o dispositivo PRECISA identificar o suporte usando a flag de recurso android.hardware.opengles.aep.

Além disso, as implementações de dispositivos PODEM implementar qualquer extensão do OpenGL ES desejada. No entanto, as implementações de dispositivos precisam informar todas as strings de extensão com suporte pelas APIs gerenciadas e nativas do OpenGL ES e não informar as que não têm suporte.

O Android inclui suporte para aplicativos que especificam opcionalmente que precisam de formatos de compactação de textura do OpenGL específicos. Esses formatos geralmente são específicos do fornecedor. O Android não exige que as implementações de dispositivos implementem um formato específico de compressão de textura. No entanto, eles precisam informar com precisão todos os formatos de compactação de textura compatíveis, usando o método getString() na API OpenGL.

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

As implementações de dispositivos PRECISAM ativar a aceleração de hardware por padrão e PRECISAM desativar a aceleração de hardware se o desenvolvedor solicitar isso 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 apresentar um comportamento consistente com a documentação do SDK do Android sobre aceleração de hardware.

O Android inclui um objeto TextureView que permite que os desenvolvedores integrem diretamente texturas OpenGL ES aceleradas por hardware como destinos de renderização em uma hierarquia de interface. As implementações de dispositivos PRECISAM oferecer suporte à API TextureView e PRECISAM apresentar um comportamento consistente com a implementação upstream do Android.

O Android inclui suporte a 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 dispositivo precisam oferecer suporte à extensão EGL_ANDROID_RECORDABLE.

7.1.5. Modo de compatibilidade de aplicativos legados

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

  • O Android Automotive não tem suporte ao modo de compatibilidade legada.
  • Todas as outras implementações de dispositivo PRECISAM incluir suporte ao modo de compatibilidade de aplicativos legados conforme implementado pelo código aberto do Android upstream. Ou seja, as implementações de dispositivos NÃO PODEM alterar os acionadores ou limites em que o modo de compatibilidade é ativado e NEM o comportamento do próprio modo de compatibilidade.

7.1.6. Tecnologia da tela

A plataforma Android inclui APIs que permitem que os apps renderizem gráficos avançados na tela. Os dispositivos precisam oferecer suporte a todas essas APIs, conforme definido pelo SDK do Android, a menos que seja permitido especificamente neste documento.

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

7.1.7. Telas secundárias

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

7.2. Dispositivos de entrada

Os dispositivos precisam oferecer suporte a uma tela touchscreen ou atender aos requisitos listados em 7.2.2 para navegação sem toque.

7.2.1. Teclado

As implementações do Android Watch e do Android Automotive PODEM implementar um teclado virtual. Todas as outras implementações de dispositivo precisam implementar um teclado virtual e:

Implementações de dispositivos:

  • É PRECISO incluir suporte para o framework de gerenciamento de entrada, que permite que desenvolvedores terceirizados criem editores de método de entrada (por exemplo, teclado virtual), conforme detalhado em http://developer.android.com.
  • É OBRIGATÓRIO fornecer pelo menos uma implementação de teclado virtual (independentemente de um teclado físico estar presente), 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 virtual.
  • PODE incluir um teclado físico.
  • NÃO inclua um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.keyboard (QWERTY ou 12 teclas).

7.2.2. Navegação sem toque

Os dispositivos Android TV precisam oferecer suporte ao D-pad.

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 TV.
  • É necessário informar o valor correto para android.content.res.Configuration.navigation.
  • É PRECISO 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 entrada. A implementação de código aberto upstream do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação não por toque.

7.2.3. Teclas de navegação

A disponibilidade e o requisito de visibilidade das funções "Início", "Recentes" e "Voltar" variam de acordo com o tipo de dispositivo, conforme descrito nesta seção.

As funções "Início", "Recentes" e "Voltar" (mapeadas para os eventos de tecla KEYCODE_HOME, KEYCODE_APP_SWITCH e KEYCODE_BACK, respectivamente) são essenciais para o paradigma de navegação do Android e, portanto:

  • As implementações de dispositivos Android portáteis precisam fornecer as funções de tela inicial, recentes e voltar.
  • As implementações de dispositivos Android TV precisam fornecer as funções "Home" e "Back".
  • As implementações de dispositivos Android Watch precisam ter a função "Início" disponível para o usuário e a função "Voltar", exceto quando ela estiver em UI_MODE_TYPE_WATCH .
  • As implementações de dispositivos do Android Watch, e nenhum outro tipo de dispositivo Android, PODEM consumir o evento de pressionar por muito tempo no evento de tecla KEYCODE_BACK e o omitir do envio para o aplicativo em primeiro plano.
  • As implementações do Android Automotive precisam oferecer a função "Início" e podem oferecer as funções "Voltar" e "Recentes".
  • Todos os outros tipos de implementações de dispositivos precisam fornecer as funções "Início" e "Voltar".

Essas funções PODEM ser implementadas usando botões físicos dedicados (como botões mecânicos ou capacitivos) ou usando teclas de software dedicadas em uma parte distinta da tela, gestos, painel de toque etc. O Android oferece suporte para 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 estiverem visíveis.

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

As funções "Início" e "Voltar", 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 o uiMode UI_MODE_TYPE_MASK estiver definido como UI_MODE_TYPE_WATCH.

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

  • PRECISA mostrar o botão de ação flutuante na barra de ações quando ele estiver visível e o menu flutuante de ação flutuante resultante não estiver vazio. Para uma implementação de dispositivo lançada antes do Android 4.4, mas que está sendo atualizada para o Android 7.0, isso é RECOMENDADO.
  • NÃO deve modificar a posição do pop-up de overflow de ação exibido ao selecionar o botão de overflow na barra de ação.
  • PODE renderizar o pop-up de overflow de ação em uma posição modificada na tela quando ele é mostrado selecionando o botão físico do menu.

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

As implementações de dispositivos Android que oferecem suporte à ação de assistência e/ou VoiceInteractionService precisam ser capazes de 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. É ALTAMENTE RECOMENDADO usar o toque e manter pressionado na tela inicial como essa interação. A interação designada PRECISA iniciar o app de assistência selecionado pelo usuário, ou seja, 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 mostrar as teclas de navegação, mas, se for o caso, elas PRECISAM atender a estes requisitos:

  • As teclas de navegação de implementação do dispositivo PRECISAM usar uma parte distinta da tela, que não está disponível para aplicativos, e NÃO PODEM obscurecer ou interferir de outra forma na parte da tela disponível para aplicativos.
  • As implementações de dispositivos PRECISAM disponibilizar uma parte da tela para apps 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 "de perfil baixo" (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 apps especificam SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Entrada por touchscreen

Dispositivos portáteis e relógios Android precisam oferecer suporte à entrada por touchscreen.

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

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

O Android oferece suporte a várias telas, touchpads e dispositivos de entrada falsos. As implementações de dispositivos com tela touchscreen são associadas a uma tela de modo que o usuário tem a impressão de manipular itens diretamente na tela. Como o usuário toca diretamente na tela, o sistema não exige recursos 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 tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela se aproxima do toque, mas exige que o usuário primeiro aponte ou foque e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse aéreo com 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 não por toque (baseado em ponteiro) de alta fidelidade, como um mouse ou trackpad que pode emular adequadamente a entrada por toque (incluindo suporte a gestos básicos) e indica que o dispositivo oferece suporte a um subconjunto emulado de recursos da tela touchscreen. As implementações de dispositivos que declaram o recurso de toque falso PRECISAM atender aos requisitos de toque falso na 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 (single-touch ou melhor) PRECISAM informar a constante do recurso de plataforma android.hardware.touchscreen. As implementações de dispositivo que informam a constante de recurso da plataforma android.hardware.touchscreen também precisam informar a constante de recurso da plataforma android.hardware.faketouch. Implementações de dispositivo que não incluem uma tela touchscreen (e dependem apenas de um dispositivo de ponteiro) NÃO PODEM informar nenhum recurso de tela touchscreen e APENAS podem informar android.hardware.faketouch se atenderem aos requisitos de toque simulado na seção 7.2.5.

7.2.5. Entrada por toque falsa

Implementações de dispositivos que declaram suporte para android.hardware.faketouch:

  • DEVEM informar as posições absolutas X e Y da tela do local do ponteiro e mostrar um ponteiro visual na tela.
  • É OBRIGATÓRIO informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre no ponteiro subindo ou descendo na tela.
  • PRECISA oferecer suporte ao ponteiro para baixo e para cima em um objeto na tela, o que permite que os usuários simulem o toque em um objeto na tela.
  • PRECISA oferecer suporte ao ponteiro para baixo, para cima, para baixo e para cima no mesmo local em um objeto na tela dentro de um limite de tempo, o que permite que os usuários emulem o toque duplo em um objeto na tela.
  • PRECISA oferecer suporte ao ponteiro para baixo em um ponto arbitrário na tela, movimento do ponteiro para qualquer outro ponto arbitrário na tela, seguido por um ponteiro para cima, o que permite que os usuários emulem um arrasto 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, o ponteiro para cima na tela, o que permite que os usuários joguem um objeto na tela.

Os dispositivos que declaram suporte a android.hardware.faketouch.multitouch.distinct precisam atender aos requisitos para faketouch acima e também precisam oferecer suporte a rastreamento distinto de duas ou mais entradas de ponteiro independentes.

7.2.6. Suporte a controles de jogos

As implementações de dispositivos Android TV 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 atende a esse requisito.

7.2.6.1. Mapeamentos de botões

As implementações de dispositivos Android TV precisam oferecer suporte aos seguintes mapeamentos de teclas:

Botão Uso de HID 2 Botão do Android
A 1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B 1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X 1 0x09 0x0004 KEYCODE_BUTTON_X (99)
S 1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Botão direcional para cima 1
Botão direcional para baixo 1 		0x01 0x0039 3 AXIS_HAT_Y 4
Botão direcional esquerdo 1
Botão direcional direito 1 		0x01 0x0039 3 AXIS_HAT_X 4
Botão de ombro esquerdo 1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Botão de ombro direito 1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clique no botão esquerdo 1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clique no botão direito 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 Esse uso precisa ter um mínimo lógico de 0, um máximo lógico de 7, um mínimo físico de 0, um máximo físico de 315, unidades em graus e um tamanho de relatório de 4. O valor lógico é definido como a rotação no sentido horário para longe do eixo vertical. Por exemplo, um valor lógico de 0 representa nenhuma rotação e o botão para cima pressionado, enquanto um valor lógico de 1 representa uma rotação de 45 graus e as teclas para cima e esquerda pressionadas.

4 MotionEvent

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

1 MotionEvent

7.2.7. Controle remoto

As implementações de dispositivos Android TV precisam 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, acessível por smartphone ou tablet. O controle remoto PRECISA atender aos requisitos definidos abaixo.

7.3. Sensores

O Android inclui APIs para acessar vários tipos de sensores. As implementações de dispositivos geralmente 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 de código aberto do Android sobre sensores. Por exemplo, implementações de dispositivos:

  • É PRECISO 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 dos sensores compatíveis usando SensorManager.getSensorList() e métodos semelhantes.
  • PRECISA se comportar de forma razoável para todas as outras APIs de sensor (por exemplo, retornando "true" ou "false" conforme apropriado quando os aplicativos tentam registrar listeners, não chamando listeners de sensor quando os sensores correspondentes não estão presentes etc.).
  • É necessário informar todas as medições do sensor usando os valores relevantes do Sistema Internacional de Unidades (métrica) para cada tipo de sensor, conforme definido na documentação do SDK do Android.
  • DEVE informar o horário do evento em nanossegundos, conforme definido na documentação do SDK do Android, representando o horário em que o evento ocorreu e sincronizado com o relógio SystemClock.elapsedRealtimeNano(). É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam ser atualizados para as versões futuras da plataforma, em que esse componente pode se tornar OBRIGATÓRIO. O erro de sincronização DEVE ser inferior a 100 milissegundos.
  • É PRECISO informar dados do sensor com uma latência máxima de 100 milissegundos + 2 * sample_time para o caso de um sensor transmitido com uma latência mínima de 5 ms + 2 * sample_time quando o processador do aplicativo está ativo. Esse atraso não inclui atrasos de filtragem.
  • DEVE informar a primeira amostra do sensor em 400 milissegundos + 2 * sample_time do sensor 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 sobre sensores é considerado oficial.

Alguns tipos de sensores são compostos, ou seja, podem ser derivados de dados fornecidos por um ou mais outros sensores. Por exemplo, o sensor de orientação e o sensor de aceleração linear. As implementações de dispositivos precisam implementar esses tipos de sensores quando incluem os sensores físicos necessários, conforme descrito em tipos de sensores. Se uma implementação de dispositivo incluir um sensor composto, ela PRECISA implementar o sensor conforme descrito na documentação do Android Open Source sobre sensores compostos.

Alguns sensores do Android oferecem suporte a um modo de acionamento "contínuo", que retorna dados continuamente. Para que qualquer API indicada pela documentação do SDK do Android seja um sensor contínuo, as implementações de dispositivo precisam fornecer continuamente amostras de dados periódicos que precisam ter um jitter abaixo de 3%, em que o jitter é definido como a variação padrão da diferença dos valores de carimbo de data/hora informados entre eventos consecutivos.

As implementações do dispositivo precisam garantir que a transmissão de eventos do sensor NÃO impeça a CPU do dispositivo de entrar ou sair do estado de suspensão.

Por fim, quando vários sensores são ativados, o consumo de energia NÃO DEVE exceder a soma do consumo de energia informado pelo sensor individual.

7.3.1. Acelerômetro

As implementações de dispositivos devem incluir um acelerômetro de três eixos. É ALTAMENTE RECOMENDÁVEL que dispositivos portáteis Android, implementações do Android Automotive e dispositivos Android Watch incluam esse sensor. Se uma implementação de dispositivo incluir um acelerômetro de três eixos, ela:

  • É PRECISO implementar e informar o sensor TYPE_ACCELEROMETER.
  • É PRECISO que o app possa informar eventos com frequência de pelo menos 50 Hz para dispositivos Android Watch, já que eles têm uma restrição de energia mais rígida, e 100 Hz para todos os outros tipos de dispositivos.
  • DEVE informar eventos de até 200 Hz.
  • É PRECISO 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 do carro do Android.
  • É PRECISO 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 pelo menos 16 bits.
  • DEVEM ser calibrados durante o uso se as características mudarem ao longo do ciclo de vida e forem compensadas, e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • DEVE ser compensada pela temperatura.
  • Deve ter uma variação padrão não superior a 0,05 m/s^, em que a variação padrão precisa ser calculada por eixo em amostras coletadas durante um período de pelo menos 3 segundos na taxa de amostragem mais rápida.
  • IMPLEMENTE os sensores compostos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR e TYPE_STEP_COUNTER, conforme descrito no documento do SDK do Android. É ALTAMENTE RECOMENDADO que dispositivos Android novos e atuais implementem 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 CADA UM PRECISA estar abaixo de 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 for incluído, ele PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e DEVE implementar o sensor composto TYPE_GAME_ROTATION_VECTOR. É ALTAMENTE RECOMENDADO que os dispositivos Android novos e atuais implementem o sensor TYPE_GAME_ROTATION_VECTOR.
  • É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR se um sensor de giroscópio e um sensor de magnetômetro também forem incluídos.

7.3.2. Magnetômetro

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

  • É OBRIGATÓRIO implementar o sensor TYPE_MAGNETIC_FIELD e RECOMENDÁVEL implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED. É ALTAMENTE RECOMENDÁVEL que os dispositivos Android novos e atuais implementem o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • PRECISA ser capaz de informar eventos com frequência de pelo menos 10 Hz e DEVE informar eventos com frequência de pelo menos 50 Hz.
  • É PRECISO obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android.
  • Deve ser capaz de medir entre -900 µT e +900 µT em cada eixo antes da saturação.
  • É PRECISO ter um valor de deslocamento de ferro rígido menor que 700 µT e um valor menor que 200 µT, colocando o magnetômetro longe de campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímã).
  • 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 compensada pela temperatura.
  • É PRECISO oferecer suporte à calibração on-line e à compensação do viés de hardware e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • A compensação de ferro macio PRECISA ser 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 com base em amostras coletadas por um período de pelo menos 3 segundos na taxa de amostragem mais rápida, não superior a 0, 5 µT.
  • É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR se um sensor de acelerômetro e um sensor de giroscópio também forem incluídos.
  • PODE implementar o sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR se um sensor de acelerômetro também for implementado. No entanto, se for implementado, ele PRECISA consumir menos de 10 mW e DEVE consumir menos de 3 mW quando o sensor estiver registrado para o modo de lote a 10 Hz.

7.3.3. GPS

As implementações de dispositivos precisam incluir um receptor de GPS/GNSS. Se uma implementação de dispositivo incluir um receptor GPS/GNSS e informar a capacidade para os aplicativos usando a flag de recurso android.hardware.location.gps:

  • É ALTAMENTE RECOMENDÁVEL que o dispositivo continue a fornecer saídas normais de GPS/GNSS para os aplicativos durante uma ligação de emergência e que a saída de localização não seja bloqueada durante uma ligação de emergência.
  • Ele PRECISA oferecer suporte a saídas de localização com 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 desprezível, HDOP < 2) em 10 segundos (tempo rápido até a primeira correção), quando conectado a uma conexão de Internet de 0,5 Mbps ou mais rápida. Esse requisito geralmente é atendido pelo uso de alguma forma de técnica de GPS/GNSS assistida ou prevista 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 efemérides/relógio do satélite.
    • Depois de fazer esse cálculo de localização, é ALTAMENTE RECOMENDADO que o dispositivo possa determinar a própria localização, em céu aberto, em até 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, depois de determinar o local, enquanto estiver parado ou se movendo com menos de 1 metro por segundo ao quadrado de aceleração:
    • Ele PRECISA ser capaz de determinar a localização em até 20 metros e a velocidade em até 0, 5 metro por segundo, pelo menos 95% do tempo.
    • Ele PRECISA rastrear e informar simultaneamente pelo menos 8 satélites de uma constelação usando GnssStatus.Callback.
    • 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).
  • Ele PRECISA informar a geração da tecnologia GNSS pela API de teste "getGnssYearOfHardware".
  • É ALTAMENTE RECOMENDÁVEL atender a todos os requisitos abaixo se a geração da tecnologia GNSS for informada como o ano "2016" ou mais recente.
    • Ele PRECISA informar as medições de GPS assim que elas forem encontradas, mesmo que um local calculado pelo GPS/GNSS ainda não tenha sido informado.
    • Ele PRECISA informar pseudorragem e taxas de pseudorragem do GPS que, em condições de céu aberto após a determinação do local, enquanto está parado ou se move com menos de 0, 2 metro por segundo ao quadrado de aceleração, são suficientes para calcular a posição em até 20 metros e a velocidade em até 0, 2 metro por segundo, pelo menos 95% do tempo.

Embora alguns dos requisitos de GPS acima sejam indicados como ALTAMENTE RECOMENDADOS, a definição de compatibilidade para a próxima versão principal deve mudar isso 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 uma implementação de dispositivo incluir um giroscópio, ela:

  • É PRECISO implementar o sensor TYPE_GYROSCOPE e também o sensor TYPE_GYROSCOPE_UNCALIBRATED. É ALTAMENTE RECOMENDADO que os dispositivos Android novos e atuais implementem o sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
  • Deve ser capaz de medir mudanças de orientação de até 1.000 graus por segundo.
  • É PRECISO que o app possa informar eventos com frequência de pelo menos 50 Hz para dispositivos Android Watch, já que eles têm uma restrição de energia mais rígida, e 100 Hz para todos os outros tipos de dispositivos.
  • DEVE informar eventos de até 200 Hz.
  • PRECISA ter uma resolução de 12 bits ou mais e DEVE ter uma resolução de 16 bits ou mais.
  • Deve ser compensado pela temperatura.
  • Devem ser calibrados e compensados durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • A variância PRECISA ser menor que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar com a taxa de amostragem, mas precisa ser limitada por esse valor. Em outras palavras, se você medir a variação do giroscópio com uma taxa de amostragem de 1 Hz, ela não poderá ser maior que 1e-7 rad^2/s^2.
  • É PRECISO implementar um sensor composto TYPE_ROTATION_VECTOR se um sensor de acelerômetro e um sensor de magnetômetro também forem incluídos.
  • Se um sensor de acelerômetro for incluído, ele PRECISA implementar os sensores compostos TYPE_GRAVITY e TYPE_LINEAR_ACCELERATION e DEVE implementar o sensor composto TYPE_GAME_ROTATION_VECTOR. É ALTAMENTE RECOMENDADO que os dispositivos Android novos e atuais implementem o sensor TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

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

  • É PRECISO implementar e informar o sensor TYPE_PRESSURE.
  • Precisa ser capaz de enviar eventos a 5 Hz ou mais.
  • PRECISA ter precisão adequada para permitir a estimativa de altitude.
  • Deve ser compensado pela temperatura.

7.3.6. Termômetro

As implementações de dispositivos PODEM incluir um termômetro ambiente (sensor de temperatura). Se presente, ele PRECISA ser definido como SENSOR_TYPE_AMBIENT_TEMPERATURE e PRECISA medir a temperatura ambiente (do 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, PRECISA 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.

Para implementações do Android Automotive, SENSOR_TYPE_AMBIENT_TEMPERATURE PRECISA medir a temperatura dentro da cabine do veículo.

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 uma chamada de voz e indicar qualquer valor diferente de PHONE_TYPE_NONE em getPhoneType precisam incluir um sensor de proximidade. Se uma implementação de dispositivo incluir um sensor de proximidade, ele:

  • DEVE medir a proximidade de um objeto na mesma direção da tela. Ou seja, o sensor de proximidade PRECISA ser orientado para detectar objetos próximos à tela, já que a intenção principal desse tipo de sensor é detectar um telefone 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 precisão de 1 bit ou mais.

7.3.9. Sensores de alta fidelidade

As implementações de dispositivos que oferecem suporte a um conjunto de sensores de maior qualidade que atendem a todos os requisitos listados nesta seção PRECISAM identificar o suporte usando a 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 sensores a seguir que atendem aos requisitos de qualidade, conforme abaixo:

  • SENSOR_TYPE_ACCELEROMETER
    • É PRECISO 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 inferior.
    • PRECISA ter uma frequência máxima de medição de 400 Hz ou mais.
    • Deve ter um ruído de medição não superior a 400 uG/√Hz.
    • É PRECISO implementar um formulário de desativação desse sensor com um recurso de buffer de pelo menos 3.000 eventos do sensor.
    • O consumo de energia em lote precisa ser de no máximo 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 relação à temperatura de ≤ +/- 1 mg / °C.
    • DEVE ter uma não linearidade de linha de melhor ajuste de ≤ 0,5% e uma mudança de sensibilidade em relação à temperatura de ≤ 0,03%/C°.

  • SENSOR_TYPE_GYROSCOPE

    • PRECISA ter um intervalo de medição entre pelo menos -1000 e +1000 dps.
    • PRECISA ter uma resolução de medição de pelo menos 16 LSB/dps.
    • PRECISA ter uma frequência de medição mínima de 12,5 Hz ou inferior.
    • PRECISA ter uma frequência máxima de medição de 400 Hz ou mais.
    • Deve ter um ruído de medição não superior a 0,014°/s/√Hz.
    • DEVE ter uma estabilidade de viés estático de < 0,0002 °/s √Hz do conjunto de dados estático de 24 horas.
    • DEVE ter uma mudança de viés em relação à temperatura de ≤ +/- 0,05 °/ s / °C.
    • DEVE ter uma mudança de sensibilidade em relação à temperatura de ≤ 0,02% / °C.
    • DEVE ter uma não linearidade de linha de ajuste ideal de ≤ 0,2%.
    • DEVE ter uma densidade de ruído de ≤ 0,007 °/s/√Hz.

  • SENSOR_TYPE_GYROSCOPE_UNCALIBRATED com os mesmos requisitos de qualidade de SENSOR_TYPE_GYROSCOPE.

  • SENSOR_TYPE_GEOMAGNETIC_FIELD
    • PRECISA ter um intervalo de medição entre pelo menos -900 e +900 uT.
    • É PRECISO ter uma resolução de medição de pelo menos 5 LSB/uT.
    • PRECISA ter uma frequência de medição mínima de 5 Hz ou menor.
    • PRECISA ter uma frequência máxima de medição de 50 Hz ou mais.
    • Deve ter um ruído de medição não superior a 0,5 uT.
  • SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED com os mesmos requisitos de qualidade de SENSOR_TYPE_GEOMAGNETIC_FIELD e, além disso:
    • É PRECISO implementar um formulário sem ativação desse sensor com capacidade de buffer de pelo menos 600 eventos do sensor.
  • SENSOR_TYPE_PRESSURE
    • PRECISA ter um intervalo de medição entre pelo menos 300 e 1.100 hPa.
    • PRECISA ter uma resolução de medição de pelo menos 80 LSB/hPa.
    • Deve ter uma frequência de medição mínima de 1 Hz ou inferior.
    • PRECISA ter uma frequência de medição máxima de 10 Hz ou mais.
    • O ruído de medição não pode exceder 2 Pa/√Hz.
    • É PRECISO implementar um formulário sem ativação desse sensor com um recurso de buffer de pelo menos 300 eventos do sensor.
    • O consumo de energia em lote precisa ser de no máximo 2 mW.
  • SENSOR_TYPE_GAME_ROTATION_VECTOR
    • É PRECISO implementar um formulário sem ativação desse sensor com um recurso de buffer de pelo menos 300 eventos do sensor.
    • O consumo de energia em lote precisa ser de no máximo 4 mW.
  • SENSOR_TYPE_SIGNIFICANT_MOTION
    • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
  • SENSOR_TYPE_STEP_DETECTOR
    • É PRECISO implementar um formulário sem ativação desse sensor com capacidade de buffer de pelo menos 100 eventos do sensor.
    • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
    • O consumo de energia em lote precisa ser de no máximo 4 mW.
  • SENSOR_TYPE_STEP_COUNTER
    • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.
  • SENSOR_TILT_DETECTOR
    • O consumo de energia DEVE ser de no máximo 0,5 mW quando o dispositivo estiver estático e de 1,5 mW quando estiver em movimento.

Além disso, esse dispositivo PRECISA atender aos seguintes requisitos do subsistema do sensor:

  • O carimbo de data/hora do mesmo evento físico informado pelo acelerômetro, pelo sensor de giroscópio e pelo magnetômetro PRECISA estar a 2,5 milissegundos um do outro.
  • Os carimbos de data/hora do evento do sensor do giroscópio precisam estar na mesma base de tempo que o subsistema da câmera e com um erro de 1 milissegundo.
  • Os sensores de alta fidelidade precisam enviar amostras para os aplicativos em até cinco 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 superior a 0,5 mW quando o dispositivo está estático e 2,0 mW quando o dispositivo está em movimento quando qualquer combinação dos seguintes sensores está ativada:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

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

Os seguintes tipos de sensores PODEM ter suporte em uma implementação de dispositivo que declara android.hardware.sensor.hifi_sensors, mas, se esses tipos de sensores estiverem presentes, eles PRECISAM atender ao seguinte requisito mínimo de capacidade de 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 PRECISAM incluir um sensor de impressão digital. Se uma implementação de 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 totalmente a API correspondente, conforme descrito na documentação do SDK do Android.
  • A taxa de aceitação falsa PRECISA ser menor que 0,002%.
  • É ALTAMENTE RECOMENDADO ter uma taxa de rejeição falsa inferior a 10%, conforme medido no dispositivo
  • É ALTAMENTE RECOMENDADO ter uma latência abaixo de 1 segundo, medida desde o momento em que o sensor de impressão digital é tocado até a tela ser desbloqueada, para um dedo registrado.
  • É necessário limitar a taxa de tentativas por pelo menos 30 segundos após cinco tentativas falsas de verificação de impressão digital.
  • PRECISA ter uma implementação de keystore com suporte de 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, de modo 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 do site do Projeto Android Open Source.
  • É PRECISO impedir a adição de uma impressão digital sem primeiro estabelecer uma cadeia de confiança, fazendo com que o usuário confirme ou adicione uma nova credencial de dispositivo (PIN/padrão/senha) protegida pelo TEE. A implementação do Projeto Android Open Source fornece o mecanismo no framework para fazer isso.
  • NÃO ative aplicativos de terceiros para distinguir impressões digitais individuais.
  • DEVE respeitar a flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • Ao fazer upgrade de uma versão anterior ao Android 6.0, os dados de impressão digital PRECISAM ser 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

Os 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 precisam fornecer a engrenagem atual como SENSOR_TYPE_GEAR.

7.3.11.2. Modo dia/noite

As implementações do Android Automotive precisam oferecer suporte ao modo diurno/noturno definido como SENSOR_TYPE_NIGHT. O valor dessa flag PRECISA ser consistente com o modo dia/noite do painel e PRECISA ser baseado na entrada do sensor de luz ambiente. O sensor de luz ambiente pode ser o mesmo que o fotômetro.

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 SENSOR_TYPE_DRIVING_STATUS em conformidade com todas as leis e regulamentações aplicáveis aos mercados em que o produto é enviado.

7.3.11.4. Velocidade da roda

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

7.3.12. Sensor de pose

As implementações de dispositivos PODEM oferecer suporte ao sensor de pose com seis graus de liberdade. É RECOMENDÁVEL que os dispositivos Android Handheld ofereçam suporte a esse sensor. Se uma implementação de dispositivo oferecer suporte ao sensor de pose com seis graus de liberdade, ela:

  • É PRECISO implementar e informar o sensor TYPE_POSE_6DOF.
  • PRECISA ser mais preciso que o vetor de rotação sozinho.

7.4. Conectividade de dados

7.4.1. Telefonia

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

O Android PODE ser usado em dispositivos que não incluem hardware de telefonia. Ou seja, o Android é compatível com dispositivos que não são smartphones. No entanto, se uma implementação de dispositivo incluir telefonia GSM ou CDMA, ela PRECISA implementar suporte total à API para essa tecnologia. As implementações de dispositivos que não incluem hardware de telefonia PRECISAM implementar as APIs completas como no-ops.

7.4.1.1. Compatibilidade com o bloqueio de números

As implementações de dispositivos de telefonia Android precisam incluir suporte ao bloqueio de números e:

  • É PRECISO implementar totalmente o BlockedNumberContract e a API correspondente, conforme descrito na documentação do SDK.
  • É necessário bloquear todas as ligações e mensagens de um número de telefone em "BlockedNumberProvider" sem nenhuma interação com apps. A única exceção é quando o bloqueio de número é temporariamente suspenso, conforme descrito na documentação do SDK.
  • NÃO PODE gravar no provedor de registro de chamadas da plataforma para uma chamada bloqueada.
  • NÃO DEVE ser gravado no provedor de telefonia para 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 permita que usuários secundários visualizem ou editem os números bloqueados no dispositivo, porque a plataforma Android assume que o usuário principal tem controle total dos serviços de telefonia, uma única instância, no dispositivo. Toda a interface relacionada ao bloqueio PRECISA ser oculta para usuários secundários, e a lista de bloqueios 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 precisam incluir suporte a 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 correspondente do Android e:

  • É PRECISO informar a flag de recurso de hardware android.hardware.wifi.
  • PRECISA implementar a API multicast conforme descrito na documentação do SDK.
  • DEVE oferecer suporte a DNS multicast (mDNS) e NÃO DEVE filtrar pacotes mDNS (224.0.0.251) em nenhum momento da operação, incluindo:
    • Mesmo quando a tela não está em um estado ativo.
    • Para implementações de dispositivos Android TV, mesmo em estados de energia em espera.

7.4.2.1. Wi-Fi Direct

As implementações de dispositivos precisam incluir suporte ao 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 correspondente do Android, conforme descrito na documentação do SDK. Se uma implementação de dispositivo incluir suporte para Wi-Fi Direct, ela:

  • É PRECISO informar o recurso de hardware android.hardware.wifi.direct.
  • PRECISA oferecer suporte à operação regular de Wi-Fi.
  • DEVE oferecer suporte a operações simultâneas de Wi-Fi e Wi-Fi Direct.

As implementações de dispositivos precisam incluir suporte para a Configuração de link direto com encapsulamento (TDLS, na sigla em inglês) do Wi-Fi, conforme descrito na documentação do SDK do Android. Se uma implementação de dispositivo incluir suporte para TDLS e o TDLS for ativado pela API WiFiManager, o dispositivo:

  • Use TDLS apenas quando possível E benéfico.
  • DEVE ter alguma heurística e NÃO usar TDLS quando o desempenho for pior do que passar pelo ponto de acesso Wi-Fi.

7.4.3. Bluetooth

As implementações do Android Watch precisam oferecer suporte a Bluetooth. As implementações do Android TV precisam oferecer suporte a Bluetooth e Bluetooth LE. As implementações do Android Automotive precisam ter suporte a Bluetooth e Bluetooth LE.

As implementações de dispositivos que oferecem suporte ao recurso android.hardware.vr.high_performance precisam oferecer suporte ao 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 para Bluetooth e Bluetooth de baixa energia PRECISAM declarar os recursos relevantes da plataforma (android.hardware.bluetooth e android.hardware.bluetooth_le, respectivamente) e implementar as APIs da plataforma. As implementações de dispositivos precisam implementar os perfis de Bluetooth relevantes, como A2DP, AVCP, OBEX etc., conforme apropriado para o dispositivo.

As implementações do Android Automotive precisam oferecer suporte ao perfil de acesso a mensagens (MAP). As implementações do Android Automotive precisam oferecer suporte aos seguintes perfis Bluetooth:

  • Ligações telefônicas pelo perfil viva-voz (HFP).
  • Reprodução de mídia pelo perfil de distribuição de áudio (A2DP).
  • Controle de reprodução de mídia pelo perfil de controle remoto (AVRCP).
  • Compartilhamento de contatos usando o perfil de acesso à agenda telefônica (PBAP).

Implementações de dispositivos com suporte para Bluetooth de baixa energia:

  • PRECISA declarar o recurso de hardware android.hardware.bluetooth_le.
  • É PRECISO ativar as APIs Bluetooth baseadas em GATT (perfil de atributo genérico), conforme descrito na documentação do SDK e em android.bluetooth.
  • É ALTAMENTE RECOMENDADO implementar um tempo limite de endereço particular solucionável (RPA) de no máximo 15 minutos e girar 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 e DEVE informar o valor correto de onde a lógica de filtragem é implementada sempre que consultada pelo método android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported().
  • DEVE oferecer suporte ao descarregamento da digitalização em lote para o chipset Bluetooth, mas, se não houver suporte, DEVE informar "false" sempre que for consultado pelo método android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported().
  • DEVE oferecer suporte a anúncios múltiplos com pelo menos quatro slots. Se não houver suporte, DEVE informar "false" sempre que for consultado pelo método android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

7.4.4. Comunicação a curta distância (NFC)

As implementações de dispositivos devem incluir um transceptor e hardware relacionado para comunicações a curta distância (NFC). Se uma implementação de dispositivo incluir hardware NFC e planejar disponibilizá-lo para apps de terceiros, ela:

  • É PRECISO 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 de NFC:
    • PRECISA ser capaz de atuar como um leitor/gravador do NFC Forum (conforme definido pela especificação técnica do NFC Forum NFCForum-TS-DigitalProtocol-1.0) pelos seguintes padrões de NFC:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS X 6319-4)
      • IsoDep (ISO 14443-4)
      • Tipos de tag do NFC Forum 1, 2, 3 e 4 (definidos pelo NFC Forum)
    • É ALTAMENTE RECOMENDÁVEL que o app seja capaz de ler e gravar mensagens NDEF, bem como dados brutos, usando os seguintes padrões de NFC. Embora os padrões de NFC abaixo sejam indicados como ALTAMENTE RECOMENDADOS, a definição de compatibilidade para uma versão futura está planejada para mudar para OBRIGATÓRIO. Esses padrões são opcionais nesta versão, mas serão obrigatórios em versões futuras. É altamente recomendável que os dispositivos atuais e novos que executam essa versão do Android atendam a esses requisitos agora para que possam fazer upgrade para as versões futuras da plataforma.
      • NfcV (ISO 15693)
    • DEVE ser capaz de ler o código de barras e o URL (se codificado) dos produtos de código de barras NFC Thinfilm.
    • DEVE ser capaz de transmitir e receber dados pelos seguintes padrões e protocolos ponto a ponto:
      • ISO 18092
      • LLCP 1.2 (definido pelo NFC Forum)
      • SDP 1.0 (definido pelo Fórum de NFC)
      • Protocolo NDEF Push
      • SNEP 1.0 (definido pelo NFC Forum)
    • PRECISA incluir suporte ao Android Beam.
    • É PRECISO implementar o servidor padrão do SNEP. As mensagens NDEF válidas recebidas pelo servidor SNEP padrão PRECISAM ser enviadas para os aplicativos usando a intent android.nfc.ACTION_NDEF_DISCOVERED. A desativação do Android Beam nas configurações NÃO deve desativar o envio de mensagens NDEF recebidas.
    • PRECISA honrar a intent android.settings.NFCSHARING_SETTINGS para mostrar as configurações de compartilhamento de NFC.
    • É PRECISO implementar o servidor NPP. As mensagens recebidas pelo servidor NPP precisam ser processadas da mesma forma que o servidor padrão do SNEP.
    • PRECISA implementar um cliente SNEP e tentar enviar 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 PRECISA tentar enviar para um servidor NPP.
    • É NECESSÁRIO permitir que as atividades em primeiro plano definam a mensagem P2P NDEF de saída usando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback e android.nfc.NfcAdapter.enableForegroundNdefPush.
    • DEVE usar um gesto ou uma confirmação na tela, como "Tocar para transmitir", antes de enviar mensagens NDEF P2P de saída.
    • DEVE ativar o Android Beam por padrão e DEVE ser capaz de enviar e receber usando o Android Beam, mesmo quando outro modo P2P de NFC proprietário estiver ativado.
    • PRECISA oferecer suporte à transferência de conexão NFC para Bluetooth quando o dispositivo oferece suporte ao perfil de envio de objeto Bluetooth. As implementações de dispositivos precisam oferecer suporte à transferência de conexão para Bluetooth ao usar android.nfc.NfcAdapter.setBeamPushUris, implementando as especificações " Transferência de conexão versão 1.2 " e " Pareamento simples e seguro do Bluetooth usando NFC versão 1.0 " do Fórum NFC. Essa implementação PRECISA implementar o serviço de transferência LLCP com o nome de serviço "urn:nfc:sn:handover" para trocar os registros de solicitação/seleção de transferência por NFC e PRECISA usar o perfil de envio de objeto Bluetooth para a transferência real de dados Bluetooth. Por motivos de compatibilidade com versões anteriores (para permanecer compatível com dispositivos Android 4.1), a implementação PRECISA aceitar solicitações SNEP GET para trocar os registros de solicitação de transferência/seleção por NFC. No entanto, uma implementação não deve enviar solicitações GET do SNEP para realizar a transferência de conexão.
    • É PRECISO pesquisar todas as tecnologias compatíveis no modo de descoberta NFC.
    • DEVE estar no modo de descoberta de NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.

Os links disponíveis publicamente não estão disponíveis para as especificações do JIS, ISO e NFC Forum citadas acima.

O Android inclui suporte para o modo de emulação de cartão host (HCE) do NFC. Se uma implementação de dispositivo incluir um chipset de controlador NFC compatível com HCE (para NfcA e/ou NfcB) e oferecer suporte ao roteamento de ID do aplicativo (AID), ela:

  • É PRECISO informar a constante de recurso android.hardware.nfc.hce.
  • PRECISA oferecer suporte a APIs HCE NFC, conforme definido no SDK do Android.

Se uma implementação de dispositivo incluir um chipset de controlador NFC compatível com HCE para NfcF e implementar o recurso para aplicativos de terceiros, ele:

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

  • MIFARE Classic
  • MIFARE Ultralight
  • NDEF no MIFARE Classic

O Android inclui APIs para esses tipos de MIFARE. Se uma implementação de dispositivo oferecer suporte a MIFARE na função de leitor/gravador, ela:

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

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

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 a NFC ou declarem o recurso android.hardware.nfc.

7.4.5. Capacidade mínima de rede

As implementações de dispositivos precisam incluir suporte a 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.

Implementações de dispositivos em que um padrão de rede física (como Ethernet) é a conexão de dados principal DEVEM incluir suporte a 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 , e as APIs nativas, como os soquetes AF_INET6. O nível necessário de suporte ao IPv6 depende do tipo de rede, conforme descrito abaixo:

  • Os dispositivos compatíveis com redes Wi-Fi precisam oferecer suporte à operação de pilha dupla e somente IPv6 no Wi-Fi.
  • Os dispositivos compatíveis com redes Ethernet precisam ser compatíveis com a operação de pilha dupla em Ethernet.
  • Os dispositivos compatíveis com dados móveis DEVEM oferecer suporte à operação IPv6 (somente IPv6 e possivelmente pilha dupla) em dados móveis.
  • Quando um dispositivo está conectado a mais de uma rede ao mesmo tempo (por exemplo, Wi-Fi e dados móveis), ele PRECISA atender simultaneamente a esses requisitos em cada rede à qual está conectado.

O IPv6 PRECISA estar ativado por padrão.

Para garantir que a comunicação IPv6 seja tão confiável quanto o IPv4, os pacotes unicast IPv6 enviados ao dispositivo NÃO PODEM ser descartados, mesmo quando a tela não está em um estado ativo. Pacotes IPv6 de multicast redundantes, como anúncios de roteador idênticos repetidos, PODEM ter a taxa limitada em hardware ou firmware, se isso for necessário para economizar energia. Nesses casos, a limitação de taxa NÃO pode fazer com que o dispositivo perca a conectividade IPv6 em qualquer rede compatível com IPv6 que use tempos de vida de RA de pelo menos 180 segundos.

A conectividade IPv6 PRECISA ser mantida no modo de suspensão.

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 getMasterSyncAutomatically() retorne "true".

7.4.7. Economia de dados

É ALTAMENTE RECOMENDADO que as implementações de dispositivos com uma conexão tarifada ofereçam o modo de economia de dados.

Se uma implementação do dispositivo oferecer o modo de Economia de dados, ele:

  • PRECISA oferecer suporte a todas as APIs na classe ConnectivityManager, conforme descrito na documentação do SDK.

  • É PRECISO fornecer uma interface do usuário nas configurações, permitindo que os usuários adicionem ou removam aplicativos da lista de permissões.

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

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

  • NÃO transmita ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

  • PRECISA ter uma atividade que processe a intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mas PODE implementá-la como uma operação nula.

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 oposta à tela. Ou seja, ela captura imagens do lado oposto 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 normalmente usada para capturar imagens do usuário, como em videoconferências e aplicativos semelhantes.

Se uma implementação de dispositivo incluir pelo menos uma câmera, será PRECISO que um aplicativo possa alocar simultaneamente três bitmaps RGBA_8888 iguais ao tamanho das imagens produzidas pelo sensor de câmera de maior resolução no dispositivo, enquanto a câmera estiver aberta para fins de visualização básica e captura de fotos.

7.5.1. Câmera traseira

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

  • PRECISA 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 o foco automático de hardware ou de software implementado no driver da câmera (transparente para o 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 PODERÁ estar aceso enquanto uma instância android.hardware.Camera.PreviewCallback estiver registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha ativado explicitamente o flash ativando os atributos FLASH_MODE_AUTO ou FLASH_MODE_ON de um objeto Camera.Parameters. Essa restrição não se aplica ao app de câmera do sistema integrado do dispositivo, mas apenas a apps de terceiros que usam Camera.PreviewCallback.

7.5.2. Câmera frontal

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

  • É PRECISO informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
  • TER uma resolução mínima de VGA (640 x 480 pixels).
  • NÃO use uma câmera frontal como padrão para a API Camera. A API de 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 do 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 fluxo mostrado por um app em uma CameraPreview, conforme abaixo:
    • Se a implementação do dispositivo puder ser girada pelo usuário (como automaticamente por um acelerômetro ou manualmente pela entrada do usuário), a visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação atual do dispositivo.
    • Se o aplicativo atual solicitou explicitamente que a tela da câmera fosse girada por uma chamada ao 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.
  • DEVE espelhar a imagem exibida pela visualização pós-processada da mesma forma que o fluxo de imagens da visualização da câmera. Se a implementação do dispositivo não oferecer suporte ao postview, esse requisito obviamente não se aplica.
  • NÃO ESPELHA a imagem estática ou os streams de vídeo capturados finais retornados aos callbacks do aplicativo ou comprometidos com o armazenamento de mídia.

7.5.3. Câmera externa

As implementações de dispositivos PODEM incluir suporte a uma câmera externa que não está necessariamente sempre conectada. Se um dispositivo tiver suporte para 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.
  • É PRECISO ter 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ções de vídeo, como MJPEG, para permitir a transferência de streams não codificados de alta qualidade (ou seja, streams de imagem brutos ou compactados de forma independente).
  • PODE oferecer suporte à codificação de vídeo baseada na câmera. Se houver suporte, um fluxo não codificado / MJPEG simultâneo (resolução QVGA ou superior) PRECISA estar acessível à implementação do dispositivo.

7.5.4. Comportamento da API Camera

O Android inclui dois pacotes de API para acessar a câmera. A API android.hardware.camera2 mais recente expõe o controle de câmera de nível inferior ao app, incluindo fluxos de streaming/fotos em sequência eficientes sem cópia e controles por frame de exposição, ganho, ganhos de balanço de branco, conversão de cores, redução de ruído, nitidez e muito mais.

O pacote de API mais antigo, android.hardware.Camera, é marcado como descontinuado no Android 5.0, mas, como ele ainda precisa estar disponível para que os apps usem implementações de dispositivos Android, é IMPRESCINDÍVEL garantir o suporte contínuo da API, conforme descrito nesta seção e no SDK do Android.

As implementações de dispositivos precisam implementar os seguintes comportamentos para as APIs relacionadas à câmera, para todas as câmeras disponíveis:

  • Se um app nunca tiver chamado android.hardware.Camera.Parameters.setPreviewFormat(int), o dispositivo PRECISA usar android.hardware.PixelFormat.YCbCr_420_SP para os dados de visualização fornecidos aos callbacks do app.
  • Se um app 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, o NV21 PRECISA ser o padrão.
  • Para android.hardware.Camera, as implementações de dispositivo precisam oferecer suporte ao formato YV12 (conforme indicado pela constante android.graphics.ImageFormat.YV12) para visualizações de câmera frontal e traseira. O codificador de vídeo e a câmera de hardware podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA oferecer suporte à 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 sem foco automático PRECISAM chamar qualquer instância registrada de android.hardware.Camera.AutoFocusCallback, mesmo que isso não tenha relevância para uma câmera sem foco automático. Isso se aplica a câmeras frontais. Por exemplo, embora a maioria das câmeras frontais não ofereça suporte ao foco automático, os callbacks da API ainda precisam ser "falsos", conforme descrito.

As implementações de dispositivos precisam reconhecer e honrar cada nome de parâmetro definido como uma constante na classe android.hardware.Camera.Parameters, se o hardware de destino oferecer suporte ao recurso. Se o hardware do dispositivo não oferecer suporte a um recurso, a API precisa se comportar conforme a documentação. Por outro lado, as implementações de dispositivos NÃO PODEM reconhecer ou honrar constantes de string transmitidas para o método android.hardware.Camera.setParameters() que não sejam documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos precisam oferecer suporte a todos os parâmetros padrão da câmera, se o hardware permitir, e NÃO podem oferecer suporte a tipos personalizados de parâmetros da câmera. Por exemplo, implementações de dispositivos que oferecem suporte à captura de imagens usando técnicas de High Dynamic Range (HDR) PRECISAM oferecer suporte ao parâmetro de câmera Camera.SCENE_MODE_HDR.

Como nem todas as implementações de dispositivo podem oferecer 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 flags de recursos do framework adequadas.

As implementações de dispositivos também precisam declarar os recursos de câmera individuais do android.hardware.camera2 pela propriedade android.request.availableCapabilities e declarar os flags de recursos apropriados. Um dispositivo precisa definir o flag de recurso se algum dos dispositivos de câmera conectados oferecer suporte a ele.

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 à loja 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 for adicionada à loja de mídia.

7.5.5. Orientação da câmera

As câmeras frontal e traseira, se presentes, PRECISAM estar orientadas de forma que a dimensão longa da câmera se alinhe à dimensão longa da tela. Ou seja, quando o dispositivo é segurado na orientação paisagem, as câmeras precisam capturar imagens na orientação paisagem. Isso se aplica independentemente da orientação natural do dispositivo, ou seja, se aplica a dispositivos com orientação principal de paisagem e retrato.

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos

Os dispositivos Android TV precisam ter pelo menos 4 GB de armazenamento não volátil disponível para dados privados do app.

A memória disponível para o kernel e o espaço do usuário em implementações de dispositivos PRECISA ser pelo menos igual ou maior que os valores mínimos especificados na 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 extragrandes
512 MB 816MB
  • xhdpi ou superior em telas pequenas/normais
  • hdpi ou mais em telas grandes
  • mdpi ou superior em telas extragrandes
608MB 944MB
  • 400 dpi ou mais em telas pequenas/normais
  • xhdpi ou superior em telas grandes
  • tvdpi ou superior em telas extragrandes
896MB 1.280 MB
  • 560 dpi ou mais em telas pequenas/normais
  • 400 dpi ou mais em telas grandes
  • xhdpi ou superior em telas extragrandes
1344MB 1.824 MB

Os valores mínimos de memória precisam ser adicionados a qualquer espaço de memória já dedicado a componentes de hardware, como rádio, vídeo e assim por diante, que não estão 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 sejam um relógio Android, PRECISAM retornar o valor "true" para ActivityManager.isLowRamDevice().

Os dispositivos Android TV precisam ter pelo menos 4 GB, e outras implementações de dispositivo precisam ter pelo menos 3 GB de armazenamento não volátil disponível para dados privados do aplicativo. Ou seja, a partição /data PRECISA ter pelo menos 4 GB para dispositivos Android TV e pelo menos 3 GB para outras implementações de dispositivos. É ALTAMENTE RECOMENDADO que as implementações de dispositivos com Android tenham pelo menos 4 GB de armazenamento não volátil para dados privados do aplicativo, para que possam fazer upgrade para as versões futuras da plataforma.

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

7.6.2. Armazenamento compartilhado do aplicativo

As implementações de dispositivos precisam oferecer armazenamento compartilhado para aplicativos, também chamados de "armazenamento externo compartilhado".

As implementações de dispositivos precisam ser configuradas com o armazenamento compartilhado montado por padrão, "pronto para uso". Se o armazenamento compartilhado não for 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 ao usuário, como um slot de cartão Secure Digital (SD). Se esse slot for usado para atender ao requisito de armazenamento compartilhado, a implementação do dispositivo:

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

Como alternativa, as implementações de dispositivo PODEM alocar armazenamento interno (não removível) como armazenamento compartilhado para apps, conforme incluído no projeto upstream do Android Open Source. As implementações de dispositivo 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, embora esse armazenamento possa compartilhar espaço com os dados privados do aplicativo, ele PRECISA ter pelo menos 1 GB de tamanho e ser montado em /sdcard (ou /sdcard PRECISA ser um link simbólico para o local físico se ele for montado em outro lugar).

As implementações de dispositivos precisam aplicar a permissão android.permission.WRITE_EXTERNAL_STORAGE conforme documentado nesse armazenamento compartilhado. Caso contrário, o armazenamento compartilhado PRECISA ser gravável por qualquer aplicativo que receba essa permissão.

As 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 que apenas aplicativos Android pré-instalados e privilegiados com a permissão WRITE_EXTERNAL_STORAGE gravem no armazenamento externo secundário, exceto ao gravar em diretórios específicos do pacote ou no URI retornado ao acionar a intent ACTION_OPEN_DOCUMENT_TREE.

No entanto, as implementações de dispositivos precisam expor o conteúdo das duas rotas de armazenamento de forma transparente pelo serviço de scanner de mídia do Android e pelo android.provider.MediaStore.

Independentemente da forma de armazenamento compartilhado usada, se a implementação do dispositivo tiver uma porta USB com suporte ao modo periférico USB, ela PRECISA fornecer algum mecanismo para acessar o conteúdo do armazenamento compartilhado em um computador host. As implementações de dispositivos PODEM usar o armazenamento em massa USB, mas PRECISAM 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, ele:

  • PRECISA ser compatível com o host de MTP do Android de referência, 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

É ALTAMENTE RECOMENDÁVEL que as implementações de dispositivo implementem o armazenamento adaptável se a porta do dispositivo de armazenamento removível estiver em um local estável de longo prazo, como no compartimento da bateria ou em outra capa protetora.

Implementações de dispositivos, como uma televisão, PODEM permitir a adoção por portas USB, já que o dispositivo deve ser estático e não móvel. No entanto, para outras implementações de dispositivos que são móveis por natureza, é ALTAMENTE RECOMENDÁVEL implementar o armazenamento adaptável em um local estável de longo prazo, já que a desconexão acidental pode causar perda/corrupção de dados.

7.7. USB

As implementações de dispositivos precisam oferecer suporte ao modo de periférico USB e ao modo de host USB.

7.7.1. Modo de periférico USB

Se uma implementação de dispositivo incluir uma porta USB com suporte ao modo periférico:

  • A porta PRECISA ser compatível com um host USB que tenha uma porta USB tipo A ou tipo C padrão.
  • A porta DEVE usar o formato USB micro-B, micro-AB ou Type-C. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
  • A porta DEVE estar localizada na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação de tela de software para todos os apps (incluindo a tela inicial), para que a tela seja renderizada corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
  • Ele PRECISA permitir que um host USB conectado ao dispositivo Android acesse o conteúdo do volume de armazenamento compartilhado usando o armazenamento em massa USB ou o protocolo de transferência de mídia.
  • Ele PRECISA implementar a API e a especificação do acessório aberto Android (AOA, na sigla em inglês) conforme documentado na documentação do SDK do Android. Se for um dispositivo portátil Android, ele PRECISA implementar a API AOA. Implementações de dispositivos que implementam a especificação AOA:
    • É PRECISO declarar suporte ao 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 string iInterface da descrição da interface do armazenamento em massa USB.
  • Ele PRECISA implementar suporte para consumir uma corrente de 1,5 A durante o chirp e o tráfego de HS, conforme especificado na especificação de carregamento de bateria USB, revisão 1.2. É FORTEMENTE RECOMENDADO que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
  • Os dispositivos USB-C precisam detectar carregadores de 1,5 A e 3,0 A de acordo com o padrão de resistor USB-C e detectar mudanças na propaganda.
  • Dispositivos Type-C que também oferecem suporte ao modo host USB são ALTAMENTE RECOMENDADOS para oferecer suporte à transmissão de energia para dados e troca de função de energia.
  • Os dispositivos Type-C precisam oferecer suporte à entrega de energia para carregamento de alta tensão e suporte a modos alternativos, como saída de tela.
  • O valor de iSerialNumber no descritor de dispositivo padrão do USB PRECISA ser igual ao valor de android.os.Build.SERIAL.
  • É ALTAMENTE RECOMENDÁVEL que os dispositivos Type-C não ofereçam suporte a métodos de carregamento proprietários que modifiquem a tensão do Vbus além dos níveis padrão ou alterem as funções de destino/fonte, já que isso 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 "FORTEMENTE RECOMENDADO", em versões futuras do Android, podemos exigir que todos os dispositivos tipo C ofereçam suporte à interoperabilidade total com carregadores tipo C padrão.

7.7.2. Modo de host USB

Se uma implementação de dispositivo incluir uma porta USB com suporte ao modo de host, ela:

  • DEVE usar uma porta USB Type-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, se for o caso, PRECISA ser enviado com um ou mais cabos que adaptem a porta a uma porta USB tipo A ou C padrão.
  • PODE usar uma porta USB micro-AB, mas, se for o caso, DEVE ser enviada com um ou mais cabos que adaptem a porta a uma porta USB padrão tipo A ou tipo C.
  • É ALTAMENTE RECOMENDÁVEL implementar a classe de áudio USB conforme documentado na documentação do SDK do Android.
  • PRECISA implementar a API 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; anunciando uma corrente de origem de pelo menos 1,5 A, conforme especificado na seção "Terminais" da [especificação do cabo e conector USB Type-C, revisão 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) para conectores USB Type-C ou usando o intervalo de corrente de saída da porta de carregamento downstream(CDP) conforme especificado nas especificações de carregamento de bateria USB, revisão 1.2 para conectores Micro-AB.
  • É ALTAMENTE RECOMENDADO que os dispositivos USB Type-C ofereçam suporte a DisplayPort, OFEREÇAM suporte a taxas de dados USB SuperSpeed e OFEREÇAM suporte ao fornecimento de energia para troca de dados e de funções.
  • Os dispositivos com portas do tipo A ou AB NÃO PODEM ser enviados com um adaptador que converta essa porta em um receptáculo do tipo C.
  • PRECISA reconhecer todos os dispositivos MTP (Media Transfer Protocol) conectados remotamente e tornar o conteúdo deles acessível pelas intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT e ACTION_CREATE_DOCUMENT, se o Storage Access Framework (SAF) for compatível.
  • Se estiver usando uma porta USB Type-C e incluindo suporte ao modo periférico, IMPLEMENTE a funcionalidade de porta de função dupla, conforme definido pela especificação USB Type-C (seção 4.5.1.3.3).
  • DEVE, se a funcionalidade de porta de função dupla tiver suporte, implementar o modelo Try.* mais adequado para o formato do dispositivo. Por exemplo, um dispositivo portátil PRECISA implementar o modelo Try.SNK.

7.8. Áudio

7.8.1. Microfone

As implementações para dispositivos portáteis, relógios e veículos Android precisam incluir um microfone.

As implementações de dispositivos PODEM omitir um microfone. No entanto, se uma implementação de dispositivo omitir um microfone, ela NÃO PODERÁ informar a constante do recurso android.hardware.microphone e PRECISA implementar a API de gravação de áudio pelo menos como no-ops, de acordo com a seção 7. Por outro lado, as implementações de dispositivos que têm um microfone:

  • É OBRIGATÓRIO informar a constante de recurso android.hardware.microphone.
  • DEVE 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.
  • É ALTAMENTE RECOMENDADO oferecer suporte à gravação de ultrassom, conforme descrito na seção 7.8.3.

7.8.2. Saída de áudio

Os dispositivos Android Watch podem incluir uma saída de áudio.

Implementações de dispositivos que incluem 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:

  • É PRECISO 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.
  • É ALTAMENTE RECOMENDADO oferecer suporte à reprodução próxima à ultrassônica, conforme descrito na seção 7.8.3.

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

A implementação do dispositivo 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 no ecossistema do Android, se uma implementação de dispositivo incluir uma ou mais portas de áudio analógico, pelo menos uma delas DEVE ser uma entrada de áudio de 3,5 mm com quatro condutores. Se uma implementação de dispositivo tiver um conector de áudio de 3,5 mm com quatro condutores, ele:

  • PRECISA oferecer suporte à reprodução de áudio em fones de ouvido estéreo e fones de ouvido estéreo com microfone e DEVE oferecer suporte à gravação de áudio em fones de ouvido estéreo com microfone.
  • PRECISA oferecer suporte a conectores de áudio TRRS com a ordem de pinagem CTIA e DEVE oferecer suporte a conectores de áudio com a ordem de pinagem OMTP.
  • É PRECISO 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 o android.intent.action.HEADSET_PLUG com o valor extra de microfone definido como 1.
  • É PRECISO oferecer suporte à detecção e ao mapeamento para os códigos de tecla dos três intervalos de impedância equivalente entre o microfone e os condutores de aterramento no plugue de áudio:
    • 70 ohms ou menos : KEYCODE_HEADSETHOOK
    • 210-290 Ohm : KEYCODE_VOLUME_UP
    • 360-680 Ohm : KEYCODE_VOLUME_DOWN
  • É ALTAMENTE RECOMENDÁVEL detectar e mapear para o código de tecla o seguinte intervalo de impedância equivalente entre o microfone e os condutores de aterramento no plugue de áudio:
    • 110-180 Ohm: KEYCODE_VOICE_ASSIST
  • PRECISA acionar ACTION_HEADSET_PLUG ao inserir um plugue, mas somente depois que todos os contatos no plugue tocarem nos segmentos relevantes na tomada.
  • Deve ser capaz de gerar pelo menos 150 mV ± 10% da tensão de saída em uma impedância de alto-falante de 32 ohms.
  • PRECISA ter uma tensão de polarização do microfone entre 1,8 V e 2,9 V.

7.8.3. Near-Ultrasound

O áudio próximo ao ultrassom é a faixa de 18,5 kHz a 20 kHz. As implementações de dispositivos precisam informar corretamente o suporte ao recurso de áudio de quase ultrassom pela API AudioManager.getProperty da seguinte maneira:

  • Se PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 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 ser de no máximo 15 dB abaixo da resposta em 2 kHz.
    • A relação sinal-ruído não ponderada do microfone de 18,5 kHz a 20 kHz para um tom de 19 kHz em -26 dBFS PRECISA ser maior ou igual a 50 dB.
  • Se PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND for "true", a resposta média do alto-falante em 18,5 kHz a 20 kHz PRECISA ser pelo menos 40 dB abaixo da resposta em 2 kHz.

7.9. Realidade virtual

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

7.9.1. Modo de realidade virtual

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 tem 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 e possa ser ativado por apps de RV usando android.app.Activity#setVrModeEnabled .

7.9.2. Realidade virtual de alto desempenho

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

  • 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.getExclusiveCores para retornar os números dos núcleos da CPU exclusivos para o aplicativo em primeiro plano. Se o núcleo exclusivo tiver suporte, ele NÃO PODERÁ permitir que outros processos do espaço do usuário sejam executados nele (exceto drivers de dispositivo usados pelo aplicativo), mas PODERÁ permitir que alguns processos do kernel sejam executados conforme necessário.
  • As implementações de dispositivos precisam oferecer suporte ao modo performance sustentado.
  • As implementações de dispositivos precisam oferecer suporte ao OpenGL ES 3.2.
  • As implementações de dispositivos precisam oferecer suporte ao nível 0 e PODEM oferecer suporte ao nível 1 do hardware 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 no modo de buffer compartilhado e expor as extensões na lista de extensões EGL disponíveis.
  • A GPU e a tela precisam sincronizar o acesso ao buffer frontal compartilhado para que a renderização alternada do olho do conteúdo de RV a 60 fps com dois contextos de renderização seja exibida sem artefatos de rasgo visíveis.
  • As implementações de dispositivo precisam implementar EGL_IMG_context_priority e expor a extensão na lista de extensões EGL disponíveis.
  • As implementações de dispositivo PRECISAM implementar GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 e GL_OVR_multiview_multisampled_render_to_texture e expor as extensões na lista de extensões GL disponíveis.
  • As implementações de dispositivos PRECISAM implementar EGL_EXT_protected_content e GL_EXT_protected_textures para que possam ser usadas na reprodução segura de vídeos de textura 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 3840x2160 a 30 fps e 40 Mbps (equivalente a 4 instâncias de 1920x1080 a 30 fps e 10 Mbps ou 2 instâncias de 1920x1080 a 60 fps e 20 Mbps).
  • As implementações de dispositivos precisam oferecer suporte a HEVC e VP9, precisam ser capazes de decodificar pelo menos 1920x1080 a 30 fps e 10 Mbps e precisam ser capazes de decodificar 3840x2160 a 30 fps e 20 Mbps (equivalente a quatro instâncias de 1920x1080 a 30 fps e 5 Mbps).
  • É ALTAMENTE RECOMENDÁVEL que as implementações do dispositivo ofereçam suporte ao recurso android.hardware.sensor.hifi_sensors e PRECISEM atender aos requisitos relacionados ao giroscópio, ao acelerômetro e ao magnetômetro para android.hardware.hifi_sensors.
  • As implementações de dispositivos precisam oferecer suporte à API HardwarePropertiesManager.getDeviceTemperatures e retornar valores precisos para a temperatura da pele.
  • A implementação do dispositivo PRECISA ter uma tela integrada, e a resolução PRECISA ser de pelo menos FullHD(1080p) e RECOMENDAMOS FORTEMENTE que seja QuadHD (1440p) ou mais recente.
  • A tela PRECISA medir entre 4,7 e 6 polegadas na diagonal.
  • A tela PRECISA ser atualizada a pelo menos 60 Hz no modo de RV.
  • A latência de exibição no tempo de comutação de cinza para cinza, branco para preto e preto para branco PRECISA SER ≤ 3 ms.
  • A tela PRECISA oferecer suporte a um modo de baixa persistência com persistência de ≤5 ms,sendo que a persistência é definida como o tempo em que um pixel emite luz.
  • As implementações de dispositivos precisam oferecer suporte à extensão de comprimento de dados do Bluetooth 4.2 e do Bluetooth LE seção 7.4.3.

8. Desempenho e energia

Alguns critérios mínimos de desempenho e energia são essenciais para a experiência do usuário e afetam as suposições de referência que os desenvolvedores teriam ao desenvolver um app. Os dispositivos Android Watch e outros tipos de implementações de dispositivos precisam atender aos seguintes critérios.

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

As implementações de dispositivos precisam fornecer uma interface do usuário suave, garantindo uma taxa de frames e tempos de resposta consistentes para aplicativos e jogos. As implementações de dispositivos precisam atender aos seguintes requisitos:

  • Latência consistente de frames . A latência inconsistente ou um atraso na renderização de frames NÃO PODE acontecer mais de 5 vezes por segundo e DEVE ser inferior a 1 frame por segundo.
  • Latência da interface do usuário . As implementações de dispositivos precisam garantir uma experiência do usuário com baixa latência, rolando uma lista de 10 mil entradas, conforme definido pelo conjunto de testes de compatibilidade do Android (CTS, na sigla em inglês), em menos de 36 segundos.
  • Troca de tarefas . Quando vários aplicativos são iniciados, a reabertura de um aplicativo já em execução precisa levar menos de um segundo.

8.2. Desempenho de acesso a E/S de arquivos

As implementações de dispositivos precisam garantir a consistência do desempenho de acesso a arquivos de 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 um 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 um 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 ser mostrados ao usuário final. Além disso, o acionamento, a manutenção, os algoritmos de ativação e o uso das configurações globais do sistema desses modos de economia de energia NÃO PODEM se desviar do Projeto de código aberto do Android.

Além dos modos de economia de energia, as implementações de dispositivos Android PODEM implementar qualquer um ou todos os quatro estados de energia em suspensão, conforme definido pela interface Advanced Configuration and Power (ACPI). No entanto, se ela implementar os estados de energia S3 e S4, só será possível entrar nesses 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 do app 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 rastrear o consumo de energia do componente de hardware e atribuir esse consumo a aplicativos específicos. Especificamente, as implementações:
    • É NECESSÁRIO fornecer um perfil de energia por componente que defina o valor de consumo atual para cada componente de hardware e o consumo aproximado da bateria causado pelos componentes ao longo do tempo, conforme documentado no site do Projeto Android Open Source.
    • DEVEM 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.
    • É PRECISO informar o consumo de energia da CPU por UID de cada processo. O Android Open Source Project atende ao requisito com a implementação do módulo do kernel uid_cputime.
  • É OBRIGATÓRIO disponibilizar esse uso de energia ao desenvolvedor do app pelo comando de shell adb shell dumpsys batterystats.
  • PRECISA honrar a intent android.intent.action.POWER_USAGE_SUMMARY e mostrar um menu de configurações que mostre esse uso de energia.

8.5. Desempenho consistente

A performance pode variar drasticamente em apps de longa duração de alto desempenho, seja por causa de outros apps em execução em segundo plano ou do estrangulamento da CPU devido a limites de temperatura. O Android inclui interfaces programáticas para que, quando o dispositivo for compatível, o aplicativo em primeiro plano possa solicitar que o sistema otimize a alocação dos recursos para lidar com essas flutuações.

As implementações de dispositivos PRECISAM oferecer suporte ao 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 da API Window.setSustainedPerformanceMode(). Uma implementação de dispositivo PRECISA informar o suporte ao modo performance sustentado com precisão pelo método da API PowerManager.isSustainedPerformanceModeSupported().

As implementações de dispositivos com duas ou mais CPUs precisam fornecer pelo menos uma CPU exclusiva que possa ser reservada pelo aplicativo em primeiro plano. Se fornecidas, as implementações precisam atender aos seguintes requisitos:

  • As implementações precisam informar os números de ID das cores exclusivas que podem ser reservadas pelo aplicativo em primeiro plano pelo método da API Process.getExclusiveCores().
  • As implementações de dispositivos NÃO PODEM permitir que nenhum processo de espaço do usuário, exceto os drivers de dispositivo usados pelo aplicativo, sejam executados nos núcleos exclusivos, mas PODEM permitir que alguns processos do kernel sejam executados conforme necessário.

Se uma implementação de dispositivo não oferecer suporte a um núcleo exclusivo, ela PRECISA retornar uma lista vazia pelo método da 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 sobre segurança e permissões nas APIs da documentação para desenvolvedores do Android. As implementações de dispositivos precisam oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades. Especificamente, os dispositivos compatíveis precisam oferecer suporte aos mecanismos de segurança descritos nas subseções a seguir.

9.1. Permissões

As implementações de dispositivos precisam oferecer suporte ao modelo de permissões do Android, conforme definido na documentação para desenvolvedores do 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Ó PODEM ser concedidas a apps pré-carregados nos caminhos privilegiados permitidos da imagem do sistema, como o caminho system/priv-app na implementação do AOSP.

As permissões com nível de proteção perigoso são de execução. Os aplicativos com targetSdkVersion > 22 solicitam isso no momento da 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 e também fornecer uma interface para que o usuário gerencie as permissões de execução.
  • Deve ter uma e apenas uma implementação das duas interfaces do usuário.
  • NÃO conceda nenhuma permissão de execução a apps pré-instalados, a menos que:
    • o consentimento do usuário pode ser obtido antes que o aplicativo o use
    • as permissões de execução são associadas a um padrão de intent em que o aplicativo pré-instalado é definido como o gerenciador padrão;

9.2. Isolamento de UID e processo

As implementações de dispositivos precisam oferecer suporte ao modelo de sandbox de aplicativos Android, em que cada aplicativo é executado como um UID no estilo Unix exclusivo e em um processo separado. As implementações de dispositivos precisam oferecer suporte à execução de vários aplicativos como o mesmo ID de usuário do Linux, desde que os aplicativos sejam assinados e criados 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 oferecer suporte ao modelo de permissões de acesso a arquivos do Android, conforme definido na referência de segurança e permissões.

9.4. Ambientes de execução alternativos

As implementações de dispositivos PODEM incluir ambientes de execução que executam apps usando algum outro software ou tecnologia que não seja o formato executável Dalvik ou o código nativo. No entanto, esses ambientes de execução alternativos NÃO PODEM comprometer o modelo de segurança do Android ou a segurança dos aplicativos Android instalados, conforme descrito nesta seção.

Os ambientes de execução alternativos precisam ser aplicativos Android e obedecer ao modelo de segurança padrão do Android, conforme descrito em outra parte da seção 9.

Não é permitido que ambientes de execução alternativos tenham acesso a recursos protegidos por permissões não solicitadas no arquivo AndroidManifest.xml do ambiente de execução pelo mecanismo <uses-permission>.

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

Os ambientes de execução alternativos precisam obedecer ao modelo de sandbox do Android. Especificamente, os ambientes de execução alternativos:

  • DEVE instalar apps pelo PackageManager em sandboxes do Android separados (IDs de usuário do Linux etc.).
  • PODE fornecer um único sandbox do Android compartilhado por todos os aplicativos que usam o ambiente de execução alternativo.
  • Os aplicativos instalados que usam um ambiente de execução alternativo NÃO PODEM reutilizar o sandbox de nenhum outro app instalado no dispositivo, exceto pelos mecanismos padrão do Android de ID de usuário compartilhado e certificado de assinatura.
  • NÃO PODE ser iniciado com, conceder ou receber acesso aos sandboxes correspondentes a outros apps Android.
  • NÃO PODE ser iniciado com, receber ou conceder a outros aplicativos quaisquer privilégios do superusuário (raiz) ou de qualquer outro ID de usuário.

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

Ao instalar aplicativos, os ambientes de execução alternativos precisam receber o consentimento do usuário para as permissões do Android usadas pelo aplicativo. Se um app precisar usar um recurso do dispositivo que tenha uma permissão correspondente do Android (como câmera, GPS etc.), o ambiente de execução alternativo PRECISA informar ao usuário que o app 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.

9.5. Suporte a vários usuários

Esse recurso é opcional para todos os tipos de dispositivo.

O Android inclui suporte para vários usuários e oferece suporte para isolamento total do usuário. As implementações de dispositivos PODEM ativar 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 para vários usuários ATIVADO PRECISAM incluir uma conta de visitante que permita todas as funções fornecidas pelo sistema do veículo sem exigir que um 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 aos proprietários de dispositivos gerenciar outros usuários e os recursos deles no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para que outros usuários trabalhem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.
  • Por outro lado, implementações de dispositivos que declaram a flag de recurso android.hardware.telephony NÃO podem oferecer suporte a perfis restritos, mas precisam estar alinhadas com a implementação de controles do AOSP para permitir /desabilitar o acesso de outros usuários às chamadas de voz e SMS.
  • As implementações de dispositivo precisam implementar, para cada usuário, um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência sobre segurança e permissões nas 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 de vários usuários no mesmo volume ou sistema de arquivos. No entanto, a implementação do dispositivo PRECISA garantir que os apps pertencentes a um determinado usuário e executados em nome dele não possam listar, ler ou gravar dados de outro usuário. As mídias removíveis, como slots de cartão SD, podem permitir que um usuário acesse os dados de outro por meio de 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 a opção de vários usuários estiver ativada usando uma chave armazenada apenas em mídia não removível acessível apenas ao sistema. Como isso torna a mídia ilegível para um PC host, as implementações de dispositivo precisam mudar para MTP ou um sistema semelhante para fornecer aos PCs host acesso aos dados do usuário atual. Portanto, as implementações de dispositivos PODEM, mas NÃO DEVEM, ativar o acesso de vários usuários 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. SMS premium são mensagens de texto enviadas para um serviço registrado com uma operadora que pode gerar cobranças para o usuário. As implementações de dispositivo que declaram suporte para android.hardware.telephony precisam avisar os usuários antes de enviar uma mensagem SMS para números identificados por expressões regulares definidas no arquivo /data/misc/sms/codes.xml no dispositivo. O Android Open Source Project upstream oferece uma implementação que atende a esse requisito.

9.7. Recursos de segurança do kernel

O Sandbox do Android inclui recursos que usam o sistema de controle de acesso obrigatório (MAC) do Security-Enhanced Linux (SELinux), o sandbox do seccomp e outros recursos de segurança no kernel do Linux. SELinux ou qualquer outro recurso de segurança implementado abaixo do framework 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 é detectada e bloqueada, mas PODE ter uma interface do usuário visível quando ocorre uma violação de segurança não bloqueada que resulta em uma exploração bem-sucedida.
  • NÃO pode ser configurado pelo usuário ou pelo desenvolvedor.

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

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

Implementações de dispositivos:

  • PRECISA definir o SELinux como o modo de aplicação global.
  • É PRECISO configurar todos os domínios no modo de aplicação. Nenhum domínio no modo permissivo é permitido, incluindo domínios específicos de um dispositivo/fabricante.
  • NÃO PODE modificar, omitir ou substituir as regras de neverallow presentes na pasta system/sepolicy fornecida no upstream do Android Open Source Project (AOSP), e a política PRECISA ser compilada com todas as regras de neverallow presentes, tanto para domínios AOSP SELinux quanto para domínios específicos de dispositivo/fornecedor.
  • É necessário 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 Projeto de código aberto do Android.

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

Os dispositivos PRECISAM implementar um mecanismo de sandbox de aplicativo do kernel que permita a filtragem de chamadas do sistema usando uma política configurável de programas multithread. O Android Open Source Project upstream atende a esse requisito ativando o seccomp-BPF com sincronização de threadgroup (TSYNC), conforme descrito na seção "Configuração do kernel" do source.android.com.

9,8. Privacidade

Se o dispositivo implementar uma funcionalidade no sistema que capture o conteúdo exibido na tela e/ou grave o fluxo de áudio reproduzido no dispositivo, ele PRECISA notificar continuamente o usuário sempre que essa funcionalidade estiver ativada e capturar/gravar ativamente.

Se uma implementação de dispositivo tiver um mecanismo que roteie o tráfego de dados de rede por um servidor proxy ou gateway de VPN por padrão (por exemplo, pré-carregando um serviço de VPN com o android.permission.CONTROL_VPN concedido), a implementação do dispositivo PRECISA pedir o consentimento do usuário antes de ativar esse mecanismo, a menos que essa VPN seja ativada pelo Device Policy Controller pelo 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 uma loja de autoridades certificadoras (ACs) adicionadas pelo usuário vazia e precisam pré-instalar os mesmos certificados raiz para a loja de ACs confiáveis do sistema fornecidos no projeto upstream do Android Open Source.

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

Se uma implementação de dispositivo tiver uma porta USB com suporte ao modo de acessório USB, ela PRECISA apresentar uma interface que solicite o consentimento do usuário antes de permitir o acesso ao conteúdo do armazenamento compartilhado pela porta USB.

9,9. Criptografia de armazenamento de dados

Opcional para implementações de dispositivos Android sem uma tela de bloqueio segura.

Se a implementação do dispositivo oferecer suporte a uma tela de bloqueio segura, conforme descrito na seção 9.11.1, o dispositivo PRECISA oferecer suporte à criptografia de armazenamento de dados dos dados privados do aplicativo (partição /data) e da partição de armazenamento compartilhada do aplicativo (partição /sdcard) se ela for uma parte permanente e não removível do dispositivo.

Para implementações de dispositivos com suporte à criptografia de armazenamento de dados e com desempenho de criptografia de padrão de criptografia avançada (AES) acima de 50 MiB/s, a criptografia de armazenamento de dados PRECISA ser ativada por padrão quando o usuário concluir a experiência de configuração inicial. 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 poderá atender ao requisito com uma atualização de software do sistema e, portanto, PODE ser dispensado.

As implementações de dispositivos precisam atender ao requisito de criptografia de armazenamento de dados acima ao implementar a Criptografia baseada em arquivos (FBE).

9.9.1. Inicialização direta

Todos os dispositivos precisam implementar as APIs do modo de inicialização direta, mesmo que não ofereçam suporte à criptografia de armazenamento. Especificamente, as intents LOCKED_BOOT_COMPLETED e ACTION_USER_UNLOCKED ainda precisam ser transmitidas para sinalizar aos aplicativos com suporte ao Direct Boot que os locais de armazenamento com criptografia de dispositivo (DE) e criptografia de credencial (CE) estão disponíveis para o usuário.

9.9.2. Criptografia baseada em arquivos

Implementações de dispositivos com suporte a FBE:

  • PRECISA ser inicializado sem pedir credenciais ao usuário e permitir que apps compatíveis com a inicialização direta acessem o armazenamento criptografado pelo dispositivo (DE, na sigla em inglês) depois que a mensagem LOCKED_BOOT_COMPLETED for transmitida.
  • Só é permitido o acesso ao armazenamento criptografado por credenciais (CE) depois que o usuário desbloqueia o dispositivo fornecendo as credenciais (por exemplo, senha, PIN, padrão ou impressão digital) e a mensagem ACTION_USER_UNLOCKED é 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.
  • DEVE oferecer suporte à inicialização verificada e garantir que as chaves de DE sejam vinculadas criptograficamente à raiz de confiança de hardware do dispositivo.
  • PRECISA oferecer suporte à criptografia do conteúdo do arquivo usando AES com uma chave de 256 bits no modo XTS.
  • PRECISA oferecer suporte à criptografia do nome do arquivo usando AES com um comprimento de chave de 256 bits no modo CBC-CTS.
  • PODE oferecer suporte a cifras, comprimentos de chave e modos alternativos para criptografia de conteúdo e nome de arquivo, mas PRECISA usar as cifras, comprimentos de chave e modos com suporte obrigatório por padrão.
  • É NECESSÁRIO que os apps essenciais pré-carregados (por exemplo, Alarm, Phone, Messenger) sejam compatíveis com a inicialização direta.

As chaves que protegem as áreas de armazenamento de 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 de um usuário. Se o usuário não especificou credenciais para a tela de bloqueio, as chaves de CE precisam estar vinculadas a uma senha padrão.
  • PRECISA ser exclusivo e distinto. Em outras palavras, nenhuma chave CE ou DE de um usuário pode corresponder a qualquer outra chave CE ou DE.

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 com suporte para criptografia de disco completo (FDE). É OBRIGATÓRIO usar o AES com uma chave de 128 bits (ou mais) e um modo projetado para armazenamento (por exemplo, AES-XTS, AES-CBC-ESSIV). A chave de criptografia NÃO PODE ser gravada no armazenamento sem ser criptografada. Além do uso ativo, a chave de criptografia DEVE ser criptografada com AES com as credenciais da tela de bloqueio esticadas usando um algoritmo de alongamento lento (por exemplo, PBKDF2 ou scrypt). Se o usuário não tiver especificado credenciais da tela de bloqueio ou tiver desativado o uso da senha para criptografia, o sistema PRECISA usar uma senha padrão para agrupar a chave de criptografia. Se o dispositivo oferecer um keystore protegido por hardware, o algoritmo de alongamento de senha PRECISA estar vinculado criptograficamente a esse keystore. A chave de criptografia NÃO PODE ser enviada do dispositivo, mesmo quando envolvida com a senha do usuário e/ou a chave vinculada ao hardware. O projeto upstream do Android Open Source oferece uma implementação preferencial desse recurso com base no recurso dm-crypt do kernel do Linux.

9.10. Integridade do dispositivo

Os requisitos a seguir garantem a transparência do status da integridade do dispositivo.

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 estão sendo atualizadas de uma versão anterior do Android, em que esse novo método da 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:

  • Declare a flag de recurso da plataforma android.software.verified_boot.
  • Faça a verificação em cada sequência de inicialização.
  • Inicie a verificação em uma chave de hardware imutável que seja a raiz de confiança e vá até a partição do sistema.
  • Implemente cada etapa de verificação para verificar a integridade e a autenticidade de todos os bytes na próxima etapa antes de executar o código na próxima etapa.
  • 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 DEVE permitir que a inicialização seja concluída quando a verificação do sistema falhar, a menos que o usuário consinta tentar a inicialização. Nesse caso, os dados de qualquer bloco de armazenamento não verificado NÃO PODEM ser usados.
  • NÃO DEVE permitir que as 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 upstream oferece uma implementação preferencial desse recurso com base no recurso dm-verity do kernel do Linux.

A partir do Android 6.0, as implementações de dispositivos com desempenho criptográfico do Advanced Encryption Standard (AES) acima de 50 MiB/segundos precisam oferecer suporte à inicialização verificada para a integridade do dispositivo.

Se uma implementação de dispositivo já foi lançada sem oferecer suporte à inicialização verificada em uma versão anterior do Android, esse dispositivo não pode adicionar suporte a esse recurso com uma atualização do software do sistema e, portanto, está isento do requisito.

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 pela API KeyChain ou pela 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 DEVE permitir a importação de pelo menos 8.192 chaves.
  • A autenticação da tela de bloqueio PRECISA limitar a taxa de tentativas e PRECISA ter um algoritmo de espera exponencial. Após 150 tentativas, o atraso DEVE 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:
    • É PRECISO ter implementações de hardware com suporte a 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 aceitos pelo sistema do Keystore do Android.
    • PRECISA realizar a autenticação da tela de bloqueio no hardware seguro e permitir o uso das chaves vinculadas à autenticação somente quando for bem-sucedida. O upstream do Android Open Source Project fornece a camada de abstração de hardware (HAL) do 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, ele estará isento do requisito de ter uma keystore protegida por hardware, a menos que declare o recurso android.hardware.fingerprint, que exige uma keystore protegida por hardware.

9.11.1. Tela de bloqueio segura

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 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 substitua nenhum dos métodos de autenticação (PIN, padrão, senha) implementados e fornecidos no AOSP.
    • PRECISA ser desativado quando o aplicativo do controlador de políticas do dispositivo (DPC) tiver definido a política de qualidade da 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:
    • Ele PRECISA ter um mecanismo de fallback para usar um dos métodos de autenticação principais, que é baseado em um secret conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
    • Ele PRECISA ser desativado e permitir que apenas a autenticação primária desbloqueie a tela quando o aplicativo do controlador de políticas do dispositivo (DPC) tiver definido a política com o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou DevicePolicyManager.setPasswordQuality() com uma constante de qualidade mais restritiva 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:
    • Ele PRECISA ter um mecanismo de fallback para usar um dos métodos de autenticação principais, que é baseado em um secret conhecido e atende aos requisitos para ser tratado como uma tela de bloqueio segura.
    • Ele PRECISA ser desativado e permitir que apenas a autenticação primária desbloqueie a tela quando o aplicativo do controlador de políticas do dispositivo (DPC) tiver definido a política de recurso de proteção de chaves chamando o método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
    • Ela PRECISA ter uma taxa de aceitação falsa igual ou mais forte do que a exigida para um sensor de impressão digital, conforme descrito na seção 7.3.10. Caso contrário, ela PRECISA ser desativada e permitir apenas que a autenticação primária desbloqueie a tela quando o aplicativo de controle de política de dispositivo (DPC) tiver definido a política de qualidade da 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:
  • Se o método de autenticação for baseado em um token físico, no local ou na biometria que tenha uma taxa de aceitação falsa maior do que a necessária para sensores de impressão digital, conforme descrito na seção 7.3.10, então:

9.12. Exclusão de dados

Os dispositivos precisam oferecer aos usuários um mecanismo para realizar uma "Redefinição de dados de fábrica" que permita a exclusão lógica e física de todos os dados, exceto:

  • A imagem do sistema
  • Todos os arquivos do sistema operacional necessários para a imagem do sistema

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

Os dispositivos PODEM oferecer uma exclusão rápida de dados que realiza um apagamento lógico de dados.

9.13. Modo de inicialização segura

O Android oferece um modo que permite que os usuários inicializem em um modo em que apenas os apps do sistema pré-instalados podem ser executados e todos os apps de terceiros são desativados. Esse modo, conhecido como "Modo de inicialização segura", permite que o usuário desinstale apps de terceiros potencialmente nocivos.

É ALTAMENTE RECOMENDADO que as implementações de dispositivos Android implementem o modo de inicialização segura e atendam aos seguintes requisitos:

  • As implementações de dispositivos PRECISAM oferecer ao usuário a opção de entrar no modo de inicialização segura pelo menu de inicialização, que pode ser acessado por um fluxo de trabalho diferente do da 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 forma ininterruptível por apps de terceiros instalados no dispositivo, exceto quando o app de terceiros é um controlador de política de dispositivo e definiu 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 do sistema de veículos automotivos

Espera-se que os dispositivos Android Automotive troquem dados com subsistemas críticos do veículo, por exemplo, usando o HAL do veículo para enviar e receber mensagens em redes de veículos, como o barramento CAN. As implementações de dispositivos do 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 os subsistemas do veículo. Esses recursos de segurança são os seguintes:

  • Mensagens de controle de acesso de subsistemas de veículos do framework do Android, por exemplo, a lista de permissões de tipos e fontes de mensagens.
  • Watchdog contra ataques de negação de serviço do framework do Android ou de apps de terceiros. Isso protege contra softwares maliciosos que inundam a rede do veículo com tráfego, o que pode levar a um mau funcionamento dos subsistemas do veículo.

10. Teste de compatibilidade de software

As implementações de dispositivos precisam passar em todos os testes descritos nesta seção.

No entanto, nenhum pacote de teste de software é totalmente abrangente. Por esse motivo, É ALTAMENTE RECOMENDADO que os implementadores de dispositivos façam o menor número possível de mudanças na implementação de referência e preferida do Android disponível no Projeto Android Open Source. 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 ser aprovadas no Conjunto de teste de compatibilidade do Android (CTS) disponível no Projeto Android Open Source, usando o software de envio final no dispositivo. Além disso, os implementadores de dispositivos PRECISAM usar a implementação de referência na árvore do Android Open Source o máximo possível e PRECISAM garantir a compatibilidade em casos de ambiguidade no CTS e para qualquer nova implementação de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. A versão do CTS será independente 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 na 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 CTS. O Verificador do CTS está incluído no Compatibility Test Suite e é destinado a 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 Verificador do CTS tem testes para muitos tipos de hardware, incluindo alguns opcionais. As implementações de dispositivos precisam ser aprovadas em todos os testes de hardware que eles têm. Por exemplo, se um dispositivo tiver um acelerômetro, ele precisa executar corretamente o caso de teste do acelerômetro no Verificador do CTS. Os casos de teste para recursos indicados como opcionais neste documento de definição de compatibilidade PODEM ser pulados ou omitidos.

Todos os dispositivos e builds precisam executar corretamente o Verificador CTS, conforme observado acima. No entanto, como muitos builds são muito semelhantes, não é esperado que os implementadores de dispositivos executem explicitamente o Verificador do CTS em builds que diferem apenas de maneiras triviais. Especificamente, implementações de dispositivos que diferem de uma implementação que passou pelo Verificador do CTS apenas pelo conjunto de localidades, branding etc. incluídos 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 upgrades "ao vivo", ou seja, pode ser necessário reiniciar o dispositivo.

Qualquer método pode ser usado, desde que ele substitua todo o software pré-instalado no dispositivo. Por exemplo, qualquer uma das seguintes abordagens atende a esse requisito:

  • Downloads "over-the-air (OTA)" com atualização off-line por reinicialização.
  • Atualizações "conectadas" por USB de um PC host.
  • Atualizações "off-line" com 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 não tarifadas, como o perfil 802.11 ou Bluetooth PAN (rede de área pessoal), ele PRECISA oferecer suporte a downloads OTA com atualização off-line por reinicialização.

O mecanismo de atualização usado PRECISA oferecer suporte a atualizações sem apagar os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados privados e compartilhados do app. O software upstream do Android inclui um mecanismo de atualização que atende a esse requisito.

Para implementações de dispositivos lançadas com o Android 7.0 e versões mais recentes, o mecanismo de atualização PRECISA oferecer suporte à verificação de que a imagem do sistema é binária idêntica ao resultado esperado após uma OTA. A implementação OTA baseada em blocos no upstream do Android Open Source Project, adicionada desde o Android 5.1, atende a esse requisito.

Se um erro for encontrado em uma implementação de dispositivo após o lançamento, mas dentro de um período razoável de vida útil do produto determinado em consulta com a equipe de compatibilidade do Android para afetar a compatibilidade de apps de terceiros, o implementador do dispositivo PRECISA corrigir o erro com uma atualização de software disponível que pode ser aplicada de acordo com o mecanismo descrito.

O Android inclui recursos que permitem ao app proprietário do dispositivo (se presente) controlar a instalação de atualizações do sistema. Para facilitar isso, o subsistema de atualização do sistema para dispositivos que relatam android.software.device_admin PRECISA implementar o comportamento descrito na classe SystemUpdatePolicy.

12. Registro de alterações do documento

Para um resumo das mudanças na definição de compatibilidade nesta versão:

Confira um resumo das mudanças nas seções de pessoas:

  1. Introdução
  2. Tipos de dispositivo
  3. Software
  4. Embalagem do aplicativo
  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 para visualizar o registro de alterações

As mudanças são marcadas da seguinte maneira:

  • CDD
    Mudanças substanciais nos requisitos de compatibilidade.

  • Documentos
    Mudanças cosméticas ou relacionadas ao build.

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

13. Entre em contato

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