A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.

Esta página foi traduzida pela API Cloud Translation.

Documento de definição de compatibilidade do Android 4.0
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Revisão 4
Última atualização: 21 de abril de 2013

Índice

1. Introdução
2. Recursos
3. Software

3.1. Compatibilidade com a API gerenciada
3.2. Compatibilidade flexível de API

3.2.1. Permissões
3.2.2. Parâmetros do build
3.2.3. Compatibilidade de intent

3.2.3.1. Intenções principais de app
3.2.3.2. Modificações de intent
3.2.3.3. Namespaces de intent
3.2.3.4. Intents de transmissão

3.3. Compatibilidade com a API nativa

3.3.1 Interfaces binárias do aplicativo

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView
3.4.2. Compatibilidade com navegadores

3.5. Compatibilidade comportamental da API
3.6. Namespaces da API
3.7. Compatibilidade com máquinas virtuais
3.8. Compatibilidade com a interface do usuário

3.8.1. Widgets
3.8.2. Notificações
3.8.3. Pesquisa
3.8.4. Toasts
3.8.5. Temas
3.8.6. Planos de fundo interativos
3.8.7. Exibição de aplicativos recentes
3.8.8. Configurações de gerenciamento de entrada

3.9 Administração de dispositivos
3.10 Acessibilidade
3.11 Conversão de texto em fala

4. Compatibilidade de empacotamento de apps
5. Compatibilidade com multimídia

5.1. Codecs de mídia
5.2. Codificação de vídeo
5.3. Gravação de áudio
5.4. Latência de áudio
5.5. Protocolos de rede

6. Compatibilidade de ferramentas para desenvolvedores
7. Compatibilidade de hardware

7.1. Tela e gráficos

7.1.1. Configuração da tela
7.1.2. Métricas de exibição
7.1.3. Orientação da tela
7.1.4. Aceleração de gráficos 2D e 3D
7.1.5. Modo de compatibilidade de aplicativos legados
7.1.6. Tipos de tela
7.1.7. Tecnologia da tela

7.2. Dispositivos de entrada

7.2.1. Teclado
7.2.2. Navegação sem toque
7.2.3. Teclas de navegação
7.2.4. Entrada por tela touch
7.2.5. Entrada de toque falsa
7.2.6. Microfone

7.3. Sensores

7.3.1. Acelerômetro
7.3.2. Magnetômetro
7.3.3. GPS
7.3.4. Giroscópio
7.3.5. Barômetro
7.3.6. Termômetro
7.3.7. Fotômetro
7.3.8. Sensor de proximidade

7.4. Conectividade de dados

7.4.1. Telefonia
7.4.2. IEEE 802.11 (Wi-Fi)
7.4.3. Bluetooth
7.4.4. Comunicação a curta distância
7.4.5. Capacidade mínima de rede

7.5. Câmeras

7.5.1. Câmera traseira
7.5.2. Câmera frontal
7.5.3. Comportamento da API Camera
7.5.4. Orientação da câmera

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos
7.6.2. Armazenamento compartilhado do aplicativo

7.7. USB

8. Compatibilidade de desempenho
9. Compatibilidade do modelo de segurança

9.1. Permissões
9.2. Isolamento de UID e de processo
9.3. Permissões do sistema de arquivos
9.4. Ambientes de execução alternativos

10. Teste de compatibilidade de software

10.1. Conjunto de teste de compatibilidade
10.2. Verificador do CTS
10.3. Aplicativos de referência

11. Software atualizável
12. Entre em contato
Apêndice A: procedimento de teste de Bluetooth

1. Introdução

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

O uso de "precisa", "não pode", "requer", "deve", "não deve", "recomendado", "pode" e "opcional" é conforme o padrão IETF definido na 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 4.0. Uma "implementação de dispositivo" ou "implementação" é a solução de hardware/software desenvolvida.

Para serem consideradas compatíveis com o Android 4.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 implementações existentes.

Por esse motivo, o Android Open Source Project [Resources, 3] é a implementação de referência e preferida do Android. Os implementadores de dispositivos são fortemente incentivados a basear as implementações o máximo possível no código de origem "upstream" disponível no Android Open Source Project. Embora alguns componentes possam ser teoricamente substituídos por implementações alternativas, essa prática é fortemente desencorajada, porque passar nos testes de software vai se tornar substancialmente mais difícil. É responsabilidade do implementador garantir a compatibilidade com o comportamento completo da implementação padrão do Android, incluindo e além do conjunto de teste de compatibilidade. Por fim, observe que algumas substituições e modificações de componentes são explicitamente proibidas por este documento.

2. Recursos

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

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

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

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

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

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

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

RenderScript: http://developer.android.com/guide/topics/graphics/renderscript.html

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

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

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

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

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

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

API Webdatabase do HTML5/W3C: http://www.w3.org/TR/webdatabase/

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

Especificação da máquina virtual Dalvik: disponível no código-fonte do Android, em dalvik/docs

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

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

Recursos do aplicativo: http://code.google.com/android/reference/available-resources.html

Guia de estilo de ícones da barra de status: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure

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

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

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

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

Planos de fundo interativos: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

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

Classe android.app.admin.DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

APIs do Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/package-summary.html

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

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

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

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

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

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

Ferramenta de teste do Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey

Classe Android android.content.pm.PackageManager e lista de recursos de hardware: http://developer.android.com/reference/android/content/pm/PackageManager.html

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

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

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

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

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

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

MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

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

android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html

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

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

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

Apps para Android: http://code.google.com/p/apps-for-android

Classe android.app.DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

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

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

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

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

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

Muitos desses recursos são derivados diretamente ou indiretamente do SDK do Android 4.0 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.

3. Software

3.1. Compatibilidade com a API gerenciada

O ambiente de execução gerenciado (baseado em Dalvik) é o veículo principal para apps 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 VM 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 4.0 [Resources, 4].

As implementações de dispositivos NÃO PODEM omitir APIs gerenciadas, alterar interfaces ou assinaturas de API, desviar do comportamento documentado ou incluir no-ops, exceto quando especificamente permitido por esta definição de compatibilidade.

Essa definição de compatibilidade permite que alguns tipos de hardware para os quais o Android inclui APIs sejam omitidos pelas implementações de dispositivos. Nesses casos, as APIs ainda precisam estar presentes e se comportar de maneira razoável. Consulte a Seção 7 para ver os requisitos específicos para esse 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 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, 5]. A seção 10 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, 6] que têm a finalidade de descrever o dispositivo atual. Para fornecer valores consistentes e significativos em todas as implementações de dispositivos, a tabela abaixo inclui outras restrições sobre os formatos desses valores aos quais as implementações de dispositivos PRECISAM se conformar.

Parâmetro	Comentários
android.os.Build.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, 7].
android.os.Build.VERSION.SDK	A versão do sistema Android em execução no momento, em um formato acessível ao código de aplicativos de terceiros. Para o Android 4.0.1 a 4.0.2, esse campo PRECISA ter o valor inteiro 14. Para o Android 4.0.3 ou versões mais recentes, esse campo PRECISA ter o valor inteiro 15.
android.os.Build.VERSION.SDK_INT	A versão do sistema Android em execução no momento, em um formato acessível ao código de aplicativos de terceiros. Para o Android 4.0.1 a 4.0.2, esse campo PRECISA ter o valor inteiro 14. Para o Android 4.0.3 ou versões mais recentes, esse campo PRECISA ter o valor inteiro 15.
android.os.Build.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 ("").
android.os.Build.BOARD	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.,_-]+$"`.
android.os.Build.BRAND	Um valor escolhido pelo implementador do dispositivo que identifica o nome da empresa, organização, indivíduo etc. que produziu o dispositivo em formato legível por humanos. Um possível uso desse campo é indicar o OEM e/ou a operadora que vendeu o dispositivo. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.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.
android.os.Build.CPU_ABI2	O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a Seção 3.3: Compatibilidade com a API nativa.
android.os.Build.DEVICE	Um valor escolhido pelo implementador do dispositivo que identifica a configuração ou revisão específica do corpo (às vezes chamado de "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.,_-]+$"`.
android.os.Build.FINGERPRINT	Uma string que identifica exclusivamente esse build. Ele PRECISA ser razoavelmente legível para humanos. Ele precisa seguir este modelo: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Por exemplo: `acme/mydevice/generic:4.0/IRK77/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.
android.os.Build.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.,_-]+$"`.
android.os.Build.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 para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
android.os.Build.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.,_-]+$"`.
android.os.Build.MANUFACTURER	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 ("").
android.os.Build.MODEL	Um valor escolhido pelo implementador do dispositivo que contém o nome do dispositivo conhecido pelo usuário final. Ele DEVE ser o mesmo nome usado para comercializar e vender o dispositivo para os usuários finais. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
android.os.Build.PRODUCT	Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o nome de código do produto (SKU). 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.,_-]+$"`.
android.os.Build.SERIAL	Um número de série do hardware, se disponível. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `"^([a-zA-Z0-9]{0,20})$"`.
android.os.Build.TAGS	Uma lista separada por vírgulas de tags escolhidas pelo implementador do dispositivo que diferenciam ainda mais o build. Por exemplo, "unsigned,debug". O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.TIME	Um valor que representa o carimbo de data/hora de quando o build ocorreu.
android.os.Build.TYPE	Um valor escolhido pelo implementador do dispositivo que especifica a configuração do ambiente de execução do build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas de ambiente de execução do Android: "user", "userdebug" ou "eng". O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.USER	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. "Atendida" significa que o implementador do dispositivo PRECISA fornecer uma atividade ou serviço do Android que especifique um filtro de intent correspondente e se vincule e implemente o comportamento correto para cada padrão de intent especificado.

