Definição de compatibilidade do Android 5.1

Índice

1. Introdução

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

O uso de “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” e “OPTIONAL” é conforme o padrão IETF definido em RFC2119 [Resources, 1].

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

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

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

Por esse motivo, o Android Open Source Project [Resources, 2] é a implementação de referência e preferida do Android. Recomendamos que os implementadores de dispositivos baseiem as implementações deles o mais possível no código-fonte "upstream" disponível no Android Open Source Project. Embora alguns componentes possam ser substituídos por implementações alternativas, essa prática é desencorajada, porque passar nos testes de software fica 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 listados na seção 14 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 conjunto de testes de compatibilidade discordar da documentação do SDK, a documentação do SDK será considerada autorizada. Todos os detalhes técnicos fornecidos nas referências incluídas na seção 14 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 na mão, como players de mp3, smartphones e tablets. Implementações de dispositivos Android portáteis:

  • 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 de relaxamento" 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 [Resources, 3].

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 [Resources, 4].

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 todo o sistema e/ou a funcionalidade de infoentretenimento. As implementações do Android Automotive precisam oferecer suporte a uiMode = UI_MODE_TYPE_CAR [Resources, 111].

Todas as implementações de dispositivos Android que não se encaixam em nenhum dos tipos de dispositivo acima PRECISAM atender a todos os requisitos deste documento para serem compatíveis com o Android 5.1, 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. (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 OBRIGATÓRIO 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
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 dispositivos precisam fornecer implementações completas, incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo SDK do Android [Resources, 5] ou qualquer API decorada com o marcador "@SystemApi" no código-fonte do Android upstream.

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 permitido especificamente 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 do dispositivo. 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.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 elementos como intents, permissões e aspectos semelhantes de apps Android que não podem ser aplicados no momento da compilação do aplicativo.

3.2.1. Permissões

Os implementadores de dispositivos precisam oferecer suporte e aplicar todas as constantes de permissão, conforme documentado na página de referência de permissões [Resources, 6]. 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 [Resources, 7] que descrevem 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 que as implementações de dispositivos PRECISAM seguir.

Parâmetro Detalhes
VERSION.RELEASE A versão do sistema Android em execução no momento, em formato legível por humanos. Esse campo PRECISA ter um dos valores de string definidos em [Resources, 8].
VERSION.SDK A versão do sistema Android em execução no momento, em um formato acessível ao código de aplicativo de terceiros. Para o Android 5.1, esse campo PRECISA ter o valor inteiro 22.
VERSION.SDK_INT A versão do sistema Android em execução no momento, em um formato acessível ao código de aplicativo de terceiros. Para o Android 5.1, esse campo PRECISA ter o valor inteiro 22.
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 deste 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, conforme 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) de 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) de 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 o nome 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_-]+$".
FINGERPRINT Uma string que identifica exclusivamente esse build. Ele PRECISA ser razoavelmente legível para humanos. Ele PRECISA seguir este modelo:

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

Por exemplo: acme/myproduct/mydevice:5.1/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 na impressão digital 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 PRECISA 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 forma exclusiva o host em que o build foi criado, em formato legível por humanos. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
ID Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão específica, em 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 deste 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 PRECISA ser exclusivo na mesma marca. PRECISA ser legível por humanos, mas não é necessariamente destinada a ser visualizada por usuários finais. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9_-]+$".
SERIAL Um número de série do hardware, que PRECISA estar disponível. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular “^([a-zA-Z0-9]{6,20})$”.
TAGS Uma lista separada por vírgulas de tags escolhidas pelo implementador do dispositivo que diferenciam 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 do ambiente de execução do Android: user, userdebug ou eng.
USUÁRIO Um nome ou ID do usuário (ou usuário automatizado) que gerou o build. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").

3.2.3. Compatibilidade de intents

As implementações de dispositivos precisam respeitar o sistema de intent de acoplamento flexível do Android, conforme descrito nas seções abaixo. "Atendido" significa que o implementador do dispositivo PRECISA fornecer uma atividade ou serviço do Android que especifique um filtro de intent correspondente que se vincula e implementa o comportamento correto para cada padrão de intent especificado.

3.2.3.1. Intents principais do aplicativo

As intents do Android permitem que os componentes do aplicativo solicitem a funcionalidade de outros componentes do Android. O projeto upstream do Android inclui uma lista de aplicativos considerados principais, 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 de forma adequada, mas precisam incluir um componente que implemente os mesmos padrões de intent definidos por todos os componentes de atividade ou serviço "públicos" desses principais aplicativos Android. Os componentes de atividade ou serviço são considerados "públicos" quando o atributo android:exported está ausente ou tem o valor "true".

3.2.3.2. Substituições de intent

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 do Android permitirá isso por padrão. Os implementadores de dispositivos NÃO PODEM anexar privilégios especiais ao uso de aplicativos do sistema desses padrões de intent ou impedir que aplicativos de terceiros se associem e assumam o controle desses padrões. Essa proibição inclui especificamente, mas não se limita a, desativar a interface do usuário "Chooser", que permite ao usuário selecionar entre vários aplicativos que processam o mesmo padrão de intent.

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) se a atividade padrão fornecer um filtro mais específico para o URI de dados. Por exemplo, um filtro de intent que especifica o URI de dados "http://www.android.com" é mais específico do que o filtro do navegador para "http://". As implementações de dispositivos precisam fornecer uma interface para que os usuários modifiquem a atividade padrão para intents.

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 DEVEM incluir componentes do Android que respeitem padrões de intent ou intent de transmissão usando uma string de ação, categoria ou outra chave em um espaço de pacote pertencente a outra organização. Os implementadores de dispositivos NÃO PODEM alterar ou ampliar nenhum dos padrões de intent usados pelos apps principais listados na seção 3.2.3.1. As implementações de dispositivos PODEM incluir padrões de intent usando namespaces claramente e obviamente associados à própria organização. Essa proibição é análoga à especificada para classes de linguagem Java na seção 3.6.

3.2.3.4. Intents de transmissão

Os aplicativos de terceiros dependem da plataforma para transmitir determinadas intents e notificar sobre mudanças no ambiente de hardware ou software. Dispositivos compatíveis com o Android precisam transmitir as intents de transmissão pública em resposta a 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 apropriado, as implementações de dispositivos precisam fornecer um menu de configurações semelhante e ser compatíveis com o padrão de filtro de intent e os métodos de API descritos na documentação do SDK, conforme abaixo.

Implementações de dispositivos:

  • É NECESSÁRIO 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 [Resources, 10]
  • É 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 [Resources, 9].
  • É NECESSÁRIO honrar a intent android.settings.NFC_PAYMENT_SETTINGS para mostrar um menu de configurações padrão do app para o recurso Pagar por aproximação, se a implementação do dispositivo informar android.hardware.nfc.hce [Resources, 10]

3.3. Compatibilidade com a API nativa

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 ELF .so compilado para a arquitetura de hardware do dispositivo. Como o código nativo é altamente dependente da tecnologia do processador subjacente, o Android define várias interfaces binárias de app (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:

  • É necessário 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 origem (ou seja, com o cabeçalho) e com o binário (para a ABI) com cada biblioteca necessária na lista abaixo
  • É PRECISO oferecer suporte à ABI de 32 bits equivalente se houver suporte para ABIs de 64 bits
  • PRECISA informar com precisão a interface binária de aplicativo (ABI) nativa apoiada 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 uma lista separada por vírgulas de ABIs ordenadas da mais para a menos preferida.
  • É OBRIGATÓRIO informar, pelos parâmetros acima, apenas as ABIs documentadas na versão mais recente do Android NDK, "NDK Programmer’s Guide | ABI Management" no diretório docs/.
  • DEVE ser criado usando o código-fonte e os arquivos de cabeçalho disponíveis no projeto upstream do Android Open Source

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

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

Versões futuras do Android NDK podem oferecer suporte a ABIs adicionais. 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 implementações do dispositivo precisam incluir libGLESv3.so e precisam ter um link simbólico (link simbólico) para libGLESv2.so. Por sua vez, precisam exportar todos os símbolos de função do OpenGL ES 3.1 e do pacote de extensão do Android [Resources, 11] conforme definido na versão do NDK android-21. 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.

A compatibilidade com o código nativo é desafiadora. Por esse motivo, os implementadores de dispositivos são fortemente recomendados a usar as implementações das bibliotecas listadas acima do Android Open Source Project.

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

A arquitetura ARMv8 descontinua várias operações de CPU, incluindo algumas operações 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 NDK do Android usavam /proc/cpuinfo para descobrir recursos de CPU do código nativo ARM de 32 bits. Para compatibilidade com aplicativos criados usando este NDK, os dispositivos PRECISAM incluir as seguintes linhas em /proc/cpuinfo quando ele for lido por aplicativos ARM de 32 bits:

  • "Recursos", seguido de uma lista de recursos opcionais de CPU ARMv7 com suporte do dispositivo.
  • "Arquitetura da CPU: ", seguido por um número inteiro que descreve a arquitetura ARM mais recente 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 PRECISA 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 [Resources, 12]. 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 5.1. Esse build inclui um conjunto específico de correções de funcionalidade e segurança para a WebView [Resources, 13].
  • A string do agente do usuário informada pela WebView PRECISA estar neste formato:

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

    • O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
    • A string $(WEBVIEW) PODE ser omitida, mas, se incluída, PRECISA ser "; wv" para indicar que se trata de uma webview.
    • 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 ele oferecer suporte ao recurso, PRECISA estar em conformidade com a especificação HTML5 [Resources, 14].

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 dispositivo precisam incluir um aplicativo de navegador independente para navegação geral do usuário.

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) PRECISA incluir suporte para o maior número possível de recursos do HTML5 [Resources, 14]. 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 [Resources, 18] e à API IndexedDB do HTML5/W3C [Resources, 19]. Como os órgãos de padrões de desenvolvimento da Web estão fazendo a transição para favorecer o IndexedDB em vez do WebStorage, espera-se que ele se torne um componente obrigatório em uma versão futura do Android.

