Revisão 1
Última atualização: 12 de janeiro de 2015
Copyright © 2015, Google Inc. Todos os direitos reservados.
compatibility@android.com
Índice
1. Introdução
Este documento enumera os requisitos que precisam ser atendidos para que os dispositivos sejam compatíveis com o Android 5.0.
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 que executa o Android 5.0. Uma "implementação de dispositivo" ou "implementação" é a solução de hardware/software desenvolvida.
Para serem consideradas compatíveis com o Android 5.0, as implementações de dispositivos PRECISAM atender aos requisitos apresentados nesta definição de compatibilidade, incluindo todos os documentos incorporados por referência.
Quando essa definição ou os testes de software descritos na seção 10 forem silenciosos, ambíguos ou incompletos, será responsabilidade do implementador do dispositivo garantir a compatibilidade com as implementações atuais.
Por esse motivo, o Android Open Source Project [Resources, 2] é a implementação de referência e preferida do Android. Os implementadores de dispositivos são fortemente incentivados a basear 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 desse 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
- É PRECISO declarar o recurso android.hardware.type.watch.
- É necessário oferecer suporte a uiMode = UI_MODE_TYPE_WATCH [Resources, 4].
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.0, a menos que o requisito seja descrito explicitamente como aplicável apenas a um tipo específico de dispositivo Android.
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.
|
Categorias |
Recurso |
Section |
Portátil |
Televisão |
Assista |
Outro |
|
Entrada |
Botão direcional |
OBRIGATÓRIO |
||||
|
Tela touchscreen |
OBRIGATÓRIO |
OBRIGATÓRIO |
DEVE |
|||
|
Microfone |
OBRIGATÓRIO |
DEVE |
OBRIGATÓRIO |
DEVE |
||
|
Sensores |
Acelerômetro |
DEVE |
DEVE |
DEVE |
||
|
GPS |
DEVE |
|||||
|
Conectividade |
Wi-Fi |
DEVE |
OBRIGATÓRIO |
DEVE |
||
|
Wi-Fi Direct |
DEVE |
DEVE |
DEVE |
|||
|
Bluetooth |
DEVE |
OBRIGATÓRIO |
OBRIGATÓRIO |
DEVE |
||
|
Bluetooth de baixa energia |
DEVE |
OBRIGATÓRIO |
DEVE |
DEVE |
||
|
Modo de periférico/ host USB |
DEVE |
|
DEVE |
|||
|
Saída |
Alto-falantes e/ou portas de saída de áudio |
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.0, esse campo PRECISA ter o valor inteiro 21. |
|
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.0, esse campo PRECISA ter o valor inteiro 21. |
|
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) Exemplo: acme/myproduct/mydevice:5.0/LRWXX/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 intents 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 associe e implemente 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 que o filtro do navegador para "http://". As implementações de dispositivos precisam fornecer uma interface do usuário 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.4. Compatibilidade com a Web
3.4.1. Compatibilidade com a WebView
|
A implementação completa da API android.webkit.Webview PODE ser fornecida em dispositivos Android Watch, mas PRECISA ser fornecida em todos os outros tipos de implementações de dispositivo. |
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.0. 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)) AppleWebKit/537.36 (KHTML, como Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
- O valor da string $(MODEL) PRECISA ser igual ao valor de android.os.Build.MODEL.
- O valor da string $(BUILD) PRECISA ser igual ao valor de android.os.Build.ID.
- O valor da string $(CHROMIUM_VER) PRECISA ser a versão do Chromium no 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
|
Dispositivos Android TV e de relógio podem omitir um aplicativo de navegador, mas precisam oferecer suporte aos padrões de intent pública, conforme descrito na seção 3.2.3.1. Todos os outros tipos de implementações de dispositivos precisam incluir um aplicativo de navegador independente para navegação geral na Web. |
O navegador independente PODE ser baseado em uma tecnologia de navegador diferente do WebKit. No entanto, mesmo que um aplicativo de navegador alternativo seja usado, o componente android.webkit.WebView fornecido a aplicativos de terceiros PRECISA ser baseado no WebKit, conforme descrito na seção 3.4.1.
As implementações podem enviar uma string de user agent personalizada no aplicativo de navegador independente.
O aplicativo de navegador independente (seja baseado no aplicativo de navegador WebKit upstream ou em uma substituição de terceiros) 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:
- cache do aplicativo/operação off-line [Recursos, 15]
- a
- geolocalização [Recursos, 17]
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
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) |
16MB |
|
160 dpi (mdpi) |
||
|
213 dpi (tvdpi) |
32MB |
|
|
240 dpi (hdpi) |
||
|
320 dpi (xhdpi) |
64MB |
|
|
400 dpi (400dpi) |
96MB |
|
|
480 dpi (xxhdpi) |
128MB |
|
|
560 dpi (560dpi) |
192MB |
|
|
640 dpi (xxxhdpi) |
256MB |
|
|
grande |
120 dpi (ldpi) |
16MB |
|
160 dpi (mdpi) |
32MB |
|
|
213 dpi (tvdpi) |
64MB |
|
|
240 dpi (hdpi) |
||
|
320 dpi (xhdpi) |
128MB |
|
|
400 dpi (400dpi) |
192MB |
|
|
480 dpi (xxhdpi) |
256MB |
|
|
560 dpi (560dpi) |
384MB |
|
|
640 dpi (xxxhdpi) |
512 MB |
|
|
extra grande |
160 dpi (mdpi) |
64MB |
|
213 dpi (tvdpi) |
96MB |
|
|
240 dpi (hdpi) |
||
|
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 tenha suporte em 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 som etc.) fornecidos nas APIs [Resources, 23] ou no guia de estilo de ícones da barra de status/sistema [Resources, 24]. 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: as visualizações interativas podem ser aceitas ou dispensadas pelos usuários sem que eles precisem sair do app atual.
- Notificações na tela de bloqueio: notificações exibidas em uma tela de bloqueio com controle granular de visibilidade.
As implementações de dispositivos precisam mostrar e executar essas notificações corretamente, incluindo 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.
3.8.4. Pesquisar
O Android inclui APIs [Resources, 26] que permitem que os desenvolvedores incorporem a pesquisa aos aplicativos 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 aplicativos apliquem estilos em uma atividade ou aplicativo inteiro.
O Android inclui uma família de temas "Holo" como um conjunto de estilos definidos para que os desenvolvedores de 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 5.0 inclui uma família de temas "Material" como um conjunto de estilos definidos para que os desenvolvedores de apps possam usar se quiserem combinar a aparência e a sensação do tema de design em uma ampla variedade de tipos de dispositivos Android. As implementações de dispositivos precisam oferecer suporte à família de temas "Material" e NÃO podem alterar nenhum dos atributos do tema Material ou 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 apps possam usar se quiserem combinar a aparência e a sensação do tema do dispositivo conforme definido pelo implementador do dispositivo. As implementações 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 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 destaque nos itens 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 uma capacidade 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 no dispositivo PRECISAM oferecer suporte ao modelo de notificação de mídia junto com outras notificações.
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 de emoji em glifo de cor.
O Android 5.0 inclui suporte à 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 de 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 dispositivo que incluem suporte para a tela de bloqueio 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 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 precisam atender aos seguintes requisitos:
- PRECISA oferecer suporte a implementações de serviços de acessibilidade de terceiros pelas APIs android.accessibilityservice [Resources, 43]
- PRECISA 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.
- A menos que um dispositivo Android Watch não tenha saída de áudio, as implementações de dispositivo PRECISAM fornecer um mecanismo acessível ao usuário para ativar e desativar serviços de acessibilidade e PRECISAM 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 de dispositivos:
- 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 de dispositivos precisam oferecer suporte aos formatos de mídia, codificadores, decodificadores, tipos de arquivo e formatos de contêiner definidos nas tabelas abaixo. 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) |
REQUIRED1 |
REQUIRED |
Compatível com 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+) |
REQUIRED1 (Android 4.1+) |
REQUIRED |
Compatível com 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 |
Compatível com 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) |
REQUIRED1 (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 |
|
REQUIRED (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 |
REQUIRED4 (Android 4.1+) |
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 |
REQUIRED (Android 5.0+) |
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 |
REQUIRED1 |
REQUIRED2 |
|
• 3GPP (.3gp) • MPEG-4 (.mp4) |
|
H.264 AVC |
REQUIRED2 |
REQUIRED2 |
• 3GPP (.3gp) • MPEG-4 (.mp4) • MPEG-TS (.ts, AAC exclusivo de áudio, não pesquisável, Android 3.0+) |
|
|
H.265 HEVC |
REQUIRED2 |
Consulte a seção 5.3 para mais detalhes. |
MPEG-4 (.mp4) |
|
|
MPEG-4 SP |
|
REQUIRED2 |
|
3GPP (.3gp) |
|
VP83 |
REQUIRED2 (Android 4.3 ou mais recente) |
REQUIRED2 (Android 2.3.3+) |
• WebM (.webm) [Resources, 110] • Matroska (.mkv, Android 4.0+)4 |
|
|
VP9 |
REQUIRED2 (Android 4.4+) |
Consulte a seção 5.3 para mais detalhes. |
• WebM (.webm) [Resources, 110] • Matroska (.mkv, Android 4.0+)4 |
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.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 |
|
Taxa de frames 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 os codecs VP8, VP9, H.264 e H.265.
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 |
|
Taxa de frames 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 |
|
Taxa de frames 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 |
|
Taxa de frames 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 nível principal do perfil principal de nível 4.1 e ao perfil de decodificação HD 1080p e devem oferecer suporte ao perfil de nível principal do Main10 de nível 5 e ao perfil de decodificação UHD.
|
SD (baixa qualidade) |
SD (alta qualidade) |
HD 720p 1 |
HD 1080p 1 |
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 |
|
Taxa de frames 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 Obrigatório 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. Caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.
5.4.1. Captura de áudio bruto
As implementações de dispositivo que declaram android.hardware.microphone precisam permitir a captura de conteúdo de áudio bruto com as seguintes características:
- Formato: PCM linear, 16 bits
- Taxas de amostragem: 8.000, 11.025, 16.000, 44.100
- Canais: mono
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 AudioEffect Equalizer e LoudnessEnhancer
- PRECISA oferecer suporte à implementação da API do visualizador, controlável pela classe Visualizer
- DEVE oferecer suporte às implementações EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB e EFFECT_TYPE_VIRTUALIZER controláveis pelas subclasses 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 estava inativo e desligado antes da solicitação.
- latência de saída contínua: a latência de saída para frames subsequentes, depois que o dispositivo começa a reproduzir á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 da latência de entrada do primeiro frame, quando o sistema de entrada de áudio ficou ocioso e desativado antes da solicitação.
- Latência na entrada contínua: a latência na entrada de frames subsequentes enquanto o dispositivo captura á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 OpenSL ES PCM buffer queue: 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:
- Android Debug Bridge (adb) [Resources, 55]
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.
- Monkey [Resources, 58]
As implementações de dispositivos precisam incluir o framework Monkey e disponibilizá-lo para uso de aplicativos.
- SysTrace [Resources, 59]
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 do componente AINDA precisam ser apresentadas.
- Os comportamentos da API precisam ser implementados como no-ops de maneira razoável.
- Os métodos da API precisam retornar valores nulos quando permitido pela documentação do SDK.
- Os métodos da API precisam retornar implementações sem operação de classes em que valores nulos não são permitidos pela documentação do SDK.
- Os métodos da API não podem gerar exceções não documentadas pela documentação do SDK.
Um exemplo típico de um cenário em que esses requisitos se aplicam é a API de telefonia: mesmo em dispositivos que não são smartphones, essas APIs precisam ser implementadas como no-ops razoáveis.
As implementações de dispositivos precisam informar 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 da diagonal: a distância em polegadas entre dois cantos opostos da parte iluminada da tela.
- Pontos por polegada (dpi): o número de pixels 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 da dimensão mais longa da tela em relação à dimensão mais curta. Por exemplo, uma tela de 480 x 854 pixels seria 854 / 480 = 1,779, ou aproximadamente "16:9".
- Pixel de densidade independente (dp): a unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como: pixels = dps * (densidade / 160).
7.1.1. Configuração da tela
7.1.1.1. Tamanho da tela
|
Dispositivos Android Watch (detalhados na seção 2) PODEM ter tamanhos de tela menores, conforme descrito nesta seção. |
O framework da 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 ('pequeno'), a menos que sejam um dispositivo 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 como "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 da diagonal entre 1,1 e 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
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)
- 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 pelo 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 equivalente ao tamanho de tela "normal" (largura de 320 dp) para beneficiar aplicativos legados que não foram desenvolvidos para versões antigas do Android que antecedem a independência do tamanho da tela. As implementações de dispositivos precisam incluir suporte ao modo de compatibilidade de aplicativos legados conforme implementado pelo código aberto do Android upstream. Ou seja, as implementações de dispositivos NÃO PODEM alterar os gatilhos ou os 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 externas
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
7.2.1. Teclado
|
Os dispositivos Android Watch podem, mas outros tipos de implementações de dispositivo precisam implementar um teclado virtual. |
Implementações de dispositivos:
- DEVE 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 torne menos razoável ter um teclado virtual.
- PODE incluir outras implementações de teclado virtual
- PODE incluir um teclado de hardware
- 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, 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.
- 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 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.0, isso é RECOMENDADO.
- NÃO pode modificar a posição do pop-up de overflow de ação exibido ao selecionar o botão de overflow na barra de ações.
- PODE renderizar o pop-up de ação em uma posição modificada na tela quando ele é mostrado selecionando o botão físico do menu.
Para garantir a compatibilidade com versões anteriores, as implementações de dispositivos precisam disponibilizar a função Menu para os aplicativos quando targetSdkVersion for menor ou igual a 10, seja por um botão físico, uma chave 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 "perfil baixo" discreto (por exemplo, escurecido) 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.
- DEVE 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 5.0 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 de funcionalidade de tela touch. 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:
- PRECISA 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 no ponteiro para baixo ou para cima 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:
|
Button |
Uso de HID2 |
Botão do Android |
|
A1 |
0x09 0x0001 |
KEYCODE_BUTTON_A (96) |
|
B1 |
0x09 0x0002 |
KEYCODE_BUTTON_B (97) |
|
X1 |
0x09 0x0004 |
KEYCODE_BUTTON_X (99) |
|
Y1 |
0x09 0x0005 |
KEYCODE_BUTTON_Y (100) |
|
0x01 0x00393 |
||
|
0x01 0x00393 |
||
|
0x09 0x0007 |
KEYCODE_BUTTON_L1 (102) |
|
|
0x09 0x0008 |
KEYCODE_BUTTON_R1 (103) |
|
|
0x09 0x000E |
KEYCODE_BUTTON_THUMBL (106) |
|
|
0x09 0x000F |
KEYCODE_BUTTON_THUMBR (107) |
|
|
0x0c 0x0223 |
KEYCODE_HOME (3) |
|
|
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 |
|
0x02 0x00C5 |
AXIS_LTRIGGER |
|
|
0x02 0x00C4 |
AXIS_RTRIGGER |
|
|
0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
|
|
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 dispositivo 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", "Início" e "Selecionar" e oferecer suporte a eventos de 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].
- PRECISA ser capaz de informar eventos com frequência de pelo menos 100 Hz e deve informar eventos com frequência de pelo menos 200 Hz
- É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android [Resources, 74].
- PRECISA ser capaz de medir a partir da queda livre até quatro vezes a gravidade (4g) ou mais em qualquer eixo
- PRECISA ter uma resolução de pelo menos 8 bits e DEVE ter uma resolução de pelo menos 16 bits
- DEVEM ser calibrados durante o uso se as características mudarem ao longo do ciclo de vida e forem compensadas, e preservar os parâmetros de compensação entre as reinicializações do dispositivo.
- DEVE ser compensada pela temperatura
- 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 forem incluídos
7.3.2. Magnetômetro
As implementações de dispositivos devem incluir um magnetômetro de três eixos (bússola). Se um dispositivo incluir um magnetômetro de três eixos, ele:
- É 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].
- PRECISA ser capaz de medir entre -900 μT e +900 μT em cada eixo antes de saturar
- É PRECISO ter um valor de deslocamento de ferro rígido menor que 700 μT e TER um valor abaixo de 200 μT, colocando o magnetômetro longe de campos magnéticos dinâmicos (induzidos por corrente) e estáticos (induzidos por ímã).
- PRECISA ter uma resolução igual ou mais densa que 0,6 μT e DEVE ter uma resolução igual ou mais densa que 0,2 μT
- DEVE ser compensada pela temperatura
- PRECISA 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 em 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
- PRECISA ser capaz de informar eventos com frequência de pelo menos 100 Hz e deve informar eventos com frequência de pelo menos 200 Hz
- PRECISA ter uma resolução de 12 bits ou mais e DEVE ter uma resolução de 16 bits ou mais
- PRECISA ser compensada por temperatura
- PRECISA ser calibrado e compensado durante o uso e preservar os parâmetros de compensação entre as reinicializações do dispositivo
- PRECISA ter uma variação não maior 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
- PRECISA ser compensada por 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 uma 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, as APIs e a funcionalidade 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
- É NECESSÁRIO implementar a API multicast conforme descrito na documentação do SDK [Resources, 79].
- DEVE oferecer suporte a DNS multicast (mDNS) e NÃO DEVE 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:
- É OBRIGATÓRIO informar o recurso de hardware android.hardware.wifi.direct
- PRECISA ter suporte à operação regular de Wi-Fi
- DEVE oferecer suporte a operações simultâneas de Wi-Fi e Wi-Fi Direct
7.4.2.2. Configuração de link direto com Wi-Fi em túnel
|
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 o TDLS apenas quando for 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 de dispositivos Android TV precisam oferecer suporte a Bluetooth e Bluetooth LE, e as implementações de dispositivos Android Watch precisam oferecer suporte a Bluetooth. |
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:
- É PRECISO declarar o recurso de hardware android.hardware.bluetooth_le.
- É necessário 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. Caso contrário, DEVE informar "false" sempre que 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. É recomendado que os dispositivos novos e atuais que executam essa versão do Android atendam a esses requisitos para que possam ser atualizados 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.
- É NECESSÁRIO 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 "Toque para transmitir", antes de enviar mensagens P2P NDEF de saída.
- DEVE ativar o Android Beam por padrão e DEVE ser capaz de enviar e receber usando o Android Beam, mesmo quando outro modo P2P de NFC proprietário estiver ativado
- PRECISA oferecer suporte à transferência de conexão NFC para Bluetooth quando o dispositivo oferece suporte ao perfil de envio de objeto Bluetooth. As implementações de dispositivos precisam oferecer suporte à transferência de conexão para Bluetooth ao usar android.nfc.NfcAdapter.setBeamPushUris, implementando as especificações "Connection Handover version 1.2" [Resources, 87] e "Bluetooth Secure Simple Pairing Using NFC version 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 de NFC.
- DEVE estar no modo de descoberta de NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.
- 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:
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 5.0 inclui suporte para o modo de emulação de cartão host (HCE, na sigla em inglês) do NFC. Se uma implementação de dispositivo incluir um controlador NFC compatível com HCE e roteamento de ID do aplicativo (AID), ele:
- É PRECISO informar a constante de recurso android.hardware.nfc.hce.
- É PRECISO 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:
- PRECISA implementar as APIs correspondentes do Android, conforme documentado pelo SDK do Android
- É PRECISO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature() [Resources, 53]. Esse não é um recurso padrão do Android e, como tal, não aparece como uma constante na classe PackageManager.
- NÃO IMPLEMENTE as APIs correspondentes do Android nem informe o recurso com.nxp.mifare, a menos que ele também implemente o suporte geral ao NFC, conforme descrito nesta seção.
Se uma implementação de dispositivo não incluir hardware NFC, ela NÃO PODE declarar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature() [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:
- É PRECISO informar a flag de recurso android.hardware.camera.any e android.hardware.camera.front.
- TER uma resolução mínima de VGA (640 x 480 pixels)
- NÃO use uma câmera frontal como padrão para a API Camera. A API de câmera no Android tem suporte específico para câmeras frontais, e as implementações de dispositivos NÃO PODEM configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que 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 ESPELHE os streams de imagem estática ou vídeo capturados finais retornados aos respostas de chamada do aplicativo ou comprometidos 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 tenha 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 ao recurso.
As implementações de dispositivos precisam transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada da foto 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 |
|
xhdpi ou menor em telas pequenas/normais hdpi ou menor em telas grandes mdpi ou menor 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 etc., que não estão sob o controle do kernel.
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 de "cache" padrão.
7.6.2. Armazenamento compartilhado do aplicativo
As implementações de dispositivos precisam oferecer armazenamento compartilhado para aplicativos, também chamados de "armazenamento externo compartilhado".
As implementações de dispositivos precisam ser configuradas com armazenamento compartilhado montado por padrão, "fora da caixa". Se o armazenamento compartilhado não estiver montado no caminho /sdcard do Linux, o dispositivo PRECISA incluir um link simbólico do Linux de /sdcard para o ponto de montagem real.
As implementações de dispositivos PODEM ter hardware para armazenamento removível acessível ao usuário, como um slot de cartão Secure Digital (SD). Se esse slot for usado para atender ao requisito de armazenamento compartilhado, a implementação do dispositivo:
- PRECISA implementar uma interface do usuário pop-up ou aviso ao usuário quando não houver um cartão SD
- É OBRIGATÓRIO incluir um cartão SD com formato FAT de 1 GB ou mais OU mostrar na caixa e em outros materiais disponíveis no momento da compra que o cartão SD precisa ser comprado separadamente
- PRECISA montar o cartão SD por padrão
Como alternativa, as implementações de dispositivo PODEM alocar armazenamento interno (não removível) como armazenamento compartilhado para apps, conforme incluído no projeto upstream do Android Open Source. As implementações de dispositivo 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, esse armazenamento PRECISA ter o tamanho de 1 GB ou mais 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 de 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 para os diretórios específicos do pacote no armazenamento externo secundário, mas devem expor o conteúdo de ambos os caminhos 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, as implementações de dispositivo precisam oferecer algum mecanismo para acessar o conteúdo do armazenamento compartilhado em um computador host, como armazenamento em massa USB (UMS) ou protocolo de transferência de mídia (MTP). As implementações de dispositivos PODEM usar o armazenamento em massa USB, mas PRECISAM usar o protocolo de transferência de mídia. Se a implementação do dispositivo oferecer suporte ao protocolo de transferência de mídia, ele:
- DEVE ser compatível 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"
Se a implementação do dispositivo não tiver portas USB, ela PRECISA fornecer a um computador host acesso ao conteúdo do armazenamento compartilhado por outros meios, como um sistema de arquivos de rede.
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].
- É NECESSÁRIO 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 enviada 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
|
Os dispositivos portáteis e de relógio 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:
- É OBRIGATÓRIO informar a constante de recurso android.hardware.audio.output.
- PRECISA atender aos requisitos de reprodução de áudio na seção 5.5
- Precisa atender aos requisitos de latência de áudio na seção 5.6
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:
- PRECISA oferecer suporte à reprodução de áudio em fones de ouvido estéreo e fones de ouvido estéreo com microfone e DEVE oferecer suporte à gravação de áudio em fones de ouvido estéreo com microfone
- DEVE oferecer suporte a conectores de áudio TRRS com a ordem de pinagem CTIA e DEVE oferecer suporte a conectores de áudio com a ordem de pinagem OMTP
- 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 gerar pelo menos 150 mV +/- 10% da tensão de saída em uma impedância de alto-falante de 32 Ohm
- A tensão de polarização do microfone PRECISA estar 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 DEVE estar abaixo de 1 frame por segundo.
- Latência da interface do usuário: as implementações de dispositivos precisam garantir uma experiência de usuário com baixa latência rolando uma lista de 10 mil entradas, conforme definido pelo Conjunto de testes de compatibilidade do Android (CTS, na sigla em inglês) em menos de 36 segundos.
- Troca de tarefasQuando vários aplicativos são iniciados, a reabertura de um aplicativo já em execução PRECISA levar menos de um segundo.
8.2. Desempenho de acesso a E/S de arquivos
As implementações de dispositivos precisam garantir a consistência do desempenho de acesso a arquivos para operações de leitura e gravação.
- Gravação sequencial: as implementações de dispositivo precisam garantir um desempenho de gravação sequencial de 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 dispositivo precisam garantir um desempenho de gravação aleatória de 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 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 dispositivo precisam garantir um desempenho de leitura aleatória de 3,5 MB/s para um arquivo de 256 MB usando 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 ambientes de execução alternativos a recursos protegidos por
permissões não solicitadas no arquivo AndroidManifest.xml do ambiente de execução pelo
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 aplicativos Android.
- NÃO PODE ser iniciado com, receber ou conceder a outros aplicativos qualquer privilégio 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 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].
- 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 usam 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 implementado abaixo do framework do Android:
- PRECISA manter a compatibilidade com os aplicativos atuais
- NÃO DEVE 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 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, se estiverem usando um kernel diferente do Linux, um sistema de controle de acesso obrigatório equivalente. Os dispositivos também precisam atender aos seguintes requisitos, que são atendidos pela implementação de referência no projeto de código aberto do Android upstream.
Implementações de dispositivos:
- PRECISA definir o SELinux como modo de aplicação global,
- É PRECISO configurar todos os domínios no modo de aplicação. Não são permitidos domínios no modo permissivo, incluindo domínios específicos de um dispositivo/fornecedor.
- NÃO é permitido modificar, omitir ou substituir as regras neverallow presentes na pasta external/sepolicy fornecida no upstream do Android Open Source Project (AOSP). Além disso, a política PRECISA ser compilada com todas as regras neverallow presentes, tanto para domínios AOSP SELinux quanto para domínios específicos de dispositivo/fornecedor.
As implementações de dispositivos precisam manter a política SELinux padrão fornecida na pasta external/sepolicy do Android Open Source Project upstream e adicionar apenas a essa política para a própria configuração específica do dispositivo. As implementações de dispositivos precisam ser compatíveis com o upstream do Android Open Source Project.
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.
9,9. Criptografia de disco completo
|
Opcional para implementações de dispositivos Android sem tela de bloqueio. |
Se a implementação do dispositivo tiver uma tela de bloqueio, ele PRECISA oferecer suporte à criptografia de disco completo dos dados privados do aplicativo (partição /data) e à 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
As implementações de dispositivos PRECISAM oferecer suporte à inicialização verificada para a integridade do dispositivo e, se o recurso tiver suporte, ele PRECISA declarar a flag de recurso da plataforma android.software.verified_boot. Embora esse requisito seja indicado como DEVE para essa versão da plataforma Android, ele é ALTAMENTE RECOMENDADO, já que esperamos que ele mude para OBRIGATÓRIO nas próximas versões do Android. O Android Open Source Project upstream oferece uma implementação preferencial deste 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 poderão ser lançadas para o Android 5.0. As implementações de dispositivos precisam passar na versão mais recente do CTS disponível no momento em que o software do dispositivo for concluído.
10.2. Verificador do CTS
As implementações de dispositivos precisam executar corretamente todos os casos aplicáveis no verificador CTS. O Verificador do CTS está incluído no Compatibility Test Suite e é destinado a ser executado por um operador humano para testar funcionalidades que não podem ser testadas por um sistema automatizado, como o funcionamento correto de uma câmera e sensores.
O Verificador do CTS tem testes para muitos tipos de hardware, incluindo alguns opcionais. As implementações de dispositivos precisam ser aprovadas em todos os testes de hardware que eles têm. Por exemplo, se um dispositivo tiver um acelerômetro, ele precisa executar corretamente o caso de teste do acelerômetro no Verificador 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" com uma reinicialização e atualização de um arquivo no armazenamento removível
No entanto, se a implementação do dispositivo incluir suporte a uma conexão de dados não medida, como o perfil 802.11 ou Bluetooth PAN (rede de área pessoal), o dispositivo PRECISA oferecer suporte a downloads over-the-air 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.0 e versões mais recentes, o mecanismo de atualização PRECISA oferecer suporte à verificação de que a imagem do sistema é binária idêntica ao resultado esperado após uma OTA. A implementação OTA baseada em blocos no Android Open Source Project upstream, adicionada desde o Android 5.0, 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ções |
Resumo da mudança |
|
1. Introdução |
Os requisitos foram atualizados para indicar a documentação do SDK como fonte de informações. |
|
2. Tipos de dispositivo |
Incluiu definições para tipos de dispositivos portáteis, de TV e de relógio. |
|
2.1 Configuração do dispositivo |
Adição de uma lista não exaustiva para ilustrar o desvio de configuração de hardware em dispositivos. |
|
3.1. Compatibilidade com a API gerenciada |
Também é NECESSÁRIO fornecer implementações completas de APIs com o marcador "@SystemApi" no código-fonte upstream do Android. |
|
3.2.2. Parâmetros do build |
Incluiu os parâmetros SUPPORTED_ABIS, SUPPORTED_32_BIT_ABIS e SUPPORTED_64_BIT_ABIS na lista, atualizou o PRODUTO para exigir SKUs de produtos exclusivos e atualizou as TAGS. |
|
3.2.3.1. Intents principais do aplicativo |
A linguagem foi esclarecida para que o requisito de compatibilidade seja principalmente o padrão de intents. |
|
3.2.3.5. Configurações padrão do app |
Incluiu novos requisitos para a tela inicial, NFC e apps de SMS padrão. |
|
3.3.1 Interfaces binárias do aplicativo |
Foram adicionados requisitos para oferecer suporte a ABIs de 32 bits equivalentes, caso haja suporte a ABIs de 64 bits. Os parâmetros foram atualizados para refletir essa mudança. |
|
3.4.1. Compatibilidade com a WebView |
Compatibilidade com o Webview necessária para todos os dispositivos, exceto dispositivos Android Watch. O requisito de string de localidade foi removido. |
|
3.4.2. Compatibilidade de navegadores |
Dispositivos Android TV e de relógio podem omitir um aplicativo de navegador, mas todos os outros tipos de implementações de dispositivo precisam incluir um. |
|
3.7. Compatibilidade com o ambiente de execução |
Requisitos mínimos de memória do aplicativo atualizados |
|
3.8.2. Widgets |
O suporte a widgets é opcional para todos os tipos de dispositivo, mas é recomendado para dispositivos portáteis. |
|
3.8.3. Notificações |
Definições expandidas para tipos de notificações com suporte. |
|
3.8.4. Pesquisar |
Os dispositivos Android TV precisam incluir a pesquisa global. Todos os outros tipos de dispositivos DEVEM. |
|
3.8.6. Temas |
Os dispositivos precisam oferecer suporte ao tema do Material Design. |
|
3.8.7. Planos fundo interativos |
Os dispositivos que incluem planos de fundo interativos precisam informar a flag de recurso da plataforma android.software.live_wallpaper. |
|
3.8.8. Troca de atividades |
Foi recomendado o suporte à nova interface do usuário "Recentes". DEVE mostrar pelo menos o título de quatro atividades por vez. |
|
3.8.10. Controle remoto de mídia na tela de bloqueio |
A API Cliente de controle remoto foi descontinuada em favor do modelo de notificação de mídia |
|
3.8.11. Sonhos |
Opcional para dispositivos Android Watch. Obrigatório para todos os outros tipos de dispositivo. |
|
3.8.13 Unicode e fonte |
PRECISA oferecer suporte a Roboto 2, além dos requisitos atuais. |
|
3.12. TV Input Framework |
As implementações de dispositivos Android TV precisam oferecer suporte ao framework de entrada de TV. |
|
5.1. Codecs de mídia |
Foram adicionadas três seções para codecs de áudio, imagem e vídeo. |
|
5.4 Gravação de áudio |
Dividido em subseções |
|
5.4.1. Captura de áudio bruto |
Características definidas para a captura de áudio bruto em dispositivos que declaram android.hardware.microphone |
|
5.5. Reprodução de áudio |
Adicionamos a seção 5.5. Reprodução de áudio com duas seções: 5.5.1 Efeitos de áudio e 5.5.2. Volume da saída de áudio |
|
5.6 Latência de áudio |
Foram adicionadas definições e requisitos para jitter de saída fria, jitter de entrada fria e latência de ida e volta contínua. |
|
5.8 Mídia segura |
Incluiu os requisitos de mídia segura da versão 7.1.8. Telas externas e requisitos adicionais para Android TV. |
|
6.1. Ferramentas para desenvolvedores |
Recursos atualizados. |
|
6.2.1. Experimental |
Seção removida |
|
7. Compatibilidade de hardware |
Atualização para refletir que as implementações de dispositivos precisam informar consistentemente a configuração de hardware precisa para o mesmo fingerprint de build. |
|
7.1.1.1. Tamanho da tela |
Atualização para refletir o tamanho da tela dos dispositivos Android Watch e para que o valor não mude |
|
7.1.1.2. Proporção da tela |
Atualização para refletir a proporção da tela dos dispositivos Android Watch (1:1). |
|
7.1.3. Orientação da tela |
Atualização para refletir que os dispositivos com uma orientação fixa de tela no modo paisagem DEVEM informar apenas essa orientação. |
|
7.1.4. Aceleração gráfica 2D e 3D |
Foi adicionado que os dispositivos Android PODEM oferecer suporte ao pacote de extensão do Android. |
|
(antiga) 7.1.6. Tipos de tela |
Seção removida |
|
7.1.6. Tecnologia da tela |
A proporção de pixels (PAR) foi atualizada para ficar entre 0,9 e 1,15. (~15% de tolerância) |
|
7.1.7. Telas externas |
Parte da seção foi movida para a seção 5.8. Secure Media. |
|
7.2.2. Navegação sem toque |
Os dispositivos Android TV precisam oferecer suporte ao D-pad. |
|
7.2.3. Teclas de navegação |
Idioma incluído para suporte a diferentes tipos de dispositivos. |
|
7.2.4. Entrada por tela touchscreen |
Os dispositivos Android Watch precisam oferecer suporte à entrada por touchscreen. |
|
7.2.6. Suporte a controles de jogos |
Adicionamos uma seção com os requisitos do Android TV. |
|
7.2.7. Controle remoto |
Adicionamos uma seção com os requisitos do Android TV. |
|
7.3. Sensores |
Os sensores sintéticos foram redefinidos como sensores compostos, e os sensores de streaming como sensores contínuos. Os sensores precisam informar o horário do evento em nanossegundos. |
|
7.3.1. Acelerômetro |
Foram esclarecidos os tipos de sensores necessários e os limites de requisito revisados. |
|
7.3.2. Magnetômetro |
Foram esclarecidos os tipos de sensores necessários e os limites de requisito revisados. |
|
7.3.4. Giroscópio |
Foram esclarecidos os tipos de sensores necessários e os limites de requisito revisados. |
|
7.3.5. Barômetro |
Mudou de "pode" para "deve" implementar o barômetro. É PRECISO implementar e informar o sensor TYPE_PRESSURE. |
|
7.3.6. Termômetro |
Os dispositivos podem incluir um termômetro ambiente. PODE, mas NÃO DEVE incluir o termômetro da CPU. |
|
7.3.8. Sensor de proximidade |
Os dispositivos que podem fazer uma chamada de voz e indicar qualquer valor diferente de PHONE_TYPE_NONE em getPhoneType precisam incluir um sensor de proximidade. |
|
7.4.2. IEEE 802.11 (Wi-Fi) |
Os dispositivos Android TV precisam incluir suporte a Wi-Fi. Os dispositivos que oferecem suporte ao Wi-Fi precisam informar android.hardware.wifi. |
|
7.4.2.1. Wi-Fi Direct |
É PRECISO informar o recurso de hardware android.hardware.wifi.direct. |
|
7.4.2.2. Configuração de link direto com Wi-Fi em túnel |
Os dispositivos Android TV precisam incluir suporte a Wi-Fi TDLS. |
|
7,5. Cameras |
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.3. Câmeras externas |
Foram adicionados requisitos que as implementações de dispositivos com modo de host USB PODEM incluir suporte a uma câmera externa. |
|
7.5.5. Recursos do sistema de câmera |
Adição de uma lista de recursos da câmera e de quando eles precisam ser definidos. |
|
7.6.1. Memória e armazenamento mínimos |
Requisitos atualizados para dispositivos de 32 e 64 bits. O requisito de memória do SVELTE foi removido. Os dispositivos PRECISAM ter pelo menos 1,5 GB de armazenamento não volátil. |
|
7.6.2. Armazenamento compartilhado do aplicativo |
Requisitos atualizados para armazenamento removível acessível ao usuário |
| 7.6.2. Armazenamento compartilhado do aplicativo | Requisitos atualizados que os apps do sistema pré-instalados podem gravar no armazenamento externo secundário. |
|
7.7. USB |
Os requisitos para portas que não carregam na mesma borda da porta micro-USB foram removidos. Atualização dos requisitos para o modo host e periférico. |
|
7.7. USB |
Correção de erros de digitação na seção de USB. |
|
7.8.1. Áudio |
Movemos a seção do microfone para aqui. Foram adicionados requisitos para portas analógicas e de saída de áudio. |
|
8. Compatibilidade de performance |
Requisitos adicionados para a consistência da interface do usuário. |
|
9.5. Suporte a vários usuários |
O recurso de suporte para vários usuários é opcional para todos os tipos de dispositivo. Detalhes dos requisitos por tipo de dispositivo na seção. |
|
9.5. Suporte a vários usuários |
A criptografia do cartão SD é necessária para o armazenamento externo principal. |
|
9.7. Recursos de segurança do kernel |
PODE ter uma interface do usuário visível quando ocorre uma violação de segurança não bloqueada, resultando em uma exploração bem-sucedida. Não são permitidos domínios no modo permissivo. |
|
9,9. Criptografia de disco completo |
Dispositivos com uma tela de bloqueio precisam oferecer suporte à criptografia de disco completo. Para dispositivos novos, a criptografia de disco completo precisa ser ativada. |
|
9.10 Inicialização verificada |
Adicionamos uma seção para recomendar que as implementações de dispositivos ofereçam suporte à inicialização verificada para a integridade do dispositivo. |
|
10.3. Aplicativos de referência |
A seção foi removida do CDD. |
|
11. Software atualizável |
Se um dispositivo for compatível com o perfil 802.11 ou PAN (rede de área pessoal) do Bluetooth, ele PRECISA ser compatível com o download over-the-air com atualização off-line por reinicialização. |
|
14. Recursos |
Os recursos foram movidos da seção 2 para a seção 14 |
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.0: http://source.android.com//docs/compatibility/5.0/versions
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://www.whatwg.org/specs/web-apps/current-work/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:
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/guide/developing/tools/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: https://developer.android.com/studio/command-line/dumpsys.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:
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/docs/core/interaction/input/touch-devices
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/docs/core/interaction/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: http://source.android.com/devices/sensors/composite_sensors.html
77. Modo de acionador contínuo: http://source.android.com/devices/sensors/base_triggers.html#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/docs/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://www.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/docs/core/camera/versioning
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/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 de bateria USB, revisão 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip
100. API Host USB: http://developer.android.com/guide/topics/usb/host.html
101. Fone de ouvido com fio: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec
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/devices/tech/encryption/index.html
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/
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.