3.2.3.1. Intents principais do aplicativo

O projeto upstream do Android define vários aplicativos principais, como contatos, agenda, galeria de fotos, player de música e assim por diante. Os implementadores de dispositivos podem substituir esses aplicativos por versões alternativas.

No entanto, todas essas versões alternativas precisam respeitar os mesmos padrões de intent fornecidos pelo projeto upstream. Por exemplo, se um dispositivo tiver um player de música alternativo, ele ainda precisa honrar o padrão de intent emitido por aplicativos de terceiros para escolher uma música.

Os seguintes aplicativos são considerados principais do sistema Android:

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

Os principais aplicativos do sistema Android incluem vários componentes de atividade ou serviço considerados "públicos". Ou seja, o atributo "android:exported" pode estar ausente ou ter o valor "true".

Para cada atividade ou serviço definido em um dos apps principais do sistema Android que não é marcado como não público por um atributo android:exported com o valor "false", as implementações de dispositivos precisam incluir um componente do mesmo tipo que implementa os mesmos padrões de filtro de intent que o app principal do sistema Android.

Em outras palavras, uma implementação de dispositivo PODE substituir os apps do sistema Android principais. No entanto, se isso acontecer, a implementação do dispositivo PRECISA oferecer suporte a todos os padrões de intent definidos por cada app do sistema Android principal que está sendo substituído.

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

3.2.3.3. Namespaces de intent

As implementações de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou broadcast usando uma string de chave ACTION, CATEGORY ou outra no namespace android.* ou com.android.*. Os implementadores de dispositivos NÃO PODEM incluir componentes do Android que respeitem novos padrões de intent ou broadcast usando uma string de chave ACTION, CATEGORY ou outra 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 associados de forma clara e óbvia à própria organização.

Essa proibição é análoga à especificada para classes de linguagem Java na seção 3.6.

3.2.3.4. Intents de transmissão

Os aplicativos de terceiros dependem da plataforma para transmitir determinadas intents e receber notificações sobre mudanças no ambiente de hardware ou software. Dispositivos compatíveis com Android precisam transmitir as intents de transmissão pública em resposta a eventos do sistema adequados. As intents de transmissão são descritas na documentação do SDK.

3.3. Compatibilidade com a API nativa

3.3.1 Interfaces binárias do aplicativo

O código gerenciado em execução no Dalvik pode chamar o código nativo fornecido no arquivo .apk do aplicativo como um arquivo ELF .so compilado para a arquitetura de hardware adequada do dispositivo. Como o código nativo é altamente dependente da tecnologia do processador, o Android define várias interfaces binárias de aplicativos (ABIs) no Android NDK, no arquivo docs/CPU-ARCH-ABIS.txt. Se uma implementação de dispositivo for compatível com uma ou mais ABIs definidas, ela PRECISA implementar a compatibilidade com o Android NDK, conforme abaixo.

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

É necessário incluir suporte para que o código executado no ambiente gerenciado seja chamado em código nativo, usando a semântica padrão da Java Native Interface (JNI).
PRECISA ser compatível com a fonte (ou seja, compatível com o cabeçalho) e com binários (para a ABI) com cada biblioteca necessária na lista abaixo
É PRECISO informar com precisão a interface binária de aplicativo (ABI, na sigla em inglês) nativa compatível com o dispositivo pela API android.os.Build.CPU_ABI.
DEVE informar apenas as ABIs documentadas na versão mais recente do SDK do Android, no arquivo docs/CPU-ARCH-ABIS.txt.
DEVE ser criado usando o código-fonte e os arquivos de cabeçalho disponíveis no projeto de código aberto upstream do Android.

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.0)
libGLESv2.so (OpenGL ES 2.0)
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)
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.

A compatibilidade com o código nativo é desafiadora. Por esse motivo, é necessário repetir que os implementadores de dispositivos são MUITO incentivados a usar as implementações upstream das bibliotecas listadas acima para ajudar a garantir compatibilidade.

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView

A implementação do Android Open Source usa o mecanismo de renderização do WebKit para implementar o android.webkit.WebView. Como não é viável desenvolver um conjunto de testes abrangente para um sistema de renderização da Web, os implementadores de dispositivos precisam usar o build upstream específico do WebKit na implementação da WebView. Especificamente:

As implementações de android.webkit.WebView das implementações de dispositivos PRECISAM ser baseadas no build 534.30 do WebKit da árvore Android Open Source upstream para o Android 4.0. Esse build inclui um conjunto específico de correções de segurança e funcionalidade para a WebView. Os implementadores de dispositivos PODEM incluir personalizações na implementação do WebKit. No entanto, essas personalizações NÃO PODEM alterar o comportamento da WebView, incluindo o comportamento de renderização.
A string do user agent informada pela WebView PRECISA estar neste formato:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
- O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
- O valor da string $(LOCALE) DEVE seguir as convenções ISO para código de país e idioma e DEVE se referir à localidade configurada atual do dispositivo
- 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 componente WebView DEVE incluir suporte para o maior número possível de recursos HTML5 [Resources, 11]. No mínimo, as implementações de dispositivos precisam oferecer suporte a cada uma dessas APIs associadas ao HTML5 na WebView:

cache do aplicativo/operação off-line [Recursos, 12]
a tag <video> [Recursos, 13].
geolocalização [Recursos, 14]

Além disso, as implementações de dispositivos precisam oferecer suporte à API HTML5/W3C Webstorage [Resources, 15] e à API IndexedDB HTML5/W3C [Resources, 16]. Observação 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.

As APIs HTML5, como todas as APIs JavaScript, PRECISAM ser desativadas por padrão em uma WebView, a menos que o desenvolvedor as ative explicitamente usando as APIs do Android.

3.4.2. Compatibilidade de navegadores

As implementações de dispositivos precisam incluir um aplicativo de navegador independente para navegação geral do usuário 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 de HTML5 [Resources, 11]. 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, 12]
a tag <video> [Recursos, 13].
geolocalização [Recursos, 14]

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 Android upstream [Resources, 3]. 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 determinado tipo de componente do sistema (como Service, Activity, ContentProvider etc.)
Os dispositivos NÃO PODEM mudar a semântica de uma permissão padrão.

A lista acima não está completa. O conjunto de teste de compatibilidade (CTS) testa partes significativas da plataforma para compatibilidade comportamental, mas não todas. É responsabilidade do implementador garantir a compatibilidade 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 implementar novamente partes significativas do sistema.

3.6. Namespaces de API

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

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

As modificações proibidas incluem:

As implementações de dispositivos NÃO PODEM modificar as APIs expostas publicamente na plataforma Android alterando 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 ou alterar APIs existentes nos namespaces mencionados acima. Os implementadores de dispositivos PODEM fazer modificações apenas internas, mas essas modificações NÃO PODEM ser anunciadas ou expostas aos desenvolvedores.

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

Se um implementador de dispositivo propor a melhoria de um dos namespaces de pacote acima (por exemplo, adicionando uma nova funcionalidade útil a uma API existente ou adicionando uma nova API), ele PRECISA acessar source.android.com e iniciar o processo de contribuição de mudanças e código, de acordo com as informações deste 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 reforçar essas convenções e torná-las obrigatórias com a inclusão nesta definição de compatibilidade.

3.7. Compatibilidade com máquinas virtuais

As implementações de dispositivos precisam oferecer suporte à especificação completa do bytecode do Dalvik Executable (DEX) e à semântica da máquina virtual Dalvik [Resources, 17].

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

Tamanho da tela	Densidade da tela	Memória do aplicativo
pequeno / normal / grande	ldpi / mdpi	16MB
pequeno / normal / grande	tvdpi / hdpi	32MB
pequeno / normal / grande	xhdpi	64MB
extra grande	mdpi	32MB
extra grande	tvdpi / hdpi	64MB
extra grande	xhdpi	128MB

3.8. Compatibilidade da interface do usuário

3.8.1. Widgets

O Android define um tipo de componente e a API e o ciclo de vida correspondentes que permitem que os aplicativos exponham um "AppWidget" ao usuário final [Resources, 18]. A versão de referência do Android Open Source inclui um aplicativo de inicialização que oferece recursos de interface que permitem ao usuário adicionar, visualizar e remover AppWidgets da tela inicial.

As implementações de dispositivos PODEM substituir uma alternativa ao iniciador de referência (ou seja, a tela inicial). Os iniciadores alternativos precisam incluir suporte integrado a AppWidgets e expor recursos da interface do usuário para adicionar, configurar, visualizar e remover AppWidgets diretamente no iniciador. Os iniciadores alternativos PODEM omitir esses elementos da interface do usuário. No entanto, se eles forem omitidos, a implementação do dispositivo PRECISA fornecer um aplicativo separado acessível pelo iniciador que permita aos usuários adicionar, configurar, visualizar e remover AppWidgets.

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 de widgets de app na documentação do SDK do Android [Resources, 18] para mais detalhes.

3.8.2. Notificações

O Android inclui APIs que permitem que os desenvolvedores notifiquem os usuários sobre eventos importantes [Resources, 19], 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, 20] ou no guia de estilo de ícones da barra de status/sistema [Resources, 21]. 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 4.0 inclui suporte a notificações avançadas, como visualizações interativas para notificações em andamento. As implementações de dispositivos precisam mostrar e executar notificações avançadas corretamente, conforme documentado nas APIs do Android.