3.5. Compatibilidade comportamental da API

Os comportamentos de cada um dos tipos de API (gerenciada, soft, nativa e da Web) precisam ser consistentes com a implementação preferencial do projeto de código aberto do Android upstream [Resources, 2]. 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 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 DEVEM usar o código-fonte disponível no Projeto Android Open Source sempre que possível, em vez de reimplementar 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" usado no código-fonte do Android upstream. Em outras palavras, os implementadores de dispositivos NÃO PODEM expor novas APIs nem alterar APIs existentes 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 espaço de nome 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. Somente 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. Esta seção tem como objetivo apenas reforçar essas convenções e torná-las obrigatórias pela 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 [Resources, 20]. 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 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
pequeno/normal 120 dpi (ldpi) 32MB
160 dpi (mdpi)
213 dpi (tvdpi) 48MB
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 80MB
400 dpi (400dpi) 96MB
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
400 dpi (400dpi) 192MB
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
400 dpi (400dpi) 288MB
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 oferece suporte a aplicativos de terceiros para substituir o acesso rápido do dispositivo (tela inicial). As implementações de dispositivos que permitem que aplicativos de terceiros substituam a tela inicial do dispositivo PRECISAM declarar o recurso 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 a dispositivos portáteis Android.

O Android define um tipo de componente e a API e o ciclo de vida correspondentes que permitem que os aplicativos exponham um "AppWidget" ao usuário final [Resources, 21], um recurso que é ALTAMENTE RECOMENDADO que seja compatível com 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 da plataforma android.software.app_widgets.

  • Os inicializadores de dispositivos precisam incluir suporte integrado a widgets de app e expor 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 [Resources, 21] para mais detalhes.
  • 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 [Resources, 22], 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 [Resources, 23], ou no guia de estilo de ícones da barra de status/sistema [Resources, 24], 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 de usuário alternativa para notificações diferente da oferecida pela implementação de referência do Android Open Source. No entanto, esses sistemas de notificação alternativos PRECISAM oferecer suporte a recursos de notificação existentes, conforme mencionado acima.

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 mostradas, precisam executar corretamente notificações Rich e Heads-up e incluir o título/nome, ícone e texto conforme documentado nas APIs do Android [Resources, 25].

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 conforme são postadas ou atualizadas. As implementações de dispositivos precisam enviar notificações corretamente e rapidamente na íntegra para todos os serviços de listener instalados e ativados pelo usuário, incluindo todos os metadados anexados ao objeto de notificação.

O Android inclui APIs [Resources, 26] que permitem que os desenvolvedores incorporem a pesquisa aos apps e exibam os dados deles na pesquisa global do sistema. De modo 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 resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para oferecer pesquisa nos próprios apps e fornecer resultados à interface do usuário de pesquisa global comum.

As implementações de dispositivos Android DEVEM incluir a pesquisa global, uma interface do 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 precisam implementar as APIs que permitem que os desenvolvedores reutilizem essa interface do usuário para oferecer pesquisas nos próprios aplicativos. As implementações de dispositivo 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 será mostrar os resultados e as sugestões do mecanismo de pesquisa da Web.

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 [Resources, 27]. As implementações de dispositivos precisam mostrar avisos de apps para os usuários finais de maneira bem visível.

3.8.6. Temas

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

O Android inclui uma família de temas "Holo" 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 Holo, conforme definido pelo SDK do Android [Resources, 28]. As implementações de dispositivos NÃO PODEM alterar nenhum dos atributos do tema Holo expostos aos aplicativos [Resources, 29].

O Android inclui uma família de temas "Material" como um conjunto de estilos definidos para desenvolvimento de apps, caso os desenvolvedores queiram 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 dos recursos expostos aos apps [Resources, 30].

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 aplicativos usem se quiserem combinar a aparência e a sensação do tema do dispositivo conforme definido pelo implementador do dispositivo. As implementações do dispositivo PODEM modificar os atributos de tema padrão do dispositivo expostos aos aplicativos [Resources, 29].

O Android oferece suporte a um novo tema de 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 navegação com o conteúdo do app. Para permitir uma experiência consistente do desenvolvedor nessa configuração, é importante que o estilo do ícone da barra de status seja mantido em diferentes implementações de dispositivo. Portanto, as implementações de dispositivos Android PRECISAM usar o 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 [Resources, 29].

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 "Wallpapers animados" ao usuário final [Resources, 31]. 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 planos de fundo interativos de forma confiável se puder executar todos os planos de fundo interativos, sem limitações de funcionalidade, a uma taxa de frames razoável sem efeitos adversos em outros aplicativos. Se as limitações no hardware causarem falhas em planos de fundo e/ou aplicativos, mal funcionamento, consumo excessivo de CPU ou bateria 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 por um papel de parede animado pode entrar em conflito com outros aplicativos que também usam um contexto OpenGL.

As implementações de dispositivos capazes de executar planos de fundo interativos de forma confiável, conforme descrito acima, DEVEM implementar planos de fundo interativos e, quando implementados, 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, os requisitos para implementar a tela de visão geral são OPCIONAIS para dispositivos Android TV e Android Watch.

O código-fonte upstream do Android inclui a tela de visão geral [Resources, 32], 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:

  • PRECISA mostrar os afiliados recentes como um grupo que se move junto.
  • É necessário oferecer suporte a pelo menos 20 atividades exibidas.
  • DEVE mostrar pelo menos o título de quatro atividades por vez.
  • DEVE mostrar a cor, o ícone e o título da tela em destaques recentes.
  • PRECISA implementar o comportamento de fixação de tela [Resources, 33] e oferecer ao usuário um menu de configurações para ativar o recurso.
  • DEVE mostrar um recurso de fechamento ("x"), mas PODE atrasar isso até que o usuário interaja com as telas.

É FORTEMENTE RECOMENDADO que as implementações de dispositivos usem a interface do usuário do Android upstream (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 [Resources, 34]. 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.

Implementações de dispositivos que declaram o recurso android.software.input_methods PRECISAM fornecer um mecanismo acessível ao usuário para adicionar e configurar métodos de entrada de terceiros. As implementações de dispositivos precisam mostrar a interface de configurações em resposta à intent android.settings.INPUT_METHOD_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 [Resources, 35]. 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. Sonhos

O Android inclui suporte para protetores de tela interativos chamados Dreams [Resources, 36]. O Dreams permite que os usuários interajam com aplicativos quando um dispositivo conectado a uma fonte de energia está ocioso ou conectado a uma base para mesa. Dispositivos Android Watch PODEM implementar o recurso Dreams, mas outros tipos de implementações de dispositivos PRECISAM incluir suporte a ele e oferecer uma opção de configurações para que os usuários possam configurar o recurso em resposta à intent android.settings.DREAM_SETTINGS.

3.8.12. Local

Quando um dispositivo tem um sensor de hardware (por exemplo, GPS) capaz de fornecer as coordenadas de localização, os modos de localização precisam ser exibidos no menu "Localização" nas Configurações [Resources, 37].

3.8.13. Unicode e fonte

O Android inclui suporte para caracteres emoji coloridos. Quando as implementações de dispositivos Android incluem um IME, os dispositivos PRECISAM fornecer um método de entrada ao usuário para os caracteres emoji definidos no Unicode 6.1 [Resources, 38]. Todos os dispositivos precisam ser capazes de renderizar esses caracteres emoji em glifos coloridos.

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 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.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, pela API Android Device Administration [Resources, 39]. As implementações de dispositivo precisam fornecer uma implementação da classe DevicePolicyManager [Resources, 40]. As implementações de dispositivos que incluem suporte a telas de bloqueio com PIN (numérico) ou SENHA (alfanumérico) precisam oferecer suporte a toda a gama de políticas de administração de dispositivos definidas na documentação do SDK do Android [Resources, 39] e informar o recurso da plataforma android.software.device_admin.

As implementações de dispositivos PODEM ter um aplicativo pré-instalado que executa funções de administração do dispositivo, mas esse aplicativo NÃO PODE ser definido como o app padrão do proprietário do dispositivo [Resources, 41].

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 text-to-speech, feedback tátil e navegação por trackball/d-pad [Resources, 42].

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 dispositivos (exceto o Android Automotive) precisam oferecer suporte a implementações de serviços de acessibilidade de terceiros usando as APIs android.accessibilityservice [Resources, 43].
  • As implementações de dispositivo (exceto o Android Automotive) precisam gerar eventos de acessibilidade e enviá-los a todas as implementações do 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.

Além disso, as implementações de dispositivo PRECISAM fornecer uma implementação de um serviço de acessibilidade no dispositivo e um mecanismo para que os usuários ativem o serviço de acessibilidade durante a configuração do dispositivo. Uma implementação de código aberto de um serviço de acessibilidade está disponível no projeto Eyes Free [Resources, 44].

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 fala (TTS, na sigla em inglês) e que os provedores de serviços ofereçam implementações de serviços TTS [Resources, 45]. 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 do Android upstream inclui uma implementação de mecanismo de TTS com todos os recursos.
  • PRECISA oferecer suporte à instalação de mecanismos de TTS de terceiros
  • É PRECISO fornecer uma interface acessível ao usuário que permita selecionar 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 framework de entrada de TV [Resources, 46].

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

4. Compatibilidade de empacotamento de apps

As implementações de dispositivos precisam instalar e executar arquivos ".apk" do Android conforme gerados pela ferramenta "aapt" incluída no SDK oficial do Android [Resources, 47].

As implementações de dispositivos NÃO PODEM estender o .apk [Resources, 48], o manifesto do Android [Resources, 49], o bytecode Dalvik [Resources, 20] ou os formatos de bytecode do RenderScript de forma que impeça a instalação e a execução correta desses arquivos em outros dispositivos compatíveis.

5. Compatibilidade com multimídia

5.1. Codecs de mídia

As implementações de dispositivos PRECISAM oferecer suporte aos formatos de mídia principais especificados na documentação do SDK do Android [Resources, 50], exceto quando explicitamente permitido neste documento. Especificamente, as implementações do dispositivo precisam oferecer suporte aos formatos de mídia, codificadores, decodificadores, tipos de arquivo e formatos de contêiner definidos nas tabelas abaixo e informados pelo MediaCodecList [Resources,112]. As implementações de dispositivos também precisam ser capazes de decodificar todos os perfis informados no CamcorderProfile [Resources, 113]. Todos esses codecs são fornecidos como implementações de software na implementação do Android preferencial do Android Open Source Project.

Nem o Google nem a Open Handset Alliance fazem qualquer representação de que esses codecs estão livres de patentes de terceiros. Aqueles que pretendem usar esse código-fonte em produtos de hardware ou software são avisados de que as implementações desse código, incluindo em software de código aberto ou shareware, podem exigir licenças de patente dos detentores de patente 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ÓRIO1 REQUIRED Suporte a conteúdo mono/estéreo/5.0/5.12 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+, não há suporte para ADIF)
  • MPEG-TS (.ts, não pesquisável, Android 3.0+)
Perfil MPEG-4 HE AAC (AAC+) OBRIGATÓRIO1
(Android 4.1+)		 REQUIRED Suporte a conteúdo mono/estéreo/5.0/5.12 com taxas de amostragem padrão de 16 a 48 kHz.
MPEG-4 HE AACv2

Perfil (AAC+ aprimorado)

 REQUIRED Suporte a conteúdo mono/estéreo/5.0/5.12 com taxas de amostragem padrão de 16 a 48 kHz.
AAC ELD (AAC aprimorado com atraso baixo) OBRIGATÓRIO1

(Android 4.1+)

 REQUIRED

(Android 4.1+)

 Suporte a conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.
AMR-NB OBRIGATÓRIO3 OBRIGATÓRIO3 4,75 a 12,2 kbps com amostragem a 8 kHz. 3GPP (.3gp)
AMR-WB OBRIGATÓRIO3 OBRIGATÓRIO3 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). Recomendação de 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. Suporte para 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ÓRIO4
(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 ou mais recente)		 Matroska (.mkv)

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

2 Apenas o downmix de conteúdo 5.0/5.1 é necessário. A gravação ou renderização de mais de dois canais é opcional.

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 dispositivos 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)

5.1.3. Codecs de vídeo

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

Formato/Codec Codificador Decodificador Detalhes Tipos de arquivo/
Formatos de contêiner compatíveis
H.263 OBRIGATÓRIO1 OBRIGATÓRIO2
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC OBRIGATÓRIO2 OBRIGATÓRIO2 Consulte as seções 5.2 e 5.3 para mais detalhes.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-TS (.ts, AAC exclusivo de áudio, não pesquisável, Android 3.0+)
H.265 HEVC OBRIGATÓRIO5 Consulte a seção 5.3 para mais detalhes. MPEG-4 (.mp4)
MPEG-4 SP OBRIGATÓRIO2 3GPP (.3gp)
VP83 OBRIGATÓRIO2

(Android 4.3 ou mais recente)

 OBRIGATÓRIO2

(Android 2.3.3+)

 Consulte as seções 5.2 e 5.3 para mais detalhes.
VP9 OBRIGATÓRIO2
(Android 4.4 ou mais recente)		 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 em [Recursos, 51].

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

5 Altamente recomendado para o Android Automotive, opcional para o Android Watch e obrigatório para todos os outros tipos de dispositivo.

5.2. Codificação de vídeo

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

As implementações de dispositivos Android com suporte ao codec H.264 precisam oferecer suporte ao perfil de referência de nível 3 e aos seguintes perfis de codificação de vídeo SD (definição padrão) e devem oferecer suporte ao perfil principal de nível 4 e aos seguintes perfis de codificação de vídeo HD (alta definição). É ALTAMENTE RECOMENDADO que os dispositivos Android TV codifiquem vídeos HD 1080p a 30 QPS.

SD (baixa qualidade) SD (alta qualidade) HD 720p1 HD 1080p1
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.

As implementações de dispositivos Android com suporte ao codec VP8 precisam oferecer suporte aos perfis de codificação de vídeo SD e devem oferecer suporte aos seguintes perfis de codificação de vídeo HD.

SD (baixa qualidade) SD (alta qualidade) HD 720p1 HD 1080p1
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.

As implementações de dispositivos precisam oferecer suporte à alternância dinâmica de resolução de vídeo no mesmo fluxo para todos os codecs VP8, VP9, H.264 e H.265 expostos aos desenvolvedores por meio das APIs padrão do Android.

As implementações de dispositivos Android com decodificadores H.264 precisam oferecer suporte ao perfil de referência de nível 3 e aos seguintes perfis de decodificação de vídeo SD e também aos perfis de decodificação de HD. Os dispositivos Android TV precisam oferecer suporte ao perfil de alta nível 4.2 e ao perfil de decodificação HD 1080p.

SD (baixa qualidade) SD (alta qualidade) HD 720p1 HD 1080p1
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 30 qps / 60 qps2 30 qps / 60 qps2
Taxa de bits do vídeo 800 Kbps 2 Mbps 8 Mbps 20 Mbps

1 Obrigatório para implementações de dispositivos Android TV, mas para outros tipos de dispositivos, somente quando houver suporte de hardware.

2 Obrigatório para implementações de dispositivos Android TV.

As implementações de dispositivos Android, quando oferecem suporte ao codec VP8, conforme descrito na seção 5.1.3, PRECISAM oferecer suporte aos seguintes perfis de decodificação de SD e DEVEM oferecer suporte aos perfis de decodificação de HD. Os dispositivos Android TV precisam oferecer suporte ao perfil de decodificação HD 1080p.

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

1 Obrigatório para implementações de dispositivos Android TV, mas para outros tipos de dispositivos, somente quando houver suporte de hardware.

2 Obrigatório para implementações de dispositivos Android TV.

As implementações de dispositivos Android, quando oferecem suporte ao codec VP9, conforme descrito na seção 5.1.3, PRECISAM oferecer suporte aos seguintes perfis de decodificação de vídeo SD e DEVEM oferecer suporte aos perfis de decodificação de HD. É ALTAMENTE RECOMENDÁVEL que os dispositivos Android TV ofereçam suporte ao perfil de decodificação HD 1080p e ao perfil de decodificação UHD. Quando o perfil de decodificação de vídeo UHD tiver suporte, ele PRECISA ter suporte à profundidade de cor de 8 bits.

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

1 Obrigatório para implementações de dispositivos Android TV, mas para outros tipos de dispositivos, somente quando houver suporte de hardware.

2 ALTAMENTE RECOMENDADO para implementações de dispositivos Android TV quando oferecem suporte a hardware.

As implementações de dispositivos Android, quando oferecem suporte ao codec H.265, conforme descrito na seção 5.1.3, PRECISAM oferecer suporte ao nível principal do perfil principal de nível 3 e aos seguintes perfis de decodificação de vídeo SD e DEVEM oferecer suporte aos perfis de decodificação HD. Os dispositivos Android TV precisam oferecer suporte ao perfil de nível principal Main10 nível 5 e ao perfil de decodificação UHD. É ALTAMENTE RECOMENDÁVEL que os dispositivos Android TV ofereçam suporte ao perfil de decodificação HD 1080p. Se o perfil de decodificação HD 1080p tiver suporte, ele PRECISA ter suporte ao nível 4.1 do perfil principal.

SD (baixa qualidade) SD (alta qualidade) HD 720p 1 HD 1080p 2 UHD 2
Resolução do vídeo 352 x 288 px 640 x 360 px 1.280 x 720 px 1.920 x 1.080 px 3840 x 2160 px
Frame rate do vídeo 30 fps 30 fps 30 fps 30 fps 30 fps
Taxa de bits do vídeo 600 Kbps 1,6 Mbps 4 Mbps 10 Mbps 20 Mbps

1 Obrigatório para a implementação de dispositivos Android TV, mas para outros tipos de dispositivos, somente quando houver suporte de hardware.

2 ALTAMENTE RECOMENDADO para implementações de dispositivos Android TV quando houver suporte de hardware.

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 está planejada para mudar para OBRIGATÓRIO. É 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 do 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

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