3.8.3. Pesquisar

O Android inclui APIs [Resources, 22] que permitem que os desenvolvedores incorporem a pesquisa aos apps e exponham os dados deles na pesquisa global do sistema. Em geral, essa funcionalidade consiste em uma única interface do usuário em todo o sistema que permite que os usuários entrem com consultas, mostrem sugestões à medida que digitam e mostrem resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para oferecer a pesquisa nos próprios apps e fornecer resultados à interface do usuário de pesquisa global comum.

As implementações de dispositivos precisam incluir 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 a pesquisa nos próprios aplicativos. As implementações de dispositivos precisam implementar as APIs que permitem que aplicativos de terceiros adicionem sugestões à caixa de pesquisa quando ela é executada no modo de pesquisa global. Se nenhum aplicativo de terceiros que use essa funcionalidade estiver instalado, o comportamento padrão DEVE ser mostrar os resultados e as sugestões do mecanismo de pesquisa da Web.

3.8.4. Avisos

Os aplicativos podem usar a API "Toast" (definida em [Resources, 23]) para mostrar strings não modais curtas ao usuário final, que desaparecem após um breve período. As implementações de dispositivos precisam mostrar avisos de apps para os usuários finais de maneira bem visível.

3.8.5. Temas

O Android oferece "temas" como um mecanismo para que os aplicativos apliquem estilos em uma atividade ou aplicativo inteiro. O Android 3.0 introduziu um novo tema "Holo" ou "holográfico" como um conjunto de estilos definidos para que os desenvolvedores de aplicativos os usem se quiserem combinar a aparência e a sensação do tema Holo, conforme definido pelo SDK do Android [Resources, 24]. As implementações de dispositivos NÃO PODEM alterar nenhum dos atributos do tema Holo expostos aos aplicativos [Resources, 25].

O Android 4.0 apresenta um novo tema "Padrão do dispositivo" como um conjunto de estilos definidos para que os desenvolvedores de aplicativos possam usar se quiserem combinar a aparência do tema do dispositivo conforme definido pelo implementador do dispositivo. As implementações de dispositivos podem modificar os atributos do tema DeviceDefault expostos aos apps [Resources, 25].

3.8.6. 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 "papéis de parede animados" ao usuário final [Resources, 26]. Os planos de fundo animados são animações, padrões ou imagens semelhantes com recursos de entrada limitados que aparecem como um plano de fundo, atrás de outros aplicativos.

O hardware é considerado capaz de executar papéis de parede animados de forma confiável se for capaz de executar todos os papéis de parede animados, sem limitações de funcionalidade, a uma taxa de quadros razoável sem efeitos adversos em outros aplicativos. Se limitações no hardware causarem falhas em planos de fundo e/ou aplicativos, funcionamento incorreto, consumo excessivo de bateria ou CPU ou execução com taxas de frames inaceitáveis, o hardware será considerado incapaz de executar o plano de fundo em tempo real. Por exemplo, alguns planos de fundo animados podem usar um contexto do Open GL 1.0 ou 2.0 para renderizar o conteúdo. O papel de parede animado não será executado de forma confiável em hardwares que não oferecem 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. Implementações de dispositivos determinadas a não executar planos de fundo interativos de forma confiável, conforme descrito acima, NÃO PODEM implementar planos de fundo interativos.

3.8.7. Exibição de apps recentes

O código-fonte upstream do Android 4.0 inclui uma interface do usuário para mostrar os apps recentes usando uma miniatura do estado gráfico do app no momento em que o usuário saiu dele. As implementações do dispositivo PODEM alterar ou eliminar essa interface do usuário. No entanto, uma versão futura do Android está planejada para fazer uso mais amplo dessa funcionalidade. As implementações de dispositivos são fortemente incentivadas a usar a interface do usuário do Android 4.0 upstream (ou uma interface semelhante baseada em miniaturas) para aplicativos recentes. Caso contrário, elas podem não ser compatíveis com uma versão futura do Android.

3.8.8. Configurações de gerenciamento de entrada

O Android 4.0 inclui suporte para mecanismos de gerenciamento de entrada. As APIs do Android 4.0 permitem que IMEs de apps personalizados especifiquem configurações que podem ser ajustadas pelo usuário. As implementações do dispositivo precisam incluir uma maneira de o usuário acessar as configurações do IME sempre que um IME que fornece essas configurações for mostrado.

3.9 Administração de dispositivos

O Android 4.0 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 Administration de dispositivos Android [Resources, 27]. As implementações de dispositivo precisam fornecer uma implementação da classe DevicePolicyManager [Resources, 28] e precisam oferecer suporte a toda a gama de políticas de administração de dispositivos definidas na documentação do SDK do Android [Resources, 27].

Se as implementações de dispositivos não oferecerem suporte a todas as políticas de administração de dispositivos, elas NÃO PODEM permitir que os aplicativos de administração de dispositivos sejam ativados. Especificamente, se um dispositivo não oferecer suporte a todas as políticas de administração de dispositivos, a implementação do dispositivo PRECISA responder à intent android.app.admin.DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN, mas PRECISA mostrar uma mensagem notificando o usuário de que o dispositivo não oferece suporte à administração de dispositivos.

3.10 Acessibilidade

O Android 4.0 oferece uma camada de acessibilidade que ajuda usuários com deficiência a navegar pelos dispositivos com mais facilidade. Além disso, o Android 4.0 oferece APIs da plataforma que permitem que as implementações de serviços de acessibilidade recebam callbacks para eventos do usuário e do sistema e gerem mecanismos de feedback alternativos, como texto para fala, feedback tátil e navegação por trackball/d-pad [Resources, 29]. 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. Especificamente, as implementações de dispositivos precisam atender aos seguintes requisitos.

As implementações de dispositivos precisam oferecer suporte a implementações de serviços de acessibilidade de terceiros pelas APIs android.accessibilityservice [Resources, 30].
As implementações de dispositivos precisam gerar AccessibilityEvents e transmitir esses eventos para todas as implementações de AccessibilityService registradas de maneira consistente com a implementação padrão do Android.
As implementações de dispositivo precisam fornecer um mecanismo acessível ao usuário para ativar e desativar os serviços de acessibilidade e mostrar essa interface em resposta à intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

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

3.11 Conversão de texto em voz

O Android 4.0 inclui APIs que permitem que os aplicativos usem serviços de conversão de texto em voz (TTS) e que os provedores de serviços forneçam implementações de serviços de TTS [Resources, 32]. As implementações de dispositivos PRECISAM atender a estes requisitos relacionados ao framework Android TTS:

As implementações de dispositivos precisam oferecer suporte às APIs do framework TTS do Android e incluir um mecanismo TTS que ofereça suporte aos idiomas disponíveis no dispositivo. O software de código aberto upstream do Android inclui uma implementação de mecanismo de TTS com recursos completos.
As implementações de dispositivos precisam oferecer suporte à instalação de mecanismos de TTS de terceiros.
As implementações de dispositivos precisam fornecer uma interface acessível ao usuário que permita que os usuários selecionem um mecanismo de TTS para uso no nível do sistema.

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, 33].

As implementações de dispositivos NÃO PODEM estender o .apk [Resources, 34], o manifesto do Android [Resources, 35], o bytecode do Dalvik [Resources, 17] ou os formatos de bytecode do renderscript de modo a impedir a instalação e a execução correta desses arquivos em outros dispositivos compatíveis. Os implementadores de dispositivos precisam usar a implementação upstream de referência do Dalvik e o sistema de gerenciamento de pacotes da implementação de referência.

5. Compatibilidade com multimídia

As implementações de dispositivos precisam incluir pelo menos uma forma de saída de áudio, como alto-falantes, conector de fone de ouvido, conexão de alto-falante externo etc.

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, 58], exceto quando expressamente 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 preferida do Android do Android Open Source Project.

Nem o Google nem a Open Handset Alliance fazem qualquer representação de que esses codecs não estão sujeitos a patentes de terceiros. Aqueles que pretendem usar esse código-fonte em produtos de hardware ou software devem saber que as implementações desse código, incluindo em software de código aberto ou shareware, podem exigir licenças de patente dos detentores de patente relevantes.

Essas tabelas não listam requisitos específicos de taxa de bits para a maioria dos codecs de vídeo porque o hardware do dispositivo atual não oferece suporte a taxas de bits que mapeiam exatamente as taxas de bits necessárias especificadas pelos padrões relevantes. Em vez disso, as implementações de dispositivos precisam oferecer suporte ao bitrate mais alto possível no hardware, até os limites definidos pelas especificações.