5.4.2. Captura para reconhecimento de voz

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 amplitude aproximadamente plana em relação às características de frequência: especificamente, ±3 dB, de 100 Hz a 4.000 Hz.
  • A sensibilidade de entrada de áudio PRECISA ser definida de modo que uma fonte de nível de potência de som (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 precisa ser menor que 1% para 1 kHz em 90 dB SPL 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 sintonizadas para reconhecimento de voz, 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ído.

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 dispositivo 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 [Resources, 52]. 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 Equalizer e LoudnessEnhancer do AudioEffect.
  • PRECISA oferecer suporte à implementação da API do visualizador, controlável pela classe Visualizer.
  • DEVE oferecer suporte às implementações EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controláveis pelas subclasses AudioEffect BassBoost, EnvironmentalReverb, PresetReverb e Virtualizer.

5.5.3. Volume da saída de áudio

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

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 pode ser ouvido por um listener externo ou observado por um transdutor.
  • Latência de saída fria. A latência de saída do primeiro frame, quando o sistema de saída de áudio está 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 externo é apresentado ao dispositivo e o momento em que um aplicativo lê o frame correspondente de dados codificados em PCM.
  • 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 variação entre medições separadas de valores de latência de saída fria.
  • Jitter de entrada fria. A variação 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 5 milissegundos.
  • API da fila de buffer de PCM do OpenSL ES. O conjunto de APIs OpenSL ES relacionadas ao PCM no Android NDK. Consulte NDK_root/docs/opensles/index.html.

As implementações de dispositivo que declaram android.hardware.audio.output precisam 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 calibragem 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, ele PODE informar suporte para áudio de baixa latência, informando o recurso android.hardware.audio.low_latency pela classe android.content.pm.PackageManager [Resources, 53]. 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 dispositivo que incluem android.hardware.microphone precisam 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 [Resources, 50]. Especificamente, os dispositivos precisam oferecer suporte aos seguintes protocolos de rede de mídia:

  • RTSP (RTP, SDP)
  • Streaming progressivo HTTP(S)
  • Draft protocolo do HTTP(S) Live Streaming, versão 3 [Resources, 54]

5.8. Secure Media

As implementações de dispositivos que oferecem suporte à saída de vídeo segura e são capazes de oferecer suporte a superfícies seguras PRECISAM declarar suporte a Display.FLAG_SECURE. As implementações de dispositivos que declaram suporte a 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 a 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.

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:

As implementações de dispositivos precisam oferecer suporte a todas as funções do adb, conforme documentado no SDK do Android, incluindo dumpsys [Resources, 56]. O daemon adb do dispositivo PRECISA estar inativo por padrão, e é PRECISO ter 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 a ponte de depuração do Android 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 monitoração de depuração do Dalvik (ddms) [Resources, 57]

As implementações de dispositivos precisam oferecer suporte a todos os recursos do DDMS, conforme documentado no SDK do Android. Como o ddms usa adb, o suporte a ele DEVE estar inativo por padrão, mas PRECISA ser compatível sempre que o usuário tiver ativado a ponte de depuração do Android, como acima.

As implementações de dispositivos precisam incluir o framework Monkey e disponibilizá-lo para uso de aplicativos.

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 os sistemas Apple Macintosh reconhecem dispositivos Android usando as ferramentas padrão do SDK do Android, sem suporte extra. 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 TERÃO QUE 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 9 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 app [Resources, 60]. 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 o 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.

7. Compatibilidade de hardware

Se um dispositivo incluir um componente de hardware específico que tenha uma API correspondente para desenvolvedores de terceiros, 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 de componentes 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 consistentemente 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 build fingerprint. [Resources, 53]

7.1. Tela e gráficos

O Android inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts da interface para o dispositivo, garantindo que os apps de terceiros funcionem bem em várias configurações de hardware [Resources, 61]. 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, o dpi horizontal e vertical precisa 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 dispositivo precisam informar o tamanho correto da tela, conforme definido na documentação do SDK do Android [Resources, 61] e determinado pela plataforma upstream do Android. Especificamente, as implementações do dispositivo precisam informar o tamanho correto da tela de acordo com as seguintes dimensões de tela de pixel (dp) de densidade independente.

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

Os dispositivos Android Watch PODEM ter uma proporção de 1,0 (1:1).

A proporção da tela PRECISA ser um valor de 1,3333 (4:3) a 1,86 (aproximadamente 16:9), mas os dispositivos Android Watch PODEM ter uma proporção de 1,0 (1:1) porque essa implementação de dispositivo vai usar um UI_MODE_TYPE_WATCH como o android.content.res.Configuration.uiMode.

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 e PRECISAM executar aplicativos nessa densidade padrão. Além disso, elas NÃO PODEM 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)
  • 400 dpi (400dpi)
  • 480 dpi (xxhdpi)
  • 560 dpi (560dpi)
  • 640 dpi (xxxhdpi)

As implementações de dispositivos DEVEM definir a densidade padrão do framework Android que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica empurre 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 que o menor tamanho de tela compatível com suporte (largura de 320 dp), as implementações de dispositivo precisam informar a próxima densidade padrão mais baixa do framework do Android.

7.1.2. Métricas de tela

As implementações de dispositivos precisam informar os valores corretos para todas as métricas de tela definidas em android.util.DisplayMetrics [Resources, 62] 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 relatar 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 ou 3.1 em dispositivos compatíveis. As implementações do dispositivo também precisam oferecer suporte ao RenderScript do Android, conforme detalhado na documentação do SDK do Android [Resources, 63].

As implementações de dispositivo também precisam se identificar corretamente como compatíveis com OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 ou OpenGL 3.1. 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 nativas C/C++ (disponíveis para apps por meio de libGLES_v1CM.so, libGLES_v2.so ou libEGL.so) PRECISAM informar suporte para OpenGL ES 1.0 e OpenGL ES 2.0.
  • As implementações de dispositivo que declaram suporte ao OpenGL ES 3.0 ou 3.1 precisam oferecer suporte às APIs gerenciadas correspondentes e incluir suporte a APIs nativas C/C++. Em implementações de dispositivo que declaram suporte ao OpenGL ES 3.0 ou 3.1, 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.

Além do OpenGL ES 3.1, o Android oferece um pacote de extensões com interfaces Java [Resources, 64] e suporte nativo para recursos gráficos avançados, como a tesselada e o formato de compactação de textura ASTC. As implementações de dispositivos Android PODEM oferecer suporte a esse pacote de extensão e, apenas se forem totalmente implementadas, PRECISAM 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, pelas APIs gerenciadas e nativas do OpenGL ES, todas as strings de extensão com suporte e, inversamente, não precisam informar as que não têm suporte.

O Android inclui suporte para aplicativos que especificam opcionalmente que eles exigem formatos de compactação de textura OpenGL específicos. Esses formatos geralmente são específicos do fornecedor. As implementações de dispositivos não são necessárias pelo Android para implementar qualquer formato de compressão de textura específico. No entanto, eles DEVEM 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 [Resources, 65].

As implementações de dispositivo 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 nas 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 a aceleração de hardware [Resources, 65].

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 dispositivo PRECISAM oferecer suporte à API TextureView e PRECISAM apresentar 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 dispositivos precisam oferecer suporte à extensão EGL_ANDROID_RECORDABLE [Resources, 66].

7.1.5. Modo de compatibilidade de aplicativos legados

O Android especifica um "modo de compatibilidade" em que o framework opera em um modo de tamanho de tela "normal" equivalente (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 de origem aberto do Android. Ou seja, as implementações de dispositivos NÃO PODEM alterar os acionadores ou limites em que o modo de compatibilidade é ativado e NÃO PODEM alterar o comportamento do próprio modo de compatibilidade.

7.1.6. Tecnologia da tela

A plataforma Android inclui APIs que permitem que os aplicativos renderizem gráficos avançados 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 capazes de renderizar gráficos coloridos de 16 bits e DEVEM oferecer suporte a telas capazes de renderizar 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 estar 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 a telas secundárias para ativar recursos de compartilhamento de mídia e APIs para desenvolvedores acessarem telas externas. Se um dispositivo oferecer suporte a uma tela externa por uma conexão de tela adicional com ou sem fio ou integrada, a implementação do dispositivo PRECISA implementar a API do gerenciador de tela, conforme descrito na documentação do SDK do Android [Resources, 67].

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:

  • É necessário incluir suporte ao framework de gerenciamento de entrada, que permite que desenvolvedores terceirizados criem editores de método de entrada, ou seja, teclados virtuais, 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 pode incluir um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.keyboard [Resources, 68] (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.
  • É PRECISO informar o valor correto para android.content.res.Configuration.navigation [Resources, 68].
  • É 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 táctil.

7.2.3. Teclas de navegação

A disponibilidade e o requisito de visibilidade das funções "Início", "Recentes" e "Voltar" diferem entre os tipos 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 início, recentes e voltar.
  • As implementações de dispositivos Android TV precisam fornecer as funções de voltar e home.
  • 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 estiver em UI_MODE_TYPE_WATCH.
  • 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 PODEM ser implementadas 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 visíveis.

A função "Recentes", se fornecida, PRECISA ter um botão ou ícone visível, a menos que esteja oculta com outras funções de navegação no modo de tela cheia. Isso não se aplica a dispositivos que 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 5.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 overflow de ação na barra de ação quando ele estiver visível e o menu pop-up de overflow de ação 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 5.1, isso é RECOMENDADO.
  • NÃO MODIFIQUE 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 ação flutuante 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 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.

O Android oferece suporte à ação de assistência [Resources, 69]. As implementações de dispositivos Android, exceto dispositivos Android Watch, precisam disponibilizar a ação de assistência ao usuário sempre que executarem aplicativos. A ação de assistência precisa ser implementada como um toque longo no botão Home ou um gesto de deslizar para cima na tecla Home do software. Essa função PODE ser implementada por outro botão físico, tecla de software ou gesto, mas PRECISA ser acessível com uma única ação (por exemplo, toque, clique duplo ou gesto) quando outras teclas de navegação estiverem visíveis.

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 os aplicativos, e NÃO podem obscurecer ou interferir na parte da tela disponível para os aplicativos.
  • As implementações de dispositivos PRECISAM disponibilizar uma parte da tela para aplicativos que atendam aos requisitos definidos na seção 7.1.1.
  • As implementações de dispositivos precisam mostrar as teclas de navegação quando os aplicativos não especificam um modo de interface do sistema ou especificam SYSTEM_UI_FLAG_VISIBLE.
  • As implementações de dispositivos PRECISAM apresentar as teclas de navegação em um modo de "perfil baixo" discreto (por exemplo, esmaecido) quando os aplicativos especificam SYSTEM_UI_FLAG_LOW_PROFILE.
  • As implementações de dispositivos precisam ocultar as teclas de navegação quando os aplicativos especificam SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Entrada por 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 [Resources, 68] 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 [Resources, 70], 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 precisa de 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 base em giroscópio, ponteiro com giroscópio, joystick e trackpad multitoque, podem oferecer suporte a interações de toque falsas. O Android inclui a constante 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 da funcionalidade 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 (de toque único ou melhor) PRECISAM informar a constante do recurso da plataforma android.hardware.touchscreen. As implementações de dispositivos 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 DEVEM informar apenas android.hardware.faketouch se atendem 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 exibir um ponteiro visual na tela [Resources, 71].
  • É PRECISO informar o evento de toque com o código de ação que especifica a mudança de estado que ocorre quando o ponteiro desce ou sobe na tela [Resources, 71].
  • PRECISA oferecer suporte ao ponteiro para baixo e para cima em um objeto na tela, o que permite que os usuários emulem o toque em um objeto na tela.
  • PRECISA oferecer suporte ao ponteiro para baixo, ponteiro para cima, ponteiro para baixo e ponteiro 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 [Resources, 71].
  • 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 movam um objeto na tela.

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

7.2.6. Suporte a controles de jogos

As implementações de dispositivos Android 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 chaves:

Botão Uso do HID2 Botão do Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Botão direcional para cima1

Botão direcional para baixo1

 0x01 0x00393 AXIS_HAT_Y4
Botão Dpad para a esquerda1

D-pad para a direita1

 0x01 0x00393 AXIS_HAT_X4
Botão de ombro esquerdo1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Botão de ombro direito1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clique no botão esquerdo1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clique no botão direito1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Início1 0x0c 0x0223 KEYCODE_HOME (3)
Voltar1 0x0c 0x0224 KEYCODE_BACK (4)

1 [Recursos, 72]

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 [Resources, 71]

Controles analógicos1 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 [Resources, 71]

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 um controle baseado em software acessível por um smartphone ou tablet. O controle remoto PRECISA atender aos requisitos definidos abaixo.

  • Affordance de pesquisa. As implementações de dispositivos precisam acionar KEYCODE_SEARCH quando o usuário aciona a pesquisa por voz no controle remoto físico ou baseado em software.
  • Navegação. Todos os controles remotos de Android TV precisam incluir os botões "Voltar", "Página inicial" e "Selecionar" e suportar eventos do D-pad [Resources, 72].

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 do Android Open Source sobre sensores [Resources, 73]. 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 [Resources, 53].
  • PRECISA retornar uma lista precisa de sensores compatíveis pelo SensorManager.getSensorList() e métodos semelhantes.
  • PRECISA se comportar de maneira razoável para todas as outras APIs de sensor (por exemplo, retornando "true" ou "false" conforme apropriado quando os aplicativos tentam registrar listeners, não chamando listeners de sensor quando os sensores correspondentes não estão presentes; etc.).
  • É 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 [Resources, 74].
  • 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 SystemClock.elapsedRealtimeNano(). É recomendado que os dispositivos Android atuais e novos atendam a esses requisitos para que possam fazer upgrade 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 [Resources, 75].

A lista acima não é abrangente. O comportamento documentado do SDK do Android e da documentação do Android Open Source sobre sensores [Resources, 73] é considerado oficial.

Alguns tipos de sensores são compostos, ou seja, podem ser derivados de dados fornecidos por um ou mais outros sensores. Exemplos incluem o sensor de orientação e o sensor de aceleração linear. As implementações de dispositivos PRECISAM implementar esses tipos de sensores, quando eles incluem os sensores físicos necessários, conforme descrito em [Recursos, 76]. 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 [Resources, 76].

Alguns sensores do Android oferecem suporte a um modo de acionamento "contínuo", que retorna dados contínuos [Resources, 77]. Para que qualquer API indicada pela documentação do SDK do Android seja um sensor contínuo, as implementações do dispositivo precisam fornecer continuamente amostras de dados perió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 em um estado de suspensão ou de sair de um estado de suspensão.

Por fim, quando vários sensores são ativados, o consumo de energia NÃO DEVE ultrapassar 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 Android portáteis e dispositivos Android Watch incluam esse sensor. Se uma implementação de dispositivo incluir um acelerômetro de três eixos, ela:

  • É NECESSÁRIO implementar e informar o sensor TYPE_ACCELEROMETER [Resources, 78].
  • É 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.
  • É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android [Resources, 74].
  • É PRECISO medir a queda livre até quatro vezes a gravidade (4g) ou mais em qualquer eixo.
  • Precisa ter uma resolução de pelo menos 8 bits e recomenda-se que tenha 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.
  • PRECISA 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 recomendável que os dispositivos Android atuais e novos 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. Dispositivos Android novos e atuais são fortemente recomendados para implementar o sensor TYPE_GAME_ROTATION_VECTOR.
  • DEVE implementar um sensor composto TYPE_ROTATION_VECTOR, se um sensor de giroscópio e um sensor de magnetômetro também estiverem incluídos.

7.3.2. Magnetômetro

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

  • É PRECISO implementar o sensor TYPE_MAGNETIC_FIELD e também implementar o sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED. É altamente recomendável que 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.
  • É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android [Resources, 74].
  • É PRECISO 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 abaixo de 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 µ.
  • 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 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 em amostras coletadas por um período de pelo menos 3 segundos na taxa de amostragem mais rápida, não maior que 0,5 µT.
  • DEVE 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 implementado, ele PRECISA consumir menos de 10 mW e DEVE consumir menos de 3 mW quando o sensor for registrado para o modo lote a 10 Hz.

7.3.3. GPS

As implementações de dispositivo devem incluir um receptor de GPS. Se uma implementação de dispositivo incluir um receptor de GPS, ela PRECISA incluir alguma forma de técnica de "GPS assistido" para minimizar o tempo de bloqueio do GPS.

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 3 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 implementar o sensor TYPE_GYROSCOPE_UNCALIBRATED. É altamente recomendável que 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.
  • É NECESSÁRIO que o app possa informar eventos com uma frequência de pelo menos 50 Hz para dispositivos Android Watch, já que esses dispositivos 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 16 bits ou mais.
  • Deve ser compensado pela temperatura.
  • PRECISA ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
  • PRECISA ter uma variação não maior 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.
  • DEVE 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. Dispositivos Android novos e atuais são fortemente recomendados para implementar o sensor TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barômetro

As implementações de dispositivos precisam 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 cômodo) 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.

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

7.4. Conectividade de dados

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android e neste documento, se refere especificamente a hardware relacionado a fazer chamadas de voz e enviar mensagens SMS por uma rede GSM ou CDMA. Embora essas ligações 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 ligações 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 o suporte completo à 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.2. IEEE 802.11 (Wi-Fi)

As implementações de dispositivos Android TV PRECISAM incluir suporte a Wi-Fi.

As implementações de dispositivos Android TV precisam incluir suporte a uma ou mais formas de 802.11 (b/g/a/n, etc.), e outros tipos de implementação 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 Android correspondente e:

  • É PRECISO informar a flag de recurso de hardware android.hardware.wifi.
  • PRECISA implementar a API multicast conforme descrito na documentação do SDK [Resources, 79].
  • É necessário oferecer suporte a DNS multicast (mDNS) e NÃO filtrar pacotes mDNS (224.0.0.251) em nenhum momento da operação, inclusive quando a tela não está em um estado ativo.

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 Android correspondente, conforme descrito na documentação do SDK [Resources, 80]. 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 Android TV precisam incluir suporte para a configuração de link direto com túnel (TDLS, na sigla em inglês) do Wi-Fi.

As implementações de dispositivos Android TV precisam incluir suporte para a configuração de link direto com túnel (TDLS, na sigla em inglês) do Wi-Fi, e outros tipos de implementações de dispositivos Android precisam incluir suporte para o TDLS do Wi-Fi, conforme descrito na documentação do SDK do Android [Resources, 81]. Se uma implementação de dispositivo incluir suporte a 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 e do Automotive precisam ter suporte a Bluetooth. As implementações de televisões Android precisam oferecer suporte a Bluetooth e Bluetooth LE.

O Android inclui suporte para Bluetooth e Bluetooth de baixa energia [Resources, 82]. As implementações de dispositivos que incluem suporte a 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 perfis Bluetooth relevantes, como A2DP, AVCP, OBEX etc., conforme apropriado para o dispositivo. As implementações de dispositivos Android TV precisam oferecer suporte a Bluetooth e Bluetooth LE.

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 [Resources, 82].
  • DEVE oferecer suporte ao descarregamento da lógica de filtragem para o chipset Bluetooth ao implementar a API ScanFilter [Resources, 83] 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 consultado pelo método android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported().
  • DEVE oferecer suporte a vários anúncios com pelo menos quatro slots, mas, 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() [Resources, 53].
  • PRECISA ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões 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) usando os seguintes padrões de NFC:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS 6319-4)
      • IsoDep (ISO 14443-4)
      • Tipos de tag do NFC Forum 1, 2, 3 e 4 (definidos pelo NFC Forum)
    • DEVE ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões NFC. Embora os padrões de NFC abaixo sejam indicados como "SHOULD", a definição de compatibilidade para uma versão futura está planejada para mudar para "MUST". Essas normas são opcionais nesta versão, mas serão obrigatórias em versões futuras. É altamente recomendado que os dispositivos novos e atuais que executam essa versão do Android atendam a esses requisitos para que possam fazer upgrade para as versões futuras da plataforma.
      • NfcV (ISO 15693)
    • PRECISA transmitir e receber dados pelos seguintes padrões e protocolos ponto a ponto:
      • ISO 18092
      • LLCP 1.0 (definido pelo NFC Forum)
      • SDP 1.0 (definido pelo Fórum de NFC)
      • Protocolo NDEF Push [Resources, 84]
      • SNEP 1.0 (definido pelo NFC Forum)
    • É necessário incluir suporte ao Android Beam [Resources, 85]:
      • É PRECISO implementar o servidor padrão do SNEP. Mensagens NDEF válidas recebidas pelo servidor SNEP padrão PRECISAM ser enviadas para aplicativos usando a intent android.nfc.ACTION_NDEF_DISCOVERED. A desativação do Android Beam nas configurações NÃO pode desativar o envio de mensagens NDEF recebidas.
      • PRECISA honrar a intent android.settings.NFCSHARING_SETTINGS para mostrar as configurações de compartilhamento de NFC [Resources, 86].
      • É 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 P2P NDEF 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 P2P NDEF de saída.
      • DEVE ativar o Android Beam por padrão e PRECISA 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" [Resources, 87] e "Pareamento simples e seguro por Bluetooth usando NFC versão 1.0" [Resources, 88] 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 objetos 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 AINDA DEVE 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 do fórum 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 e roteamento de ID do aplicativo (AID), ele:

  • É PRECISO informar a constante de recurso android.hardware.nfc.hce.
  • É necessário oferecer suporte a APIs NFC HCE, conforme definido no SDK do Android [Resources, 10].