Tipo	Formato/Codec	Codificador	Decodificador	Detalhes	Tipos de arquivo/Formatos de contêiner
Áudio	AAC LC/LTP	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de microfone e definem `android.hardware.microphone`.	REQUIRED	Conteúdo mono/estéreo em qualquer combinação de taxas de bits padrão de até 160 kbps e taxas de amostragem de 8 a 48 kHz	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC bruto ADTS (.aac, decodificado no Android 3.1+, codificado no Android 4.0+, sem suporte a ADIF) MPEG-TS (.ts, não pesquisável, Android 3.0+)
	HE-AACv1 (AAC+)		REQUIRED
	HE-AACv2 (AAC+ aprimorado)		REQUIRED
	AMR-NB	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de microfone e definem `android.hardware.microphone`.	REQUIRED	4,75 a 12,2 kbps com amostragem a 8 kHz.	3GPP (.3gp)
	AMR-WB	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de microfone e definem `android.hardware.microphone`.	REQUIRED	9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz.	3GPP (.3gp)
	FLAC		OBRIGATÓRIO (Android 3.1+)	Mono/estéreo (sem multicanal). Taxas de amostragem de até 48 kHz (mas o valor de até 44,1 kHz é recomendado em dispositivos com saída de 44,1 kHz, já que o redutor de 48 para 44,1 kHz não inclui um filtro passa baixa). Recomendação de 16 bits; sem pontilhamento aplicado para 24 bits.	Somente FLAC (.flac)
	MP3		REQUIRED	Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8-320 kbps.	MP3 (.mp3)
	MIDI		REQUIRED	MIDI tipos 0 e 1. DLS versões 1 e 2. XMF e XMF para celular. Compatível com os formatos de toque RTTTL/RTX, OTA e iMelody.	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbis		REQUIRED		Ogg (.ogg) Matroska (.mkv)
	PCM/WAVE		REQUIRED	PCM linear de 8 e 16 bits (taxas até o limite do hardware)	WAVE (.wav)
Imagem	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)
Vídeo	H.263	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de câmera e definem `android.hardware.camera` ou `android.hardware.camera.front`.	REQUIRED		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de câmera e definem `android.hardware.camera` ou `android.hardware.camera.front`.	REQUIRED	Perfil de referência (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, AAC exclusivo de áudio, não pesquisável, Android 3.0+)
	MPEG-4 SP		REQUIRED		3GPP (.3gp)
	VP8		OBRIGATÓRIO (Android 2.3.3+)		WebM (.webm) e Matroska (.mkv, Android 4.0+)

5.2 Codificação de vídeo

Implementações de dispositivos Android que incluem uma câmera traseira e declaram android.hardware.camera precisam oferecer suporte aos seguintes perfis de codificação de vídeo.

	SD (baixa qualidade)	SD (alta qualidade)	Alta definição (quando compatível com o hardware)
Codificação de vídeo	Perfil básico H.264	Perfil básico H.264	Perfil básico H.264
Resolução do vídeo	176 x 144 px	480 x 360 px	1.280 x 720 px
Frame rate do vídeo	12 fps	30 fps	30 fps
Taxa de bits do vídeo	56 Kbps	500 Kbps ou mais	2 Mbps ou mais
Codec de áudio	AAC-LC	AAC-LC	AAC-LC
Canais de áudio	1 (mono)	2 (estéreo)	2 (estéreo)
Taxa de bits do áudio	24 Kbps	128 Kbps	192 Kbps

5.3. Gravação em áudio

Quando um aplicativo usa a API android.media.AudioRecord para iniciar a gravação de um stream de áudio, as implementações de dispositivo que incluem hardware de microfone e declaram android.hardware.microphone PRECISAM amostrar e gravar áudio com cada um desses comportamentos:

O dispositivo DEVE apresentar uma amplitude aproximadamente plana em relação às características de frequência, especificamente ±3 dB, de 100 Hz a 4.000 Hz.
A sensibilidade 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 DEVE ser menor que 1% de 100 Hz a 4.000 Hz em nível de entrada de 90 dB SPL.

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 processamento de redução de ruído, se presente, PRECISA ser desativado.
O controle de ganho automático, se presente, PRECISA ser desativado.

Observação:embora alguns dos requisitos descritos acima sejam indicados como "SHOULD" para o Android 4.0, a definição de compatibilidade para uma versão futura está planejada para mudar para "MUST". Ou seja, esses requisitos são opcionais no Android 4.0, mas serão obrigatórios em uma versão futura. É altamente recomendável que os dispositivos novos e atuais que executam o Android 4.0 atendam a esses requisitos no Android 4.0, 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. Latência de áudio

A latência do áudio é definida de forma ampla como o intervalo entre o momento em que um aplicativo solicita uma operação de gravação ou reprodução de áudio e o momento em que a implementação do dispositivo realmente inicia a operação. Muitas classes de aplicativos dependem de latências curtas para conseguir efeitos em tempo real, como efeitos sonoros ou comunicação VOIP. Implementações de dispositivos que incluem hardware de microfone e declaram android.hardware.microphone precisam atender a todos os requisitos de latência de áudio descritos nesta seção. Consulte a Seção 7 para saber mais sobre as condições em que o hardware do microfone pode ser omitido pelas implementações do dispositivo.

Para os fins desta seção:

A "latência de saída fria" é definida como o intervalo entre o momento em que um aplicativo solicita a reprodução de áudio e o momento em que o som começa a ser reproduzido, quando o sistema de áudio estava inativo e desligado antes da solicitação.
A "latência de saída quente" é definida como o intervalo entre o momento em que um aplicativo solicita a reprodução de áudio e quando o som começa a ser reproduzido, quando o sistema de áudio foi usado recentemente, mas está ocioso (ou seja, silencioso).
A "latência de saída contínua" é definida como o intervalo entre o momento em que um aplicativo emite uma amostra para ser reproduzida e o momento em que o alto-falante reproduz fisicamente o som correspondente, enquanto o dispositivo está reproduzindo áudio.
A "latência de entrada fria" é definida como o intervalo entre o momento em que um aplicativo solicita a gravação de áudio e o momento em que a primeira amostra é entregue ao aplicativo pelo callback, quando o sistema de áudio e o microfone estão inativos e desligados antes da solicitação.
A "latência de entrada contínua" é definida como o momento em que um som ambiente ocorre e quando a amostra correspondente a esse som é enviada a um aplicativo de gravação pelo callback, enquanto o dispositivo está no modo de gravação.

Usando as definições acima, as implementações de dispositivos devem mostrar cada uma destas propriedades:

latência de saída a frio de 100 milissegundos ou menos
latência de saída quente de 10 milissegundos ou menos
latência de saída contínua de 45 milissegundos ou menos
latência de entrada fria de 100 milissegundos ou menos
latência de entrada contínua de 50 milissegundos ou menos

Observação:embora os requisitos descritos acima sejam indicados como "SHOULD" para o Android 4.0, a definição de compatibilidade para uma versão futura está planejada para mudar para "MUST". Ou seja, esses requisitos são opcionais no Android 4.0, mas serão obrigatórios em uma versão futura. É altamente recomendável que os dispositivos novos e atuais que executam o Android 4.0 atendam a esses requisitos no Android 4.0, caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

Se uma implementação de dispositivo atender aos requisitos desta seção, ela PODE informar suporte para áudio de baixa latência, informando o recurso "android.hardware.audio.low-latency" pela classe android.content.pm.PackageManager. [Resources, 37] Por outro lado, se a implementação do dispositivo não atender a esses requisitos, ela NÃO PODERÁ informar suporte para áudio de baixa latência.

5.5. 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, 58]. Especificamente, os dispositivos precisam oferecer suporte a estes protocolos de rede de mídia:

RTSP (RTP, SDP)
Streaming progressivo HTTP(S)
HTTP(S) Live Streaming draft protocol, Version 3 [Resources, 59]

6. Compatibilidade de ferramentas para desenvolvedores

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

Android Debug Bridge (conhecida como adb) [Resources, 33]
As implementações de dispositivos PRECISAM oferecer suporte a todas as funções adb, conforme documentado no SDK do Android. O daemon adb do dispositivo PRECISA estar inativo por padrão, e é PRECISO ter um mecanismo acessível ao usuário para ativar a Android Debug Bridge.
Serviço de monitoramento de depuração do Dalvik (conhecido como ddms) [Resources, 33]
As implementações de dispositivos precisam oferecer suporte a todos os recursos ddms, conforme documentado no SDK do Android. Como ddms usa adb, o suporte a ddms PRECISA estar inativo por padrão, mas PRECISA ter suporte sempre que o usuário tiver ativado a ponte de depuração do Android, conforme acima.
Monkey [Resources, 36]
As implementações de dispositivos PRECISAM incluir o framework Monkey e disponibilizá-lo para uso de aplicativos.

A maioria dos sistemas baseados em Linux e os sistemas Apple Macintosh reconhecem dispositivos Android usando as ferramentas padrão do SDK Android, sem suporte adicional. No entanto, os sistemas Microsoft Windows geralmente exigem um driver para novos dispositivos Android. Por exemplo, novos IDs de fornecedor e, às vezes, novos IDs de dispositivo exigem drivers USB personalizados para sistemas Windows. Se uma implementação de dispositivo não for reconhecida pela ferramenta adb conforme fornecida no SDK padrão do Android, os implementadores de dispositivos PRECISAM fornecer drivers do Windows que permitam que os desenvolvedores se conectem ao dispositivo usando o protocolo adb. Esses drivers precisam ser fornecidos para Windows XP, Windows Vista e Windows 7, nas versões de 32 e 64 bits.

7. Compatibilidade de hardware

Se um dispositivo incluir um componente de hardware específico que tenha uma API correspondente para desenvolvedores terceirizados, a implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android. Se uma API no SDK interagir com um componente de hardware declarado como opcional e a implementação do dispositivo não tiver esse componente:

As definições de classe completas (como documentadas pelo SDK) para as APIs do componente PRECISAM estar presentes.
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 corretamente as informações de configuração de hardware usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager. [Resources, 37]

7.1. Tela e gráficos