Além disso, as implementações de dispositivos PODEM incluir suporte de 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 no papel de leitor/gravador, ela:

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() [Resources, 53] e PRECISA implementar a API Android NFC 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 para 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 também precisam 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.

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" [Resources, 89].

7,5. Cameras

As implementações de dispositivos PRECISAM 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á POSSÍVEL que um app aloque simultaneamente três bitmaps iguais ao tamanho das imagens produzidas pelo sensor de câmera de maior resolução no dispositivo.

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:

  • É PRECISO 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 iluminado enquanto uma instância de android.hardware.Camera.PreviewCallback tiver sido 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:

  • PRECISA 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 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 stream exibido por um app em uma CameraPreview, conforme mostrado abaixo:
    • Se a implementação do dispositivo puder ser girada pelo usuário (por exemplo, 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 girando por uma chamada ao método android.hardware.Camera.setDisplayOrientation()[Resources, 90], 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 mostrada pela visualização pós-postagem da mesma forma que o stream de imagem de visualização da câmera. Se a implementação do dispositivo não oferecer suporte à visualização pós-aquisição, esse requisito obviamente não se aplica.
  • NÃO ESPELHAR as transmissões de imagem estática ou de vídeo capturadas e retornadas para respostas de chamada do aplicativo ou comprometidas com o armazenamento de mídia.

7.5.3. Câmera externa

As implementações de dispositivos com o modo host USB PODEM incluir suporte para uma câmera externa que se conecta à porta USB. Se um dispositivo incluir suporte a uma câmera externa, ele:

  • É PRECISO declarar o recurso da plataforma android.hardware.camera.external e android.hardware camera.any.
  • É necessário oferecer suporte à classe de vídeo USB (UVC 1.0 ou mais recente).
  • PODE oferecer suporte a várias câmeras.

O suporte à compactação de vídeo (como MJPEG) é RECOMENDADO para permitir a transferência de streams não codificados de alta qualidade (ou seja, streams de imagem brutos ou compactados independentemente). A codificação de vídeo baseada na câmera PODE ser aceita. Nesse caso, uma transmissão simultânea não codificada/ MJPEG (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 mais baixo para o 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, está 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, é PRECISO 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 aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int), o dispositivo PRECISA usar android.hardware.PixelFormat.YCbCr_420_SP para dados de visualização fornecidos aos callbacks do aplicativo.
  • Se um aplicativo registrar uma instância android.hardware.Camera.PreviewCallback e o sistema chamar o método onPreviewFrame() quando o formato de visualização for YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame() precisarão estar no formato de codificação NV21. Ou seja, 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 de hardware e a câmera podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA oferecer suporte à conversão para YV12.
  • Para android.hardware.camera2, as implementações de dispositivo 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 [Resources, 91], independentemente de o dispositivo incluir foco automático de hardware ou outros recursos. Por exemplo, câmeras que não têm foco automático PRECISAM chamar 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 base oferecer suporte ao recurso. Se o hardware do dispositivo não oferecer suporte a um recurso, a API precisará se comportar conforme documentado. 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 aquelas documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações do dispositivo 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 da câmera Camera.SCENE_MODE_HDR [Resources, 92].

Como nem todas as implementações de dispositivo podem oferecer suporte total a todos os recursos da API android.hardware.camera2, as implementações de dispositivo PRECISAM informar o nível adequado de suporte com a propriedade android.info.supportedHardwareLevel, conforme descrito no SDK do Android [Resources, 93] e informar as flags de recurso do framework apropriado [Resources, 94].

As implementações de dispositivos também precisam declarar os recursos de câmera individuais de android.hardware.camera2 pela propriedade android.request.availableCapabilities e declarar as flags de recursos adequadas [Resources, 94]. Um dispositivo precisa definir a flag de recurso se algum dos dispositivos de câmera conectados oferecer suporte a ela.

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 tiver sido adicionada à mídia store.

As implementações de dispositivos precisam transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da imagem tiver sido adicionada à 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 nessa orientação. 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 5 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 dispositivo PRECISA ser pelo menos igual ou maior que os valores mínimos especificados pela tabela abaixo. 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
 424MB 704MB
  • xhdpi ou superior em telas pequenas/normais
  • hdpi ou mais em telas grandes
  • mdpi ou superior em telas extragrandes
 512 MB 832MB
  • 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 um relógio Android, PRECISAM retornar o valor "true" para ActivityManager.isLowRamDevice().

Os dispositivos Android TV precisam ter pelo menos 5 GB, e outras implementações de dispositivo precisam ter pelo menos 1,5 GB de armazenamento não volátil disponível para dados privados do app. Ou seja, a partição /data PRECISA ter pelo menos 5 GB para dispositivos Android TV e pelo menos 1,5 GB para outras implementações de dispositivos. As implementações de dispositivos que executam o Android são fortemente recomendadas para ter pelo menos 3 GB de armazenamento não volátil para dados privados do aplicativo, para que elas 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 [Resources, 95]. 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 padrão de "cache".

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 armazenamento compartilhado montado por padrão, "fora da caixa". Se o armazenamento compartilhado não estiver montado no caminho /sdcard do Linux, o dispositivo precisará 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 de aviso para alertar o 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 precisam 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 estiver 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.

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 dentro do 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 do dispositivo 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 Media Transfer Protocol, ela:

  • DEVEM ser compatíveis com o host de MTP de referência do Android, o Android File Transfer [Resources, 96].
  • DEVE informar uma classe de dispositivo USB de 0x00.
  • DEVE informar um nome de interface USB de "MTP".

7.7. USB

As implementações de dispositivos precisam oferecer suporte ao modo de periférico USB e ao modo de host 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 padrão tipo A ou tipo C.
  • 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 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 novos e atuais cumpram esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
  • Ele PRECISA implementar a API e a especificação do Android Open Accessory (AOA, na sigla em inglês) conforme documentado na documentação do SDK do Android. Se for um dispositivo Android portátil, ele PRECISA implementar a API AOA. Implementações de dispositivos que implementam a especificação de AOA:
    • É PRECISO declarar suporte ao recurso de hardware android.hardware.usb.accessory [Resources, 97].
    • PRECISA implementar a classe de áudio USB conforme documentado na documentação do SDK do Android [Resources, 98].
  • Ele PRECISA implementar suporte para consumir 1,5 A de corrente durante o chirp e o tráfego HS, conforme especificado na especificação de carregamento de bateria USB, revisão 1.2 [Resources, 99]. É 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.
  • O valor de iSerialNumber no descritor de dispositivo padrão USB PRECISA ser igual ao valor de android.os.Build.SERIAL.

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 tipo C padrão.
  • PODE usar uma porta USB micro-AB, mas, se for o caso, DEVE ser enviado com um ou mais cabos adaptando a porta a uma porta USB padrão tipo A ou tipo C.
  • É ALTAMENTE RECOMENDADO implementar a classe de áudio USB conforme documentado na documentação do SDK do Android [Resources, 98].
  • É NECESSÁRIO implementar a API host USB do Android conforme documentado no SDK do Android e É NECESSÁRIO declarar suporte ao recurso de hardware android.hardware.usb.host [Resources, 100].
  • DEVE oferecer suporte ao intervalo de corrente de saída da porta de carregamento downstream de 1,5 A a 5 A, conforme especificado na especificação de carregamento de bateria USB, revisão 1.2 [Resources, 99].

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.
  • PRECISA atender aos requisitos de gravação de áudio na seção 5.4
  • Precisa atender aos requisitos de latência de áudio na seção 5.6

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.

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 de áudio android.hardware.audio e PRECISA implementar as APIs relacionadas à saída de áudio como no-ops, pelo menos.

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 fones de ouvido e outros acessórios de áudio que usam o plugue de áudio de 3,5 mm em todo o ecossistema do Android [Resources, 101], se uma implementação de dispositivo incluir uma ou mais portas de áudio analógicas, pelo menos uma das portas de áudio precisa 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, ela:

  • É PRECISO oferecer suporte à reprodução de áudio em fones de ouvido estéreo com microfone e à gravação de áudio em fones de ouvido estéreo com microfone.
  • PRECISA oferecer suporte a plugues de áudio TRRS com a ordem de pinagem CTIA e DEVE oferecer suporte a plugues de áudio com a ordem de pinagem OMTP.
  • PRECISA oferecer suporte à detecção de microfone no acessório de áudio conectado, se a implementação do dispositivo oferecer suporte a um microfone, e transmitir o android.intent.action.HEADSET_PLUG com o valor extra de microfone definido como 1.
  • DEVE 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 ohms: KEYCODE_VOLUME_UP
    • 360-680 Ohm: KEYCODE_VOLUME_DOWN
  • DEVE oferecer suporte à detecção e ao mapeamento para o código de tecla do 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.
  • PRECISA ser capaz de acionar pelo menos 150 mV +/- 10% da tensão de saída em uma impedância de alto-falante de 32 Ohm.
  • PRECISA ter uma tensão de polarização do microfone entre 1,8 V e 2,9 V.

8. Compatibilidade de performance

Alguns critérios mínimos de desempenho são essenciais para a experiência do usuário e impactam 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 de frames ou um atraso na renderização de frames NÃO PODE acontecer mais frequentemente do que 5 frames por segundo e PRECISA estar abaixo de 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 teste 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 do 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.

9. Compatibilidade do modelo de segurança

As implementações de dispositivos PRECISAM implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs [Resources, 102] na 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 [Resources, 102]. 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.*.

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 [Resources, 102].

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 [Resources, 102].

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 outro lugar na seção 9.

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

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

Os 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.
  • e aplicativos instalados usando 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 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 do 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 aplicativo precisar usar um recurso do dispositivo para o qual exista uma permissão do Android correspondente (como câmera, GPS etc.), o ambiente de execução alternativo PRECISA informar ao usuário que o aplicativo poderá acessar esse recurso. Se o ambiente de execução não registrar os recursos do aplicativo dessa maneira, o ambiente de execução 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 a vários usuários e oferece suporte à total isolação de usuários [Resources, 103]. As implementações de dispositivos PODEM ativar vários usuários, mas, quando ativadas, PRECISAM atender aos seguintes requisitos relacionados ao suporte a vários usuários [Resources, 104]:

  • As implementações de dispositivo que não declaram a flag de recurso android.hardware.telephony precisam oferecer suporte a perfis restritos, um recurso que permite aos proprietários do dispositivo gerenciar outros usuários e os respectivos recursos no dispositivo. Com os perfis restritos, os proprietários de dispositivos podem configurar rapidamente ambientes separados para outros usuários trabalharem, com a capacidade de gerenciar restrições mais refinadas nos apps disponíveis nesses ambientes.
  • 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 /desativar o acesso de outros usuários às chamadas de voz e SMS.
  • As implementações de dispositivo precisam implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs [Resources, 102].
  • As implementações de dispositivos PODEM oferecer suporte à criação de usuários e perfis gerenciados pelas APIs android.app.admin.DevicePolicyManager e, se houver suporte, DEVEM declarar a flag de recurso da plataforma android.software.managed_users.
  • Implementações de dispositivos que declaram a flag de recurso android.software.managed_users precisam usar o selo de ícone AOSP upstream para representar os aplicativos gerenciados e outros elementos da IU do selo, como "Recentes" e "Notificações".
  • 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 principal PRECISAM criptografar o conteúdo do cartão SD se a opção multiusuário 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 dispositivos precisam mudar para o 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 modo multiusuário se usarem mídia removível [Resources, 105] 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 [Resources, 106] . 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. 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 podem usar o sistema de controle de acesso obrigatório (MAC) do Security-Enhanced Linux (SELinux) e outros recursos de segurança no kernel do Linux. SELinux ou qualquer outro recurso de segurança, se 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 uma violação de segurança não bloqueada ocorre, resultando em uma exploração bem-sucedida.
  • NÃO pode ser configurado pelo usuário ou pelo desenvolvedor.

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

Os dispositivos PRECISAM implementar o SELinux ou um sistema de controle de acesso obrigatório equivalente se estiverem usando um kernel diferente do Linux e atenderem aos requisitos a seguir, que são atendidos pela implementação de referência no projeto de código aberto do Android upstream.

Implementações de dispositivos:

  • DEVE oferecer suporte a uma política do SELinux que permita que o modo SELinux seja definido por domínio e configurá-los no modo de aplicação. Não são permitidos domínios no modo permissivo, incluindo domínios específicos de um dispositivo/fornecedor.
  • DEVE carregar a política do arquivo /sepolicy no dispositivo.
  • NÃO PODE modificar, omitir ou substituir as regras de neverallow presentes no arquivo sepolicy fornecido 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 do AOSP SELinux quanto para domínios específicos de dispositivos/fornecedores.
  • PRECISA oferecer suporte a atualizações dinâmicas do arquivo de política do SELinux sem exigir uma atualização da imagem do sistema.

As implementações de dispositivos DEVEM manter a política padrão do SELinux fornecida no projeto upstream do Android Open Source, até que tenham auditado as adições à política do SELinux. As implementações de dispositivos precisam ser compatíveis com o upstream do Android Open Source Project.

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 capturando/gravando ativamente.

Se uma implementação de dispositivo tiver um mecanismo que roteia 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 android.permission.CONTROL_VPN concedido), a implementação do dispositivo PRECISA solicitar o consentimento do usuário antes de ativar esse mecanismo.