O Android 4.0 inclui recursos que ajustam automaticamente os recursos do aplicativo e os layouts da interface de forma adequada para o dispositivo, garantindo que os aplicativos de terceiros sejam executados bem em várias configurações de hardware [Resources, 38]. 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.
"dpi" (que significa "pontos por polegada") é 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 relação entre a dimensão mais longa da tela e a mais curta. Por exemplo, uma tela de 480 x 854 pixels seria 854 / 480 = 1,779, ou aproximadamente "16:9".
Um "pixel independente de densidade" ou ("dp") é a unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como: pixels = dps * (density / 160).

7.1.1. Configuração da tela

Tamanho da tela

O framework de interface do Android oferece suporte a vários tamanhos de tela diferentes e permite que os aplicativos consultem o tamanho da tela do dispositivo (também conhecido como "layout da tela") usando android.content.res.Configuration.screenLayout com SCREENLAYOUT_SIZE_MASK. As implementações de dispositivos precisam informar o tamanho da tela correto, conforme definido na documentação do SDK do Android [Resources, 38] e determinado pela plataforma Android upstream. Especificamente, as implementações de dispositivo precisam informar o tamanho correto da tela de acordo com as seguintes dimensões de tela de pixel de densidade independente (dp) lógicas.

Os dispositivos PRECISAM ter tamanhos de tela de pelo menos 426 dp x 320 dp ('pequeno')
Os dispositivos que informam o tamanho da tela como "normal" PRECISAM ter tamanhos de tela de pelo menos 470 dp x 320 dp.
Os dispositivos que informam o tamanho da tela como "grande" PRECISAM ter tamanhos de tela de pelo menos 640 dp x 480 dp.
Os dispositivos que informam o tamanho da tela "extra grande" precisam ter tamanhos de tela de pelo menos 960 dp x 720 dp.

Além disso, os dispositivos PRECISAM ter tamanhos de tela de pelo menos 2,5 polegadas de tamanho físico diagonal.

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

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

Proporção da tela

A proporção PRECISA estar entre 1,3333 (4:3) e 1,85 (16:9).

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 uma das seguintes densidades de framework lógico do Android pelas APIs android.util.DisplayMetrics e PRECISAM executar aplicativos nessa densidade padrão.

120 dpi, conhecido como "ldpi"
160 dpi, conhecido como "mdpi"
213 dpi, conhecido como "tvdpi"
240 dpi, conhecido como "hdpi"
320 dpi, conhecido como "xhdpi"

As implementações de dispositivos DEVEM definir a densidade padrão do framework do Android que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica 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 do 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 exibição definidas em android.util.DisplayMetrics [Resources, 39].

7.1.3. Orientação da tela

Os dispositivos 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 do dispositivo podem selecionar a orientação 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.

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 de orientação paisagem de orientação fixa, como uma televisão ou um laptop, SÓ PODE informar android.hardware.screen.landscape.

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 também precisam oferecer suporte ao RenderScript do Android, conforme detalhado na documentação do SDK do Android [Resources, 8].

As implementações de dispositivo também precisam se identificar corretamente como compatíveis com o OpenGL ES 1.0 e 2.0. Isto é:

As APIs gerenciadas (como pelo método GLES10.getString()) PRECISAM informar suporte para o OpenGL ES 1.0 e 2.0.
As APIs OpenGL C/C++ nativas (ou seja, as 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 2.0.

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 strings de extensão sem suporte.

O Android 4.0 inclui suporte para aplicativos que podem especificar 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 4.0 para implementar qualquer formato de compactação de textura específico. No entanto, eles precisam informar com precisão todos os formatos de compactação de textura com suporte pelo método getString() na API OpenGL.

O Android 3.0 introduziu um mecanismo para que os aplicativos declarassem que queriam 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, 9].

No Android 4.0, 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 definindo android:hardwareAccelerated="false" ou desativando a aceleração de hardware diretamente pelas APIs do Android View.

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, 9].

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

7.1.5. Modo de compatibilidade de aplicativos legados

O Android 4.0 especifica um "modo de compatibilidade" em que o framework opera em um modo equivalente ao tamanho de tela "normal" (largura de 320 dp) para o benefício de aplicativos legados não 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 de origem aberto do Android. Ou seja, as implementações de dispositivos NÃO PODEM alterar os gatilhos ou limites em que o modo de compatibilidade é ativado e NÃO PODEM alterar o comportamento do próprio modo de compatibilidade.

7.1.6. Tipos de tela

As telas de implementação do dispositivo são classificadas em dois tipos:

Implementações de exibição de pixel fixo: a tela é um único painel que oferece suporte apenas a largura e altura de um único pixel. Normalmente, a tela é integrada fisicamente ao dispositivo. Exemplos incluem smartphones, tablets etc.
Implementações de tela de pixel variável: a implementação do dispositivo não tem tela integrada e inclui uma porta de saída de vídeo, como VGA ou HDMI para tela, ou tem uma tela integrada que pode mudar as dimensões dos pixels. Exemplos incluem TVs, conversores e assim por diante.

Implementações de dispositivos de pixels fixos

As implementações de dispositivos de pixels fixos PODEM usar telas de qualquer dimensão de pixel, desde que atendam aos requisitos definidos nesta definição de compatibilidade.

As implementações de pixels fixos PODEM incluir uma porta de saída de vídeo para uso com uma tela externa. No entanto, se essa tela for usada para executar apps, o dispositivo PRECISA atender aos seguintes requisitos:

O dispositivo PRECISA informar a mesma configuração de tela e métricas de exibição, conforme detalhado nas Seções 7.1.1 e 7.1.2, como a tela de pixels fixos.
O dispositivo PRECISA informar a mesma densidade lógica que a tela de pixels fixos.
O dispositivo PRECISA informar dimensões de tela iguais ou muito próximas à tela de pixels fixos.

Por exemplo, um tablet de 7 polegadas com resolução de 1024 x 600 pixels é considerado uma implementação de tela mdpi de pixels fixos grande. Se ele tiver uma porta de saída de vídeo que aparece em 720p ou 1080p, a implementação do dispositivo PRECISA dimensionar a saída para que os aplicativos sejam executados apenas em uma janela mdpi grande, independentemente de a tela de pixels fixos ou a porta de saída de vídeo estar em uso.

Implementações de dispositivos de pixel variável

As implementações de dispositivos de pixels variáveis precisam oferecer suporte a 1280 x 720 ou 1920 x 1080 (ou seja, 720p ou 1080p). As implementações de dispositivos com telas de pixels variáveis NÃO podem oferecer suporte a qualquer outra configuração ou modo de tela. Implementações de dispositivos com telas de pixels variáveis PODEM mudar a configuração ou o modo da tela no momento da execução ou da inicialização. Por exemplo, um usuário de uma set-top box pode substituir uma tela de 720p por uma de 1080p, e a implementação do dispositivo pode ser ajustada de acordo com isso.

Além disso, as implementações de dispositivos de pixel variável precisam informar os seguintes buckets de configuração para essas dimensões de pixel:

1280x720 (também conhecido como 720p): tamanho de tela "grande", densidade "tvdpi" (213 dpi)
1920x1080 (também conhecido como 1080p): tamanho de tela "grande", densidade "xhdpi" (320 dpi).

Para maior clareza, as implementações de dispositivos com dimensões variáveis de pixels são restringidas a 720p ou 1080p no Android 4.0 e precisam ser configuradas para informar tamanhos de tela e buckets de densidade, conforme observado acima.

7.1.7. 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. Especificamente:

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 exibição usada PRECISA ter uma proporção de pixels (PAR) entre 0,9 e 1,1. Ou seja, a proporção de pixels PRECISA estar próxima de um quadrado (1,0) com uma tolerância de 10%.

7.2. Dispositivos de entrada

7.2.1. Teclado

Implementações de dispositivos:

É PRECISO incluir suporte para o Input Management Framework, que permite que desenvolvedores de terceiros criem mecanismos de gerenciamento de entrada, como detalhado em http://developer.android.com.
É PRECISO fornecer pelo menos uma implementação de teclado virtual (mesmo que um teclado físico esteja presente)
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, 40], ou seja, QWERTY ou 12 teclas.

Implementações de dispositivos:

PODE omitir uma opção de navegação sem toque (ou seja, pode omitir um trackball, um botão direcional ou uma roda)
É necessário informar o valor correto para android.content.res.Configuration.navigation [Resources, 40].
É 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. O software de código aberto upstream do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação não por toque.

As funções "Início", "Menu" e "Voltar" são essenciais para o paradigma de navegação do Android. As implementações de dispositivos precisam disponibilizar essas funções ao usuário o tempo todo ao executar aplicativos. Essas funções PODEM ser implementadas por meio de botões físicos dedicados (como botões mecânicos ou capacitivos), ou PODEM ser implementadas usando teclas de software, gestos, painel de toque etc. O Android 4.0 oferece suporte a ambas as implementações.

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

As teclas de navegação de implementação do dispositivo PRECISAM usar uma parte distinta da tela, que não está disponível para aplicativos, e PRECISAM NÃO obscurecer ou interferir na parte da tela disponível para aplicativos.
As implementações de dispositivos PRECISAM disponibilizar uma parte da tela para apps que atendam aos requisitos definidos na Seção 7.1.1.
As implementações de dispositivos precisam mostrar as teclas de navegação quando os aplicativos não especificam um modo de interface do sistema ou especificam SYSTEM_UI_FLAG_VISIBLE.
As implementações de dispositivos precisam apresentar as teclas de navegação em um modo "baixo perfil" discreto (por exemplo, escurecido) quando os aplicativos especificam SYSTEM_UI_FLAG_LOW_PROFILE.
As implementações de dispositivo precisam ocultar as teclas de navegação quando os aplicativos especificam SYSTEM_UI_FLAG_HIDE_NAVIGATION.
A implementação do dispositivo PRECISA apresentar uma tecla de menu para os aplicativos quando targetSdkVersion for menor ou igual a 10 e NÃO PRECISA apresentar uma tecla de menu quando targetSdkVersion for maior que 10.