9,9. Criptografia de disco completo

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

Se a implementação do dispositivo oferecer suporte a uma tela de bloqueio com PIN (numérico) ou SENHA (alfanumérico), o dispositivo PRECISA oferecer suporte à criptografia de disco completo dos dados particulares do aplicativo (partição /data), bem como à partição do cartão SD, se ela for uma parte permanente e não removível do dispositivo [Resources, 107]. Para dispositivos com suporte à criptografia de disco completo, ela PRECISA estar ativada o tempo todo depois que o usuário concluir a experiência pronta para uso. Embora esse requisito seja indicado como "deve" para esta versão da plataforma Android, ele é ALTAMENTE RECOMENDADO, já que esperamos que ele mude para "precisa" nas versões futuras do Android. A criptografia PRECISA usar 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 a qualquer momento sem ser criptografada. Além do uso ativo, a chave de criptografia DEVE ser criptografada com AES com a senha da tela de bloqueio esticada usando um algoritmo de alongamento lento (por exemplo, PBKDF2 ou scrypt). Se o usuário não tiver especificado uma senha de 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 para fora do dispositivo, mesmo quando envolvida com a senha do usuário e/ou 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. Inicialização verificada

A inicialização verificada é um recurso que garante a integridade do software do dispositivo. Se uma implementação de dispositivo oferecer suporte ao recurso, ela PRECISA:

  • Declarar a flag de recurso da plataforma android.software.verified_boot
  • Fazer a verificação em cada sequência de inicialização
  • Iniciar a verificação em uma chave de hardware que é a raiz de confiança e ir 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 nela
  • Usar algoritmos de verificação tão fortes quanto as recomendações atuais do NIST para algoritmos de hash (SHA-256) e tamanhos de chave pública (RSA-2048)

As implementações de dispositivos precisam oferecer suporte à inicialização verificada para a integridade do dispositivo. Embora esse requisito seja recomendado para esta versão da plataforma Android, ele é ALTAMENTE RECOMENDADO, já que esperamos que ele mude para OBRIGATÓRIO em versões futuras do Android. O upstream do Android Open Source Project oferece uma implementação preferencial desse recurso com base no recurso dm-verity do kernel do Linux.

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, os implementadores de dispositivos são fortemente incentivados a fazer o menor número possível de mudanças na implementação de referência e preferencial do Android disponível no Android Open Source Project. Isso vai minimizar o risco de introduzir bugs que criam incompatibilidades que exigem retrabalho e possíveis atualizações do dispositivo.

10.1. Conjunto de teste de compatibilidade

As implementações de dispositivos PRECISAM ser aprovadas no conjunto de teste de compatibilidade do Android (CTS) [Resources, 108] 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 reimplementação de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. A versão do CTS será independente dessa definição de compatibilidade, e várias revisões do CTS podem ser lançadas para o Android 5.1. 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 CTS. Os casos de teste para recursos indicados como opcionais por este documento de definição de compatibilidade PODEM ser pulados ou omitidos.

Todos os dispositivos e builds precisam executar corretamente o CTS Verifier, 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 no Verificador do CTS apenas pelo conjunto de localidades incluídas, branding etc. PODEM omitir o teste do Verificador do CTS.

11. Software atualizável

As implementações de dispositivos precisam incluir um mecanismo para substituir todo o software do sistema. O mecanismo não precisa realizar upgrades "ao vivo", ou seja, pode ser necessário reiniciar o dispositivo.

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

  • Downloads "over-the-air (OTA)" com atualização off-line por reinicialização
  • Atualizações "conectadas" por USB de um PC host
  • Atualizações "off-line" por meio de uma reinicialização e atualização de um arquivo em armazenamento removível

No entanto, se a implementação do dispositivo incluir suporte a uma conexão de dados não tarifada, como o perfil 802.11 ou Bluetooth PAN (rede de área pessoal):

  • As implementações do Android Automotive precisam oferecer suporte a downloads OTA com atualização off-line por reinicialização.
  • Todas as outras implementações de dispositivo precisam 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 aplicativo. 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 5.1 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 Android Open Source Project upstream, adicionada desde o Android 5.1, atende a esse requisito.

Se um erro for encontrado em uma implementação de dispositivo após 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 usando uma atualização de software disponível que possa ser aplicada de acordo com o mecanismo descrito.

12. Registro de alterações do documento

A tabela a seguir contém um resumo das mudanças na definição de compatibilidade desta versão.