7.2.4. Entrada por tela touchscreen

Implementações de dispositivos:

PRECISA ter um sistema de entrada de ponteiro de algum tipo (semelhante a um mouse ou por toque)
PODE ter uma tela touchscreen de qualquer tipo (como capacitiva ou resistiva)
DEVE oferecer suporte a ponteiros rastreados de forma totalmente independente, se uma tela sensível ao toque oferecer suporte a vários ponteiros
PRECISA informar o valor de android.content.res.Configuration.touchscreen [Resources, 40] correspondente ao tipo de tela touchscreen específica no dispositivo

O Android 4.0 inclui suporte para várias telas, touchpads e dispositivos de entrada falsos. As implementações de dispositivos baseadas em tela touchscreen são associadas a uma tela [Resources, 61], de modo que o usuário tem a impressão de manipular itens diretamente na tela. Como o usuário toca diretamente na tela, o sistema não exige recursos adicionais para indicar os objetos que estão sendo manipulados. Por outro lado, uma interface de toque simulada fornece um sistema de entrada do usuário que se aproxima de um subconjunto de recursos de tela touchscreen. Por exemplo, um mouse ou controle remoto que aciona um cursor na tela se aproxima do toque, mas exige que o usuário primeiro aponte ou foque e depois clique. Vários dispositivos de entrada, como mouse, trackpad, mouse aéreo com giroscópio, ponteiro com giroscópio, joystick e trackpad multitoque, podem oferecer suporte a interações de toque falsas. O Android 4.0 inclui a constante de recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada não touch de alta fidelidade (ou seja, baseado em ponteiro), 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 (single-touch ou melhor) também precisam informar a constante de recurso da plataforma android.hardware.faketouch. As implementações de dispositivos que não incluem uma tela touchscreen (e dependem apenas de um dispositivo de ponteiro) NÃO PODEM informar nenhum recurso de tela touchscreen e APENAS android.hardware.faketouch se atenderem aos requisitos de toque falso na Seção 7.2.5.

7.2.5. Entrada por toque falsa

Implementações de dispositivos que declaram suporte a 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, 60].
É PRECISO informar o evento de toque com o código de ação [Resources, 60] que especifica a mudança de estado que ocorre no ponteiro, indo para down ou up na tela [Resources, 60].
PRECISA oferecer suporte ao ponteiro down e up 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 down, ao ponteiro up, ao ponteiro down e ao ponteiro up 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, 60].
PRECISA oferecer suporte à down do ponteiro em um ponto arbitrário na tela, o movimento do ponteiro para qualquer outro ponto arbitrário na tela, seguido por um up do ponteiro, que permite que os usuários emulem um arrasto de toque
PRECISA oferecer suporte ao ponteiro down e permitir que os usuários movam rapidamente o objeto para uma posição diferente na tela e, em seguida, ao ponteiro up na tela, o que permite que os usuários joguem um objeto na tela

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

7.2.6. 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 precisará implementar a API de gravação de áudio como no-ops, conforme a Seção 7. Por outro lado, as implementações de dispositivos que têm um microfone:

É PRECISO informar a constante do recurso android.hardware.microphone.
DEVEM atender aos requisitos de qualidade de áudio da Seção 5.3.
DEVE atender aos requisitos de latência de áudio na Seção 5.4

7.3. Sensores

O Android 4.0 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. Por exemplo, implementações de dispositivo:

É PRECISO informar com precisão a presença ou ausência de sensores por classe android.content.pm.PackageManager. [Resources, 37]
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.).
É PRECISO informar todas as medições do sensor usando os valores relevantes do sistema internacional de unidades (ou seja, métricas) para cada tipo de sensor, conforme definido na documentação do SDK do Android [Resources, 41].

A lista acima não é abrangente. O comportamento documentado do SDK do Android é considerado oficial.

Alguns tipos de sensores são sintéticos, ou seja, podem ser derivados de dados fornecidos por um ou mais outros sensores. Os 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.

As APIs do Android 4.0 apresentam o conceito de um sensor "de streaming", que retorna dados continuamente, em vez de apenas quando os dados mudam. As implementações de dispositivos precisam fornecer continuamente amostras de dados periódicos para qualquer API indicada pela documentação do SDK do Android 4.0 como um sensor de streaming.

7.3.1. Acelerômetro

As implementações de dispositivos devem incluir um acelerômetro de três eixos. Se uma implementação de dispositivo incluir um acelerômetro de três eixos, ela:

Precisa transmitir eventos a 50 Hz ou mais
PRECISA estar em conformidade com o sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android (consulte [Resources, 41]).
PRECISA ser capaz de medir de queda livre até o dobro da gravidade (2g) ou mais em qualquer vetor tridimensional
PRECISA ter 8 bits de precisão ou mais
Deve ter um desvio padrão não maior que 0,05 m/s^2

7.3.2. Magnetômetro

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

Precisa ser capaz de enviar eventos a 10 Hz ou mais
PRECISA estar em conformidade com o sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android (consulte [Resources, 41]).
Deve ser capaz de amostrar uma variedade de intensidades de campo adequadas para cobrir o campo geomagnético
PRECISA ter 8 bits de precisão ou mais
Deve ter uma variação padrão não superior a 0,5 µT

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 precisam incluir um giroscópio (ou seja, um 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 seja incluído. Se uma implementação de dispositivo incluir um giroscópio, ela:

PRECISA ser compensada por temperatura
É PRECISO medir mudanças de orientação de até 5,5*Pi radianos/segundo (aproximadamente 1.000 graus por segundo)
Precisa transmitir eventos a 100 Hz ou mais
PRECISA ter 12 bits de precisão ou mais
A variância PRECISA ser menor que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar com a taxa de amostragem, mas precisa ser limitada por esse valor. Em outras palavras, se você medir a variação do giroscópio com uma taxa de amostragem de 1 Hz, ela não deve ser maior que 1e-7 rad^2/s^2.
PRECISA ter carimbos de data/hora o mais próximo possível do momento em que o evento de hardware ocorreu. A latência constante precisa ser removida.

7.3.5. Barômetro

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

Precisa ser capaz de enviar eventos a 5 Hz ou mais
PRECISA ter precisão adequada para permitir a estimativa de altitude

7.3.7. Termômetro

As implementações de dispositivos PODEM, mas NÃO DEVEM incluir um termômetro (ou seja, sensor de temperatura). Se uma implementação de dispositivo incluir um termômetro, ele PRECISA medir a temperatura da CPU do dispositivo. Ele NÃO PODE medir nenhuma outra temperatura. Esse tipo de sensor foi descontinuado nas APIs do Android 4.0.

7.3.7. Fotômetro

As implementações de dispositivos PODEM incluir um fotômetro (ou seja, um sensor de luz ambiente).

7.3.8. Sensor de proximidade

As implementações de dispositivos PODEM incluir um sensor de proximidade. Se uma implementação de dispositivo incluir um sensor de proximidade, ele PRECISA 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. Se uma implementação de dispositivo tiver um sensor de proximidade, ela PRECISA ter 1 bit de precisão ou mais.

7.4. Conectividade de dados

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android 4.0 e neste documento, se refere especificamente a hardware relacionado a ligações de voz e envio de mensagens SMS por uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ser comutadas por pacotes, elas são consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade "telefonia" do Android e as APIs 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, independentemente de usar uma rede celular para conectividade de dados.

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

7.4.2. IEEE 802.11 (Wi-Fi)

As implementações de dispositivos Android 4.0 DEVEM incluir suporte a uma ou mais formas de 802.11 (b/g/a/n, etc.) Se uma implementação de dispositivo incluir suporte para 802.11, ela PRECISA implementar a API correspondente do Android.

7.4.3. Bluetooth

As implementações de dispositivos precisam incluir um transceptor Bluetooth. As implementações de dispositivos que incluem um transceptor Bluetooth precisam ativar a API Bluetooth baseada em RFCOMM, conforme descrito na documentação do SDK [Resources, 42]. As implementações de dispositivos precisam implementar os perfis de Bluetooth relevantes, como A2DP, AVRCP, OBEX etc., conforme apropriado para o dispositivo.

O conjunto de testes de compatibilidade inclui casos que abrangem a operação básica da API Bluetooth RFCOMM do Android. No entanto, como o Bluetooth é um protocolo de comunicações entre dispositivos, ele não pode ser totalmente testado por testes de unidade executados em um único dispositivo. Consequentemente, as implementações de dispositivos também precisam passar pelo procedimento de teste de Bluetooth conduzido por humanos descrito no Apêndice A.

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, ela:

É PRECISO informar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature(). [Resources, 37]
PRECISA ser capaz de ler e gravar mensagens NDEF pelos seguintes padrões de NFC:
- PRECISA ser capaz de atuar como leitor/gravador do NFC Forum (conforme definido pela especificação técnica do NFC Forum NFCForum-TS-DigitalProtocol-1.0) pelos seguintes padrões de NFC:
  - NfcA (ISO14443-3A)
  - NfcB (ISO14443-3B)
  - NfcF (JIS 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 de NFC. Embora os padrões NFC abaixo sejam indicados como "SHOULD" para o Android 4.0, a definição de compatibilidade para uma versão futura está planejada para mudar para "MUST". Ou seja, esses padrões são opcionais no Android 4.0, mas serão obrigatórios em versões futuras. É recomendado que os dispositivos atuais e novos que executam o Android 4.0 atendam a esses requisitos no Android 4.0 para que possam fazer upgrade para as versões futuras da plataforma.
- NfcV (ISO 15693)
PRECISA transmitir e receber dados pelos seguintes padrões e protocolos ponto a ponto:
- ISO 18092
- LLCP 1.0 (definido pelo NFC Forum)
- SDP 1.0 (definido pelo Fórum de NFC)
- Protocolo NDEF Push [Resources, 43]
- SNEP 1.0 (definido pelo NFC Forum)
É PRECISO incluir suporte ao Android Beam:
- É PRECISO implementar o servidor padrão do SNEP. Mensagens NDEF válidas recebidas pelo servidor SNEP padrão PRECISAM ser enviadas para aplicativos que usam 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.
- É 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.
- É necessário usar um gesto ou uma confirmação na tela, como "Tocar para transmitir", antes de enviar mensagens P2P NDEF de saída.
- DEVE ativar o Android Beam por padrão
É PRECISO pesquisar todas as tecnologias compatíveis no modo de descoberta NFC.
DEVE estar no modo de descoberta de NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.

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

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

MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 44])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])
NDEF no MIFARE Classic (NXP AN130511 [Resources, 48], AN130411 [Resources, 49]).

O Android 4.0 inclui APIs para esses tipos de MIFARE. Se uma implementação de dispositivo oferecer suporte a MIFARE no papel de leitor/escritor, ela:

PRECISA implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
É PRECISO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). [Resources, 37] 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 do Android correspondentes nem informe o recurso com.nxp.mifare, a menos que ele também implemente o suporte geral ao NFC, conforme descrito nesta seção.

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

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 se elas não incluírem suporte a NFC ou declararem 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 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,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.

7.5.1. Câmera traseira

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

PRECISA ter uma resolução de pelo menos 2 megapixels
DEVE ter o foco automático de hardware ou de software implementado no driver da câmera (transparente para o software do aplicativo)
PODE ter hardware de foco fixo ou EDOF (profundidade de campo estendida)
PODE incluir um flash. Se a câmera incluir um flash, ele NÃO poderá estar aceso enquanto uma instância de android.hardware.Camera.PreviewCallback estiver registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha ativado explicitamente o flash ativando os atributos FLASH_MODE_AUTO ou FLASH_MODE_ON de um objeto Camera.Parameters. Essa restrição não se aplica ao aplicativo 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 uma câmera frontal, ela:

TERÃO que ter uma resolução mínima de VGA (ou seja, 640 x 480 pixels)
NÃO use uma câmera frontal como padrão para a API Camera. Ou seja, a API de câmera no Android 4.0 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 no dispositivo.
PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.
PRECISA refletir horizontalmente (ou seja, espelhar) o stream exibido por um app em uma CameraPreview, conforme mostrado a seguir:

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 girada por uma chamada ao método android.hardware.Camera.setDisplayOrientation() [Resources, 50], 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 fluxo de imagem de visualização da câmera. Se a implementação do dispositivo não oferecer suporte à pós-visualização, esse requisito obviamente não se aplica.
NÃO ESPELHAR as imagens estáticas ou os streams de vídeo capturados finais retornados a callbacks de aplicativos ou comprometidos com o armazenamento de mídia

7.5.3. Comportamento da API Camera

As implementações de dispositivos precisam implementar os seguintes comportamentos para as APIs relacionadas à câmera, para câmeras frontal e traseira:

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 a callbacks de aplicativos.
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() precisam estar no formato de codificação NV21. Ou seja, o NV21 PRECISA ser o padrão.
As implementações de dispositivos precisam oferecer suporte ao formato YV12 (conforme indicado pela constante android.graphics.ImageFormat.YV12) para visualizações de câmera tanto para câmeras frontais quanto traseiras. O decodificador 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.

As implementações de dispositivos PRECISAM implementar a API Camera completa incluída na documentação do SDK do Android 4.0 [Resources, 51], independente de o dispositivo incluir foco automático de hardware ou outros recursos. Por exemplo, câmeras sem foco automático PRECISAM chamar qualquer instância registrada de android.hardware.Camera.AutoFocusCallback, mesmo que isso não tenha relevância para uma câmera sem foco automático. Isso se aplica a câmeras frontais. Por exemplo, embora a maioria das câmeras frontais não ofereça suporte ao foco automático, os callbacks de API ainda precisam ser "falsos", conforme descrito.

As implementações de dispositivos precisam reconhecer e honrar cada nome de parâmetro definido como uma constante na classe android.hardware.Camera.Parameters, se o hardware de destino oferecer suporte ao recurso. Se o hardware do dispositivo não oferecer suporte a um recurso, a API precisará se comportar conforme documentado. Por outro lado, as implementações de dispositivos NÃO PODEM reconhecer ou honrar constantes de string transmitidas ao método android.hardware.Camera.setParameters(), exceto aquelas documentadas como constantes no android.hardware.Camera.Parameters. Ou seja, as implementações de dispositivos precisam oferecer suporte a todos os parâmetros padrão da câmera, se o hardware permitir, e NÃO podem oferecer suporte a tipos personalizados de parâmetros da câmera.

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

As implementações de dispositivos precisam transmitir a intent Camera.ACTION_NEW_VIDEO sempre que um novo vídeo for gravado pela câmera e a entrada da imagem tiver sido adicionada à loja de mídia.

7.5.4. Orientação da câmera

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

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos

As implementações de dispositivos precisam ter pelo menos 340 MB de memória disponível para o kernel e o espaço do usuário. Os 340 MB precisam ser adicionados a qualquer memória dedicada a componentes de hardware, como rádio, vídeo e assim por diante, que não estão sob o controle do kernel.

As implementações de dispositivos precisam ter pelo menos 350 MB de armazenamento não volátil disponível para dados particulares do aplicativo. Ou seja, a partição /data PRECISA ter pelo menos 350 MB.

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

7.6.2. Armazenamento compartilhado do aplicativo

As implementações de dispositivos precisam oferecer armazenamento compartilhado para aplicativos. O armazenamento compartilhado fornecido PRECISA ter pelo menos 1 GB.

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 precisam aplicar a permissão android.permission.WRITE_EXTERNAL_STORAGE conforme documentado neste armazenamento compartilhado. O armazenamento compartilhado PRECISA ser gravável por qualquer aplicativo que receba essa permissão.

As implementações de dispositivos PODEM ter hardware para armazenamento removível acessível ao usuário, como um cartão Secure Digital. Como alternativa, as implementações do dispositivo podem alocar o armazenamento interno (não removível) como armazenamento compartilhado para apps.

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 do dispositivo 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:

A implementação do dispositivo PRECISA ser compatível com o host de MTP de referência do Android, o Android File Transfer [Resources, 57].
A implementação do dispositivo DEVE informar uma classe de dispositivo USB de 0x00.
A implementação do dispositivo 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 o acesso ao conteúdo do armazenamento compartilhado por outros meios, como um sistema de arquivos de rede.

Para ilustrar, considere dois exemplos comuns. Se uma implementação de dispositivo incluir um slot de cartão SD para atender ao requisito de armazenamento compartilhado, um cartão SD com formato FAT de 1 GB ou maior PRECISA ser incluído com o dispositivo vendido aos usuários e PRECISA ser montado por padrão. Como alternativa, se uma implementação de dispositivo usar armazenamento fixo interno para satisfazer esse requisito, 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 for montado em outro lugar).

Implementações de dispositivos que incluem vários caminhos de armazenamento compartilhado (como um slot de cartão SD e armazenamento interno compartilhado) PRECISAM modificar os principais aplicativos, como o Media Scanner e o ContentProvider, para oferecer suporte transparente a arquivos colocados nos dois locais.

7.7. USB

As implementações de dispositivos precisam incluir uma porta de cliente USB e uma porta de host USB.

Se uma implementação de dispositivo incluir uma porta de cliente USB:

A porta PRECISA ser conectável a um host USB com uma porta USB-A padrão
a porta DEVE usar o formato micro USB no dispositivo
Ele PRECISA permitir que um host conectado ao dispositivo acesse o conteúdo do volume de armazenamento compartilhado usando o armazenamento em massa USB ou o protocolo de transferência de mídia.
Ele PRECISA implementar a API e a especificação do acessório aberto do Android conforme documentado na documentação do SDK do Android e PRECISA declarar suporte ao recurso de hardware android.hardware.usb.accessory [Resources, 51]

Se uma implementação de dispositivo incluir uma porta host USB:

Ele PODE usar um formato de porta não padrão, mas, se for o caso, DEVE ser enviado com um ou mais cabos que adaptam a porta ao USB-A padrão
Ele PRECISA implementar a API host USB do Android conforme documentado no SDK do Android e PRECISA declarar suporte ao recurso de hardware android.hardware.usb.host [Resources, 52].

As implementações de dispositivos precisam implementar o Android Debug Bridge. Se uma implementação de dispositivo omitir uma porta de cliente USB, ela PRECISA implementar a ponte de depuração do Android por rede local (como Ethernet ou 802.11).

8. Compatibilidade de performance

As implementações de dispositivos PRECISAM atender às principais métricas de desempenho de um dispositivo compatível com o Android 4.0, definidas na tabela abaixo:

Métrica	Limite de desempenho	Comentários
Tempo de inicialização do aplicativo	Os aplicativos a seguir precisam ser iniciados no prazo especificado. Navegador: menos de 1.300 ms Contatos: menos de 700 ms Configurações: menos de 700 ms	O tempo de inicialização é medido como o tempo total para concluir o carregamento da atividade padrão do aplicativo, incluindo o tempo necessário para iniciar o processo do Linux, carregar o pacote Android na VM Dalvik e chamar onCreate.
Aplicativos simultâneos	Quando vários aplicativos são iniciados, a reabertura de um aplicativo em execução precisa levar menos tempo que o tempo de inicialização original.

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

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, 54].

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 a máquina virtual 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.

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

Os ambientes de execução alternativos NÃO PODEM permitir que os aplicativos usem recursos protegidos por permissões do Android 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 PRECISAM instalar apps pelo PackageManager em sandboxes do Android separados (ou seja, IDs de usuário do Linux etc.).
Os ambientes de execução alternativos PODEM fornecer um único sandbox do Android compartilhado por todos os aplicativos que usam o ambiente de execução alternativo.
Os runtimes alternativos e os aplicativos instalados que usam um runtime alternativo NÃO PODEM reutilizar o sandbox de nenhum outro app instalado no dispositivo, exceto pelos mecanismos padrão do Android de ID do usuário compartilhado e certificado de assinatura.
As runtimes alternativas NÃO PODEM ser iniciadas com, conceder ou receber acesso aos sandboxes correspondentes a outros apps Android.

As runtimes alternativas NÃO PODEM ser iniciadas com, receber ou conceder a outros aplicativos privilégios do superusuário (raiz) ou de qualquer outro ID de usuário.

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

Ao instalar aplicativos, os ambientes de execução alternativos precisam receber o consentimento do usuário para as permissões do Android usadas pelo aplicativo. Ou seja, se um app precisar usar um recurso do dispositivo para o qual exista uma permissão correspondente do Android (como câmera, GPS etc.), o ambiente de execução alternativo PRECISA informar ao usuário que o app poderá acessar esse recurso. Se o ambiente de execução não registrar os recursos do aplicativo dessa maneira, ele PRECISA listar todas as permissões mantidas pelo próprio ambiente de execução ao instalar qualquer aplicativo usando esse ambiente.

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, recomendamos que os implementadores de dispositivos façam o menor número possível de mudanças na implementação de referência e preferencial do Android 4.0 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, 2] 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 de código-fonte aberta do Android o máximo possível e PRECISAM garantir a compatibilidade em casos de ambiguidade no CTS e para qualquer nova implementação de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. A versão do CTS será independente dessa definição de compatibilidade, e várias revisões do CTS poderão ser lançadas para o Android 4.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 é concluído.

10.2. Verificador do CTS

As implementações de dispositivos precisam executar corretamente todos os casos aplicáveis no CTS Verifier. O Verificador do CTS está incluído no conjunto de testes de compatibilidade e é destinado a ser executado por um operador humano para testar a funcionalidade que não pode ser testada 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 sensor de aceleração, ele precisa executar corretamente o caso de teste do sensor de aceleração no CTS Verifier. 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 esperamos 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.

10.3. Aplicativos de referência

Os implementadores de dispositivos precisam testar a compatibilidade da implementação usando os seguintes aplicativos de código aberto:

Os aplicativos "Apps for Android" [Resources, 55].
Replica Island (disponível no Android Market)

Cada app acima PRECISA ser iniciado e se comportar corretamente na implementação para que ela seja considerada compatível.

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, uma reinicialização do dispositivo PODE ser necessária.

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

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

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 particulares e compartilhados do aplicativo. O software upstream do Android inclui um mecanismo de atualização que atende a esse requisito.

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

12. Entre em contato

Entre em contato com os autores do documento em compatibility@android.com para esclarecimentos e para informar problemas que você acha que o documento não abrange.

Apêndice A: procedimento de teste de Bluetooth

O procedimento de teste é baseado no app de exemplo BluetoothChat incluído na árvore de projetos de código aberto do Android. O procedimento requer dois dispositivos:

uma implementação de dispositivo candidata que executa o build de software a ser testado
uma implementação de dispositivo separada que já é conhecida por ser compatível e de um modelo da implementação de dispositivo que está sendo testada, ou seja, uma implementação de dispositivo "conhecida"

O procedimento de teste abaixo se refere a esses dispositivos como "candidato" e "bom conhecido", respectivamente.

Configuração e instalação

Crie BluetoothChat.apk usando "make samples" em uma árvore de código-fonte do Android.
Instale o BluetoothChat.apk no dispositivo conhecido por ser bom.
Instale o BluetoothChat.apk no dispositivo candidato.

Testar o controle Bluetooth por apps

Inicie o BluetoothChat no dispositivo candidato com o Bluetooth desativado.
Verifique se o dispositivo candidato ativa o Bluetooth ou solicita que o usuário abra uma caixa de diálogo para ativá-lo.

Testar o pareamento e a comunicação

Abra o app Chat por Bluetooth nos dois dispositivos.
Torne o dispositivo conhecido por BluetoothChat detectável (usando o Menu).
No dispositivo candidato, procure dispositivos Bluetooth no BluetoothChat (usando o Menu) e faça o pareamento com o dispositivo conhecido.
Envie 10 ou mais mensagens de cada dispositivo e verifique se o outro dispositivo as recebe corretamente.
Feche o app BluetoothChat nos dois dispositivos pressionando Home.
Desemparelhe cada dispositivo do outro usando o app Configurações.

Testar o pareamento e a comunicação na direção inversa

Abra o app Chat por Bluetooth nos dois dispositivos.
Torne o dispositivo candidato detectável no BluetoothChat (usando o Menu).
No dispositivo conhecido, procure dispositivos Bluetooth no BluetoothChat (usando o Menu) e faça o pareamento com o dispositivo candidato.
Envie 10 mensagens de cada dispositivo e verifique se o outro dispositivo as recebe corretamente.
Feche o app Chat por Bluetooth nos dois dispositivos pressionando "Voltar" várias vezes para acessar a tela de início.

Testar re-lançamentos

Reinicie o app Chat por Bluetooth nos dois dispositivos.
Envie 10 mensagens de cada dispositivo e verifique se o outro dispositivo as recebe corretamente.

Observação: os testes acima têm alguns casos que encerram uma seção de teste usando "Início" e outros usando "Voltar". Esses testes não são redundantes nem opcionais: o objetivo é verificar se a API e a pilha do Bluetooth funcionam corretamente quando as atividades são encerradas explicitamente (quando o usuário pressiona "Voltar", que chama finish()) e enviadas implicitamente para o segundo plano (quando o usuário pressiona "Home"). Cada sequência de teste PRECISA ser realizada conforme descrito.

Documento de definição de compatibilidade do Android 4.0 Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Índice

1. Introdução

2. Recursos

3. Software

3.1. Compatibilidade com a API gerenciada

3.2. Compatibilidade de API flexível

3.2.1. Permissões

3.2.2. Parâmetros do build

3.2.3. Compatibilidade de intents

3.2.3.1. Intents principais do aplicativo

3.2.3.2. Substituições de intent

3.2.3.3. Namespaces de intent

3.2.3.4. Intents de transmissão

3.3. Compatibilidade com a API nativa

3.3.1 Interfaces binárias do aplicativo

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView

3.4.2. Compatibilidade de navegadores

3.5. Compatibilidade comportamental da API

3.6. Namespaces de API

3.7. Compatibilidade com máquinas virtuais

3.8. Compatibilidade da interface do usuário

3.8.1. Widgets

3.8.2. Notificações

3.8.3. Pesquisar

3.8.4. Avisos

3.8.5. Temas

3.8.6. Planos fundo interativos

3.8.7. Exibição de apps recentes

3.8.8. Configurações de gerenciamento de entrada

3.9 Administração de dispositivos

3.10 Acessibilidade

3.11 Conversão de texto em voz

4. Compatibilidade de empacotamento de apps

5. Compatibilidade com multimídia

5.1. Codecs de mídia

5.2 Codificação de vídeo

5.3. Gravação em áudio

5.4. Latência de áudio

5.5. Protocolos de rede

6. Compatibilidade de ferramentas para desenvolvedores

7. Compatibilidade de hardware

7.1. Tela e gráficos

7.1.1. Configuração da tela

7.1.2. Métricas de tela

7.1.3. Orientação da tela

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

7.1.5. Modo de compatibilidade de aplicativos legados

7.1.6. Tipos de tela

7.1.7. Tecnologia da tela

7.2. Dispositivos de entrada

7.2.1. Teclado

7.2.2. Navegação sem toque

7.2.3. Teclas de navegação

7.2.4. Entrada por tela touchscreen

7.2.5. Entrada por toque falsa

7.2.6. Microfone

7.3. Sensores

7.3.1. Acelerômetro

7.3.2. Magnetômetro

7.3.3. GPS

7.3.4. Giroscópio

7.3.5. Barômetro

7.3.7. Termômetro

7.3.7. Fotômetro

7.3.8. Sensor de proximidade

7.4. Conectividade de dados

7.4.1. Telefonia

7.4.2. IEEE 802.11 (Wi-Fi)

7.4.3. Bluetooth

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

7.4.5. Capacidade mínima de rede

7,5. Cameras

7.5.1. Câmera traseira

7.5.2. Câmera frontal

7.5.3. Comportamento da API Camera

7.5.4. Orientação da câmera

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos

Documento de definição de compatibilidade do Android 4.0
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.