Seção Resumo da mudança
2. Tipos de dispositivo A definição da implementação do Android Automotive foi adicionada.
2.1 Configurações do dispositivo Coluna adicionada para implementação do Android Automotive.
3.3.2. Compatibilidade com código nativo ARM de 32 bits Nova seção adicionada.
3.4.1. Compatibilidade com a WebView Atualizamos o requisito da string do user agent do WebView para acomodar a mudança de implementação upstream.
3.4.2. Compatibilidade de navegadores Adição de implementações automotivas do Android como outro caso que PODE omitir um aplicativo de navegador.
3.7. Compatibilidade com o ambiente de execução O tamanho de heap necessário para execução foi atualizado para telas menores, e foi adicionado um requisito para o novo bucket de dpi (280 dpi).
3.8.3. Notificações Foi esclarecido o requisito de notificação para implementações do Android Watch, da televisão e automotiva.
3.8.8. Troca de atividades Redução do requisito de contagem de títulos da visão geral.
3.8.10. Controle de mídia na tela de bloqueio Explicamos o requisito para implementações do Android Watch e Automotive.
3.8.13. Unicode e fonte Redução do requisito de método de entrada de caracteres Emoji.
3.9. Administração do dispositivo A condição foi esclarecida quando o conjunto completo de políticas de administração de dispositivos precisa ser compatível.
3.10. Acessibilidade Foram adicionados requisitos do Android Automotive.
3.11. Conv. de texto em voz Foram adicionados requisitos do Android Automotive.
5.1. Codecs de mídia Suporte obrigatório à decodificação de codecs informados pelo CamcorderProfile.
5.1.3 Codecs de vídeo Foram adicionados requisitos do Android Automotive.
5.4. Gravação em áudio A linguagem foi esclarecida no início da seção para garantir que os requisitos OBRIGATÓRIOS sejam lidos como OBRIGATÓRIOS.
7.1.1.3. Densidade da tela Adição de uma nova dpi de tela (280 dpi).
7.1.5. Modo de compatibilidade de aplicativos legados Foram adicionados requisitos do Android Automotive.
7.2 Dispositivos de entrada Foi adicionada uma declaração de introdução geral.
7.2.1. Teclado Foram adicionados requisitos do Android Automotive.
7.2.3. Teclas de navegação Foram adicionados requisitos do Android Automotive.
7.3.1. Acelerômetro Redução do requisito de frequência de relatórios no Android Watch.
7.3.4. Giroscópio Redução do requisito de frequência de relatórios no Android Watch.
7.4.3 Bluetooth Foram adicionados requisitos do Android Automotive.
7.4.4. Comunicação a curta distância (NFC) Foi esclarecida a condição em que a emulação de cartão host é um requisito.
7.6.1. Memória e armazenamento mínimos Os requisitos mínimos de memória foram atualizados para dispositivos de tela de resolução mais baixa e foi adicionado o requisito de limite rígido isLowRamDevice().
7.6.2. Armazenamento compartilhado do aplicativo Os requisitos foram atualizados quando o suporte ao acesso à máquina host é obrigatório.
7,7 USB Correção de erros de digitação na seção de USB
7.6.2. Armazenamento compartilhado do aplicativo Requisitos atualizados que os apps do sistema pré-instalados podem gravar no armazenamento externo secundário.
7.6.2. Armazenamento compartilhado do aplicativo Os apps podem usar ACTION_OPEN_DOCUMENT_TREE para gravar no armazenamento externo secundário.
7.6.2. Armazenamento compartilhado do aplicativo Esclarecer que /sdcard pode compartilhar armazenamento com /data
7,7 USB O requisito redundante foi removido do UMS/MTP na versão 7.7
7.8.1. Microfone Foram adicionados requisitos do Android Automotive.
8.2. Desempenho de acesso a E/S de arquivos Esclarecimento dos requisitos.
9.5. Suporte a vários usuários A criptografia do cartão SD é necessária para o armazenamento externo principal.
9,8. Privacidade Adição de um requisito de privacidade para VPNs pré-carregadas.
9,9. Criptografia de disco completo Foi esclarecida a condição em que o suporte à criptografia de disco completo é obrigatório.
9.10. Inicialização verificada Melhoramos a definição de inicialização verificada.
11. Software atualizável Foi esclarecido que o requisito de download OTA é permitido, mas não obrigatório para implementações do Android Automotive.

13. Entre em contato

Você pode participar do fórum de compatibilidade do Android [Resources, 109] e pedir esclarecimentos ou apresentar problemas que você acha que o documento não aborda.

14. Recursos

1. Níveis de requisito do IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

2. Android Open Source Project: http://source.android.com/

3. Recursos do Android TV: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Recurso do Android Watch: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. Definições e documentação da API: http://developer.android.com/reference/packages.html

6. Referência de permissões do Android: http://developer.android.com/reference/android/Manifest.permission.html

7. Referência do android.os.Build: http://developer.android.com/reference/android/os/Build.html

8. Strings de versão permitidas do Android 5.1: http://source.android.com/compatibility/5.1/versions.html

9. Provedor de telefonia: http://developer.android.com/reference/android/provider/Telephony.html

10. Emulação de cartão com base em host: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. Pacote de extensões para Android: http://developer.android.com/guide/topics/graphics/opengl.html#aep

12. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

13. Compatibilidade com a WebView: http://www.chromium.org/

14. HTML5: http://html.spec.whatwg.org/multipage/

15. Recursos off-line do HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

16. Tag de vídeo HTML5: http://dev.w3.org/html5/spec/Overview.html#video

17. API Geolocation HTML5/W3C: http://www.w3.org/TR/geolocation-API/

18. API Webstorage do HTML5/W3C: http://www.w3.org/TR/webstorage/

19. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/

20. Formato executável do Dalvik e especificação de bytecode: disponível no código-fonte do Android, em dalvik/docs

21. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

22. Notificações: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

23. Recursos do aplicativo: https://developer.android.com/guide/topics/resources/available-resources.html

24. Guia de estilo de ícones da barra de status: http://developer.android.com/design/style/iconography.html

25. Recursos de notificações: https://developer.android.com/design/patterns/notifications.html

26. Gerenciador de pesquisa: http://developer.android.com/reference/android/app/SearchManager.html

27. Toasts: http://developer.android.com/reference/android/widget/Toast.html

28. Temas: http://developer.android.com/guide/topics/ui/themes.html

29. Classe R.style: http://developer.android.com/reference/android/R.style.html

30. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. Planos de fundo interativos: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. Recursos da tela de informações gerais: http://developer.android.com/guide/components/recents.html

33. Fixação de tela: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. Métodos de entrada: http://developer.android.com/guide/topics/text/creating-input-method.html

35. Notificação de mídia: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

36. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

37. Settings.Secure LOCATION_MODE:

http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

39. Administração de dispositivos Android: http://developer.android.com/guide/topics/admin/device-admin.html

40. Referência do DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

41. App proprietário do dispositivo Android:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. APIs do Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. APIs de acessibilidade do Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

44. Projeto Eyes Free: http://code.google.com/p/eyes-free

45. APIs Text-to-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. TV Input Framework: /devices/tv/index.html

47. Documentação de referência da ferramenta (para adb, aapt, ddms, systrace): http://developer.android.com/tools/help/index.html

48. Descrição do arquivo apk do Android: http://developer.android.com/guide/components/fundamentals.html

49. Arquivos de manifesto: http://developer.android.com/guide/topics/manifest/manifest-intro.html

50. Formatos de mídia do Android: http://developer.android.com/guide/appendix/media-formats.html

51. Requisitos de codificação de hardware do RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/ (em inglês)

52. API AudioEffect: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. Classe android.content.pm.PackageManager do Android e lista de recursos de hardware:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: http://developer.android.com/tools/help/adb.html

56. Dumpsys: /devices/input/diagnostics.html

57. DDMS: http://developer.android.com/tools/debugging/ddms.html

58. Ferramenta de teste do Monkey: http://developer.android.com/tools/help/monkey.html

59. Ferramenta SysyTrace: http://developer.android.com/tools/help/systrace.html

60. Configurações relacionadas ao desenvolvimento de apps Android:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

61. Suporte a várias telas: http://developer.android.com/guide/practices/screens_support.html

62. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

63. RenderScript: http://developer.android.com/guide/topics/renderscript/

64. Pacote de extensões do Android para OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. Aceleração de hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. Extensão EGL-EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

67. Gerenciador de tela: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

68. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

69. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

70. Configuração de entrada por toque: http://source.android.com/devices/tech/input/touch-devices.html

71. API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html

72. API Key Event: http://developer.android.com/reference/android/view/KeyEvent.html

73. Sensores de código aberto do Android: http://source.android.com/devices/sensors

74. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

75. Evento do sensor de carimbo de data/hora: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. Sensores compostos de código aberto do Android: /devices/sensors/sensor-types.html#composite_sensor_type_summary

77. Modo de acionamento contínuo: /docs/core/interaction/sensors/report-modes#continuous

78. Sensor de acelerômetro: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

79. API Wi-Fi Multicast: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

80. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

81. API WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html

82. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

83. API Bluetooth ScanFilter: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. Protocolo Push NDEF: http://source.android.com/compatibility/ndef-push-protocol.pdf

85. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

86. Configurações de compartilhamento de NFC do Android:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

87. Transferência de conexão NFC: http://members.nfc-forum.org/specs/spec_list/#conn_handover

88. Pareamento simples e seguro do Bluetooth usando NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

90. API de orientação da câmera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

91. Câmera: http://developer.android.com/reference/android/hardware/Camera.html

92. Câmera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

93. Nível do hardware da câmera: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. Suporte à versão da câmera: http://source.android.com/devices/camera/versioning.html

95. DownloadManager do Android: http://developer.android.com/reference/android/app/DownloadManager.html

96. Transferência de arquivos do Android: http://www.android.com/filetransfer

97. Acessórios abertos do Android: http://developer.android.com/guide/topics/connectivity/usb/accessory.html

98. Áudio USB do Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

99. Especificação de carregamento USB: http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf

100. API Host USB: http://developer.android.com/guide/topics/connectivity/usb/host.html

101. Fone de ouvido de áudio com fio: http://source.android.com//docs/core/interaction/accessories/headset/plug-headset-spec.html

102. Referência de segurança e permissões do Android: http://developer.android.com/guide/topics/security/permissions.html

103. Referência do UserManager: http://developer.android.com/reference/android/os/UserManager.html

104. Referência de armazenamento externo: http://source.android.com/docs/core/storage

105. APIs de armazenamento externo: http://developer.android.com/reference/android/os/Environment.html

106. Código abreviado de SMS: http://en.wikipedia.org/wiki/Short_code

107. Criptografia de código aberto do Android: http://source.android.com/docs/security/features/encryption

108. Visão geral do Programa de compatibilidade do Android: http://source.android.com//docs/compatibility

109. Fórum de compatibilidade com o Android: https://groups.google.com/forum/#!forum/android-compatibility

110. Projeto WebM: http://www.webmproject.org/

111. API Android UI_MODE_TYPE_CAR: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

112. API MediaCodecList do Android: http://developer.android.com/reference/android/media/MediaCodecList.html

113. API CamcorderProfile do Android: http://developer.android.com/reference/android/media/CamcorderProfile.html

Muitos desses recursos 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 Conjunto de teste de compatibilidade não concordar com a documentação do SDK, a documentação do SDK será considerada oficial. Todos os detalhes técnicos fornecidos nas referências acima são considerados parte desta definição de compatibilidade.